Bridging the Gap: Adapting a Wireshark Escher Lua Dissector for NetScout InfiniStreamNG

Bridging the Gap: Adapting a Wireshark Escher Lua Dissector for NetScout InfiniStreamNG

by | May 6, 2026 | OCNCC, Architecture, Operations

🔍 Introduction: The Need for Custom Protocol Visibility

In modern telecom and enterprise networks, proprietary or niche protocols often operate under the radar of standard monitoring tools. For example, the Escher protocol, a binary protocol used in charging and session management systems, lacks native support in most commercial monitoring platforms. While my earlier Wireshark Lua dissector provided a way to decode and analyse Escher traffic offline, the real challenge was bringing this visibility into a production-grade monitoring environment like NetScout’s nGeniusONE.

This post explores how to adapt a Wireshark Lua dissector for real-time protocol dissection in NetScout InfiniStreamNG, enabling live monitoring, troubleshooting, and analytics for custom protocols within the nGeniusONE Service Assurance platform.

🌟 Why NetScout nGeniusONE?

Before diving into the technical details, it’s worth highlighting why NetScout nGeniusONE is the ideal platform for this kind of custom protocol integration. nGeniusONE is a comprehensive service assurance solution designed to provide end-to-end visibility across physical, virtual, and cloud environments. Here’s how it stands out:

📌 Key Benefits of NetScout nGeniusONE

FeatureBenefitRelevance to Custom Protocols
Real-Time VisibilityMonitors live traffic with sub-second latency, enabling immediate detection of issues.Custom protocols like Escher can be monitored in real-time, not just post-mortem.
Adaptive Session Intelligence (ASI)Uses deep packet inspection (DPI) to automatically classify and analyse traffic.ASI can recognise standard protocols (e.g., Diameter, SIP, HTTP), while custom Lua scripts handle proprietary ones like Escher.
End-to-End CorrelationCorrelates multi-protocol sessions (e.g., Diameter + Escher + HTTP) for holistic troubleshooting.Enables tracking of Escher messages alongside standard protocols in a single workflow.
Custom Dashboards and AlertsCreate tailored dashboards and proactive alerts based on custom metrics.Custom fields from the Escher dissector (e.g., escher.ACTN, escher.TYPE) can power real-time dashboards and alerts.
Scalable ArchitectureHandles 10Gbps+ traffic with distributed probes (InfiniStreamNG, vSTREAM).Lua scripts run directly on the probe, ensuring low-latency processing even at scale.
Historical and Trend AnalysisStores long-term data for trend analysis, capacity planning, and forensic investigations.Custom protocol data can be historically analysed alongside other network metrics.
Unified WorkflowSingle pane of glass for network, application, and service-layer visibility.Escher traffic can be seamlessly integrated with other protocols in nGeniusONE’s UI.
Open ExtensibilitySupports custom Lua scripts for proprietary protocols and REST APIs for integration.Enables adaptation of Wireshark dissectors and other custom logic.

🖼️ Architecture Overview

Here’s how the custom Escher dissector fits into the nGeniusONE ecosystem:

Diagram: Custom Escher Dissector in NetScout nGeniusONE Architecture

🧩 The Challenge: From Wireshark to InfiniStreamNG

While Wireshark is an excellent tool for offline protocol analysis, it has limitations for production environments:

  • No real-time processing: Wireshark dissectors run in a desktop app, not on live traffic.
  • No integration with monitoring platforms: Insights from Wireshark cannot directly feed into dashboards, alerts, or automated workflows in tools like nGeniusONE.
  • Manual effort: Engineers must manually capture and analyse PCAPs, which is not scalable for 24/7 operations.

NetScout InfiniStreamNG solves these issues by allowing custom Lua scripts to run directly on the probe, enabling real-time dissection of proprietary protocols like Escher.

🔧 The Adaptation Process: Key Steps

