Skip to content

Architecture Overview

The telecom billing platform is divided into two primary microservices that interact to provide a complete Business Support System (BSS) and Customer Relationship Management (CRM) solution.

Deployment Context

The platform is designed to be Kubernetes-ready and operates in a high-availability environment suitable for small to medium-sized telecom operators.

1. server.micro.bss (The Core Engine)

A high-performance C++ backend application built using the ACE (ADAPTIVE Communication Environment) Reactor framework.

Key Responsibilities: - DIAMETER Server (Credit-Control Application): Listens for real-time CCR (Credit-Control-Request) messages from network gateways (GGSN/PGW). It handles session management, balance reservations, and final charge deductions. - Offline Billing (CDRLoader): Asynchronously processes flat-file CDRs (Call Detail Records), rating them according to the subscriber's price plan, and recording the charges. - gRPC API Provider: Exposes the CRMServer service over strict gRPC/ProtoBuf interfaces for external management. - Database Interaction: Holds the DB_layer singleton, responsible for transactions against the MySQL database.

2. crm2.micro.bss (The CRM Frontend)

A lightweight PHP frontend web application serving as the administrative console.

Key Responsibilities: - User Interface: Provides HTML UI dashboards for operators to view subscribers, manage price plans, generate invoices, and handle voucher top-ups. - gRPC Client: Acts as the primary consumer of the server.micro.bss API. It does not perform charging or complex rating logic itself; instead, it delegates business logic to the C++ core engine.

Architectural Interaction

graph TD
    subgraph Public_Network [Public Network]
        Admin[Telco Operator]
        Mobile[Mobile Handset]
    end

    subgraph CRM2 [crm2.micro.bss - PHP Frontend]
        UI[Web Dashboard]
        gRPC_Client[gRPC Proxy Client]
    end

    subgraph Server [server.micro.bss - C++ Core]
        gRPC_Server[CRM Server / ACE Reactor]
        Diameter_Server[DIAMETER Server / RFC 4006]
        DB_Layer[DB Interaction Layer]
        Loader[CDR Loader]
    end

    Database[(MySQL X DevAPI)]
    Network_Element[GGSN / MSC]

    Admin -->|HTTPS| UI
    UI -->|Internal PHP call| gRPC_Client
    gRPC_Client -->|gRPC / Protobuf| gRPC_Server

    Mobile -->|Generates Traffic| Network_Element
    Network_Element -->|DIAMETER CCR / CCA| Diameter_Server
    Network_Element -->|FTP/SFTP| Loader

    gRPC_Server -->|Select/Insert/Update| DB_Layer
    Diameter_Server -->|Debit/Reserve| DB_Layer
    Loader -->|Batch Insert| DB_Layer

    DB_Layer --> Database

Communication Protocols

  • Between CRM and Server: Strict gRPC over SSL/TLS. Data payloads are defined using Google Protocol Buffers (billing.proto, crm.proto).
  • Between Network Elements and Server: DIAMETER protocol implementing the Credit-Control Application (RFC 4006). This allows the rating engine to intercept sessions in real-time, enforcing balance limits before data/voice/sms resources are granted.
  • Internal Server Concurrency: The ACE Reactor (ACE_Reactor::instance()) multiplexes connections. The gRPC server and DIAMETER servers run in detached threads, utilizing mutexes (e.g., in Refdata) to protect shared state during hot-reloads.