Buyer's guide · Deep packet inspection for operators
How to evaluate a carrier-grade DPI platform: what to require in the RFP
A deep packet inspection platform should be judged on how accurately it classifies your traffic, at your peak rate, without putting the network or subscriber data at risk. This guide turns that into requirements for an RFP, questions vendors should answer in writing, and a three-stage proof of concept that measures the answers on your own network.
Published 7 min read
In short
- Start from the governance job: capacity planning, plan and fair-use policy, regulatory reporting or security visibility. Each one changes what you must require.
- Ask for measured results, not a headline figure: per-class detection and false-positive rates on a sample of your own traffic.
- Sequence the risk: out-of-band classification first, report-only policy next, inline enforcement last.
- Make data jurisdiction explicit: where processing runs, what is stored, for how long, and who can see it.
Start with the job the platform must do
Measuring how much traffic crosses a network is routine; knowing what that traffic is takes more. DPI answers the second question by classifying traffic by application and protocol at the network's operating rate. Which governance job comes first decides the requirements:
| Governance job | What the platform must deliver | Requirements it drives |
|---|---|---|
| Capacity and congestion planning | Traffic by application, network area and time | Reporting granularity and latency; out-of-band deployment is often enough |
| Plan, fair-use and quality-of-service policy | Policy actions per application | Inline deployment, failure behaviour, integration with policy and charging |
| Regulatory reporting | Traffic descriptions in the form your reporting obligations require | Report formats, retention rules, audit trail |
| Security visibility | Application context for tunnelled or anomalous traffic | Export to existing security tools; it complements the security operations centre rather than replacing it |
Where DPI is the wrong tool: on a corporate network, flow records and firewall logs usually answer the question already. A carrier-grade DPI platform is built for operator-scale traffic and operator questions.
Ten requirement areas, and how to verify each
| Area | What to require | How to verify it | Warning sign |
|---|---|---|---|
| Classification coverage | Applications and protocols that matter in your subscriber base, including locally popular apps | Compare against a sample of your traffic that you have labelled independently | A catalogue size quoted with no link to your traffic |
| Encrypted and tunnelled traffic | Classification without decrypting subscriber traffic, from observable characteristics | Measure results on the encrypted share of your sample | A design that depends on decrypting subscriber traffic |
| Accuracy and false positives | Per-class detection and false-positive rates on your traffic | Ground-truth comparison during the proof of concept | One accuracy percentage with no method behind it |
| Update cadence | How new or changed applications are added, how quickly, and who builds the signatures | Observe a live update during the proof of concept, under your change control | Updates that bypass your change control |
| Throughput | Committed throughput at your busiest-hour peak, with stated headroom and hardware | Load test with mirrored peak traffic | Lab-only figures |
| Deployment and failure behaviour | Out-of-band and inline modes; what happens to traffic if an inline component fails; redundancy | Failover test before inline go-live | Inline-only designs |
| Policy and integration | Actions per application, subscriber group or cell; integration with policy and charging, the 5G core and OSS/BSS | Written integration design for your network | Integration promised without a design |
| Reporting | Granularity, latency, retention and export to your reporting and security systems | Compare reports with your ground truth | Dashboards with no export |
| Data governance and jurisdiction | In-Kingdom processing; metadata rather than content; retention and role-based access set by your rules; audit logs | Architecture review and an access test | Content retained by default, or processing outside the Kingdom |
| Support and commercial basis | Local support languages and hours, upgrade path, signature updates during the contract; what the licence is based on and what is excluded | Support plan and priced bill of quantities in the contract | Per-feature charges discovered after award |
Questions to copy into the RFP
Ask every vendor to answer in writing. A vendor that can't answer these before a proof of concept will find them harder to answer after one.
Read more
- Which applications and protocols will you classify on our network, and how was that list derived from our traffic mix?
- How do you classify encrypted and tunnelled traffic? Does any part of your design require decrypting subscriber traffic?
- Provide per-class detection and false-positive rates measured on a sample of our traffic, against labels we verify.
- How are new or changed applications added, how long does that take, and who develops the signatures?
- What throughput do you commit to at our busiest-hour peak, on which hardware, and with what headroom?
- Which deployment modes do you support, and what happens to traffic if an inline component fails?
- Which policy actions can be applied, and at what granularity: application, subscriber group or cell?
- How will the platform integrate with our policy and charging systems and our 5G core? Provide the integration design.
- Which reports are available, at what latency, and how are they exported to our reporting and security systems?
- Where does processing run, what is stored (metadata or content), for how long, and who can access it?
- How are access and configuration changes logged and made auditable?
- Who supports the platform in Saudi Arabia, in which languages and hours, and how are upgrades delivered?
- What is the licence based on, and what is excluded from the price?
- Which acceptance criteria do you propose for the proof of concept, and will you accept criteria we define?
How to read an accuracy claim, including ours
An accuracy figure means little without three facts: which traffic it was measured on, which classes it covers, and how the correct answer was established. Classifier results depend on subscriber mix, application mix, the share of encrypted traffic and how recently the classifier was updated, so a figure from one operator's network will not transfer directly to another's.
Ask for detection and false-positive rates per class, measured on your sample. A false positive matters as much as a miss: it means a policy acts on the wrong traffic.
Read more
Interkey's product material states 99% recognition accuracy for Interkey Intelligent DPI. The figure has not been independently benchmarked and is not a specification for any particular network, which is why we recommend measuring it on your traffic before any decision.
A three-stage proof of concept that tests the answers
-
Agree acceptance criteria in writing first.
What will be tested, on which traffic, how it will be measured, and what counts as a pass.
-
Classify out-of-band.
The platform observes mirrored traffic without touching the forwarding path. Compare its results with traffic you have verified independently, and measure false positives as carefully as detections.
-
Run policy in report-only mode, then decide.
See what each rule would have done before it does anything. Move inline only after classification has proven itself, then accept against the written criteria, measured by your own engineers.
How Interkey runs this with operators: Interkey Intelligent DPI proof of concept
How Interkey Intelligent DPI answers these requirements
| Requirement area | Interkey Intelligent DPI |
|---|---|
| Technology | Interkey's DPI product, built on a technology collaboration with Huawei |
| Encrypted traffic | Classifies encrypted and tunnelled flows without decrypting them, from handshake structure, packet sizing and timing, and endpoint behaviour |
| Accuracy | 99% recognition accuracy as stated in Interkey's product material; not independently benchmarked, so we recommend measuring it on your traffic |
| Deployment | Inline or out-of-band on your own infrastructure; most operators start out-of-band |
| Architecture | Closed-loop pipeline of traffic ingestion, AI classification, policy execution and feedback; full-mesh architecture with multi-level disaster recovery |
| Policy and integration | Policy actions per application, subscriber group or cell; integration with policy and charging and the 5G core is scoped with you as part of deployment design |
| Reporting | Live traffic reporting with latency measured in seconds, and a reporting layer for capacity and regulatory teams |
| Data | Runs on your infrastructure and can operate entirely in the Kingdom; classification produces metadata; retention, duration and access follow your data-governance rules and the contract |
| Support | Riyadh team, Arabic and English, during the Saudi working week; Interkey handles integration into the live network |
| Pricing | Quoted per deployment and capacity |
For the technical feature overview: Interkey Intelligent DPI features
Questions buyers ask about DPI evaluation
Does classifying encrypted traffic require decrypting it?
No. Classification can rely on observable characteristics such as handshake structure, packet sizing and timing, and endpoint behaviour; Interkey Intelligent DPI does not decrypt traffic to classify it. Whether any other inspection is permitted is a matter for your policy and applicable regulation.
Should we deploy inline or out-of-band first?
Out-of-band first. It lets you measure classification against your own ground truth without touching the forwarding path. Inline enforcement comes after classification has proven itself, because only inline deployment can act on traffic.
Can the RFP require that processing stays in the Kingdom?
Yes. State it as a requirement, and ask each vendor for the architecture that shows where processing runs, what is stored and who can access it.
What should a vendor's proposal include besides price?
Measured results on your traffic, an integration design, a failure-behaviour description, a support plan with named languages and hours, and the licence basis with exclusions.
Next
Related resources
Next step
Discuss your DPI requirements
Tell us which governance job comes first, where the visibility gap sits (RAN, core or peering) and your timeline. A specialist in Riyadh replies on Saudi working days, in Arabic or English.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia