DOCSIS provisioning & OSS
A provisioning and OSS platform that owns the subscriber record, generates per-device config files, and gives you a straight answer to why a modem is not online — built for Kubernetes and highly available by default.
A provisioning and OSS platform that owns the subscriber record, generates config files, and answers "why is this modem not online?" without a three-hour investigation. Runs on Kubernetes and is meant to be deployed HA.
What it is
Provisioning happens in DHCP, config generation, and the subscriber record. Those three things are the product; the rest of the plant is something ProvOSS observes rather than drives.
Provisioning happens in DHCP, config generation and the subscriber record. That's the product. Everything else in the plant it just watches.
Subscriber, device and service state in one place, so activation, change and teardown are operations on a record rather than a sequence of systems.
Subscriber, device and service state in one place. Turning service on, changing it or shutting it off is one operation, not five.
Service tiers, filters and TLVs rendered for the device in front of you, from the subscriber record — not selected from a shelf of near-enough templates.
Service tiers, filters and TLVs built for that specific device from the subscriber record. Not a pile of nearly-right templates you pick from.
When a modem is not online, the reason is a field on a page rather than a three-hour investigation across four systems.
When a modem isn't online, it tells you why. You don't go digging through four systems to work it out.
The CMTS
ProvOSS queries the CMTS for modem diagnostics and nothing else. It does not sit in the registration path, and it does not need to drive the CMTS to do its job — which keeps the blast radius of a CMTS change, or a CMTS outage, small.
The only thing ProvOSS asks the CMTS for is modem diagnostics. It isn't in the registration path and doesn't drive the CMTS. So a CMTS change — or a CMTS falling over — doesn't take provisioning with it.
The primary test platform today. Development and diagnostics work are validated against it first.
What I test against. If something works, it worked on CableOS first.
The diagnostics collector is deliberately the only component that speaks CMTS, so support for another platform is one component's problem rather than the system's.
Only one component talks to the CMTS at all, so adding another platform means changing that one piece, not the whole system.
Every service in the provisioning path is stateless. Capacity is a replica count rather than a forklift, a failed pod is rescheduled rather than escalated, and a highly available deployment is the default shape rather than a licensed tier.
Every service in the provisioning path is stateless. Need more capacity, add replicas. Lose a pod, Kubernetes replaces it. Running it HA is just how it's meant to be deployed.
It ships as containers with manifests, so it runs on the cluster you already operate rather than a bespoke appliance you have to learn.
It's containers and manifests. It runs on the cluster you already have instead of a special appliance nobody else knows how to fix.
The same provisioning model extended to PON: ONT onboarding, service profiles, and one view of subscribers across both access technologies.
Same thing for PON: ONT onboarding and service profiles, so you don't end up running two separate provisioning systems.
Components
Contact
ProvOSS is in active development. If you run a plant and your current provisioning system is a constraint rather than a tool, this is the right moment to talk.
ProvOSS is still being built and I won't pretend otherwise. If you run a plant and hate your provisioning system, talk to me now — I'd rather build what you actually need than guess.