Adapting a Wireshark Lua dissector for InfiniStreamNG requires addressing fundamental differences between the two environments. Below are the critical steps and considerations:

1. Understand the Protocol Structure

The Escher protocol uses a binary format with:

  • MAPs (key-value pairs, similar to JSON objects).
  • ARRAYs (ordered lists).
  • Scalar types (INT32, INT64, SYMBOL, STRING, etc.).
  • Nested structures (MAPs/ARRAYs can contain other MAPs/ARRAYs).

Example Escher MAP structure:

[0:2]   u16  total_byte_length
[2:4]   u16  num_items
[4:8]   u32  internal_ptr
[8:]    Index entries (4 bytes each):
         bits [31:13]  symbol value (19 bits, base-27 encoded)
         bits [12:9]   typecode (4 bits)
         bits [8:0]    data_offset (9 bits, in 4-byte words from MAP start)

2. Replace Wireshark APIs with InfiniStreamNG Equivalents

Your Wireshark dissector relies on Wireshark’s Lua API, which is GUI-focused and not compatible with InfiniStreamNG. Here’s how to map the key functions:

Wireshark LuaInfiniStreamNG LuaExample
tvb(offset, length):uint()payload:uint32_be(offset + 1)local total_len = payload:uint16_be(offset + 1) (1-based indexing).
tvb(offset, length):int64()payload:int64_be(offset + 1)local val = payload:int64_be(data_offset + 1)
tree:add(proto, tvb, label)packet:add_custom_field(name, value)packet:add_custom_field("escher.ACTN", "REQ ")
DissectorTable.get("tcp.port")register_dissector(name, port, func)register_dissector("ESCHER", 1500, dissect_escher)
bit.band(), bit.rshift()Same (InfiniStreamNG includes bit library).local typecode = bit.band(bit.rshift(entry_raw, 9), 0x0F)

3. Handle Big-Endian Fields Explicitly

InfiniStreamNG provides explicit big-endian methods for multi-byte fields. Replace all multi-byte reads with:

  • payload:uint16_be(offset)
  • payload:uint32_be(offset)
  • payload:int64_be(offset)

Example:

4. Optimise for Performance

Example:

-- Wireshark:
local total_len = tvb(offset, 2):uint()

-- InfiniStreamNG:
local total_len = payload:uint16_be(offset + 1)  -- +1 for 1-based indexing

InfiniStreamNG probes process millions of packets per second, so your Lua script must be highly optimised:

  • Cache repeated lookups (e.g., FIELD_LABELS[sym_name]).
  • Avoid loops over large tables (e.g., pairs(FIELD_LABELS)).
  • Minimise add_custom_field calls (each call adds overhead).
  • Use local variables (Lua accesses locals faster than globals).
-- ❌ Slow (repeated global lookups):
for i = 0, num_items - 1 do
    local sym_name = decode_symbol(payload:uint32_be(idx_off + 1))
    local label = FIELD_LABELS[sym_name] or sym_name
    packet:add_custom_field("escher." .. sym_name, label)
end

-- ✅ Faster (local references):
local FIELD_LABELS_LOCAL = FIELD_LABELS
for i = 0, num_items - 1 do
    local sym_val = payload:uint32_be(idx_off + 1)
    local sym_name = decode_symbol(sym_val)
    local label = FIELD_LABELS_LOCAL[sym_name] or sym_name
    packet:add_custom_field("escher." .. sym_name, label)
end

5. Validate All Offsets and Lengths

InfiniStreamNG does not gracefully handle out-of-bounds buffer access. Always validate:

if offset + 4 > payload:len() then return 0 end
local total_len = payload:uint32_be(offset + 1)

⚡ Performance Considerations

1. Probe Resource Usage

InfiniStreamNG probes are high-performance appliances, but Lua scripts do consume CPU and memory. Here’s what to monitor:

