MOBITELSMS 2.2: 5G SA Core and Protocol Engine Support

MOBITELSMS 2.2 represents the largest architectural expansion in the platform's history. This release introduces native 5G Standalone (SA) core network support, four purpose-built protocol engines for legacy and next-generation signalling, and a ground-up redesign of the admin dashboard. For carriers and MVNOs running production traffic, 2.2 delivers the interconnect infrastructure needed to bridge SS7 networks, 4G EPC, and 5G SA cores from a single deployable stack.

5G Standalone Core: Why SA Matters

Most commercial 5G deployments today are Non-Standalone (NSA), meaning they anchor to an existing 4G LTE Evolved Packet Core (EPC) and use 5G New Radio (NR) only at the radio layer. NSA is a pragmatic first step, but it inherits the architectural limitations of 4G: centralized packet gateways, GTP tunnels for every session, and no native support for network slicing or edge compute placement.

5G Standalone flips this model. The 5G SA core replaces the EPC entirely with a cloud-native, service-based architecture (SBA). Instead of monolithic network elements, SA decomposes core functions into discrete services:

• AMF (Access and Mobility Management Function) handles device registration, authentication, and mobility events. It replaces the MME from 4G.
• SMF (Session Management Function) manages PDU sessions, QoS policy enforcement, and UPF selection. It replaces the SGW-C and PGW-C control plane.
• UPF (User Plane Function) handles packet forwarding, traffic measurement, and lawful intercept. It can be deployed at the edge for ultra-low-latency use cases.
• NSSF (Network Slice Selection Function) routes subscribers to the appropriate network slice based on their subscription profile and service type.

MOBITELSMS 2.2 integrates with all four of these core functions via their standardized HTTP/2 service-based interfaces (SBI). This means the billing and routing engine can receive charging triggers directly from the SMF, query subscriber profiles from UDM, and enforce policy rules in real time, without an intermediate diameter proxy or offline mediation layer.

Four New Protocol Engines

While 5G SA is the future, the present is heterogeneous. Carriers interconnect over SS7, Diameter, SIP, and REST simultaneously. MOBITELSMS 2.2 ships four standalone protocol engines that run as independent processes alongside the core billing module, each handling a specific signalling domain.

SS7/SIGTRAN Gateway

The SS7 engine is a Java/Spring Boot application built on jSS7 (Oleg Okulchenko's open-source SS7 stack). It implements the full M3UA/SCCP/TCAP/MAP stack, supporting MAP SMS (MO-ForwardSM, MT-ForwardSM), HLR queries (SendRoutingInfo, AnyTimeInterrogation), and ISUP for circuit-switched interworking. The engine manages its own MTP3 link state machine and handles SCCP routing by Global Title translation.

For SMS operators, this means inbound SS7 messages arrive via MAP, get translated to the internal format, and are pushed to internal message queues for routing, all without requiring an external SIGTRAN gateway appliance.

# SS7 inbound SMS flow
MAP MO-ForwardSM  -->  SS7 Engine  -->  Message Queue  -->  Core Router
MAP MT-ForwardSM  <--  SS7 Engine  <--  Outbound Queue

Diameter OCS (Online Charging System)

The Diameter engine implements Gy/Ro for online charging and Gx for policy control, using the jDiameter stack. It supports Credit-Control-Request (CCR) Initial/Update/Terminate for real-time balance deduction, with configurable quota reservation and threshold-based re-authorization. The Gx interface allows the platform to install QoS rules (PCC rules) on the PCEF, enabling per-subscriber bandwidth control and service gating.

SCTP Transport

SCTP (Stream Control Transmission Protocol) is the mandatory transport for SIGTRAN and is commonly used for Diameter peering. The SCTP engine is a lightweight C daemon built on the Linux kernel SCTP stack (lksctp). It provides multi-homing, multi-streaming, and path failover, exposing a clean socket API to the SS7 and Diameter engines above it.

Proto-Hub Async Router

The Proto-Hub is a Rust/Tokio service that acts as the message fabric between all protocol engines and the core billing module. It implements circuit-breaker patterns (preventing cascade failures when a downstream engine is unresponsive), least-cost routing across multiple SS7 links or Diameter peers, and a REST management API for runtime inspection.

# Proto-Hub management
GET  /api/status           # Health of all connected engines
GET  /api/routes           # Current routing table
POST /api/config/reload    # Hot-reload configuration

Hot Reload and Operational Control

All four engines support hot configuration reload via two mechanisms: SIGHUP (the Unix convention) and a REST API endpoint. This means you can change SS7 point codes, Diameter peer addresses, or SCTP multi-homing parameters without restarting the process or dropping active sessions.

The Proto-Hub additionally subscribes to a internal pub/sub channel for configuration reload, so changes can be pushed programmatically from the admin dashboard or external orchestration tools. The engines are managed as systemd services under a common target:

# Start all protocol engines
systemctl start mobitelsms.target

# Restart just the SS7 engine
systemctl restart mobitelsms-ss7.service

# Check status of all engines
systemctl status mobitelsms-ss7 mobitelsms-diameter mobitelsms-sctp mobitelsms-protohub

Internal message bus for SMS Integration

The protocol engines communicate with the core billing module through internal message queues rather than direct function calls. This decoupling provides several operational advantages: engines can be restarted independently without affecting call processing, message backlogs are durable across restarts, and throughput can be scaled by adding consumer threads on either side.

The key queues are:

• Inbound queue -- messages from SS7/SMPP/HTTP for routing
• SS7 outbound queue -- messages routed to SS7 termination
• DLR queue -- delivery receipts from all engines
• Gateway status -- per-gateway health data (JSON, auto-expiring)

Performance Improvements

Beyond the protocol engines, 2.2 includes targeted performance work in the core billing path:

• Routing sort: The dial peer sorting algorithm was upgraded to O(n log n), reducing routing table construction time by 40x on large routing tables (10,000+ entries).
• Lock-free counters: Global statistics counters (CPS, active calls, CDR counts) were migrated to atomic operations, eliminating lock contention on the hot path.
• Connection pool signaling: Database connection acquisition latency dropped from an average of 50ms to under 1ms through improved pool signaling.
• Thread safety audit: A comprehensive pass across the entire codebase ensured all time, string, and state functions are fully thread-safe under high concurrency.

Redesigned Admin Dashboard

The admin interface now includes a Protocol Engines dashboard that displays the status of all four engines in real time: connection state, active sessions, throughput counters, and error rates. SS7 gateways can be configured directly from the SMS Gateways page, with a Template Wizard that provides pre-configured profiles for common interconnect scenarios (national carrier, international hub, MVNO roaming, A2P aggregator, IoT/M2M).

Server role management has been extended so that each protocol engine can be enabled or disabled per server node, supporting distributed deployments where SS7 and Diameter run on dedicated hardware while the billing core runs separately.

What This Means for Carriers and MVNOs

For Tier 2/3 carriers and MVNOs, MOBITELSMS 2.2 eliminates the need to purchase and integrate separate SS7, Diameter, and SIP gateway appliances. The entire signalling and billing stack deploys as a single coordinated system, with shared configuration, unified logging, and consistent operational tooling. For operators migrating from 4G to 5G SA, the platform provides a bridge: SS7 interconnects continue to work for legacy traffic while new 5G SA subscribers are charged in real time via the Diameter OCS or direct SBI integration.

MOBITELSMS 2.2 is available now for all customers on Professional and Enterprise plans. Existing deployments can upgrade in place; protocol engines are additive and do not require changes to the existing VoIP or SMS configuration. For detailed upgrade instructions and configuration reference, see the documentation portal.