Tools

Overview

Users have a set of tools to use in the platform, such as:

• Ping and Traceroute which allows them to check the status of their devices or hosts
• Configure FTP or SFTP connections to send the CDRs in CSV format

FTP

This feature is composed of several 1GLOBAL systems including network and mediation nodes and the IoT Portal as being the final system responsible for the delivery of CDRs.

Each system requires a certain amount of time to process CDRs and part of the flow relies on cron jobs/scheduled tasks to dispatch CDRs. Depending on the moment at which these scheduled tasks run, the CDRs can take more or less time to be processed. The following image depicts how the flow works:

• Network creates CDR files with a predefined frequency
• CDRs are sent to IoT Portal
• IoT Portal sends CDR files over FTP or SFTP with a predefined frequency (per configuration)
  note

  The minimum value is 5 minutes

Setup

The IoT Portal feature that allows delivering CDRs to a remote location is called “FTP” and is located in the IoT Portal left menu under “Tools”.

Each main organization or sub-organization can have their own FTP/SFTP setup and this will enable the delivery of CDRs for all SIMs provisioned under that organization or sub-organization. Having an FTP/SFTP setup in a main organization does not automatically enable the CDR delivery of existing or future sub-organizations.

This feature does not keep or deliver CDRs that were created before the FTP/SFTP setup which means that only CDRs created after the FTP setup will be delivered. If the FTP setup is deleted, all and subsequent CDRs will not be delivered or stored in IoT Portal.

The following steps describe how to setup this feature:

Step 1 - Go to the FTP feature

FTP feature location in IoT Portal

Step 2 - Insert FTP or SFTP details

On this step, the user needs to insert the following details:

• Host – FTP/SFTP server host
• Port – FTP/SFTP server port
• Path – Destination folder in the FTP server where the CDRs will be delivered
• Interval – Rate at which the CDRs should be sent to the FTP/SFTP server
  • Every 5 min, 30 min, 1 hour or 1 day
• FTP Type
  • FTP or SFTP
• Username – FTP/SFTP server user
• Password

FTP details screen

On this step, the following requirements need to be met so that this feature can work as expected:

• IoT Portal needs to have connectivity to the destination host and port. If there is the need to check connectivity, please reach out to 1GLOBAL.
• The user needs to have read and write permissions on the destination path

The FTP/SFTP details are stored on clicking in “Add”.

Step 3 – Manage FTP setup

Once the FTP setup is stored, it will show up on the FTP screen and can be edited or deleted

FTP management screen

CDR Delivery Schedules

This feature has a load-balancing setup with multiple workers that are executed every 5 min, 30 min, 1 hour or 1 day. Each time a worker is executed it looks for undelivered CDRs and compiles them into a file and then delivers to the configured FTP/SFTP server.

These workers synchronize if at least 2 of them try to execute at the same time. Otherwise, each worker will run regardless of the time that the previous worker executed. Therefore, some CDR deliveries happen in less than the frequency defined in the SFTP setup.

CDR Filename Format

The files that are created by this FTP feature have the following file name format:

• YYYYMM-DDHH-mmSS-uuid.csv

Example: 202102-0309-0347-3de72c98-4004-45ab-980f-658ab800ec5d.csv

CDR Details

The following table list the fields that are included in the CDR files as well as some expected values:

Field Name	Type	Description	List of Values / Samples
session_duration	(big) Integer	Difference between session_end_time and session_start_time	If session_ start_time = 11:59:59 and session_end_time = 12:59:59, the session_duration would be 10000.
msisdn	(big) Integer	For Data CDRs: msisdn that generated the session For SMSMO/SMSD CDRs: Originating MSISDN (also known as #A-Number)
mcc	Integer	Mobile country code in 3-digit format
id	Integer	CDR unique identifier
data_usage	Integer	For Data CDRs: Event total usage in bytes For SMSMO/SMSD CDRs: Event total usage in number of SMSs
apn	String (255)	SIM card APN as presented in IoT Portal
imsi	(big) Integer	SIM card primary IMSI as presented in IoT Portal
iccid	(big) Integer	SIM card ICCID
mnc	Integer	Mobile network code in 3-digit format
network_name	String (255)	Presentable network name
session_start_time	Date-time field in format of ‘YYYY-MM-DD HH:mm:SS’	Event start time
session_end_time	Date-time field in format of ‘YYYY-MM-DD HH:mm:SS’	Event end time
cdr_type	String (255)	Type of CDR	For Postpaid Data CDRs: GPRS FBCD For Prepaid Data CDRs: QUOTA For SMS CDRs: SMSMO SMSD
destination_number	(big) Integer	For Data CDRs: - N/A For SMSMO/SMSD CDRs: - Destination MSISDN (also known as #B-Number)
session_id	(big) Integer	Session identifier

The current fields shall be in the order of the above table and each CDR file has multiple records (or lines). Each record (or line) has a unique identifier.

Examples

Mobile Originated SMS CDRs

session_duration,msisdn,mcc,id,data_usage,apn,imsi,iccid,mnc,network_name,session_start_time,session_end_time,cdr_type,destination_number,session_id
0.000000,447559999999999,100,1,1,iot.truphone.com,204049999999999,8944509999999999999,200,NEt1,2021-01-25 16:38:31+00:00,2021-01-25 16:38:31+00:00,SMSD,447557777777777,124578
0.000000,447559999999999,100,2,1,iot.truphone.com,204049999999999,8944509999999999999,200,NEt1,2021-01-25 16:38:31+00:00,2021-01-25 16:38:31+00:00,SMSD,447558888888888,965412

Data CDRs

session_duration,msisdn,mcc,id,data_usage,apn,imsi,iccid,mnc,network_name,session_start_time,session_end_time,cdr_type,destination_number,session_id
1000,447559999999999,100,3,3157,iot.truphone.com,204049999999999,8944509999999999999,200,NEt1,2021-01-25 11:03:21,2021-01-25 11:13:21,GPRS,,965412
698,447559999999999,100,4,1084,iot.truphone.com,204049999999999,8944509999999999999,200,NEt1,2021-01-25 11:06:10,2021-01-25 11:13:08,GPRS,,965412

Multiple FTP setups

If there are more than one FTP setup with the same delivery frequency in the organization then they are redundant setups because the first setup to execute will deliver all pending CDRs and the remaining FTP setups won't have anything to deliver (because all CDRs were already delivered).

If the FTP setups have different delivery frequency, for example one runs every 30 min and the other runs every 5 min then the 30 min setup would deliver all CDRs that were generated after the last execution of the 5 min setup and vice-versa.

note

With more than 1 setup, a given CDR is only delivered to one location. There are no duplicate deliveries. Also, in this scenario, if one of the setups is failing then all CDRs will be delivered by the other one. However, if both are configured and working correctly then the IoT Portal will deliver CDRs to one of them randomly. This means that there may be cases, for example, where the first 3 CDR deliveries can go to the first FTP and the following 5 can go to the other FTP.

This feature primary "concern" is to guarantee that all CDRs are correctly delivered, regardless of the FTP destination that was used.