🔍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
Feature
Benefit
Relevance to Custom Protocols
Real-Time Visibility
Monitors 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.
Enables tracking of Escher messages alongside standard protocols in a single workflow.
Custom Dashboards and Alerts
Create 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 Architecture
Handles 10Gbps+ traffic with distributed probes (InfiniStreamNG, vSTREAM).
Lua scripts run directly on the probe, ensuring low-latency processing even at scale.
Historical and Trend Analysis
Stores long-term data for trend analysis, capacity planning, and forensic investigations.
Custom protocol data can be historically analysed alongside other network metrics.
Unified Workflow
Single pane of glass for network, application, and service-layer visibility.
Escher traffic can be seamlessly integrated with other protocols in nGeniusONE’s UI.
Open Extensibility
Supports 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:
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 Lua
InfiniStreamNG Lua
Example
tvb(offset, length):uint()
payload:uint32_be(offset + 1)
local total_len = payload:uint16_be(offset + 1) (1-based indexing).
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:
Metric
Impact
Target
CPU Usage
Lua dissection adds ~1-5% CPU per Gbps of traffic.
Keep total Lua CPU usage <20% to avoid impacting other probe functions.
Memory Usage
Each Lua script consumes ~1-10MB (depends on tables like FIELD_LABELS).
Monitor with show memory in the probe CLI.
Latency
Aim 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:
🚀 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.
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:
Feature
Benefit
JWT-based authentication
Secure access with token-based client authentication.
Client-level access control
Restrict endpoints per integration (e.g., MVNOs, 5G core functions).
Redis caching
Improve performance for high-frequency operations (e.g., balance checks).
Structured interaction model
Repeatable, predictable workflows for charging operations.
Subscriber data retrieval
Fetch subscriber profiles directly from OCNCC’s database.
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:
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.
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.
Improve Observability and Debugging:
Built-in statistics and logging provide visibility into charging operations, a major improvement over opaque protocol interactions.
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 chargingrequires 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:
Extending Endpoint Coverage:
Add support for all critical Escher operations (e.g., session termination, refunds, shared balance groups).
Implement idempotency keys for retry safety.
Enhancing Security:
Rate limiting to prevent abuse.
Field-level encryption for sensitive subscriber data.
Audit logs for compliance (e.g., GDPR).
Performance Optimisdation:
Connection pooling for Escher protocol sessions.
Asynchronous processing for non-blocking operations.
QA and Validation:
Load testing to ensure scalability (e.g., 10K+ TPS).
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.
Debugging Oracle Communications Network Charging and Control (OCNCC) has long been a pain point for telecom engineers who operate the platform in production environments. The traditional approach, enabling debug logging, floods systems with verbose output, degrades performance, and is often impractical in live environments. For years, this left teams with a tough choice: either accept limited visibility or risk operational instability.
But what if there was a way to bypass the logs entirely and inspect OCNCC’s inner workings at the packet level? That’s exactly what my new Wireshark dissector for the Escher protocol achieves. After months of reverse-engineering, hex-dump analysis, and collaboration with AI (Claude, in my case), I’ve built a tool that decodes Escher traffic in real time, no logging required.
In this post, I’ll share:
The challenges of debugging OCNCC with traditional methods.
How the Escher protocol works and why it’s so hard to inspect.
The solution: A custom Wireshark dissector that brings clarity to Escher traffic.
How you can licence this tool to streamline your own OCNCC troubleshooting.
The Problem: Why Debugging OCNCC is a Headache
1. The Limitations of Debug Logging
OCNCC’s debug logging is a double-edged sword. While it provides detailed insights into system behaviour, it comes with major drawbacks:
Performance Overhead: Enabling debug mode can slow down your OCNCC instance, making it unsuitable for production environments.
Information Overload: Logs generate massive volumes of data, making it difficult to isolate the root cause of issues.
No Real-Time Analysis: Debug logs are reactive, you only see problems after they’ve occurred.
For engineers like me, this meant spending hours sifting through logs, often with no guarantee of finding the answer.
2. The Escher Protocol: A Black Box
OCNCC uses a proprietary protocol called Escher for internal communication. While you can capture Escher traffic in PCAP files (via tools like tcpdump or Wireshark), the lack of native support in Wireshark renders these captures useless for analysis. Without a dissector, Escher packets appear as undecoded hex dumps, a wall of numbers and letters with no context.
Without a dissector, Escher traffic is just a wall of hex, impossible to interpret.
The Protocol: Escher 101
The ESCHER protocol, is a compact binary messaging format designed for efficient, structured data exchange over TCP. At its core, ESCHER represents data as typed key–value maps and arrays, where keys are encoded as fixed 4-character symbols and values are strongly typed (integers, floats, strings, dates, nested objects, etc.). Messages are tightly packed with alignment and indexing structures that allow fast lookup and minimal overhead, making the format well-suited to high-performance environments such as real-time billing or transaction processing systems.
The protocol operates over standard network layers by embedding ESCHER payloads inside TCP packets, which can then be captured and analysed using PCAP tooling like Wireshark, although decoding is not available without natively.
A key design feature is the deterministic encoding of fields and ordering of keys, enabling efficient binary search within messages and consistent interoperability between systems. Combined with its compact wire format and explicit typing, ESCHER strikes a balance, when decoded, between human-readable structures and, when encoded, a highly optimised binary transport, making it particularly effective for systems that require both performance and traceability.
The Solution: A Wireshark Dissector for Escher
How It Works
After countless hoursof analysing hex dumps, cross-referencing with debug logs, and writing Lua scripts (with a little help from Claude AI), I’ve created a Wireshark dissector that:
Decodes Escher packets at the protocol level, revealing their structure and fields.
Enables filtering directly in Wireshark (e.g., escher.msg_type == WI).
Works in real time, so you can monitor live traffic without touching OCNCC’s logging framework.
From hex dumps to clarity: The dissector reveals Escher’s structure in Wireshark.”
Key Features
Feature
Benefit
Packet-Level Decoding
See Escher messages as human-readable data in Wireshark.
Filters
Filter traffic by protocol fields, e.g.:
escher – All ESCHER packets
escher.val.string contains “RuntimeError” – Packets containing a specific string value
escher.val.symbol == “WI ” – Packets where any symbol field equals WI
escher.val.int32 == 12 – Packets where any INT32 field equals 12
escher.val.date – Packets that contain a DATE field
escher.map.items > 3 – Top-level maps with more than 3 items
escher.entry.raw == 0x00f80606 – Packets containing a specific raw index entry
No Performance Impact
Runs independently of OCNCC, so no risk to production systems.
Why This Matters for OCNCC Engineers
1. Faster Troubleshooting
With the dissector, you can:
Isolate issues by filtering for specific Escher message types or error codes.
Validate protocol compliance without relying on logs.
Monitor live traffic to catch problems as they happen.
2. Reduced Risk in Production
Since the dissector doesn’t require debug logging, you can:
Analyse traffic without impacting OCNCC performance.
Use it in live environments where logging is prohibited.
3. A Tool Built by an Engineer, for Engineers
This isn’t a theoretical solution, it’s a practical tool born from real-world frustration. As someone with20+ years of OCNCC, and real-time charging experience, I designed this dissector to solve the exact problems my team faced in the field.
The new workflow: No logs, no guesswork, just clarity.
How to Get the Escher Wireshark Dissector
The dissector is available for licensing to organisations and individuals who need to debug, monitor, or analyse OCNCC traffic. Here’s how to get it:
Licensing Options
Option
Description
Best For
Single-User License
One-time fee for personal use (non-commercial).
Independent engineers.
Team License
Up to 10 users within a single organisation.
Small to medium telecom teams.
Enterprise License
Unlimited users + customisation support.
Large enterprises or MNOs.
Custom Development
Need additional features or integration with other tools? Let’s talk.
Tailored solutions.
Next Steps
Contact Me: Reach out via the contact form to discuss your needs.
Demo Available: I can provide a short demo of the dissector in action (via screen share).
Customisation: Need support for a specific OCNCC version or functionality? I can tailor the dissector or build SDK solutions to your requirements.