MetricImpactTarget
CPU UsageLua dissection adds ~1-5% CPU per Gbps of traffic.Keep total Lua CPU usage <20% to avoid impacting other probe functions.
Memory UsageEach Lua script consumes ~1-10MB (depends on tables like FIELD_LABELS).Monitor with show memory in the probe CLI.
LatencyAim for <1ms per packet to avoid impacting probe performance.Test with show lua stats to measure script execution time.

2. Optimisation Techniques

To ensure your dissector runs efficiently on InfiniStreamNG:

TechniqueImpactExample
Limit Custom FieldsReduces add_custom_field calls (each adds ~1-2μs overhead).Only extract ACTN, TYPE, CMID (not every field).
Cache LookupsAvoids repeated table accesses (e.g., FIELD_LABELS[sym_name]).Use local variables: local FIELD_LABELS_LOCAL = FIELD_LABELS.
Avoid LoopsLua loops are slow; unroll or minimise iterations.Precompute offsets; avoid for i=1,1000.
Use 1-Based IndexingInfiniStreamNG Lua uses 1-based strings (unlike Wireshark’s 0-based tvb).payload:sub(1, 4) (not payload:sub(0, 3)).
Limit Recursion DepthPrevents stack overflows in deeply nested structures.if depth > 20 then return end.
Validate OffsetsPrevents crashes from malformed packets.if offset + 4 > payload:len() then return 0 end.

3. Testing and Validation

Lab Testing

  • Deploy the script to a non-production InfiniStreamNG probe:
scp escher_dissector.lua admin@<probe_ip>:/netscout/lua_scripts/
ssh admin@<probe_ip> "lua_load escher_dissector.lua"
  • Replay test traffic (e.g., using tcpreplay):
tcpreplay -i eth0 -p 1500 escher_traffic.pcap
  • Monitor probe performance:
    • CPU: top, htop.
    • Lua Errors: tail -f /var/log/netscout/lua_errors.log.
    • Custom Fields: Verify in nGeniusONE (e.g., escher.ACTN, escher.TYPE).

Production Rollout

  • Start with a subset of traffic (e.g., one probe, one port).
  • Monitor for 24-48 hours before full deployment.
  • Fallback plan: Disable the script if performance degrades:
ssh admin@<probe_ip> "lua_unload escher_dissector.lua"

📈 Use Cases in nGeniusONE

Once the dissector is deployed, you can leverage the custom fields in nGeniusONE for:

1. Real-Time Dashboards

Create custom dashboards in nGeniusONE to monitor:

  • Escher Message Types (e.g., REQ, HTBT, EXCP).
  • Error Rates (e.g., escher.ACTN == "EXCP").
  • Traffic Volume (e.g., bytes/sec, messages/sec).

Example Dashboard Widgets:

WidgetMetricVisualisation
Top Escher Message Typesescher.ACTN (count by type)Bar Chart
Escher Errors Over Timeescher.ACTN == "EXCP" (count)Line Graph
Escher Traffic Volumeescher.map.total_len (sum)Area Chart
Escher LatencyTime between REQ and RESPHistogram

2. Alerts and Troubleshooting

Configure proactive alerts in nGeniusONE for:

  • High error rates (e.g., escher.ACTN == "EXCP" > 5/min).
  • Missing heartbeats (e.g., no escher.TYPE == "HTBT" for 60s).
  • Unusual message types (e.g., unknown escher.ACTN).

Example Alert Rule:

IF (escher.ACTN == "EXCP") AND (count > 5) THEN
    trigger "Escher Error Spike" (Severity: High)
    notify: Email, SMS
END

3. Session Analysis

Use nGeniusONE’s Session Analyzer to:

  • Track end-to-end call flows: Correlate REQ → RESP sequences.
  • Link Escher to other protocols: For example, tie Escher EXCP messages to Diameter 4010 (Insufficient Funds) responses.
  • Drill down into individual sessions: Inspect raw Escher messages alongside Diameter/SIP.

