Skip to main content



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


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)

    The minimum value is 5 minutes


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 NameTypeDescriptionList of Values / Samples
session_duration(big) IntegerDifference between session_end_time and session_start_timeIf session_ start_time = 11:59:59 and session_end_time = 12:59:59, the session_duration would be 10000.
msisdn(big) IntegerFor Data CDRs:

msisdn that generated the session


Originating MSISDN (also known as #A-Number)

mccIntegerMobile country code in 3-digit format
idIntegerCDR unique identifier
data_usageIntegerFor Data CDRs:

Event total usage in bytes


Event total usage in number of SMSs

apnString (255)SIM card APN as presented in IoT Portal
imsi(big) IntegerSIM card primary IMSI as presented in IoT Portal
iccid(big) IntegerSIM card ICCID
mncIntegerMobile network code in 3-digit format
network_nameString (255)Presentable network name
session_start_timeDate-time field in format of ‘YYYY-MM-DD HH:mm:SS’Event start time
session_end_timeDate-time field in format of ‘YYYY-MM-DD HH:mm:SS’Event end time
cdr_typeString (255)Type of CDRFor Postpaid Data CDRs:



For Prepaid Data CDRs:





destination_number(big) IntegerFor Data CDRs: - N/A For SMSMO/SMSD CDRs: - Destination MSISDN (also known as #B-Number)
session_id(big) IntegerSession 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.


Mobile Originated SMS CDRs

0.000000,447559999999999,100,1,1,,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,,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

1000,447559999999999,100,3,3157,,204049999999999,8944509999999999999,200,NEt1,2021-01-25 11:03:21,2021-01-25 11:13:21,GPRS,,965412
698,447559999999999,100,4,1084,,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.


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.