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 Truphone 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
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 Truphone.
- 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
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.
The files that are created by this FTP feature have the following file name format:
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 sessionFor 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 bytesFor 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:|
FBCDFor Prepaid Data CDRs:
QUOTAFor SMS CDRs:
|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.
Mobile Originated SMS CDRs
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.