Example Workflow:

  1. Filter for sessions with escher.ACTN == "EXCP".
  2. Drill down to see the full Escher message (including BODY and HEAD fields).
  3. Correlate with Diameter Gy messages in the same session.

4. Historical Analysis

Leverage nGeniusONE’s historical data to:

  • Trend Escher traffic over time (e.g., daily/weekly patterns).
  • Identify anomalies (e.g., spikes in EXCP messages).
  • Compare with other protocols (e.g., Escher vs. Diameter latency).

Example Historical Report:

  • Escher Traffic Trends: Messages/sec over the last 30 days.
  • Error Correlation: Compare escher.ACTN == "EXCP" with Diameter Result-Code == 4010.

🔗 Resources and Further Reading

🚀 Conclusion: Unlocking Full Visibility with Custom Dissectors

Adapting a Wireshark Lua dissector for NetScout InfiniStreamNG bridges the gap between offline analysis and real-time monitoring. By leveraging InfiniStreamNG’s Lua scripting capabilities, you can:
✅ Monitor proprietary protocols (like Escher) in real-time.
✅ Integrate with nGeniusONE for dashboards, alerts, and troubleshooting.
✅ Gain end-to-end visibility into custom and standard protocols in a single pane of glass.

While the adaptation process requires careful attention to performance and API differences, the payoff is production-grade visibility into previously opaque traffic. This approach is not just for Escher, it can be applied to any custom protocol in your network, unlocking new levels of observability and control.

Have you adapted a Wireshark dissector for InfiniStreamNG or another monitoring tool? Share your experiences!

Author Bio
Tony Craven is a telecom and network solutions architect with over 20 years of experience in Oracle Communications Network Charging and Control (OCNCC) and real-time protocol analysis. He is a strategic technology executive with proven leadership in telecommunications, IoT, and SaaS, specialising in scalable, cloud-based solutions for global enterprises and startups. Adept at bridging vision and execution, from post-merger technical integration to architecting high-availability infrastructure supporting millions of IoT devices.

From API Layer to AI-Native OCS: Exposing Charging Intelligence via MCP

From API Layer to AI-Native OCS: Exposing Charging Intelligence via MCP

by | Apr 30, 2026 | OCNCC, Architecture

A few weeks ago, I shared how I built a RESTful API layer over Oracle’s OCNCC billing engine using decoded Escher protocol flows. The response from operators, MVNEs, and BSS/OSS teams was overwhelming—and it led to a simple but powerful question:

Could this API layer be exposed to AI agents?

The answer is yes, and the implications for Online Charging Systems (OCS) are far bigger than I initially anticipated.

The Problem: OCS Platforms Are Still Black Boxes

Most OCS platforms, whether Oracle OCNCC, Matrixx, or legacy IN stacks, remain hidden behind proprietary protocols (like Escher) and limited integration surfaces. Even basic operational queries often require:

  • Deep platform-specific knowledge.
  • Custom-built tooling or SDKs.
  • Manual intervention for troubleshooting or automation.

This creates a barrier to innovation. While modern telecom networks (especially 5G) demand agility, real-time intelligence, and automation, the charging layer often lags behind, locked in a specialist-driven model.

The Solution: MCP as a Bridge to AI-Native OCS

To solve this, I’ve been experimenting with Model Context Protocol (MCP), an open standard for exposing tools, data, and capabilities to AI agents in a structured, machine-readable way. Here’s how it works:

Architecture Overview

Integrating AI Agents Into A Real-time OCS

Key Design Principles:

  1. Non-Invasive: The MCP layer sits in front of your existing API and Oracle query layers, leaving the underlying OCNCC stack untouched. No re-architecture required.
  2. Tool-Centric: Instead of exposing raw endpoints, the system presents meaningful, self-descriptive tools that AI agents can reason about, not just execute.
  3. Standardised: MCP provides a common language for AI to interact with OCS capabilities, regardless of the underlying platform (OCNCC, Matrixx, etc.).

What Does an AI-Native OCS Look Like?

