Analytics Platform Mediation 

Installation and Configuration Guide for CSP Solutions

March 22, 2016

Contents
1	Overview	6
1.1	Intended Audience	6
1.2	Related Documents	7
1.3	Glossary	7
2	Executive Summary	8
3	Introduction	9
4	Installation Guide	10
4.1	Prerequisites	10
4.1.1	Key sharing with master server	10
4.2	RPM installation	11
4.2.1	Building Prerequisites	11
4.2.2	Building DBLoader	12
4.2.3	Building LookupManager	13
4.2.4	Building ITE	13
4.2.5	Building RawTDR	14
4.2.6	Listing and removing packages	15
4.3	Vedia Supercollector	15
4.3.1	Installation	15
4.3.2	Host configuration	16
4.3.3	Parameters configuration	17
4.3.3.1	SourceWorks probes	17
4.3.3.2	Output directory	17
4.3.3.3	Voice/SMS parameters	18
4.3.3.4	Voice/SMS Interface Adaptor installation	19
4.3.3.5	Streams targets	19
4.3.4	Start / stop	20
4.3.5	Cleanup	20
4.3.5.1	Logs cleanup	20
4.3.5.2	Storage cleanup	21
4.4	Streams domain and instance configuration	21
4.4.1	Zookeeper setup	21
4.4.1.1	Embedded Zookeeper	21
4.4.1.2	External Zookeeper	22
4.4.2	Streams main domain	22
4.4.3	Streams instances per blade per interface	23
4.4.4	Sizing considerations	23
4.5	Customization	24
4.5.1	Compile-time parameters	24
4.5.1.1	DBLoader	24
4.5.1.2	LookupManager	25
4.5.1.3	ITE	25
4.5.1.4	RawTDR	27
4.5.2	Probes	27
4.5.2.1	probes.csv	27
4.5.2.2	probes-tdr.csv	28
4.5.3	Constants	29
4.5.3.1	consts_gn.ini, consts_lte.ini	29
4.5.3.2	consts_voice.ini	30
4.5.3.3	consts_ran.ini	30
4.5.3.4	consts_fixedline.ini	31
4.5.3.5	rawtdr_*.ini	32
4.5.4	loader_*.ini	32
4.5.4.1	Configuring sudoers	33
4.5.5	Provisioning Files	34
4.5.5.1	cells.csv	34
4.5.5.2	mcc_mnc.csv	34
4.5.5.3	bnumber.csv	34
4.5.5.4	status.csv	35
4.5.5.5	gn_qoscategory.csv	35
4.5.5.6	lte_qoscategory.csv	35
4.5.5.7	fixedline_qos.csv	35
4.5.5.8	sgsn.csv	36
4.5.5.9	ggsn.csv	36
4.5.5.10	sgw.csv	36
4.5.5.11	bsc.csv	36
4.5.5.12	rnc.csv	36
4.5.5.13	mme.csv	37
4.5.5.14	bts.csv	37
4.5.5.15	nodeb.csv	37
4.5.5.16	enodeb.csv	37
4.5.5.17	applications.csv	38
4.5.5.18	sip_status_codes.csv	38
4.5.5.19	csid.csv	38
4.5.5.20	tier0.csv	38
4.5.5.21	tier1.csv	38
4.5.5.22	fixedline_transaction_type.csv	39
4.5.5.23	fixedline_transaction_status.csv	39
4.5.6	Provisioning Update Configuration	39
4.5.6.1	Provisioning configuration in cna.sh	39
4.5.6.2	Provisioning.cfg	40
5	Administration Guide	41
5.1	Starting the applications	41
5.2	Stopping the applications	41
5.3	Checking the application status	41
5.4	Cleaning temporary files	41
5.5	Provisioning updates	41
5.5.1	Provisioning auto-updates	41
5.5.2	Manual provisioning auto update	42
5.6	Consulting log files	42
5.6.1	Collection	42
5.6.2	Lookup	43
5.6.3	Aggregation	43
5.6.4	Database	43
5.6.5	Performance	44
5.6.6	Streams logs	44
5.7	Recovery mechanisms	44

1	Overview

This document provides information regarding installation, deployment, configuration and maintenance of the mediation layer of the Analytics Platform 2.0 system.
The business logic of Analytics Platform 2.0 is the same as Analytics Platform 1.0; the only difference is that the mediation is Streams-based instead of Vedia-based.
The mediation solutions includes the following components:
•	Super collector (Vedia-based)
•	Lookup Manager (Streams-based)
•	ITE Application to produce 5 minute aggregations (Streams-based)
•	Raw TDR processing Application (Streams-based)
•	DB Loader Application (Streams-based)
Please note that this document will not cover the installation of the Streams platform, which is a prerequisite for the application deployment.
Please also note that the Hadoop installation and Hadoop-based aggregation is out of scope of this document.

1.1	Intended Audience

This document is intended for those installing the mediation and analytics platform components and  describes the steps needed to install and deploy the following Analytics Platform 2.0 interfaces:
•	Gn
•	LTE S1U / S11
•	Voice & SMS
•	RAN
•	VoLTE
•	Fixed Line
It also describes how to install and configure all mediation components described in the Executive section above.
1.2	Related Documents
Document 	Description	
Streams 4.0.1 Documentation	Available on http://www-01.ibm.com/support/knowledgecenter/SSCRJU_4.0.1/com.ibm.streams.welcome.doc/doc/kc-homepage.html?lang=en	

1.3	Glossary
Acronyms and abbreviations used in this document are described in the table below.
Abbreviation	Description	
CI	Cell Identifier	
DB	Database	
ECI	E-UTRAN Cell Identifier	
GGSN	Gateway GPRS Support Node	
IMEI	International Mobile Equipment Identity	
IMSI	International Mobile Subscriber Identity	
LAC	Location Area Code	
LTE	Long Term Evolution	
MCC	Mobile Country Code	
MNC	Mobile Network Code	
MSISDN	Mobile Station International Subscriber Directory Number	
RPM	RedHat Package Manager	
SGSN	Serving GPRS Support Node	
Streams	IBM InfoSphere Streams 4.0.1	
TAC	Track Area Code	
TDR	Telecommunications Data Record	

2	Executive Summary
This document provides information regarding installation, deployment, configuration and maintenance of the mediation layer of the Analytics Solutions for CSps.
The mediation solutions includes the following components:
•	Super collector (Vedia-based)
•	Lookup Manager (Streams-based)
•	ITE Application to produce 5 minute aggregations (Streams-based)
•	Raw TDR processing Application (Streams-based)
•	DB Loader Application (Streams-based)
Please note that this document will not cover the installation of the Streams platform, which is a prerequisite for the application deployment.
Please also note that the Hadoop installation and Hadoop-based aggregation is out of scope of this document.

