Internet Service Providers (ISPs) in Bangladesh operate under strict licensing guidelines enforced by the Bangladesh Telecommunication Regulatory Commission (BTRC). Among these, IPDR (Internet Protocol Detail Record) accounting and Network Address Translation (NAT) log retention are critical legal requirements for all Nationwide, Zonal, District, and Thana category ISP license holders. Failure to maintain verifiable, timestamped session records can result in severe licensing sanctions or hefty fines during annual regulatory audits.
This guide provides an end-to-end technical explanation of BTRC IPDR compliance, MikroTik firewall logging architectures, RADIUS accounting data schemas, and how automated TimescaleDB hypertables prevent disk exhaustion while fulfilling the mandatory 1-year log retention policy.
What is BTRC IPDR and Why is it Mandatory?
IPDR refers to the detailed digital footprint generated whenever an internet subscriber initiates a data session. In Bangladesh, where IPv4 exhaustion forces nearly all broadband providers to utilize Carrier-Grade NAT (CGNAT) or private RFC1918 addressing (such as 10.0.0.0/8 or 100.64.0.0/10), a single public IPv4 address is shared among dozens or hundreds of subscribers.
When cyber security agencies or the National Telecommunication Monitoring Centre (NTMC) investigate an incident traced to a specific public IP and port at a given timestamp, the ISP is legally required to identify the exact subscriber responsible. Without synchronized NAT translation logs and RADIUS accounting records, mapping a shared public IP back to a specific PPPoE username is mathematically impossible.
Mandatory BTRC Log Fields Every ISP Must Retain
To meet BTRC audit standards, an ISP's billing and logging infrastructure must record and cross-reference the following data fields for every subscriber session:
- Subscriber Identity: PPPoE Username, Customer Account ID, and Registered Mobile Number
- Physical Layer: MAC Address and Assigned NAS/Router Identifier
- Private IP Address: The internal IPv4 assigned via RADIUS Framed-IP-Address
- Public NAT IP & Port Range: The external translated public IP and dedicated source port block
- Session Timestamps: Exact Acct-Start-Time and Acct-Stop-Time in Bangladesh Standard Time (BST, UTC+6)
- Session Bandwidth: Acct-Input-Octets (Download) and Acct-Output-Octets (Upload)
- Termination Reason: Acct-Terminate-Cause (User-Request, Lost-Carrier, Admin-Reset)
MikroTik RouterOS NAT Logging vs RADIUS Accounting
Many ISPs attempt to satisfy BTRC requirements solely through MikroTik syslog forwarding. While RouterOS can log connection states using firewall rules, sending raw NAT connection logs to a plain text syslog server creates massive disk bloat — often exceeding 50 GB to 100 GB per day for a medium-sized network.
The industry-standard, high-efficiency architecture decouples session authentication from NAT mapping:
1. RADIUS Accounting (radacct): Captures session lifecycle events (login, interim updates every 300 seconds, and logout) with byte counts and Framed-IP-Address.
2. Deterministic NAT / Port Block Allocation (PBA): Instead of logging every outbound TCP/UDP packet, the router pre-allocates static port ranges (e.g., 2,000 ports per private IP) on the public NAT pool. The assignment rule is static and recorded once, reducing log volume by over 98%.
3. Automated TimescaleDB Hypertables: iBilling stores accounting logs in PostgreSQL hypertables partitioned by time chunks with LZ4 compression, preserving 1 year of immutable history in a fraction of standard database storage.
Handling BTRC Inquiries and Audit Readiness
When an official inquiry is received, your engineering team must be able to query the exact subscriber identity within seconds. In iBilling, navigating to Network > IPDR & NAT Lookup allows operators to input the target public IP, port, and timestamp. The platform cross-references active session snapshots and compressed TimescaleDB archives to produce an audit-ready compliance certificate ready for regulatory submission.