By exposing OCS capabilities via MCP, AI agents gain the ability to:

  • Understand what operations are possible (e.g., subscriber lookups, balance adjustments, policy controls).
  • Reason about when and why to use them (e.g., “This subscriber’s session failed, check their balance and profile”).
  • Execute actions with structured, auditable precision.

Example Tools Exposed via MCP

Here’s a snapshot of the OCS capabilities currently exposed in the prototype:

ToolDescriptionUnderlying Action
lookup_subscriberRetrieve subscriber details (balance, profile, status) by MSISDN or IMSI.API call to OCNCC’s subscriber database.
query_network_topologyFetch the current network topology (nodes, connections, status).SQL query to OCNCC’s topology tables.
inspect_profileReturn a subscriber’s active profile blocks (e.g., barring, roaming restrictions).Escher protocol message (decoded via API).
adjust_balanceDeduct or add balance for a subscriber (with validation).OCNCC charging API call.
reset_bundleTrigger a monthly/weekly bundle reset for a subscriber or group.Batch API call to OCNCC.
check_service_eligibilityVerify if a subscriber is eligible for a service (e.g., 5G slicing, roaming).Policy control API call.
correlate_alarmsCross-reference active alarms with subscriber sessions or network events.Joins OCNCC logs with alarm databases.

Why This Matters:

  • No More Silos: AI agents can query and act across charging, policy, and network layers without jumping between systems.
  • Natural Language Interfaces: Tasks like bundle resets or subscriber diagnostics, which previously required SDKs or APIs, can now be triggered via conversational queries (e.g., “Why did MSISDN 447123456789’s session fail?”).
  • Automation-Ready: Routine operations (e.g., balance adjustments, profile updates) can be automated via AI workflows.

Use Cases: How AI-Native OCS Changes Operations

1. Support Workflows: Diagnose Issues in Seconds

Before:

  • A support agent receives a complaint: “My data isn’t working.”
  • They manually check OCNCC logs, subscriber profiles, and network alarms, often requiring multiple tools and logins.

After (with MCP):

  • The agent (or a customer-facing chatbot) asks the AI:“Diagnose why MSISDN 447123456789 can’t access data.”
  • The AI:
    1. Calls lookup_subscriber → Finds the subscriber has insufficient balance.
    2. Calls inspect_profile → Confirms no barring is active.
    3. Calls query_network_topology → Verifies the subscriber’s serving node is operational.
    4. Conclusion: “Subscriber has £0 balance. Top up required.”
  • Result: Faster resolution, fewer escalations, and happier customers.

2. Network Operations: Correlate Alarms and Charging Events

Before:

  • A network alarm fires for a billing engine node.
  • NOC teams manually cross-reference alarms with subscriber sessions and charging logs to identify impact.

After (with MCP):

  • The AI automatically:
    1. Calls correlate_alarms → Links the alarm to 1,200 failed charging sessions on that node.
    2. Calls query_network_topology → Identifies the node is overloaded.
    3. Action: Triggers a load-balancing adjustment or node restart (if automated).
  • Result: Proactive issue resolution before subscribers are impacted.

3. 5G Policy Control: Dynamic, AI-Driven Charging

Before:

  • 5G Policy Control Function (PCF) makes static charging decisions (e.g., “Allow this slice if balance > £10”).
  • No real-time intelligence: Can’t adapt to network congestion, subscriber behaviour, or business priorities.

After (with MCP):

  • The PCF queries the AI:“Should I allow a new 5G slice for MSISDN 447123456789? They’re roaming in Spain with £5 balance.”
  • The AI:
    1. Calls lookup_subscriber → Confirms £5 balance.
    2. Calls check_service_eligibility → Checks roaming agreements for Spain.
    3. Calls query_network_topology → Sees high congestion in Spain.
    4. Decision: “Deny slice. Suggest downgrading to 4G to avoid overage charges.”
  • Result: Smarter policy control, reduced revenue leakage, and better subscriber experience.

