AI-Powered Routing Intelligence
Machine learning architecture for real-time quality-weighted least cost routing
This paper describes the machine learning architecture powering VPX routing decisions. It covers the ensemble model design (gradient boosting for interpretable scoring, neural network for sequential pattern recognition), the 140+ feature engineering pipeline, the 14 quality dimensions tracked per route, the real-time model serving infrastructure designed for <10ms inference latency, the daily retraining pipeline that draws on a projected 2+ billion CDR events per 90-day window at mature network scale and the explainability framework that provides human-readable justifications for every routing decision recorded on-chain.
CONTENTS · 9 SECTIONS
1. Introduction
Traditional Least Cost Routing (LCR) in wholesale telecom operates from static rate tables updated on a daily or weekly schedule. Routes are selected primarily by cost, with quality checks performed retrospectively - often 24-48 hours after traffic has been routed. By the time a quality issue is identified, thousands of calls may have been affected.
The VPX routing engine replaces this reactive model with a predictive, quality-first approach. Every routing decision is informed by a machine learning model that predicts route quality in real time, is designed to apply quality thresholds before cost optimisation and records the decision rationale on-chain for auditable transparency.
Quality-first routing is not only better engineering, it is better economics. In a market whose reflex is to chase volume at the lowest cost, quality is the differentiator that actually pays: higher answer rates and longer calls mean more completed, billable minutes, and clean traffic earns better rates from terminating partners. The engine also resolves number portability on every decision - routing a ported mobile number to its original network is one of the most common and expensive errors in wholesale LCR - so the cheapest-looking route is never chosen when it is the wrong one. And because quality is scored and rewarded across the whole network rather than left to each carrier to optimise for cost alone, the engine works against the industry pattern in which quality erodes whenever volume is the only thing being paid for.
2. Model Architecture
The routing intelligence engine uses an ensemble of two model types, each contributing a distinct capability:
2.1 Gradient Boosting (LightGBM)
The gradient boosting model handles tabular feature scoring - evaluating structured data about each candidate route (historical ASR, current PDD, carrier reputation score, time-of-day quality patterns, destination risk profile). LightGBM was selected for its inference speed (<1ms per route evaluation), interpretability (feature importance is directly extractable) and strong performance on structured tabular data of this kind.
The model evaluates 140+ features per candidate route, grouped into five categories: historical quality (60+ features), real-time quality (25+ features), carrier characteristics (20+ features), destination characteristics (20+ features) and temporal patterns (15+ features).
2.2 Neural Network (Temporal CNN)
The neural network component is a 1D temporal convolutional network that processes sequential call outcome data for each route. It captures patterns that tabular features miss: quality degradation trends, periodic failure patterns (e.g. congestion at specific times) and anomalous sequences that may indicate route instability.
The temporal CNN operates on a sliding window of the most recent 500 call outcomes per route, updated every commit (~390ms). Its output is a quality trajectory prediction: will this route improve, degrade or remain stable over the next 30 minutes?
2.3 Ensemble Combination
The two models are combined via a learned weighting layer. For established routes with extensive historical data, the gradient boosting model dominates (typical weight: 70/30). For new routes with limited history, the temporal CNN receives higher weight as it can detect emerging patterns from fewer data points (typical weight: 40/60).
3. Feature Engineering
The 140+ features evaluated per candidate route are derived from CDR data, network metadata and external intelligence sources. Key feature groups include:
4. Quality Dimensions
The routing engine tracks 14 quality dimensions per route. The five primary dimensions (ASR, ACD, PDD, NER, MOS) are used directly in routing decisions. The remaining nine dimensions are tracked for analytics, benchmarking and anomaly detection:
- ASR (Answer-Seizure Ratio) - percentage of call attempts that are answered.
- ACD (Average Call Duration) - mean duration of answered calls.
- PDD (Post-Dial Delay) - time from call initiation to first ringback or answer.
- NER (Network Effectiveness Ratio) - percentage of calls that reach the destination network successfully.
- MOS (Mean Opinion Score) - estimated voice quality score (1.0-5.0).
- SER (Seizure-to-Event Ratio) - ratio of successful seizures to total attempts.
- ABR (Abnormal Block Rate) - percentage of calls blocked by network congestion.
- SRTT (Signalling Round-Trip Time) - SIP or H.323 signalling latency.
- Jitter - variation in packet inter-arrival time.
- Packet Loss - percentage of RTP packets lost in transit.
- Codec Distribution - mix of codecs negotiated on the route (G.711, G.729, etc.).
- CLI Pass-Through Rate - percentage of calls where originating CLI is preserved.
- Fax Success Rate - T.38 and G.711 fax completion rate (for fax-capable routes).
- DTMF Reliability - in-band and RFC 2833 DTMF transmission success rate.
5. Model Serving & Inference
The routing model is served via a local inference engine on each Routing Node. Model weights are distributed via VPX Protocol and cached locally. This architecture is designed to achieve <10ms inference latency per routing decision (scheduled target, not a measured production guarantee) - fast enough for real-time call setup.
The inference pipeline for a single routing decision:
- Receive routing request (destination, traffic class, quality requirements, budget): <1ms.
- Retrieve candidate routes from local quality cache: <1ms.
- Evaluate gradient boosting model on all candidates: <1ms per candidate, typically 5-15 candidates.
- Evaluate temporal CNN on top-5 candidates: <3ms.
- Apply ensemble weighting and select optimal route: <1ms.
- Submit routing decision to VPX Protocol: <5ms (async, does not block call setup).
5.1 Cache Architecture
Each Routing Node maintains a local quality cache that is updated every commit (~390ms). The cache stores the current quality state for every active route on the network. Cache updates are derived from on-chain quality events submitted by Analytics Nodes and Gateway Nodes. This architecture means that routing decisions are based on data no more than one commit (~390ms) old - compared to hours or days for traditional LCR systems.
6. Daily Retraining Pipeline
The gradient boosting model is retrained daily on the full CDR dataset from the previous 90 days. The training corpus has two sources: at and immediately after mainnet genesis, the model is bootstrapped from VoicePro Plus's existing wholesale CDR corpus accumulated under Ofcom General Conditions since 2022 (real routing data across a range of A-Z destinations). Once VPX mainnet is producing sufficient on-chain CDR volume, the model transitions to the on-chain VPX CDR stream as the primary training corpus. Projected steady-state corpus is 2+ billion CDR events per 90-day window at base-case network scale (Token Economy §13.2); the actual figure scales with realised mainnet adoption and is not asserted as a pre-launch metric. The temporal CNN is retrained weekly on sequential call outcome data. Retraining produces updated model weights that are distributed to all Routing Nodes via VPX Protocol.
The retraining pipeline includes automated model validation: the new model must outperform the current production model on a held-out test set across all five primary quality dimensions before it is promoted. If the new model underperforms on any dimension, the current model continues serving and the training pipeline generates a diagnostic report for human review.
7. Explainability
Every routing decision recorded on-chain includes an explainability payload. This payload provides a human-readable justification for why a specific route was selected:
- Top-5 features that influenced the decision (from gradient boosting feature importance).
- Quality trajectory prediction (from temporal CNN: improving/stable/degrading).
- Candidate routes considered and why each was selected or rejected.
- Quality scores at decision time for the selected route.
- Cost comparison: selected route cost vs. lowest-cost available route (if different).
7.1 Dispute Resolution
The on-chain explainability record serves as the authoritative source for routing dispute resolution. If a carrier questions why their route was not selected for a specific call, the explainability payload provides a complete, immutable record of the decision rationale. This eliminates the "black box" problem that characterises proprietary routing engines.
8. Conclusion
The VPX routing intelligence engine replaces static rate tables with a real-time, quality-first ML model that evaluates 140+ features per candidate route, tracks 14 quality dimensions and records every decision on-chain with a full explainability payload. The architecture is designed to achieve <10ms inference latency (scheduled target, see §6) while applying scheduled quality envelopes - target thresholds applied to every routing decision before cost optimisation - in a manner that static LCR systems are not designed for. Quality targets are scheduled, not guaranteed; they are subject to network conditions, model retraining outcomes and DAO-governable parameters (see TE §16.4 Securities-Framing Principles).
For carriers evaluating VPX routing integration, the key differentiator is transparency. Every routing decision is auditable, explainable and immutably recorded. Route quality is measured in real time - not retrospectively. And cost optimisation only activates within quality boundaries you define.
9. Canonical Disclaimers
Reproduced from the VPX Token Economy Whitepaper v3.5 (§16.2 and §16.3), with cross-references localised to this document, for consistency across the suite. Routing-related Operator rewards referenced anywhere in this paper are subject to the canonical reward disclaimer and the dynamic rate adjustment mechanism in TE §11.6.1.
This document is published by VoicePro Plus Ltd for informational purposes only. It does not constitute investment advice, a prospectus, or an offer of securities. The VPX Ecosystem is under active development; specifications described herein are subject to change. VoicePro Plus Ltd is registered in England and Wales (Company No. 14520016). Registered office: 128 City Road, London, EC1V 2NX.
9.1 Standard Reward Disclaimer
VPXN rewards are utility tokens earned through participation in the VoicePro Mobile platform or operation of VPX infrastructure. They are denominated in VPXN and convertible within the VoicePro ecosystem. Reward rates are not guaranteed; they are subject to network conditions, DAO governance changes, and the dynamic adjustment mechanisms described in Whitepaper 02, Section 11.6.1. The value of unredeemed VPXN balances may fluctuate. VoicePro does not solicit purchases of VPXN as an investment. VPXN is not a security, share, or claim on revenue.
9.2 Standard Tax Notice
VPXN rewards may constitute taxable income or a benefit in kind in the recipient's jurisdiction. UK recipients should be aware that HMRC has indicated that crypto rewards from platform engagement may be treated as miscellaneous income or, in some circumstances, as a benefit in kind. Recipients are responsible for their own tax compliance. VoicePro does not provide tax advice; recipients should consult a qualified adviser. This notice is general in nature and does not constitute legal or tax advice.
This document is published by VoicePro Plus Ltd for informational purposes only. It does not constitute investment advice, a prospectus, or an offer of securities. The VPX Ecosystem is under active development; specifications described herein are subject to change. VoicePro Plus Ltd is registered in England and Wales (Company No. 14520016). Registered office: 128 City Road, London, EC1V 2NX.
Ready to learn more?
Speak to our team about the VPX Ecosystem and how it integrates with your existing infrastructure.
Contact Our Team