The objective of this work is to extend Magma to support Call Data Records (CDR). The charging information is passed through a chain of logical charging functions. At the end of this process, CDR files are generated by the network, which are then transferred to the CDR client/network operator's Billing Domain for the purpose of subscriber billing and/or inter-operator accounting.
Software built to accomplish this (aka settlement domain service) will be open source under BSD-3-Clause and will reside in the github repository of the Magma software under the governance of the Linux foundation, such that it can be effectively maintained in the future releases.
2.0 Background
Currently Magma doesn’t support any kind of CDR files for any scenarios. By implementing this proposal Magma will have full support for standard 3GPP CDRs for inbound roaming scenario and core CDR functionality for outbound roaming scenario.
3.0 Implementation scope
3.1 High - level solution architecture
Where:
SessionD runs CTF (Charging Trigger Function) that generates and sends session init/update/terminate events to the data storage.
Session telemetry - database stores information about all sessions for all network elements for all user equipments.
CDR engine runs CDF (Charging Data Function)
Bx - 3GPP integration reference points
CDR Gateway - Persistent CDR storage
Sessiond enhancements and Session telemetry creation functions are covered inside different proposal (Settlement service, (https://github.com/magma/magma/issues/11166)) and here assumed to be fully implemented.
3.2 CDR engine
The CDR engine pulls data from the Session telemetry via GRPC interface and uses the information contained in the charging events to construct CDRs. The result of the CDR engine task is generated Charging Data Records (CDRs) with a well-defined content and format. The content and format of these CDRs are specified per domain/subsystem/service in the related charging specification 3GPP TS 32.251 for PS domain. The CDR engine implements the following main functions:
CDR pre-processing
Validation, Consolidation and (Re)Formatting of CDRs
CDR error handling
CDR filtering, push CDRs to SFTP and put on separate files based on filtering criteria such as CDR type, CDR parameters, originating of network element etc.
This scenario represent the flow how CDRs will be generated.
In the call flow below, red number messages indicate new functionality supported by a Magma elements.
Steps 1-8 General steps of Session activation and OVS provisioning in Magma.
Since the flow table is installed in to OVS, OVS start to collect session statistics
Steps 9-12 SessionD query and gets user session statistics
Step 13-14 Session telemetry pulls statistics near real time and stores in it's own database.
Step 15 CDR engine pulls statistics near real time and uses the information contained in the statistics to construct CDRs.
Step 16 CDR engine puts Charging Data Records (CDRs) with a well-defined content and format to CDR Gateway for permanent store
Step 17 Sessions has predefined/configurable time treshold to repeat statistics query by steps 18-21 described above
Steps 18-21 SessionD intermediate queries and gets user session statistics , the process of intermediate queries continues to collect usages until its flows are no longer included in the report (flow deleted in Pipelined) or a specified timeout
Steps 22-25 the same procedure as described below in steps 13-16, the process continues until sessiond can collect related flow statistics
Steps 26-32 General steps of Session deactivation and OVS flow removing in Magma.
4.0 CDR file structure
The CDR files contain a variable length header section followed by a variable sized CDR data section.
The CDR data section contains zero or more concatenated CDRs.
Each CDR in a file includes a header indicating the CDR length, data record format, release, version and encoding scheme. Basic Encoding Rules specified by (ITU-T Recommendation X.690 [301]) must be supported by all 3GPP systems.
CDR abstract syntax specification and Charging Data Record (CDR) parameters described in the (3GPP TS 32.298
5.0 Security
This functionality does not provide any changes to Magma AGW or Magma Orc8r, the only change is implementation of the exporting and transformation engine on the FeG side. There are no new public APIs with pull approach will be created, only push mechanism. In real telco implementations mostly SFTP transport protocol is used.
6.0 Testing approach
Main critical parts of the solution will be covered with unit tests
Lab with inbound roaming will be established for e2e tests
Test scenarios will be upstreamed to Magma repos
E2E tests:
One UE attaches to one AGW sunny day scenario
Few UEs attaches to multiple AGWs sunny day scenario
One UE attaches to one AGW cloudy day scenario
Few UEs attaches to multiple AGWs cloudy day scenario
Arsenii-Oganov
commented
2 years ago
CDR Availability proposal
Author(s): [@arsenii-oganov]
1.0 Objectives
The objective of this work is to extend Magma to support Call Data Records (CDR). The charging information is passed through a chain of logical charging functions. At the end of this process, CDR files are generated by the network, which are then transferred to the CDR client/network operator's Billing Domain for the purpose of subscriber billing and/or inter-operator accounting. Software built to accomplish this (aka settlement domain service) will be open source under BSD-3-Clause and will reside in the github repository of the Magma software under the governance of the Linux foundation, such that it can be effectively maintained in the future releases.
2.0 Background
Currently Magma doesn’t support any kind of CDR files for any scenarios. By implementing this proposal Magma will have full support for standard 3GPP CDRs for inbound roaming scenario and core CDR functionality for outbound roaming scenario.
3.0 Implementation scope
3.1 High - level solution architecture
Where: SessionD runs CTF (Charging Trigger Function) that generates and sends session init/update/terminate events to the data storage. Session telemetry - database stores information about all sessions for all network elements for all user equipments. CDR engine runs CDF (Charging Data Function) Bx - 3GPP integration reference points CDR Gateway - Persistent CDR storage Sessiond enhancements and Session telemetry creation functions are covered inside different proposal (Settlement service, (https://github.com/magma/magma/issues/11166)) and here assumed to be fully implemented.
3.2 CDR engine
The CDR engine pulls data from the Session telemetry via GRPC interface and uses the information contained in the charging events to construct CDRs. The result of the CDR engine task is generated Charging Data Records (CDRs) with a well-defined content and format. The content and format of these CDRs are specified per domain/subsystem/service in the related charging specification 3GPP TS 32.251 for PS domain. The CDR engine implements the following main functions:
3.3. Session based charging scenario
This scenario represent the flow how CDRs will be generated. In the call flow below, red number messages indicate new functionality supported by a Magma elements.
4.0 CDR file structure
The CDR files contain a variable length header section followed by a variable sized CDR data section. The CDR data section contains zero or more concatenated CDRs. Each CDR in a file includes a header indicating the CDR length, data record format, release, version and encoding scheme. Basic Encoding Rules specified by (ITU-T Recommendation X.690 [301]) must be supported by all 3GPP systems. CDR abstract syntax specification and Charging Data Record (CDR) parameters described in the (3GPP TS 32.298
5.0 Security
This functionality does not provide any changes to Magma AGW or Magma Orc8r, the only change is implementation of the exporting and transformation engine on the FeG side. There are no new public APIs with pull approach will be created, only push mechanism. In real telco implementations mostly SFTP transport protocol is used.
6.0 Testing approach
7.0 Team
https://github.com/abisare https://github.com/Arsenii-Oganov https://github.com/taaraora https://github.com/malcolmmadsheep https://github.com/jpad-freedomfi
8.0 Roadmap and Schedule
SWE hours approximately for proposal: 1250