4. MVNO Operations: Self-Service Charging Management

Before:

  • MVNOs rely on manual requests to the host operator for bundle resets, balance adjustments, or reporting.

After (with MCP):

  • MVNOs interact with the OCS via AI:“Reset monthly bundles for all subscribers on the ‘Premium’ plan.”
  • The AI:
    1. Calls reset_bundle for all ‘Premium’ subscribers.
    2. Logs the action for audit and billing reconciliation.
  • Result: Faster operations, reduced errors, and lower OPEX.

The Bigger Picture: Why This Matters for Telecom

1. Democratising OCS Access

  • Today: OCS platforms are specialist-driven. Only engineers with deep platform knowledge can extract insights or automate workflows.
  • Tomorrow: With MCP, anyone (support agents, NOC teams, even subscribers via chatbots) can query and act on charging data—without writing code.

2. Enabling AI-Driven Automation

  • Predictive Charging: AI can anticipate balance depletion and proactively notify subscribers or trigger auto-top-ups.
  • Anomaly Detection: AI can flag unusual patterns (e.g., fraud, misconfigurations) in real time.
  • Dynamic Pricing: AI can adjust pricing based on network demand, subscriber loyalty, or competitor offers.

3. Future-Proofing for 6G and Beyond

  • As networks evolve toward 6G, AI-native architectures will become the norm.
  • MCP provides a standardised way to expose any OCS or IN platform (OCNCC, Matrixx, legacy IN) to AI, without vendor lock-in.

What’s Next? The Roadmap for AI-Native OCS

This started as a personal R&D exercise, but the architectural pattern is universal. Any OCS or IN platform with a queryable data layer and a billing interface can be exposed via MCP. Here’s what’s left to do:

1. Expand the Tool Surface

  • Add more OCS capabilities as MCP tools (e.g., refunds, shared balance groups, QOS adjustments).
  • Support bulk operations (e.g., “Apply a discount to all subscribers in region X”).

2. Tighten Security Boundaries

  • Role-Based Access Control (RBAC): Restrict which AI agents can call which tools (e.g., a support chatbot can’t adjust balances).
  • Audit Logging: Track every AI-driven action for compliance and debugging.
  • Rate Limiting: Prevent abuse (e.g., an AI agent spamming lookup_subscriber).

3. Ensure Full Observability

  • Logging: Capture all MCP requests/responses (e.g., via Prometheus).
  • Tracing: Correlate AI actions with OCNCC logs and network events.
  • Alerting: Notify operators of failed AI-driven operations (e.g., “Balance adjustment failed for MSISDN 447123456789”).

4. Integrate with AI Orchestration Layers

  • Connect MCP to AI orchestration platforms (e.g., LangGraph, Microsoft Autogen) for multi-step workflows.
  • Example: “If a subscriber’s balance is low AND they’re roaming, send them a top-up reminder via SMS.”

The Future: From API-Enabled to AI-Native OCS

We’re at an inflection point. APIs made OCS platforms programmable. MCP makes them AI-native.

  • Phase 1 (Now): APIs expose OCS capabilities to developers.
  • Phase 2 (Emerging): MCP exposes them to AI agents.
  • Phase 3 (Future): Fully autonomous OCS, where AI manages charging in real time, optimising revenue, reducing churn, and enabling self-healing networks.

This isn’t just about efficiency. It’s about unlocking the full potential of your OCS platform, whether it’s Oracle OCNCC, Matrixx, or a legacy IN stack.

Let’s Collaborate

This is still early days, but the direction is clear: AI-native OCS is coming, and MCP is the key to getting there without replacing your existing infrastructure.

If you’re working with OCNCC, Matrixx, or similar platforms and exploring how AI fits into your operational model, I’d love to compare notes. Here are some questions to kick off the discussion:

  • Have you experimented with AI-driven telecom operations?
  • What OCS capabilities would you prioritise exposing to AI?
  • How do you see MCP (or similar protocols) fitting into your roadmap?

