CeRC

The eyes and ears of the network

Every other system described on this site tells you how the network is configured. Inventory, topology and configuration models describe intent, and a digital twin correlates that intent across domains. None of them can tell you what a subscriber standing in a particular place, on a particular handset, on a particular software build, actually experiences. CeRC can, because it is that subscriber: ordinary consumer handsets, unrooted, on the current OS, placing real calls and loading real pages, from wherever you choose to put them.

• The model knows the plan. CeRC knows the outcome. The distance between the two is where service quality is quietly lost.
• Counters can tell you a cell is healthy. They cannot tell you that an IVR menu changed, that a roaming APN broke for one device family, or that an app journey now fails at step four.
• It reports what it saw with the evidence attached: signalling capture, audio recording and transcription, on-screen state, location and timing.
• Because the devices are pooled and remotely driven, the same estate serves the lab, the device-certification function and the live network without being rebuilt for each.

Deliberately not a synthetic probe. The value is precisely that it is an ordinary handset doing an ordinary thing, so what it measures is what a customer would have got.

Why manual testing no longer scales

• Networks keep getting more complex — every operator now maintains and tests at least three radio access technologies in parallel, usually multi-vendor, with 5G and virtualisation adding layers without removing the old ones.
• Release cycles have compressed — agile delivery by network and software vendors pushes disruptive updates faster than test teams can absorb manually.
• The service portfolio keeps expanding — new layers arrive without legacy services being retired, so the test matrix only grows.
• Device variety is outside the operator's control — subscribers arrive with handsets bought anywhere and upgrade constantly.
• Quality is mission-critical — thousands of services depend on always-on connectivity, and switching provider has never been easier.

Three building blocks

A distributed platform driving real handsets.

1. IoT platform (centralised backend)

   The command centre: device management, scheduling, automation, monitoring, auditing, alarm handling, reporting, and an open API for interoperability, with identity, security, access and system management built in.

2. Gateway controllers (distributed)

   Physical controllers bridging the platform and the handsets over Ethernet, Wi-Fi or 3GPP. Each controller drives up to five devices, and can be deployed anywhere the network needs testing.

3. Mobile handsets (distributed)

   Standard consumer Android and iOS devices. Every device connected joins a shared pool and can be tasked with any network test from any location, allocated intelligently in real time to maximise utilisation.

Three modes of operation

• Full remote control — browser-based control of any device regardless of location: real-time refresh, all gestures (tap, swipe, pinch), all system keys, customisable shortcuts, file-system access and app deployment. Ideal for remote troubleshooting and ad-hoc verification.
• Scriptless automation — test cases assembled in a drag-and-drop builder from hundreds of predefined script objects for Android and iOS. Standard functions (calls, SMS, USSD, IVR recording, data sessions) work out of the box; skilled users can extend or write their own in shell, VBScript, Java or Python. Tests run on schedule or on demand, in parallel across devices, regions and platforms.
• Deep integration — CeRC drives third-party lab and network equipment to automate an entire test chain: configure the network element, set RF levels and attenuation, allocate a virtual SIM, start a trace, run the device test, then analyse the result. Interfaces include Telnet, SSH, SQL, USB, RS232, GPIB, HiSLIP, VXI-11, VISA, raw Ethernet, sockets, MML, XML, JSON, text files and equipment SDKs.

What it can test

• Voice — mobile-to-mobile calls on 2G, 3G and VoLTE including cross-technology calls; long-duration calls measuring call setup success rate and drop-call rate; up- and down-link audio streaming; audio insertion and extraction with speech-to-text; voice quality scoring (MOS/POLQA).
• Data — FTP and HTTP upload/download throughput by technology, ping latency and packet loss, web page load times, video streaming and OTT application checks.
• Messaging and self-service — SMS send/receive with content evaluation and delivery timing, USSD menus, IVR navigation with recording and transcription.
• Applications — operator app testing via screen dumping (on-screen text and objects exported to XML for reliable evaluation), purpose-built test hooks, and full APK lifecycle management including install, upgrade and permissions.
• Certification — new device certification, OS release testing, network interoperability, element software release validation, new vendor equipment validation and network feature testing.
• Assurance extras — signalling capture and analysis across the 3GPP and IETF stack with Wireshark-style decoding; CDR/EDR collection and content verification for charging and revenue assurance; roaming testing aligned to GSMA IR.24 and IR.35; virtual and remote SIM allocation.

What makes it different

