Magma CDR Availability proposal

[Arsenii-Oganov]

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, (magma/magma#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.
• CDR File Management, e.g. file creation, file opening / closure triggers, file deletion
• CDR file transfer to the CDR clients

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.

• 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

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

[Arsenii-Oganov]

Issue - magma/magma#11636
PR - magma/magma#11637