3	Introduction
This document describes steps needed to install and deploy the following interfaces:
•	Gn
•	LTE S1U / S11
•	Voice & SMS
•	Voice over LTE (VoLTE)
•	Fixed Line
•	Radio Access Network (RAN)
It also describes how to install and configure all mediation components described in the Executive section above.
4	Installation Guide
This section describes how to install the mediation layer of  the solutions.
The system is composed of the following Streams applications:
•	ITE – Aggregates TDRs over 5 minutes. Several builds of the same application are provided, one for every supported interface.
•	RawTDR – Prepares raw TDRs for loading into the DB. Several builds of the same application are provided, one for every supported interface.
•	LookupManager – The controlling process for all ITE jobs, which provides access to shared provisioning data (Home and Visited MCC/MNC, Cells)
•	DBLoader – Loads aggregated records and raw TDRs to the DB
It is possible to install one or more interfaces in the same blade if needed.
4.1	Prerequisites
This installation assumes that:
•	You have done a sizing assessment (per interface) in terms of traffic throughput (Gbit/s), number of cells and locations and number of unique daily subscribers for each of the SourceWorks probes
•	IBM InfoSphere Streams 4.0.1 is installed
•	There is a biadmin user belonging to a biadmin group, and this user can run Streams commands
•	The ulimit settings for the user are compatible with Streams (see http://www-01.ibm.com/support/knowledgecenter/SSCRJU_4.0.1/com.ibm.streams.install.doc/doc/ibminfospherestreams-install-operating-system-settings.html?lang=en)
•	BigInsights and its dependencies (Hadoop and the Data Loader) are correctly installed as per the Installation-And-Configuration-Guide.pdf located in the Analytics Platform release.
•	Network attached storage is set up and attached to all blades where both Streams and Vedia Supercollector are to be deployed. The shared storage has r/w permissions for the biadmin user. The disk capacity needs to be sufficient to contain at least an hour worth of gzipped feed from all SourceWorks probes.
4.1.1	Key sharing with master server
In order to allow the provisioning autoupdate feature within the cna.sh script to check the provisioning files on the remote server via ssh/scp, it is required to share the Mediation box public key with the central server. This has to be done for each Mediation blade. The following demonstrates the commands that need to be invoked on Mediation blades to generate and share their public keys. The master server in this example is 9.162.178.179, replace it with the actual server IP address or hostname.
# Generate a pair of authentication keys. Do not enter a passphrase
[streamsadmin@streamsqse ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/streamsadmin/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/streamsadmin/.ssh/id_rsa.
Your public key has been saved in /home/streamsadmin/.ssh/id_rsa.pub.
# Create a directory ~/.ssh for tnf user if it doesn't exist already
[streamsadmin@streamsqse ~]$ ssh tnf@9.162.178.179 mkdir -p .ssh
tnf@9.162.178.179's password:
# Append the new public key to tnf's authorized_keys
[streamsadmin@streamsqse ~]$ cat .ssh/id_rsa.pub | ssh tnf@9.162.178.179 'cat >> .ssh/authorized_keys'
tnf@9.162.178.179's password:
# You should now be able to login without the password:
[streamsadmin@streamsqse ~]$ ssh tnf@9.162.178.179
Last login: Tue Nov 10 09:21:38 2015 from icon-9-164-161-9.megacenter.de.ibm.com
[tnf@tnfvmbig3 ~]$
4.2	RPM installation
The installation of mediation components is performed through RedHat's RPM system.

file_loader-1.1.0.0.0-20151201.212905-107.rpm
interface-adapter-8.2.0.1.2.rpm
ite_fixedline-9.0.0.0.0.compile.ini
ite_fixedline-9.0.0.0.0.compile.rpm
ite_gn-9.0.0.0.0.compile.ini
ite_gn-9.0.0.0.0.compile.rpm
ite_lte-9.0.0.0.0.compile.ini
ite_lte-9.0.0.0.0.compile.rpm
ite_ran-9.0.0.0.0.compile.ini
ite_ran-9.0.0.0.0.compile.rpm
ite_voice-9.0.0.0.0.compile.ini
ite_voice-9.0.0.0.0.compile.rpm
ite_volte-9.0.0.0.0.compile.ini
ite_volte-9.0.0.0.0.compile.rpm
loader-9.0.0.0.0.compile.ini
loader-9.0.0.0.0.compile.rpm
lookup_manager-9.0.0.0.0.compile.ini
lookup_manager-9.0.0.0.0.compile.rpm
rawtdr_gn-9.0.0.0.0.compile.ini
rawtdr_gn-9.0.0.0.0.compile.rpm
rawtdr_lte-9.0.0.0.0.compile.ini
rawtdr_lte-9.0.0.0.0.compile.rpm
rawtdr_voice-9.0.0.0.0.compile.ini
rawtdr_voice-9.0.0.0.0.compile.rpm

4.2.1	Building Prerequisites
The Streams-based RPMs are self compiling: installing the provided RPM generates a binary RPM which can then be deployed on all the blades. Because of this the blade where this compilation is performed must meet the following additional prerequisites:
•	The packages rpm-build and zlib-devel are installed
•	InfoSphere Streams 4.0.1.0 is sourced in the shell from which the commands are issued
4.2.2	Building DBLoader
The DBLoader RPM is:
../rpm/streams/loader-9.0.0.0.0.compile.rpm
A configuration file is provided to specify additional options; it's named loader-9.0.0.0.0.compile.ini in the same directory as the RPM, as specified in section 4.5.1. The file contains all options commented out, and customised values can be specified by uncommenting and modifying the desired value: one important exception is the Interface option, as leaving it commented will produce a DBLoader that collects from all ITE (aggregation) directories, but not RawTDR. The package can then be built by issuing the following command as root in the same directory as the RPM:
rpm -ivh loader-9.0.0.0.0.compile.rpm --prefix $PWD
The binary RPM will be created as loader-9.0.0.0.0.rpm; if the operation fails, the file will still be present, but unusable, and the package will have to be removed (see later).
The compilation log, named loader_datetime.log (where datetime is 14 digits representing the date and time when the compilation was started) is produced in the same directory as the output RPM, and it contains the selected customisation options. Note that it is not automatically removed, so it should be cleaned manually when no longer relevant.
After a successful completion, the binary RPM will be ready to  be deployed on all blades. To install the binary RPM execute:
rpm -ivh loader-9.0.0.0.0.rpm
After the binary RPM is successfully deployed, the compiling package must be removed from the  blade with: 
rpm -e cna_loader_compile
This operation will remove the generated binary RPM, so it should be backed up somewhere else if it's necessary to preserve it.
In case the DBLoader needs to be compiled for more than one interface (e.g. gn and raw_gn), the steps are as follow:
1.	Configure the desired interface as the value of the Interface parameter in the configuration file loader-9.0.0.0.0.compile.ini
2.	Build the package with
rpm -ivh loader-9.0.0.0.0.compile.rpm --prefix $PWD
3.	Move the output file loader-9.0.0.0.0.rpm to a different name or install it with
rpm -ivh loader-9.0.0.0.0.rpm
4.	Remove the build package with rpm -e cna_loader_compile
5.	Restart at point number 1 for the next interface
If at step #3 it's been chosen to rename the files, the final step would be to deploy the files to the blades where they need to be installed.
4.2.3	Building LookupManager
The LookupManager RPM is:
../streams/lookup_manager-9.0.0.0.0.compile.rpm
A configuration file is provided to specify additional options; it 's named lookup_manager-9.0.0.0.0.compile.ini in the same directory as the RPM, as specified in section 4.5.1. The file contains all options commented out, and customised values can be specified by uncommenting and modifying the desired value. The package can then be built by issuing the following command as root in the same directory as the RPM:
rpm -ivh lookup_manager-9.0.0.0.0.compile.rpm --prefix $PWD
The binary RPM will be created as lookup_manager-9.0.0.0.0.rpm; if the operation fails, the file will still be present, but unusable, and the package will have to be removed (see later).
The compilation log, named lookup_manager_{datetime}.log (where {datetime} is 14 digits representing the date and time when the compilation was started) is produced in the same directory as the output RPM, and it contains the selected customisation options. Note that it is not automatically removed, so it should be cleaned manually when no longer relevant.
After a successful completion, the binary RPM will be ready to  be deployed on all blades. To install the binary RPM execute:
rpm -ivh lookup_manager-9.0.0.0.0.rpm
After the binary RPM is successfully deployed, the compiling package must be removed from the  blade with: 
rpm -e cna_lookup_manager_compile
This operation will remove the generated binary RPM, so it should be backed up somewhere else if it's necessary to preserve it.
4.2.4	Building ITE
The ITE RPMs are (one per interface):
../rpm/streams/ite_gn-9.0.0.0.0.compile.rpm
../rpm/streams/ite_lte-9.0.0.0.0.compile.rpm
../rpm/streams/ite_voice-9.0.0.0.0.compile.rpm
../rpm/streams/ite_volte-9.0.0.0.0.compile.rpm
../rpm/streams/ite_fixedline-9.0.0.0.0.compile.rpm
../rpm/streams/ite_ran-9.0.0.0.0.compile.rpm
A configuration file is provided to specify additional options; it's named ite_interface-9.0.0.0.0.compile.ini (where interface is the ITE interface to build) in the same directory as the RPM, as specified in section 4.5.1. The file contains all options commented out, and customised values can be specified by uncommenting and modifying the desired value. The package can then be built by issuing the following command as root in the same directory as the RPM:
rpm -ivh ite_interface-9.0.0.0.0.compile.rpm --prefix $PWD
The binary RPM will be created as ite_interface-9.0.0.0.0.rpm; if the operation fails, the file will still be present, but unusable, and the package will have to be removed (see later).
The compilation log, named ite_interface_datetime.log (where interface is the compiled interface and datetime is 14 digits representing the date and time when the compilation was started) is produced in the same directory as the output RPM, and it contains the selected customisation options. Note that it is not automatically removed, so it should be cleaned manually when no longer relevant.
After a successful completion, the binary RPM will be ready to  be deployed on all blades. To install the binary RPM execute:
rpm -ivh ite_interface-9.0.0.0.0.rpm
After the binary RPM is successfully deployed, the compiling package must be removed from the  blade with: 
rpm -e cna_ite_interface_compile
This operation will remove the generated binary RPM, so it should be backed up somewhere else if it's necessary to preserve it.
4.2.5	Building RawTDR
The RawTDR RPMs are (one per interface):
../rpm/streams/rawtdr_gn-9.0.0.0.0.compile.rpm
../rpm/streams/rawtdr_lte-9.0.0.0.0.compile.rpm
../rpm/streams/rawtdr_voice-9.0.0.0.0.compile.rpm
A configuration file is provided to specify additional options; it's named rawtdr_interface-9.0.0.0.0.compile.ini (where interface is the ITE interface to build) in the same directory as the RPM, as specified in section 4.5.1. The file contains all options commented out, and customised values can be specified by uncommenting and modifying the desired value. The package can then be built by issuing the following command as root in the same directory as the RPM:
rpm -ivh rawtdr_interface-9.0.0.0.0.compile.rpm --prefix $PWD
The binary RPM will be created as rawtdr_interface-9.0.0.0.0.rpm; if the operation fails, the file will still be present, but unusable, and the package will have to be removed (see later).
The compilation log, named rawtdr_interface_datetime.log (where interface is the compiled interface and datetime is 14 digits representing the date and time when the compilation was started) is produced in the same directory as the output RPM, and it contains the selected customisation options. Note that it is not automatically removed, so it should be cleaned manually when no longer relevant.
After a successful completion, the binary RPM will be ready to  be deployed on all blades. To install the binary RPM execute:
rpm -ivh rawtdr_interface-9.0.0.0.0.rpm
After the binary RPM is successfully deployed, the compiling package must be removed from the  blade with: 
rpm -e cna_rawtdr_interface_compile
This operation will remove the generated binary RPM, so it should be backed up somewhere else if it's necessary to preserve it.
4.2.6	Listing and removing packages
The installed Streams RPMs can be listed with:
rpm -qa | grep cna_ | sort
An example output is:
[streamsadmin@streamsqse ~]$ rpm -qa | grep cna
cna_ite_voice-9.0.0.0.0-r604.x86_64
cna_lm-9.0.0.0.0-r604.x86_64
Note that the release number (604 in the example) is the SVN revision number of the source code.
In order to remove all packages, you can execute the following command as root:
rpm -qa | grep cna_ | xargs rpm -e
For Vedia Supercollector installation please refer to the next section.
4.3	Vedia Supercollector
Streams components have no ability to collect files from a remote host (ftp/sftp). The remote collection is done using a Vedia Supercollector component. It connects to a set of SourceWorks probes and downloads netro or pagebased feed files to the network attached shared storage (see the prerequisites section). The shared storage can be then accessed by all Streams hosts.
This section describes steps necessary to deploy the Vedia Supercollector. Ideally, it has to be deployed into a separate blade or even multiple blades.
4.3.1	Installation
Extract the following file from the archive: 
cna/build/vedia_fileloader/file_loader-1.1.0.0.0.rpm. Then, as user root, perform the RPM installation in each host where you want to deploy Vedia Supercollector using the command:
rpm -ivh file_loader-1.1.0.0.0.rpm
Vedia Supercollector is now installed in /opt/tnf/file_loader/vedia/ as the user biadmin.
4.3.2	Host configuration
Change collectors and probes parameters in /opt/tnf/file_loader/vedia/cfg/VediaMain.xml. This is typically done in one host only and then all configuration files are copied to all hosts where Vedia Supercollector was installed.
First of all define as many Supercollector hosts in the <hosts> section as there are Supercollector blades. One host needs to be the main host.
<hosts>
    <host name="Collector1" address="blade01" main="1"/>
    <host name="Collector2" address="blade02"/>
</hosts>

Then define collection applications using <applications> sections. Each applications tag needs to have the following attribute:
•	probe_type: value can be netro,  lte,  pb,  S1_S6_S13,  SGs, VoiceSMS_A, VoiceSMS_IuCS, VoLTE, RAN, fixedline_netro and fixedline_pb
All collectors in this applications node group will download data from probes with this type of data only.
Then each <applications> tag has to contain one or more <application> tags that define a collector application (process):
  <applications name="CollectorNT" host="Collector" config="Collection" probe_type="netro">
    <application name="CollectionNT1" probe_name="NYCEM101" probe_ip="scw_gn_blade01"/>
    <application name="CollectionNT2" probe_name="DACEM101" probe_ip="scw_gn_blade02"/>
  </applications>

  <applications name="CollectorLTE" host="Collector" config="Collection" probe_type="lte">
    <application name="CollectionLTE1" probe_name="NYCEM103" probe_ip="scw_lte_blade03"/>
  </applications>

Each application needs to have the following attributes and all of them are mandatory:
•	name: unique logical name of this Collector
•	probe_ip: IP address or host name of the SCW probe host
•	probe_name: name of the SCW probe for storing in storage output directory (see section 4.3.3.2 for more details on the output directory structure). The name is arbitrary with two restrictions:
•	It needs to be unique within the whole deployment. The uniqueness also applies for probe names across different interfaces. The only exception is for Voice/SMS interface where there can be the same probe name for types VoiceSMS_A and VoiceSMS_IuCS
•	It needs to match to probe names as defined in Streams in configuration files probes.csv and probes-tdr.csv, see sections 4.5.2.1 and 4.5.2.2.
4.3.3	Parameters configuration
These parameters in /opt/tnf/file_loader/vedia/cfg/consts.xml can be configured:
4.3.3.1	SourceWorks probes
Parameter	Description	
probe_protocol	Remote collection protocol (sftp/ftp)	
probe_user	Username to probe (S)FTP Server	
probe_password	Password to probe (S)FTP Server	
probe_base_disk_dir	Remote directory of netro feed on probe (S)FTP Server	
probe_voicesms_base_dir	Remote directory for Voice/SMS collection	
probe_files_mask	Regular expression matching the file names; must include a timestamp between parentheses in the format below.	
probe_file_date_format	Timestamp format as found in the collected file names.	

By default, the Vedia Supercollector assumes standard feed directories and standard feed file masks in the SCW probe. These are defined in if probe_type="…" sections in consts.xml. If there is a different than standard location or file mask then you can set these different values for individual feed types in the corresponding if probe_type="…" section. In the example bellow different probe directory and file mask is set for the netro feed:
<if probe_type="netro">
  <const name="probe_dir" value="{probe_base_dir}netrofeedbin/" description="Ftp dir"/>
  <const name="probe_files_mask" value="netrobin_([0-9]{14})\.log\.gz" description="Ftp files mask"/>
</if>

4.3.3.2	Output directory
By default the output directory for all downloaded files is set to /opt/tnf/file_loader/vedia/storage/, but it can be changed:
Parameter	Description	
output_base_dir	Directory where downloaded files are stored (storage/). This has to be linked to the file system that is located in a network attached disk	

Files are being downloaded into the following directory hierarchy structure:
{output_base_dir}/{probe_name}|{probe_ip}/{probe_type}
E.g:
/opt/tnf/file_loader/vedia/P1/netro/netro_20120425000019.log.gz
4.3.3.3	Voice/SMS parameters
There are two types of Voice/SMS feed: Aif and IuCS. If a Supercollector is configured to collect Voice/SMS feed (using collection applications where probe_type=”VoiceSMS_A” or probe_type=”VoiceSMS_IuCS”), then the following can be configured in consts.xml in sections
<if probe_type="VoiceSMS_A">
   ...
</if>

and
<if probe_type="VoiceSMS_IuCS">
   ...
</if>

Parameter	Description	Default value for Aif / IuCS feed	
probe_dir	Ftp dir for the Voice/SMS Aif / IuCS feed	{probe_voicesms_base_dir}a/	
		{probe_voicesms_base_dir}iucs/	
probe_files_mask	File mask for the Voice/SMS Aif feed	Aif_ASN1_BER_[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}_([0-9]{8}\.[0-9]{4,6})	
		IuCS_ASN1_BER_[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}_([0-9]{8}\.[0-9]{4,6})	
adapted_files_mask	File mask for the adapted Voice/SMS Aif feed.
Note 1: This needs to be different than the probe_files_mask above.
Note 2: It needs to match to the Interface Adaptor output prefix and output options defined in datafeed.xml (see section 4.3.3.4)	Aif_([0-9]{8}\.[0-9]{6})_[0-9]{5}\.csv\.gz	
		IuCS_([0-9]{8}\.[0-9]{6})_[0-9]{5}\.csv\.gz	
probe_file_date_format	File date format for the Voice/SMS Aif / IuCS feed
Note: If call-interface-adaptor=no (see below) then it is assumed that the feed is already adapted. In that case this probe_file_date_format is used for this adapted feed and not the adapted_file_date_format (see below).	yyyyMMdd.HHmmss	
adapted_file_date_format	File date format for the adapted Voice/SMS Aif / IuCS feed	yyyyMMdd.HHmmss	
call-interface-adapter	Flag to enable call to the Voice/SMS feed adaptor (yes/no)	yes	
adapter-executable	Adapter script/executable to use for Voice/SMS feed	run-adapter-from-vedia-voice.sh	
adapter-data-feed-id	Feed ID of the Aif file to be adapted	polystar_a_v1	
		polystar_iucs_v1	
probe_user	Default Voice/SMS probe username	same as other feeds, can be changed	
probe_password	Default Voice/SMS probe password	same as other feeds, can be changed	

4.3.3.4	Voice/SMS Interface Adaptor installation
If call-interface-adaptor flag is set to yes then the installation of the Voice/SMS Interface Adaptor also needs to be performed. The adaptor converts Aif and IuCS feeds from different voice probe formats to a CSV format that can be parsed by Streams.
Extract the following file from the archive: cna/build/interface-adapter/interface-adapter-8.2.0.1.2.rpm. Then, as user root, perform the RPM installation in each host where Vedia Supercollector was deployed already:
rpm -ivh interface-adapter-8.2.0.1.2.rpm
This will install the Interface Adapter into /opt/tnf/apps/interface-adapter as the user boss. To modify the ownership of the adapters to biadmin, perform the following as root:
chown –R biadmin:biadmin /opt/tnf/apps/interface-adapter
The adaptor is invoked automatically from the Vedia Supercollector. 
4.3.3.5	Streams targets
Set the following variable depending on the number of Streams jobs that will collect each downloaded file from {output_base_dir}/{probe_name}|{probe_ip}/{probe_type} (i.e. as per the section above). 
Consider the following example. When the following mediation components are set up:
•	ITE Streams application for Gn
•	Raw TDR Processor Streams application for Gn
•	Vantage 8.3 Gn mediation (Vedia based)
•	Smartfeeds 2.0 Gn mediation (Vedia based)
then it means that there are 4 jobs that collect one Gn netro (and/or Gn pagebased file): 2 Streams-based and 2 Vedia-based. In this case there have to be two Streams targets configured.
Parameter	Description	
streams-target-list	Comma separated list of Streams-based mediation targets (symlinks will be created for these) – default: Streams-ITE,Streams-RawTDR	

If you want to load both aggregations (ITE application) and TDRs (RawTDR application) to Hadoop then there is no need to change the defaults. 
FYI, the purpose of these Streams targets is to create symlinks for each downloaded file in a location where Streams application expects them. E.g. for netro feed:
/opt/tnf/file_loader/vedia/storage/Streams-ITE/P1/in/data/netro/netro_20120425000019.log.gz
/opt/tnf/file_loader/vedia/storage/Streams-RawTDR/P1/in/data/netro/netro_20120425000019.log.gz

They both reference the same file: /opt/tnf/file_loader/vedia/P1/netro/netro_20120425000019.log.gz
Similarly for the pagebased feed
/opt/tnf/file_loader/vedia/storage/Streams-ITE/P1/in/data/page/pbqoe_20120425000019.log.gz
/opt/tnf/file_loader/vedia/storage/Streams-RawTDR/P1/in/data/page/pbqoe_20120425000019.log.gz

They both reference the same file: /opt/tnf/file_loader/vedia/P1/page/pbqoe_20120425000019.log.gz
It is expected that these directories (/opt/tnf/file_loader/vedia/storage/Streams-ITE/ and /opt/tnf/file_loader/vedia/storage/Streams-RawTDR/) are configured for individual Streams jobs in configuration files probes.csv (section 4.5.2) and probes-tdr.csv (section 4.5.2.2).
Please note that Vedia Supercollector creates the necessary directory hierarchy (required by Streams) automatically. I.e. the following is created automatically within the output directory:
./in/urgent/
./in/data/
./in/data/{feed_type}/
./in/inputDirectories.txt

Important note: It is expected that different file types (such as netro feed and pagebased feed) have unique file name. I.e. prefix of different file types is different.
4.3.4	Start / stop
To start, first start all “slave” Vedia Supercollector instances. Then start main instance.
To start a Vedia instance do this:
cd /opt/tnf/file_loader/vedia/
./vedia start

Stop has to be done in the reverse order to starting the Vedia Supercollector, i.e. first stop the master instance and then stop all “slave” instances.
To stop a Vedia instance do this:
cd /opt/tnf/file_loader/vedia/
./vedia stop

4.3.5	Cleanup
There are logs and temporary files that need to be cleaned periodically and also the downloaded files in the storage/ directory. Both tasks need to be scheduled in crontab in every host where Vedia Supercollector is deployed.
4.3.5.1	Logs cleanup
First add the following line to crontab:
# run pack every day
0 0 * * * cd /opt/tnf/file_loader/vedia; ./vedia pack

Secondly you need to decide what the retention period for keeping original (unzipped) and zipped log files is. This depends on the available storage. The following parameters can be set in the file /opt/tnf/file_loader/vedia/vedia:
•	logs_days_zip – Number of days to keep log files before they get zipped (default is 2 days)
•	logs_days_del – Number of days to keep zipped log files before they get deleted (default is 7 days)
•	tmp_days_del – Number of days to keep tmp files before they get cleaned (default is 2 days)
4.3.5.2	Storage cleanup
The deployment includes a script /opt/tnf/file_loader/vedia/disk-cleanup.sh for cleaning downloaded files in the storage output directories. All files older than 5 hours are cleaned (including symlinks for Streams based mediation). The period is configurable by setting the variable HOURS within the cleanup script.
Add the following line to crontab to run the script hourly:
# run storage cleanup every hour
0 * * * * /opt/tnf/file_loader/vedia/disk-cleanup.sh

Please note that the cleanup script uses the default output storage/ directory. If you changed this directory (output_base_dir value in consts.xml), need make the same change in this script:
LOCATION=/opt/tnf/file_loader/vedia/storage/
4.4	Streams domain and instance configuration
The intended setup of the system is to have one Streams instance per each interface per each blade. Also, ITE application and Raw TDR application should use different Streams instances. 
4.4.1	Zookeeper setup
There are two options for a Zookeeper:
•	Embedded (simpler)
•	External (potentially better performance)
4.4.1.1	Embedded Zookeeper
No installation is required to use the embedded Zookeeper. The embedded Zookeeper is already part of the Streams 4.0.1 installation. What is only needed is to specify the option --embeddedzk when creating a Streams domain using the mkdomain command (see section 4.4.2), i.e. 
unset STREAMS_ZKCONNECT
streamtool mkdomain -d cna_domain --embeddedzk
Also, it is needed to increase the heap size using the following command before any Streams domain is created:
streamtool setbootproperty streams.zookeeper.jvmFlags=-Xmx4096m

4.4.1.2	External Zookeeper
An external Zookeeper can deliver potentially better performance. To install the external Apache Zookeeper please follow these instructions.
Ideally, the installation should be performed in a host where there is no other Streams domain. The recommended host is the host where Vedia Supercollector is installed (see section 4.3).
After untarring the Zookeeper package (zookeeper-3.4.6.tar) into /opt/tnf/cna/zookeeper-3.4.6/ set the following parameters in the config file /opt/tnf/cna/zookeeper-3.4.6/conf/zoo.cfg:
dataDir=/opt/tnf/cna/zookeeper-3.4.6/data
clientPort=2181
maxClientCnxns=-1

Then the heap size of Zookeeper needs to be increased by putting a file java.env in the configuration directory (/opt/tnf/cna/zookeeper-3.4.6/conf/java.env) with this command:
export JVMFLAGS="-Xmx4096m"
To start the Apache Zookeeper:
cd /opt/tnf/cna/zookeeper-3.4.6/bin
./zkServer.sh start /opt/tnf/cna/zookeeper-3.4.6/conf/zoo.cfg

To stop the Apache Zookeeper:
cd /opt/tnf/cna/zookeeper-3.4.6/bin
./zkServer.sh stop /opt/tnf/cna/zookeeper-3.4.6/conf/zoo.cfg

Next step is to define an environment variable $STREAMS_ZKCONNECT in all hosts where streams is going to be deployed. It must be set to the IP and port of the running Zookeeper instance, e.g.
export STREAMS_ZKCONNECT=blade01:2181
On each of the Streams blades, set the environment variable $STREAMS_ZKCONNECT to the same value (in a .profile or a .bash_profile file)
4.4.2	Streams main domain
In order to avoid any interference the blades should share the same Streams domain.
Provided that the environment variable $STREAMS_ZKCONNECT is correctly configured as per the previous chapter, the domain can be set up with the following commands (where cna_domain is the domain to be created):
streamtool mkdomain -d cna_domain
streamtool genkey -d cna_domain
streamtool startdomain -d cna_domain
The environment variable $STREAMS_DOMAIN_ID should be set to this Streams domain (in a .profile or a .bash_profile file) in every blade so that it is not necessary to specify it when running a Streams command every time.
Note that the -d cna_domain in the commands above can be avoided if $STREAMS_DOMAIN_ID is set.
4.4.3	Streams instances per blade per interface
There has to be a different Streams instance per blade per interface per application type (ITE or Raw TDR processor).
Run the following commands to create the instance (where cna_instance_blade02_ite_gn is the name of the interface to be created and blade02 is one of the blade's external IP addresses or a host name pointing to it):
streamtool mkinstance -i cna_instance_blade02_ite_gn --hosts blade02
streamtool startinstance -i cna_instance_blade02_ite_gn
As there must be one instance per interface on each blade, it might be sensible to choose a name that reflects this, e.g. a combination of blade name, application type and interface as per the example above.
In a deployment where only one Streams interface (i.e. only one blade, one interface) is configured that one Streams instance can be set to an environment variable $STREAMS_INSTANCE_ID so that it is not necessary to type it with every Streams command.
Note that the -i instance in the commands above can be avoided if $STREAMS_INSTANCE_ID is set.
Before switching off or rebooting the blade, it's recommended to manually stop the instance with
streamtool stopinstance -i cna_instance_blade02_ite_gn
In case the blade was rebooted without stopping the instance, it can be stopped forcefully with
streamtool stopinstance -i cna_instance_blade02_ite_gn --force
Afterwards it can be restarted with:
streamtool startinstance -i cna_instance_blade02_ite_gn
You can also list all created instances with:
streamtool lsinstance 
Or list all instances for one domain by adding the -d cna_domain option:
streamtool lsinstance -d cna_domain

4.4.4	Sizing considerations
By default the ITE applications use 4 parallel collection chains and a maximum of 5 parallel aggregation contexts (configurable at compile-time as specified in section 4.5.1) divided in 3 groups for Gn and LTE (UP, UPS, CP+CPS) and 2 for Voice&SMS (VSMS, VSMSStatus); how the contexts are split between the groups is configurable as per section 4.5.3, but by default 3 contexts are used for UP, 4 for VSMS and 1 for the others.
With the above setup the tested throughput per probe is: 
For Gn: 4 million TDR/min on an HP blade and 6.5 million TDR/min on a Flex blade; performances degrade gradually when increasing the number of probes, and the maximum recommended amount of fully loaded probes is 3 on an HP blade (totaling 7.5 million TDR/min) and 4 on a Flex blade (totaling 16 million TDR/min).
For LTE: with the default setup (see 4.5.1) 6.8 million TDR/min on a Flex blade with one probe job. Performance decreases when increasing the number of probes. The maximum recommended amount of probes is 2 on a Flex blade, with 5 million TDR/min each. Totalling 10 million TDR/min.
For Voice/SMS: Using 6 parallel chains and 3 contexts, 3.4 million TDR/min for a single probe (job) on a Flex blade; 6.1 million TDR/min for two probes (e.g. A and IuCS). Performances degrade gradually when increasing the number of probes, and the maximum recommended amount of fully loaded probes is 4 (totaling 10.1 million TDR/min)
If the probes' throughput is lower than 1 million TDR/min, the ITE applications can be configured with appSplitterEnabled=false in the constants file (see section 4.5.3), so that all aggregation is performed in the same context and more probes than listed above can be processed by the same blade.
The application's footprint can be further decreased by reducing the overall maximum number of contexts (NumContexts=1) and chain processors (NumChains=1), but this configuration is a compile-time parameter (see section 4.5.1).
4.5	Customization
The following is a list of customization files for all interfaces. Please review all of them and change the configuration as needed.
Unless otherwise stated, the files are located in /opt/tnf/cna/cfg/.
4.5.1	Compile-time parameters
The Streams RPMs (see section 4.2) accept a configuration file at the path indicated by the --prefix option; it must be named as the RPM file but with suffix .ini, so e.g. loader-9.0.0.0.0.compile.rpm will use a configuration file named loader-9.0.0.0.0.compile.ini. The content must be a list of options in the form A=B, one per line, with blank lines and comments (starting with '#') allowed; the following table lists the available options.

4.5.1.1	DBLoader
Parameter	Description	
HadoopSegments	It specifies how many segments are configured in Hadoop (default 3)	
Interface	It specifies the interface the app will load: possible values are gn, lte, voice, volte, ran, fixedline, raw_gn, raw_lte, raw_voice. To load more than one interface the package must be built and installed once per interface.	
4.5.1.2	LookupManager
Parameter	Description	
NumAggProbes	It specifies how many probes can be configured at most per each interface in probes.csv, i.e. how many ITE jobs can run in the same instance (see next section, default 4)	
CellCacheSizeMB	It specifies how much space to allocate for the Cell lookup, in megabytes (default 10)	
MCCMNCCacheSizeMB	It specifies how much space to allocate for the MCC-MNC lookup, in megabytes (default 1)	
BNumberCacheSizeMB	It specifies how much space to allocate for the BNumber lookup, in megabytes (default 30)	
StatusCacheSizeMB	It specifies how much space to allocate for the Status code lookup, in megabytes (default 2)	
GnQoSCacheSizeMB	It specifies how much space to allocate for the Gn QoS category lookup, in megabytes (default 3)	
LTEQoSCacheSizeMB	It specifies how much space to allocate for the LTE QoS category lookup, in megabytes (default 3)	
SGSNCacheSizeMB	It specifies how much space to allocate for the SGSN lookup, in megabytes (default 1)	
GGSNCacheSizeMB	It specifies how much space to allocate for the GGSN lookup, in megabytes (default 1)	
SGWCacheSizeMB	It specifies how much space to allocate for the SGW lookup, in megabytes (default 1)	
BSCCacheSizeMB	It specifies how much space to allocate for the BSC lookup, in megabytes (default 1)	
RNCCacheSizeMB	It specifies how much space to allocate for the RNC lookup, in megabytes (default 1)	
MMECacheSizeMB	It specifies how much space to allocate for the MME lookup, in megabytes (default 1)	
BTSCacheSizeMB	It specifies how much space to allocate for the BTS lookup, in megabytes (default 1)	
NodeBCacheSizeMB	It specifies how much space to allocate for the NodeB lookup, in megabytes (default 1)	
EnodeBCacheSizeMB	It specifies how much space to allocate for the eNodeB lookup, in megabytes (default 1)	
AppCacheSizeMB	It specifies how much space to allocate for the Applications lookup, in megabytes (default 10)	
SipStatusCacheSizeMB	It specifies how much space to allocate for the SIP status lookup, in megabytes (default 1)	
AppStatusCacheSizeMB	It specifies how much space to allocate for the ApplicationStatus lookup, in megabytes (default 1)	

4.5.1.3	ITE
Parameter	Description	
HadoopSegments	It specifies how many segments are configured in Hadoop (default 3)	
NumChains	It specifies how many parallel collection chains to use (default 6)	
NumAggProbes	It specifies how many probes can be configured at most per each interface in probes.csv (see next section, default 4)	
AdditionalAdapters	Set the value of this parameter to an archive file in TGZ format, that contains source code for additional adapters. The new adapters will be compiled into the application. See the Adapter development guide for more details.	
KeepSources	Set this parameter to “1” in order to keep the source code after the package installation. The source can be used to implement additional adapters. See the Adapter Development Guide.	

The following options apply to Gn/LTE only:
Parameter	Description	
NumParallelLookups	Number of parallel lookups (default 3)	
NumParallelParsers	Number of parallel parsers (default 10)	
NumUPSubAggregators	Number of aggregators for UP subscriber level (default 6)	
NumUPAppAggregators	Number of aggregators for UP application level (default 2)	
NumUPCellAggregators	Number of aggregators for UP cell level (default 2)	
NumUPNetAggregators	Number of aggregators for UP network level (default 2)	
NumUPSSubAggregators	Number of aggregators for UPS subscriber level (default 1)	
NumUPSNetAggregators	Number of aggregators for UPS network level (default 1)	
NumCPSubAggregators	Number of aggregators for CP subscriber level (default 1)	
NumCPCellAggregators	Number of aggregators for CP cell level (default 1)	
NumCPNetAggregators	Number of aggregators for CP network level (default 1)	
NumCPSSubAggregators	Number of aggregators for CPS subscriber level (default 1)	
NumCPSCellAggregators	Number of aggregators for CPS cell level (default 1)	
NumCPSNetAggregators	Number of aggregators for CPS network level (default 1)	
minFields6013,maxFields6013,minFields6021,maxFields6021,minFileds6022,maxFields6022	Used only for Gn interface ITE app. Specify the minimum and maximum number of CSV fields, expected in input files of the given type. TDRs with less fields or more fields than expected are rejected.	
minFields7013,maxFields7013,minFields7021,maxFields7021,minFileds7022,maxFields7022	Used only for LTE interface ITE app. Specify the minimum and maximum number of CSV fields, expected in input files of the given type. TDRs with less fields or more fields than expected are rejected.	
CesSupported	Enable/Disable customer experience scores (yes/no)	

The following options apply to Voice&SMS only:
Parameter	Description	
NumContexts	It specifies how many aggregation contexts to use (default 5)	
minFieldsVoice,maxFieldsVoice	Used only for Voice/SMS interface ITE app. Specify the minimum and maximum number of CSV fields, expected in input file. TDRs with less fields or more fields than expected are rejected.	

The following options apply to RAN only:
Parameter	Description	
NumParallelLookups	Number of parallel lookups (default 3)	
NumParallelParsers	Number of parallel parsers (default 10)	
NumTopAggregators	Number of aggregators for top level (default 6)	
NumSubAggregators	Number of aggregators for subscriber level (default 6)	
NumDevAggregators	Number of aggregators for device level  (default 4)	
NumCellAggregators	Number of aggregators for cell level (default 2)	
NumNetAggregators	Number of aggregators for network level (default 4)	
minFieldsRan,maxFieldsRan	Used only for RAN interface ITE app. Specify the minimum and maximum number of CSV fields, expected in input file. TDRs with less fields or more fields than expected are rejected.	

The following options apply to FixedLine only:
Parameter	Description	
NumParallelLookups	Number of parallel lookups (default 3)	
NumParallelParsers	Number of parallel parsers (default 10)	
NumUPSubAggregators	Number of aggregators for UP subscriber level (default 6)	
NumUPAppAggregators	Number of aggregators for UP application level (default 2)	
NumUPNetAggregators	Number of aggregators for UP network level (default 2)	
NumUPSSubAggregators	Number of aggregators for UPS subscriber level (default 1)	
NumUPSNetAggregators	Number of aggregators for UPS network level (default 1)	
NumCPSubAggregators	Number of aggregators for CP subscriber level (default 1)	
NumCPNetAggregators	Number of aggregators for CP network level (default 1)	
NumCPSSubAggregators	Number of aggregators for CPS subscriber level (default 1)	
NumCPSNetAggregators	Number of aggregators for CPS network level (default 1)	
minFields4013,maxFields4013,minFields4021,maxFields4021,minFileds4022,maxFields4022	Specify the minimum and maximum number of CSV fields, expected in input files of the given type. TDRs with less fields or more fields than expected are rejected.	
CesSupported	Enable/Disable customer experience scores (yes/no)	

4.5.1.4	RawTDR
Parameter	Description	
NumChains	It specifies how many parallel collection chains to use (default for Gn/LTE 4, default for Voice 6)	
minFieldsVoice,maxFieldsVoice	Used only for Voice/SMS interface RawTDR app. Specify the minimum and maximum number of CSV fields, expected in input file. TDRs with less fields or more fields than expected are rejected.	

4.5.2	Probes
4.5.2.1	probes.csv
This file lists all probes collected by the blade for processing by the ITE apps. The default content of the file is a guide on how to configure it. For each probe you must specify on one line, pipe separated, the following fields:
Parameter	Description	
instance	The name of the Streams instance that the probe will be processed by	
type	One of gn, lte, voice-a, voice-iucs, volte, ran, fixedline (note that it must be the same for all lines referring to the same instance)	
name	The probe name as it should appear in the output records	
directory	A directory path (see also section 4.3.3.2 with Vedia Supercollector output directory settings), inside which a directory must exist with the same name as the probe, and inside this directory the file in/inputDirectories.txt, containing the input directory names, one per line.
Default is /opt/tnf/file_loader/vedia/storage/Streams-ITE/	

Please note that you cannot configure more probes per interface than specified in the NumAggProbes option (see section 4.5.1).
As indicated in the description, an input directory for a probe has to have a specific directory hierarchy. The default hierarchy starts at the (default) path /opt/tnf/file_loader/vedia/storage/Streams-ITE/.
In the above example path the input TDRs are expected to appear in /opt/tnf/file_loader/vedia/storage/Streams-ITE/{probe_name}/in/data/{feed_type}/, where {probe_name} is the name of the probe as per the table above and {feed_type} corresponds to different file types (e.g. netro, pagebased, etc). Any data that appear in /opt/tnf/file_loader/vedia/storage/Streams-ITE/{probe_name}/in/urgent/ will be processed with a higher priority (required during recovery). A successfully processed file is moved to the /opt/tnf/file_loader/vedia/storage/Streams-ITE/{probe_name}/in/archive/ directory.
Please also note that when Vedia Supercollector is deployed then input files are actually symlinks, because one input file might be collected by multiple mediation components. When a symlink is moved to the archive/ directory then the original file is still available for the other mediation component.
4.5.2.2	probes-tdr.csv
This file lists all probes collected by the blade for processing by the RawTDR app. The default content of the file is a guide on how to configure it. For each probe you must specify on one line, pipe separated, the following fields:
Parameter	Description	
instance	The name of the Streams instance that the probe will be collected by	
type	One of: gn, lte or voice (note that it must be the same for all lines referring to the same instance)	
name	The probe name as it should appear in the output records	
directory	A directory path (see also section 4.3.3.2 with Vedia Supercollector output directory settings), inside which a directory must exist with the same name as the probe, and inside this directory the file in/inputDirectories.txt, containing the input directory names, one per line.
Default is /opt/tnf/file_loader/vedia/storage/Streams-RawTDR/	

The input directory contains sub-directories as per the previous section with the only exception that instead of Streams-ITE subdirectory the RawTDR application uses Streams-RawTDR as per the default directory in the parameter list above.

4.5.3	Constants
4.5.3.1	consts_gn.ini, consts_lte.ini
These two files have similar contents, but each is used by the specific interface; among the many options, the following are those of greater interest (defaults in bold):
Parameter	Description	
netroFileMask	The file mask for netro input files*	
pagebasedFileMask	The file mask for page based input files*	
enableUPSubscriberAggr	Enable/disable subscriber (level 3) aggregation for User Plane. When set to false, the subscriber aggregated files should not be created for User Plane	
enableUPCellsAggr	Enable/disable cell (level 2a) aggregation. When set to false, the cell aggregated files should not be created for User Plane	
enableCPSubscriberAggr	Enable/disable subscriber (level 3) aggregation for Control Plane. When set to false, the subscriber aggregated files should not be created for Control Plane	
enableCPCellsAggr	Enable/disable cell (level 2a) aggregation for Control Plane. When set to false, the cell aggregated files should not be created for Control Plane	

enableImeiAttribute	Enable/Disable the setting of the IMEI attribute. Default value is true. If set to false, the IMEI attribute should always be blank	
enableMsisdn	Enable/Disable MSISDN field (true - populate MSISDN from feed, false - set MSISDN to empty)	
loadUnknownSubscribers	Enable/Disable the filter for unknown IMSIs in level 3 tables (true – load data for unknown IMSIs to DB, false – filter out unknown IMSIs)	
filterCPsuccessCodes	Enable/Disable control plane status code filters (true – filter out success codes, false – load all codes to DB)	
CPsuccessCodes	The comma-separated list of success codes for the interface	
ignorePageBased	Enable/Disable page based feed (true – ignore PB TDRs, false – process PB TDRs)	
checkProbeCells	Specify whether to use the provisioned cell list (true – only provisioned cells are allowed, false – non-provisioned cells are replaced by zeroes)	
operatorPrefix	Specify a list of operator prefixes; if set to a non-null value, only IMSIs starting with a value in the comma-separated list will be processed	
subscriberOperatorPrefix	Specify a list of operator prefixes; if set to a non-null value, only IMSIs starting with a value in the comma-separated list will be processed at subscriber level	
loaderDirectory	Specify where the output should be written (/opt/tnf/cna/loaderDir)	
bytesUpMax	Specify the maximum number of bytes to allow in upload in each TDR; higher values will cause the TDR to be discarded (200000000)	
bytesDownMax	Specify the maximum number of bytes to allow in download in each TDR; higher values will cause the TDR to be discarded (400000000)	
parserType	In case your installation supports multiple adapters, you can select the adapter for this application. Available adapters depend on the interface. Adapters are enumerated (1, 2, 3…). The default value is 1, and selects the TNF probe adapters.	
lte.status.code.min.value	The minimum allowed Statuscode value for LTE Controlplane. The default is 16.	

* The file masks must contain a timestamp in the format YYYYMMDD[.]hhmmss (where the square brackets indicate that the dot is optional) in order for the file ordering to correctly sort the input feed by file timestamp.
4.5.3.2	consts_voice.ini
This file is used by the Voice&SMS interface; among the many options, the following are those of greater interest (defaults in bold):
Parameter	Description	
aFileMask	The file mask for Aif (voice-a) input files*	
iucsFileMask	The file mask for IuCS (voice-iucs) input files*	
appSplitterEnabled	Enable/Disable aggregation segmentation (true – split among multiple contexts, false – do not split)	
numContextsVSMS	Specify how many contexts to split Voice&SMS data in when appSplitterEnabled=true (4)	
numContextsVSMSStatus	Specify how many contexts to split Voice&SMS Status data in when appSplitterEnabled=true (1)	
enableSubscriberAggr	Enable/disable subscriber (level 3) aggregation. When set to false, the subscriber aggregated files should not be created	
enableCellAggr	Enable/disable cell (level 2a) aggregation. When set to false, the cell aggregated files should not be created	
enableImeiAttribute	Enable/Disable the setting of the IMEI attribute. Default value is true. If set to false, the IMEI attribute should always be blank	
loadUnknownSubscribers	Enable/Disable the filter for unknown IMSIs in level 3 tables (true – load data for unknown IMSIs to DB, false – filter out unknown IMSIs)	
operatorPrefix	Specify a list of operator prefixes; if set to a non-null value, only IMSIs starting with a value in the comma-separated list will be processed	
loaderDirectory	Specify where the output should be written (/opt/tnf/cna/loaderDir)	
		
voicesms.proprietary.cause	Set to 0 if the standard GSM/UMTS termination causes are used in the feed, set to 1 if the cause is proprietary.
Default value is 0. Set to 1 for Singtel NDC feed. May be set to other values in the future to support non-standard feeds	
voicesms.adapter.calculated.rat	Set to 0 if the RAT is to be determined based on the collected file type (2G for Aif, 3G for IucS),
Set to 1 if the RAT is being calculated by the interface adapter. Default is 0	
voicesms.call.duration.get.from.feed	Set these to 1 if the durations are provided in the incoming feed (either in the raw feed or calculated by the adapter). Set to 0 if the durations should be calculated by Vedia based on timestamps.
Default: 0	
voicesms.setup.duration.get.from.feed		
voicesms.sms.duration.get.from.feed		
parserType	In case your installation supports multiple adapters, you can select the adapter for this application. Available adapters depend on the interface. Adapters are enumerated (1, 2, 3…). The default value is 1, and selects the TNF probe adapters.	

* The file masks must contain a timestamp in the format YYYYMMDD[.]hhmmss (where the square brackets indicate that the dot is optional) in order for the file ordering to correctly sort the input feed by file timestamp.
4.5.3.3	consts_ran.ini
This file is used by the RAN interface; among the many options, the following are those of greater interest (defaults in bold):
Parameter	Description	
fileMask	The file mask for input files*	
enableSubscriberAggr	Enable/disable subscriber (level 3) aggregation. When set to false, the subscriber aggregated files should not be created	
enableDeviceAggr	Enable/disable device (level 2) aggregation. When set to false, the device aggregated files should not be created	
enableCellAggr	Enable/disable cell (level 2a) aggregation. When set to false, the cell aggregated files should not be created	
enableImeiAttribute	Enable/Disable the setting of the IMEI attribute. Default value is true. If set to false, the IMEI attribute should always be blank	
internalCellId	If set to true, the cell lookup will be performed based on the internal Cell ID field, otherwise it will be performed based on the full cell key (MCC:MNC:LAC:CellID)	
internalNodeId	If set to true, the node lookups (BSC, RNC, MME, BTS, NodeB, eNodeB) will be performed based on the internal node Ids, otherwise they will be performed on the nodes IP address.	
loadUnknownSubscribers	Enable/Disable the filter for unknown IMSIs in level 3 tables (true – load data for unknown IMSIs to DB, false – filter out unknown IMSIs)	
loadUnknownDevices	Enable/Disable the filter for unknown devices in level 2 tables (true – load data for unknown devices to DB, false – filter out unknown devices)	
operatorPrefix	Specify a list of operator prefixes; if set to a non-null value, only IMSIs starting with a value in the comma-separated list will be processed	
subscriberOperatorPrefix	Specify a list of operator prefixes; if set to a non-null value, only IMSIs starting with a value in the comma-separated list will be processed at subscriber level	
loaderDirectory	Specify where the output should be written (/opt/tnf/cna/loaderDir)	
parserType	In case your installation supports multiple adapters, you can select the adapter for this application. Available adapters depend on the interface. Adapters are enumerated (1, 2, 3…). The default value is 1, and selects the TNF probe adapters.	

* The file masks must contain a timestamp in the format YYYYMMDD[.]hhmmss (where the square brackets indicate that the dot is optional) in order for the file ordering to correctly sort the input feed by file timestamp.
4.5.3.4	consts_fixedline.ini
This file is used by the FixedLine interface; among the many options, the following are those of greater interest (defaults in bold):
Parameter	Description	
netroFileMask	The file mask for netro input files*	
pagebasedFileMask	The file mask for page based input files*	
enableUPSubscriberAggr	Enable/disable subscriber (level 3) aggregation for User Plane. When set to false, the subscriber aggregated files should not be created for User Plane	
enableCPSubscriberAggr	Enable/disable subscriber (level 3) aggregation for Control Plane. When set to false, the subscriber aggregated files should not be created for Control Plane	
loadUnknownSubscribers	Enable/Disable the filter for unknown CSIDs in level 3 tables (true – load data for unknown CSIDs to DB, false – filter out unknown CSIDs)	
filterCPsuccessCodes	Enable/Disable control plane status code filters (true – filter out success codes, false – load all codes to DB)	
CPsuccessCodes	The comma-separated list of success codes for the interface	
ignorePageBased	Enable/Disable page based feed (true – ignore PB TDRs, false – process PB TDRs)	
subscriberOperatorPrefix	Specify a list of operator prefixes; if set to a non-null value, only IMSIs starting with a value in the comma-separated list will be processed at subscriber level	
loaderDirectory	Specify where the output should be written (/opt/tnf/cna/loaderDir)	
bytesUpMax	Specify the maximum number of bytes to allow in upload in each TDR; higher values will cause the TDR to be discarded (200000000)	
bytesDownMax	Specify the maximum number of bytes to allow in download in each TDR; higher values will cause the TDR to be discarded (400000000)	
parserType	In case your installation supports multiple adapters, you can select the adapter for this application. Available adapters depend on the interface. Adapters are enumerated (1, 2, 3…). The default value is 1, and selects the TNF probe adapters.	

* The file masks must contain a timestamp in the format YYYYMMDD[.]hhmmss (where the square brackets indicate that the dot is optional) in order for the file ordering to correctly sort the input feed by file timestamp.
4.5.3.5	rawtdr_*.ini
The RawTDR app prepares raw TDRs for loading into the database. The submission time parameters are:
Parameter	Description	
fileMask	The file mask for collected files. Default is '^.+\\.gz$'. 
Files that don’t match the mask will not be processed and will be placed into the ‘invalid’ directory (in/invalid)	
waitMin	Define how long (in minutes) should the 1-hour partitions wait untouched until being sent for loading to hadoop. Default 60 minutes	
maxRecordsGn
	Max number of records that can be stored in 1h partitioned files (for Gn) before they get closed for loading. If set to 0 the file will grow indefinitely and will close after the waitMin time	
maxRecordsLTE	Max number of records that can be stored in 1h partitioned files (for LTE) before they get closed for loading. If set to 0 the file will grow indefinitely and will close after the waitMin time	
maxRecordsVoice	Max number of records that can be stored in 1h partitioned files (for Voice) before they get closed for loading. If set to 0 the file will grow indefinitely and will close after the waitMin time	
ignorePageBased	Define whether page based records (x013) should be ignored (applicable for gn and lte)
1: ignore page based, 0: don't ignore	
loaderDirectory	The absolute path to the directory where rawtdr will store output files 
for processing by the loader (/opt/tnf/cna/loaderDir/raw/)	

4.5.4	loader_*.ini
The DBLoader collects aggregated and TDR files, converts them through an external script, then loads the records to the DB through yet another external script. The loader app accepts several submission time parameters which are automatically provided to the application by the cna.sh script depending on the loader type so there are currently no configurable settings available in loader.ini.
However, the application invokes loader scripts which may require customizing. The scripts are installed into /opt/tnf/cna/etc/script/, while the configuration files are named /opt/tnf/cna/cfg/loader_{interface}.ini, where {interface} represents one of the installed DBLoader interfaces.
Settings that may need modifying:
Parameter	Description	
logFile	Define where the script will write its log. Default: /opt/tnf/cna/stat/loader_script/loader.log	
dataLoaderLog	Log file for the CNA data loader. Default: /opt/tnf/cna/stat/loader_script/dataloader.log	
dataloaderSudoPrefix	If dataloader needs to be invoked as a different user, specify the sudo prefix here. For example, while the BIS framework v2 allowed any user to invoke the loader, in v3 it is required that the loader is invoked by the tnf user (configurable by hadoop). In this case, the dataloaderSudoPrefix should be set to sudo -u tnf. In case the sudo prefix is used, please see the “Configuring sudoers” section below. 	
enableHadoopVoicesms 	Enable/disable the loading Voice/SMS aggregations into hadoop	
enableHadoopVoicesmsSc	Enable/disable the loading Voice/SMS status code aggregations into hadoop	
enableHadoopUP	Enable/disable the loading of Gn/LTE/Fixed Line user plane aggregations into Hadoop	
enableHadoopUPS	Enable/disable the loading of Gn/LTE/Fixed Line user plane status code aggregations into Hadoop	
enableHadoopCP	Enable/disable the loading of Gn/LTE/Fixed Line control plane aggregations into Hadoop	
enableHadoopCPS	Enable/disable the loading of Gn/LTE/Fixed Line control plane status code aggregations into Hadoop	
enableHadoopRAN	Enable/disable the loading of RAN aggregations into Hadoop	
enableHadoopSIP	Enable/disable the loading of VoLTE SIP aggregations into Hadoop	
enableHadoopSIPS	Enable/disable the loading of VoLTE SIP status code aggregations into Hadoop	
enableHadoopRTP	Enable/disable the loading of VoLTE RTP aggregations into Hadoop	

The mapping section between the aggregation levels and table names is used in case of ITE applications (not RawTDR); the default mappings can be left as is.
Other settings in this file would usually not require changes.
4.5.4.1	Configuring sudoers
Starting with Analytics v3 it is no longer possible to perform loading to hadoop with any user (usually biadmin). Instead, the tnf user should be used for this purpose. This is an access control issue and depends on Hadoop rather than on the client (see ENGRA-738)
In case the data cannot get loaded using the default configuration, the following may need to be configured:
1.	Set dataloaderSudoPrefix = sudo -u tnf in /opt/tnf/cna/etc/script/loader.ini
2.	Add the following line to the very end of the sudoers file (sudo visudo):
biadmin    ALL=(ALL) NOPASSWD: ALL
3.	Set the following in the sudoers file (sudo visudo)
Defaults    !requiretty
The above will allow sudo commands to be invoked in non-tty mode and prevent errors such as "sudo: no tty present and no askpass program specified" from appearing in the DBLoader script invocation logs (/opt/tnf/cna/stat/loader)

4.5.5	Provisioning Files
Provisioning files are regularly updated from the master application server whenever changes are detected. These updates are performed automatically in the background by the cna.sh health monitor on all Mediation blades so there is no need to modify the provisioning files directly on the Mediation blades. However, the formats of the provisioning files are listed here for reference.

4.5.5.1	cells.csv
The cells provisioning file: it must contain the following fields, comma-separated (no comments allowed). Only TDRs with cells specified in this file may be processed (others will be rejected).
Parameter	Description	
mcc_mnc_lac_ci	MCC:MNC:LAC:CI of the cell	
name	The unique cell name	
internal_id	The internal cell id – being a secondary key, it must be unique in each row	

4.5.5.2	mcc_mnc.csv
The country/network provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
mcc	The mobile country code	
mnc	The mobile network code	
operator type	One of 0 (international), 1 (home) or 2 (probe)	
country	The name of the country	
prefix	The country's international prefix	
network	The name of the network provider	

4.5.5.3	bnumber.csv
The B-number provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
prefix	The B-number prefix (prefixed by “P” if international)	
label	The country name	

4.5.5.4	status.csv
The Voice&SMS status code provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
cause_code	The cause code, in the form record_type:operation_type:code, e.g. “mo_call:bssmap:0”	
label	The cause label	
result	Success or Failure	
operation_type	Same as in cause_code, but in printable form, e.g. “BSSMAP”	
record_type	Same as in cause_code, but in printable form, e.g. “MO Call”	

4.5.5.5	gn_qoscategory.csv
The Gn QoS Category provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
arpthp	The requested allocation and retention priority (ARP) and traffic handling priority (THP), colon separated, e.g. “1:1”	
qos_category	The integer value of QoS category	
label	The label corresponding to the selected QoS category	

4.5.5.6	lte_qoscategory.csv
The LTE QoS Category provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
qos_category	The integer value of QoS category	
label	The label corresponding to the selected QoS category	
qci	The integer value of QoS QCI	
qos_priority	The integer value of QoS priority	

4.5.5.7	fixedline_qos.csv
The FixedLine QoS Category provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
qos_priority	The integer value of QoS priority	
label	The label corresponding to the selected QoS priority	

4.5.5.8	sgsn.csv
The SGSN provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The SGSN IP address	
group	The SGSN group	

4.5.5.9	ggsn.csv
The GGSN provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The GGSN IP address	
group	The GGSN group	

4.5.5.10	sgw.csv
The SGW provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The SGW IP address	
group	The SGW group	

4.5.5.11	bsc.csv
The BSC provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The BSC IP address	
group	The BSC group	
internal_id	The internal BSC id – being a secondary key, it must be unique in each row	

4.5.5.12	rnc.csv
The RNC provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The RNC IP address	
group	The RNC group	
internal_id	The internal RNC id – being a secondary key, it must be unique in each row	

4.5.5.13	mme.csv
The MME provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The MME IP address	
group	The MME group	
internal_id	The internal MME id – being a secondary key, it must be unique in each row	

4.5.5.14	bts.csv
The BTS provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The BTS IP address	
group	The BTS group	
internal_id	The internal BTS id – being a secondary key, it must be unique in each row	

4.5.5.15	nodeb.csv
The NodeB provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The NodeB IP address	
group	The NodeB group	
internal_id	The internal NodeB id – being a secondary key, it must be unique in each row	

4.5.5.16	enodeb.csv
The eNodeB provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_address	The eNodeB IP address	
group	The eNodeB group	
internal_id	The internal eNodeB id – being a secondary key, it must be unique in each row	

4.5.5.17	applications.csv
The Applications provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
application	The application name as found in the TDRs	
label	The application name as it should appear in the aggregated output	

4.5.5.18	sip_status_codes.csv
The VoLTE SIP status codes provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
status_code	The status code in the format VOLTE:Transaction:Response, e.g. VOLTE:NOTIFY:Timeout or VOLTE:CANCEL:604	
label	The code label	
result	Success or Failure	

4.5.5.19	csid.csv
The FixedLine CSID provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
csid	The Call Station ID	
dslam	The Digital Subscriber Line Access Multiplexer 	
cpe_dev	Customer Premise Equipment Device	

4.5.5.20	tier0.csv
The FixedLine tier zero provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_addr	The tier 0 IP address	
group	The tier 0 group	

4.5.5.21	tier1.csv
The FixedLine tier one provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
ip_addr	The tier 1 IP address	
group	The tier 1 group	

4.5.5.22	fixedline_transaction_type.csv
The FixedLine transaction type provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
type	The transaction type	
label	The transaction type label (Session Create, etc)	

4.5.5.23	fixedline_transaction_status.csv
The FixedLine transaction status provisioning file: it must contain the following fields, comma-separated (no comments allowed):
Parameter	Description	
status	The transaction status as 3 colon separated values, ex: FIXEDLINE:2:3	
label	The cause code label	
result	Success or Failure	

4.5.6	Provisioning Update Configuration
Configuring the provisioning update feature consists of configuring the remote and local locations for provisioning files, which is configured in the cna.sh script, and of configuring per-dimension details which is configured in the provisioning.cfg file, located in the same dir with cna.sh.
4.5.6.1	Provisioning configuration in cna.sh
The following provisioning update settings can be configured in cna.sh
Parameter	Description	
PROVISIONING_CENTRAL_SERVER	IP Address or hostname of the central server where the auto exported provisioning files are stored	
PROVISIONING_USERNAME	User on the remote server (tnf)	
PROVISIONING_REMOTE_DIR	Directory on the remote server where the exported provisioning files are stored (/opt/tnf/apps/bis-main-var/provisioning/)	
PROVISIONING_LOCAL_DIR	Directory where the files will be downloaded to. This should be the configuration dir where the reprovision command expects the files (/opt/tnf/cna/cfg/)	
PROVISIONING_CFG_FILE	Local file where the dimensions are mapped to remote filenames and the timestamps of downloaded files are stored (provisioning.cfg)	

4.5.6.2	Provisioning.cfg
The provisioning configuration file is a CSV based file which stores the mappings between dimensions and corresponding local and remote files as well as the timestamps of the last downloaded file for the dimension. Each entry consists of the following fields:
•	Dimension (e.g. cell, apn, etc), used as a dimension key for the script onlt, can be set to any meaningful value 
•	Local filename: The name of the file as expected by the Lookup Manager (e.g. cells.csv, etc)
•	Remote filename: The name of the file as provided by the central server auto export feature
•	Timestamp: The timestamp in seconds since epoch of the most recent downloaded file for the dimension. This field is populated by the script. For new dimensions the value should be set to 0.

The default provisioning.cfg is built into the Lookup Manager RPM and installed into the root dir (/opt/tnf/cna/).
Example content:
# Dimension,LocalFilename,RemoteFilename,Timestamp
applications,applications.csv,APPLICATIONS_auto_export.csv,0
bnumber,bnumber.csv,BNUMBER_auto_export.csv,0
cell,cells.csv,CELL_auto_export.csv,0
mccmnc,mcc_mnc.csv,MCC_MNC_auto_export.csv,0
status,status.csv,STATUS_auto_export.csv,0	

The file should be edited in cases where the RemoteFilename does not match the already configured value, and to add additional dimensions if required.
5	Administration Guide
In the following instance represents the instance name as configured in probes.csv or in probes-tdr.csv.
5.1	Starting the applications
Before starting the applications check that they are not already running as detailed in section 5.3.
In order to start the applications run:
/opt/tnf/cna/cna.sh -i instance start
5.2	Stopping the applications
To stop the applications run:
/opt/tnf/cna/cna.sh -i instance stop
5.3	Checking the application status
To check what applications are running, use:
streamtool lsjobs -i instance
To check the internal state of running applications, use:
/opt/tnf/cna/cna.sh -i instance status
5.4	Cleaning temporary files
To clean up temporary files run:
/opt/tnf/cna/cna.sh -i instance clean
To clean up logs and checkpoints in the probe directories run:
/opt/tnf/cna/cna.sh -i instance cleanprobes
To clean all the contents from the loader directories run:
/opt/tnf/cna/cna.sh -i instance cleanload
5.5	Provisioning updates
5.5.1	Provisioning auto-updates
Provisioning is performed on the master application server which exports CSV files whenever a provisioning change is made. Mediation blades monitor the location of those CSV files and performs an auto update whenever an update is available. This task is performed by the cna.sh health monitor which is invoked approximately every minute, which means that as long as the start command of the cna.sh script has been invoked with the –R option, the provisioning files will be updated automatically. The process is logged in /opt/tnf/cna/stat/{interface}/health.log

5.5.2	Manual provisioning auto update
Provisioning files can be updated manually by invoking the following command
/opt/tnf/cna/cna.sh -i instance updateprov
This command can be used to update the provisioning files at times when the Streams applications are not running.
5.6	Consulting log files
5.6.1	Collection
The files {probe_dir}/{probe_name}/out/statistics/{date}_ite.{i}_Statistics.txt, where {probe_dir} and {probe_name} are the values configured in probes.csv (see section 4.5.2), ite.{i} is the job name as shown in section 5.3, while {date} is in the format YYYYMMDD, contain the collection statistics for all chains (4 by default). The content of the files are a list of labelled file attributes, as in the following LTE example (one line per one file):
{filename="/opt/tnf/file_loader/vedia/storage/Streams-ITE/P1/in/data/netro_20120227080601.log.gz",fileType="netro",filesize=17346,urgent=false,reprocess=false,filetime=1330358761,processingStartedAt="2015-08-26 07:57:06",processingStoppedAt="2015-08-26 07:57:06",duration=0.025828,startTimestamp=(1440601026,719628000,0),sentRecords=238,nRecordsDecodedASN1=0,nBytesDecodedASN1=0,nBytesReceivedASN1=0,nBytesDroppedASN1=0,recordStatsASN1={},nBytesReceivedBIN=0,nBytesDroppedBIN=0,recordCountsBIN={},byteCountsBIN={},recordStatsBIN={},nLinesDroppedCSV=0,recordStatsCSV={"m7013":{"errors":0,"records":0},"m7021":{"errors":0,"records":232},"m7022":{"errors":0,"records":6}},warnings=[],errors=[],duplicate=false,invalidFile=validFile,rejectedInvalids=0,tableStats={},tableFiles=[],chainSequenceNumber=311,groupId="00:311,01:0,02:0,03:0,04:0",chainId="02",logFileDate="20150826"}
The fields of interest are:
•	filename: identifies the file the attributes refer to;
•	sentRecords: contains the total number of TDRs in the file sent to the aggregation contexts;
•	recordStatsCSV: this attribute is further divided in specific counters per TDR type;
•	invalidFile: can be used to trace rejected files;
•	rejectedInvalids: can be used to trace rejected TDRs;
•	groupId: this string lists the aggregation contexts (comma separated) and specifies how many of the processed TDRs were sent to each (colon separated) – note that this number can be higher than sentRecords in case TDRs are duplicated for the aggregation;
•	chainId: identifies the chain that processed the file.
The rejected TDRs will have a more detailed explanation listed in a corresponding file in /opt/tnf/cna/stat/{interface}/probes/{probe_name}/rejected/, together with the line number in the file where the TDR was located and a numeric error code.
5.6.2	Lookup
The statistics for lookup tables are printed to /opt/tnf/cna/stat/{interface}/{date}_LookupManagerStatistics.txt, where {interface} is the interface type and {date} is in the format YYYYMMDD. Example content from the file follows:
{filename="",command="SUCCESS request:submit",commandStartedAt="Wed Aug 26 07:56:10 2015",commandProcessedAt="",hostStatistics=[],logFileDate="20150826"}
{filename="/opt/tnf/cna/control/lte/cmd/init_all.cmd",command="init",commandStartedAt="Wed Aug 26 07:56:15 2015",commandProcessedAt="Wed Aug 26 07:56:51 2015",hostStatistics=["Streams segments:{[sgmnt:mcc_mnc- table:mcc_mnc- reserved:1048576- free:525184-free %:50- processed:1637][sgmnt:status- table:status- reserved:2097152- free:1139760-free %:54- processed:1020][sgmnt:bnumber- table:bnumber- reserved:31457280- free:21855792-free %:69- processed:89088][sgmnt:cells- table:cells- reserved:10485760- free:4247616-free %:40- processed:81077][sgmnt:imsi_msisdn- table:imsi_msisdn- reserved:629145600- free:629145600-free %:100- processed:0]}"],logFileDate="20150826"}
{filename="appl.ctl.cmd",command="SUCCESS request:restart,ite.0",commandStartedAt="Wed Aug 26 07:58:16 2015",commandProcessedAt="",hostStatistics=[],logFileDate="20150826"}
In particular, the middle log refers to the tables being loaded: the attribute hostStatistics provides the number of records loaded (processed) and the remaining memory (free %) for each table. Please ensure that there is remaining memory for all tables; the cache size can be configured at compile-time as specified in section 4.5.1.
5.6.3	Aggregation
The files /opt/tnf/cna/stat/{interface}/probes/{probe_name}/context_statistics_{i}.txt, where {interface} is the interface type, {probe_name} is the value configured in probes.csv while {i} represents the context number, contain the aggregation statistics. An example line from the file follows:
{message="file=netro_20120227080601.log.gz, chain=03, composite=Context00.ContextRecordRegionStream.CustomContext.CustomContext.UP_SubscriberAggregateIntermediate, toolate=208, totalCount={\"20120227075000\":3,\"20120227075500\":2,\"20120227080000\":200,\"20120227072000\":1,\"20120227080500\":24,\"20120227073000\":2}"}
In particular:
•	totalCount: can be used to trace the number of TDRs (colon separated) processed in each period (comma separated);
•	toolate: can be used to trace the amount of TDRs ignored in the period.
5.6.4	Database
The files in /opt/tnf/cna/stat/loader_script/, contain eventual errors relating to the DB loader.
The variables logFile and dataLoaderLog in the file /opt/tnf/cna/etc/script/loader.ini contain the path of the log files for the loader scripts (see section ??).
The /opt/tnf/cna/etc/script/checkLoaderLog.sh script can be invoked manually at any time to printout the DB loader performance statistics. Sample output:
Start Time                       = 20151201 11:14:27.458
End Time                         = 20151201 13:05:48.642
Successfully loaded files        = 3636
Number of failed files           = 289
Total processed records          = 3598002
Size of loaded files (Bytes)     = 1266488951
Average records in one file      = 989
Average file size (Bytes)        = 348319
Duration (sec.)                  = 6681
Duration (min.)                  = 111:21
Processed records/sec.           = 538
Processed records/sec/core       = 134
Processed records/min.           = 32280
Processed input data KB/sec.     = 185
Processed input data KB/sec/core = 46
Average record size (Bytes)      = 351

These statistics are based on the contents of the /opt/tnf/cna/stat/loader_script/loader.log log file.
5.6.5	Performance
The file /opt/tnf/cna/stat/{interface}/vmstat.stat, where {interface} is the interface type, contains the memory and CPU statistics measured during the applications' current life time, as measured by the vmstat command. The monitoring daemon's pid is stored in /opt/tnf/cna/control/{interface}/vmstat.pid, and can be used to monitor its status. The daemon is killed during the stop command and both files are reset upon a full restart.
5.6.6	Streams logs
Every time a Streams job is stopped, either by the “stop” command or by the automated recovery mechanism outlined in the next section, its Streams logs are archived to /opt/tnf/cna/stat/{interface}/StreamsLogsJob{id}.tgz, where {interface} is the interface type and {id} is the (former) Streams job identifier. Refer to the Streams documentation for what the individual log files mean.
5.7	Recovery mechanisms
All applications are monitored every minute during the application's life time; if a Streams job fails or reports a status different from “run” (fully operational), the job is restarted. The monitoring daemon is started automatically by the “start” command, and is killed by the “stop” command; the process has the same name as the management script, cna.sh, and its process ID is stored in /opt/tnf/cna/control/{interface}/health.pid, which can be used to monitor its status, e.g. with
ps -fp `cat /opt/tnf/cna/control/{interface}/health.pid`
If no process is listed in the command's output, the monitoring process might have been killed or terminated unexpectedly: the process might have to be killed manually to examine Streams logs that would be removed during a restart. In this case there is no embedded mechanism to restart it, and it's recommended to manually restart the applications to restore the functionality.
The file /opt/tnf/cna/stat/{interface}/health.log contains the health monitor logs and can be used to detect instabilities in the system. Streams-related instabilities might have to be analysed using the individual job and PE logs (see related Streams documentation).
In the following example content:
08/26/15 07:56:37 === Started monitoring instance cna_lte
08/26/15 07:57:48 DBLoader (job #16): status Running/yes/run
08/26/15 07:57:58 LookupManager (job #14): status Running/yes/run
08/26/15 07:57:58 ite.0 - P1 (job #-): status -/terminated
streamtool submitjob /opt/tnf/cna/bin/ITE_LTE.sab -C data-directory=/opt/tnf/file_loader/vedia/storage/Streams-ITE/P1 -P probeId=P1 -P ite.jobName=ite.0  -P netroFileMask='netro_([0-9]{14})\\.log\\.gz'\
	 -P pagebasedFileMask='pbqoe_([0-9]{14})\\.log\\.gz'\
	 -P appSplitterEnabled=false\
	 -P numContextsUP=3\
	 -P numContextsUPS=1\
	 -P numContextsCPCPS=1\
	 -P loadUnknownSubscribers=false\
	 -P filterCPsuccessCodes=true\
	 -P CpsuccessCodes=16,17,18,19\
	 -P ignorePageBased=false\
	 -P roamersFilter=subscriber\
	 -P checkProbeCells=true -P global.applicationControlDirectory=/opt/tnf/cna/control/lte
CDISC0079I The following number of applications were submitted to the cna_lte instance: 1. The instance is in the cna domain.
CDISC0080I The 17 job was submitted for the following application: ITE_LTE.sab. The job was submitted to the cna_lte instance in the cna domain.
CDISC0020I Submitted job IDs: 17
08/26/15 07:59:24 DBLoader (job #16): status Running/yes/run
08/26/15 07:59:32 LookupManager (job #14): status Running/yes/run
08/26/15 07:59:40 ite.0 - P1 (job #17): status Running/yes/run
We can see that the applications were started at 07:56, but at 07:57 the ITE LTE application had been detected as terminated; it was immediately restarted (the individual parameters depend on the content of the ITE configuration file), and at 07:59 all applications are healthy.
In case of a failure of an ITE job, as in the above example, the last 5 processed files are also resubmitted for collection; the ITE application will automatically identify TDRs that had been already aggregated and possibly written and will not output them again to prevent duplicates.
In case of a failure of the LookupManager a full restart is automatically performed.