The tool that was missing.
Every operator has engineers who know exactly what their network should do, and no way to make it do that without booking a software team first. RAN Flow closes that distance.
Two experts, and a handoff between them.
Building an rApp takes radio knowledge and software skills at the same time. The engineer who knows the PRB threshold cannot write the SDK call that acts on it. The engineer who can write it has no basis for choosing the threshold. So the work queues behind a backlog, and an optimisation that should take days takes quarters.
The usual answer is to teach RAN engineers to code. We think that is the wrong end of the problem. The goal is not to turn them into programmers, it is to remove the step where they need one.
So the unit of work is a graph, not a file. You drag the blocks you already think in, KPI monitors, thresholds, conditions, A1 policies, and wire them into something that runs. What comes out is a real rApp, not a diagram of one.
Where RAN Flow fits.
RAN Flow sits above the Non-RT RIC. It translates visual workflows into rApp logic, pushes A1 policies down the stack, and collects KPM metrics flowing up from the gNB.
Decisions we made early, and keep.
- 01
Readable beats clever
An rApp is a graph you can open, read and audit. Not generated code you are asked to trust because it came out of a model.
- 02
Nothing reaches the RAN unreviewed
A 12-rule validator runs before every execution, test run and deploy alike, and a person approves every deployment. There is no path where a workflow reaches the network on its own.
- 03
Bounded by default
Policy actions carry guard rails in the node itself. A PRB target cannot leave the 5 to 95 percent band, so no rApp can black out a cell by typo.
- 04
Portable on purpose
Every RAN call goes through a connector interface. Adapters never touch a vendor SDK directly, which is what lets the same workflow move between SMOs instead of being rewritten for each.
In private beta, and specific about it.
We would rather tell you what is not built than have you find out. Here is the honest split.
Working today
- Visual canvas with 22 node types across triggers, data, logic and actions
- Dry run against mock RAN data, plus the 12-rule validator
- A1 policy automation with built-in bounds
- KPI prediction with LSTM, ARIMA, or your own ONNX model
- Deploy lifecycle: start, pause, stop, with live per-node status
- Export any workflow to a standalone Python script
Not yet
- Ericsson EIAP as a live connector, currently in build
- Intent-based build, drafting a workflow from a plain-language goal
- Model training inside the platform, rather than bring-your-own
- Nokia MantaRay and further SMO targets
- Registered name
- RanFlow Ltd
- Registered office
- 71-75 Shelton Street, Covent GardenLondon, WC2H 9JQ, United Kingdom