• Full device remote control and view — very few automation platforms let an engineer actually see and drive the device to confirm a test state or run something ad hoc.
• Real devices on the latest OS — no rooting or jailbreaking, so tests run on exactly the hardware and software a subscriber would use.
• Scriptless test creation — no scripting or deep device knowledge needed to build complex, reliable cases, so the operator is not dependent on the vendor to improve tests over time.
• Signalling and audio depth — automatic protocol capture and analysis plus ITU-compliant voice-path verification and built-in speech-to-text, replacing hundreds of hours of manual tracing and listening.
• Network-side automation — native MML and GUI integration with major network and IT equipment vendors, so a test can reconfigure the network, verify behaviour, and set it back.

AI-driven validation: closing the loop on a change

A change is only safe if something can tell you whether it worked. Today the two halves of that check exist separately: the configuration side validates the script before it runs, and CeRC measures the experience after it has. Joining them is what makes higher autonomy levels reachable, because a system cannot be trusted to act on its own until something independent can confirm the result it produced.

1. Baseline

   Before the change, the control plane runs the relevant test set on real devices in the affected area and keeps the result as the reference.

2. Pre-flight

   The change script is checked for syntax, parameter validity and element existence against the live configuration model, and the bad subset is rejected before anything executes.

3. Apply

   The change goes out under whichever autonomy setting the operator has chosen for that scenario: testing, human-approve, or autonomous.

4. Re-test

   The same test set runs again on the same devices. Call setup, throughput, latency, app journeys: a like-for-like comparison rather than an inferred one.

5. Promote or roll back

   If the experience held or improved, the change is promoted and the evidence is filed with it. If it degraded, the evidence is already attached to the rollback.

• CeRC already drives network elements as well as handsets, through native MML and GUI integration, so a test can reconfigure a network element, verify the behaviour and put it back.
• Failures raise an alarm into the NOC or open a trouble ticket with the full evidence trail attached, rather than sitting in a report nobody opens.
• An open API means the control plane treats a device test as one more tool it can select, on the same footing as a query against the twin.
• Scriptless test creation matters here: the operator can add a new check itself, so the loop widens without waiting on a vendor release.

Being precise about what exists: the pieces are each in production, separately. CeRC drives handsets and network elements, exposes an open API and raises alarms with evidence today; script pre-flight and configuration write-back run in operator networks now. A fully hands-off validate-and-promote loop is an integration we build per engagement against your own change process, not a switch to flip, and we would not advise running it at full autonomy on day one.

Deployment models & form factors

Benefits: time, quality, cost

Save time — shorten the testing period by up to 80%, remove human bottlenecks by running tests in parallel, and absorb peak demand without overtime or outsourcing. Improve quality — repeatable, repeated test runs find far more faults than a manual cycle can, and automated alarming pushes failures straight to the NOC or a trouble ticket with the full evidence trail attached. Reduce cost — up to 80% direct saving in test execution, automating work that would otherwise consume thousands of engineer-hours, while intelligent device pooling raises utilisation per handset.

Figures as reported by Digitata Networks across CeRC engagements; results vary with test matrix and starting maturity.

Proven in the field

• A Tier 2 North American operator runs CeRC across a network lab, a device-testing function and the live production network, with roughly 150 test devices across three locations. The lab builds complex reusable multi-integration test cases; production focuses on simple repeatable tests, continuous alarming and critical ad-hoc remote access.
• A Tier 1 Latin American operator group ran a three-month proof of concept on revenue leakage and inbound roaming: automated anti-fraud testing against known data-tunnelling applications (baseline balance check, launch the exploit app, consume data, re-check the balance, raise an alarm with the traffic trace whenever data was delivered but not charged), plus hourly inbound-roaming sanity tests across voice, SMS and data.
• A large African operator group adopted CeRC to certify a wide range of Android and iOS devices across a vast network, streamlining testing and improving device compatibility.
• A Tier 1 European operator group uses CeRC alongside configuration management for network change verification and certification.
• A global device-lifecycle services provider uses the platform for automated device testing outside the operator domain.

Customers anonymised by region and tier, except where a case study is already public.

How a proof of concept works

Typically three months on a small device footprint, with agreed success criteria up front, a half-day familiarisation workshop for the operator's engineers, a handful of the operator's own priority test cases built during the proof of concept, and live reporting, alarming and dashboards demonstrated against real network conditions. Controllers can be bought, borrowed or rented — start with a single controller and add devices and controllers into a live deployment without redesign.