Next-gen network operations for ISPs, carriers and city networks
Support that can see the line.
Customer service has worked the same way for over twenty years, like firefighting: queues, scripts and escalations on thin evidence. NetPulse connects the customer to their switch port, their path through the network and the engineers who fix it. Most problems are answered in the app, and the tickets that are created carry the full diagnosis from the start.
Speed well below plan and physical errors raised on the port. Not the customer's Wi-Fi. Sent to an engineer with the measurements attached.
7 checks · every conclusion shows its evidenceExample. Live data read straight from the switch; the customer side is measured by the app and/or the CPE.
From the first symptom to an answer, without a phone call or a chat.
Not a FAQ and not a chatbot. The app checks the customer's own connection in real time and says what to do next.
The customer opens the app or web app
The app works out by itself whether they are at home or away, so nobody is asked about Wi-Fi.
The line is checked, no guessing
Port, optical levels, session and router are read live from the network and weighed into one verdict, while the app measures Wi-Fi, DNS and speed from the customer's side.
A clear next step
If the network is fine, the app guides the customer: Wi-Fi advice and a Wi-Fi heatmap walk, speed compared with what they pay for, or a marker for faults that come and go.
Or a ticket that is ready to work on from the first minute
If it can't be solved in the app, the ticket arrives with the diagnosis, measurements and photos attached. Nobody asks the customer to start over.
Typical sequence. Times depend on the access network and the customer's equipment.
When the network breaks, the support queue shouldn't.
An outage is when support costs explode: everyone calls at once and everyone runs a speed test. NetPulse turns that around.
aDetected in seconds
A link going down on a monitored port becomes a ticket with device evidence attached, typically within ten seconds.
bCustomers told, not queued
Affected customers see "known outage in your area" in the app with the latest status, and a push notification.
cTests stopped right at the gate
Inside a declared outage area new tests are blocked on the server, and each switch has its own budget. A thousand worried customers can't overload the network or the platform.
dThe customer's phone can be a measurement point
When the number of people testing behind the same part of the network suddenly climbs, that is an outage signal, often minutes before the first call.
eRestoration verifiedroadmap
When the fault clears, affected connections are checked through the customer's router and the probes before the outage is considered resolved.
fPost-mortem written for you
Timeline, affected customers and device evidence are collected into a report when the link recovers.
Not one more system. Instead: one system that replaces several.
One data model from the subscriber to the port, the hardware and the service layer. Every test, alarm and ticket attaches to the customer and port, so nobody joins the dots by hand.
For your customers
- Self-service in app and web appOur Android app or yours, plus a web app.
- Speed against the planCompared with what the customer pays for, not a generic benchmark.
- Router and Wi-Fi statusIncluding service checks run from supported CPEs.
- Wi-Fi heatmap walkroadmapRequested by the network owner, attached to the ticket.
For the NOC
- Explainable diagnosticsMore than 110 deterministic rules across six domains. Every verdict shows its evidence.
- Live topologyDiscovered, with physical, IGP, BGP and MPLS layers and a blast-radius view.
- Path analysis and active testsPer-hop latency and loss with history, from probes and from the app.
- Config backup and consoleDiff history tied to tickets, and out-of-band console over the probe.
- Enterprise SLASLA countdown, automatic diagnosis before breach, RFO reports.
For property owners
- BRF portal with resident opt-in/opt-outRun a diagnosis on the building's connections and follow the tickets. Only service-level answers, nothing about the network itself.
- Residents decideA resident who opts out can't be tested by the association. Enforced on the server, logged per customer.
For your other systems
- REST API and webhooksPre-diagnosed tickets into the ticketing system you already use.
- Syslog, traps and existing NMSReceived and correlated instead of replaced overnight.
- Energy and CO₂Power per device rolled up to kWh and CO₂ for sustainability reporting.
Inside your network, without exposing it.
NetPulse reaches your equipment through probes at your PoPs. They dial out. Nothing listens on the inside.
- Outbound only. The probe connects out on 443 over verified TLS. Works behind NAT and CGNAT.
- Commodity hardware or virtual probes. No vendor-specific probe hardware to buy.
- One key per probe. Stored only as a hash on our side and revoked instantly.
- Your accounts, your rules. Built to run on read-only device accounts issued from your own TACACS+ or RADIUS.
- Writes are deliberate. Console write access is armed explicitly by a named engineer and logged.
NIS2 evidence from the network you already run.
Stadsnät and ISPs are essential entities under NIS2. Instead of a separate compliance tool and an impact spreadsheet, the evidence comes from real-time data.
Posture from real-time data
Each NIS2 control area scored from what the network actually shows, with a gap list per area.
The reporting clock
24-hour warning, 72-hour notification and one-month report tracked from the outage onset. Export for PTS included.
Blast radius
Fail a router or a fibre on the map and see which customers, enterprises and SLA amounts are at risk.
Supply chain and CVEs
Your inventory matched against CVEs, known-exploited lists and end-of-life dates per model and version.
Threat detection
sFlow anomalies, BGP over BMP and RPKI. Flowspec mitigation only after an engineer confirms.
Topology as evidence
Dated snapshots of the whole network graph, exportable for auditors.
One customer, several organisations, the same answer.
In a city network the customer sits between the carrier that owns the fibre and the ISP that owns the relationship. Each sees what it needs, and nothing it shouldn't.
| Who | What they see |
|---|---|
| City carrier | The infrastructure: ports, paths, devices and every operator's customers on its fibre. |
| ISP | Its own subscribers across every city network, in one login. |
| Housing association | Service-level answers for its own building. Residents can opt out. |
| End customer | The app, the ticket status, and nothing of the infrastructure. |
Subscriber data syncs from Netadmin, COS Systems, Bitvis FiberFlow and PacketFront BECS, or from a database copy.
Works with the equipment you already have.
Drivers in use today
Through the driver framework
Missing yours? New vendors are usually added in days, not months.
See it on your own network.
We walk through NetPulse with your device list, your vendor mix and your subscriber model. Not a generic demo.
We are a small team and answer within one working day.
info@netpulse.se- Built and operated in Sweden
- For Nordic ISPs and city networks
- On-site demos in Scandinavia