Reach out or connect with me on LinkedIn.

From 4G Session-Based OCS to 5G Event-Based OCS: Unlocking OCNCC’s Potential with a RESTful API Layer

From 4G Session-Based OCS to 5G Event-Based OCS: Unlocking OCNCC’s Potential with a RESTful API Layer

by | Apr 30, 2026 | OCNCC, Architecture

The telecom industry’s shift from 4G’s session-based Online Charging System (OCS) to 5G’s event-driven architecture demands a fundamental rethink of how charging systems integrate with core networks. For operators using Oracle Communications Network Charging and Control (OCNCC), this transition presents both a challenge and an opportunity: How can a traditionally session-oriented platform like OCNCC evolve to support the agility and real-time demands of 5G?

Over the recent weeks, I’ve been exploring this question, not just theoretically, but by building a proof-of-concept API layer that abstracts OCNCC’s proprietary Escher protocol into a modern, RESTful interface. The goal? To transform OCNCC from a session-based OCS into an event-based powerhouse, capable of seamless integration with 5G control planes, MVNO setups, and cloud-native architectures.

Exposing a 4G Session Based Architecture to 5G Event Based

The Problem: Session-Based OCS in a 4G World

In 4G networks, OCS typically operates in a session-based model:

  • Charging decisions are tied to active sessions (e.g., data, voice, or messaging).
  • The Escher protocol (Oracle’s proprietary interface for OCNCC) handles real-time interactions between the Billing Engine (VWS) and other network elements.
  • Limitations:
    • Tight coupling with session state makes it difficult to scale or integrate with modern, stateless systems.
    • Direct protocol handling (e.g., via SDKs) is complex, error-prone, and lacks flexibility for dynamic use cases like 5G’s event-driven charging.
    • Limited observability into protocol-level interactions, making troubleshooting and optimisation difficult.

For operators looking to modernise their charging infrastructure, these constraints can feel like a roadblock—especially when aiming to adopt 5G’s service-based architecture (SBA), where event-driven interactions (e.g., HTTP/2, JSON) replace traditional session-based protocols.

The Solution: Decoding Escher to Build an Event-Based API Layer

Step 1: Gaining Visibility with a Wireshark Dissector

The first hurdle is understanding Escher’s message flows. Without visibility into the protocol, it’s nearly impossible to design a robust abstraction layer. To solve this, I developed:

  • A custom Wireshark dissector for Escher, enabling deep packet inspection of OCNCC interactions.
  • A Javascript PCAP-to-JSON decoder to convert captured network traffic into structured, analysable data.

Result: A blueprint of Escher message sequences, including:

  • Session establishment/teardown flows.
  • Balance deduction and reservation logic.
  • Error handling and retry mechanisms.

This step was critical, in order to reverse-engineer the protocol’s behaviour and identify which operations could (and should) be exposed via a RESTful API.

Step 2: Abstracting Escher into a RESTful API

With the decoded flows in hand, we can, and have built a cloud supported JavaScript-based API server that:

  • Interfaces directly with OCNCC’s billing engines (VWS) via Escher.
  • Exposes every key operation as a RESTful endpoint, effectively decoupling the protocol from the application layer.

Key Features of the API Layer:

FeatureBenefit
JWT-based authenticationSecure access with token-based client authentication.
Client-level access controlRestrict endpoints per integration (e.g., MVNOs, 5G core functions).
Redis cachingImprove performance for high-frequency operations (e.g., balance checks).
Structured interaction modelRepeatable, predictable workflows for charging operations.
Subscriber data retrievalFetch subscriber profiles directly from OCNCC’s database.
Profile block managementBasic subscriber profile updates (e.g., barring/unbarring).

Example Endpoints:

POST /api/sessions/{sessionId}/charge      # Deduct balance for a session event
GET  /api/subscribers/{msisdn}/balance     # Retrieve subscriber balance
PUT  /api/subscribers/{msisdn}/profile     # Update subscriber profile
GET  /api/statistics                       # Observability metrics (e.g., QPS, latency)

Step 3: Enabling Event-Based OCS for 5G

By exposing OCNCC’s charging logic via RESTful APIs, the system can now:

  1. Integrate with 5G’s Service-Based Architecture (SBA):
    • Replace session-based Escher interactions with event-driven HTTP/2 calls (e.g., from the 5G PCF or CHF).
    • Support stateless charging decisions, aligning with 5G’s microservices approach.
  2. Support MVNO and Multi-Tenant Scenarios:
    • Client-level access control allows different MVNOs or partners to interact with only their permitted endpoints.
    • JWT tokens ensure secure, auditable access.
  3. Improve Observability and Debugging:
    • Built-in statistics and logging provide visibility into charging operations, a major improvement over opaque protocol interactions.
  4. Simplify Monthly Bundle Resets:
    • Previously required custom SDK scripts; now handled via a single API call (e.g., POST /api/bundles/reset).

Why This Matters for OCNCC Operators

1. Future-Proofing for 5G

5G’s event-based charging requires systems that can:

  • Handle high-volume, low-latency interactions (e.g., for IoT or URLLC use cases).
  • Support dynamic policy control (e.g., real-time QOS adjustments).
  • Integrate with cloud-native functions (e.g., Kubernetes-based NFs).

An API layer abstracting OCNCC’s Escher protocol bridges the gap between legacy OCS and modern 5G architectures.

2. Reducing Integration Complexity

Traditional OCNCC integrations often require:

  • Custom SDK development for each use case.
  • Deep protocol knowledge (Escher is proprietary and poorly documented).
  • Tight coupling with session state.

With a RESTful API:

  • Developers interact with familiar HTTP endpoints instead of raw Escher messages.
  • New services can be onboarded faster (e.g., a new MVNO or 5G network slice).

3. Unlocking New Use Cases

Potential applications include:

  • Real-time charging for 5G slicing: Dynamically adjust charging based on slice SLA.
  • Convergent charging: Unify prepaid/postpaid logic across 4G/5G.
  • AI-driven policy control: Use API hooks to inject ML-based charging decisions.

The Road Ahead: From Proof-of-Concept to Production

While the current implementation is a personal proof-of-concept, the framework is already functional for several key OCS operations. To move this toward a production-ready solution, the next steps include:

  1. Extending Endpoint Coverage:
    • Add support for all critical Escher operations (e.g., session termination, refunds, shared balance groups).
    • Implement idempotency keys for retry safety.
  2. Enhancing Security:
    • Rate limiting to prevent abuse.
    • Field-level encryption for sensitive subscriber data.
    • Audit logs for compliance (e.g., GDPR).
  3. Performance Optimisdation:
    • Connection pooling for Escher protocol sessions.
    • Asynchronous processing for non-blocking operations.
  4. QA and Validation:
    • Load testing to ensure scalability (e.g., 10K+ TPS).
    • Failure mode testing (e.g., billing engine timeouts).
  5. Documentation and SDKs:
    • OpenAPI/Swagger specs for easy integration.
    • Client libraries (e.g., Python, Java) to simplify adoption.

A Call to Collaborate

This project started as a way to scratch an itch, gaining visibility into OCNCC’s Escher protocol, but it’s evolved into something with far broader potential. By abstracting OCNCC’s charging logic into a modern API, we can:

  • Modernise legacy OCS platforms without rip-and-replace.
  • Enable 5G-ready charging architectures today.
  • Open new integration possibilities for MVNOs, IoT, and cloud-native networks.

If you’re an OCNCC operator or telecom architect exploring ways to transition from session-based to event-based charging, I’d love to discuss how this approach could work for your use case. Whether it’s a pilot project, a specific integration challenge, or just a brainstorming session, let’s connect and explore the possibilities.