Interkey products
Interkey Intelligent DPI is Interkey’s localised deep-packet-inspection product, developed and delivered in technology collaboration with Huawei, for operators who need to see, classify and control what is actually moving across their networks, in real time and at carrier scale.
Orientation
The whole page in one table, before the detail.
| Product | Interkey Intelligent DPI, an Interkey product |
|---|---|
| Technology model | Developed and delivered in technology collaboration with Huawei; localisation, customisation, integration and support by Interkey |
| Function | Traffic detection, classification and control |
| Deployment | Inline or out-of-band, on the operator’s own infrastructure |
| Scale | Carrier-grade, designed for national operator traffic volumes |
| Classification | Application and protocol identification, including encrypted and tunnelled flows |
| Recognition accuracy | 99% under the product’s own measurement (see the note below: validate on your own traffic) |
| Typical uses | Policy enforcement, congestion management, security visibility, regulatory reporting |
| Data residency | Deployable in-Kingdom; traffic never has to leave the operator’s environment |
| Support | Riyadh-based engineering team, Arabic and English |
| Commercial model | Quote only: priced per deployment and capacity |
The product
An Interkey product, built on a technology collaboration with Huawei
Interkey Intelligent DPI is Interkey’s localised deep-packet-inspection product for Saudi network operators. It is developed and delivered in technology collaboration with Huawei: the underlying inspection technology comes out of that collaboration rather than being written from nothing in Riyadh, and the product an operator buys, deploys, integrates and calls at 2am is Interkey’s. Being precise about that is the point — it is neither a Huawei box with a local reseller attached, nor a claim that Interkey independently created every component underneath it.
What Interkey adds
The difference between a global DPI platform and one an operator here can run is a body of work, not a badge. This is what that work is.
Adapting the product to how networks and applications behave in this market, and building what a customer’s environment needs rather than what the general product happens to ship. Regional and customer-specific requirements drive the development, which is only possible when the company doing the development is the one in the room.
The classifier is only as current as the traffic it has seen. Data collected locally, on the applications and protocols that are actually in use here, is what keeps identification accurate as application behaviour shifts — and it is collected in the Kingdom rather than shipped elsewhere to be processed.
Deployment into a live operator network is an integration project with the policy, billing, security and reporting systems already in place. Interkey delivers that end to end, as the same company that supplies the product, so the integration is not a separate contract with a separate escalation path.
Run and supported by a Riyadh engineering team, in Arabic and English, on the Saudi working week. For a platform sitting inline in a national network, who answers and when is not a procurement detail.
Why DPI
A large network operator can tell you how much traffic crossed its network last night. Telling you what that traffic was is a much harder question, and it is the one that matters. Without it, congestion is diagnosed by guesswork, a policy that is supposed to protect voice quality cannot be verified, and a security team investigating an incident has flow records but no idea which application produced them.
Deep packet inspection answers that question. Rather than reading only the routing headers, it examines the structure and behaviour of each flow to identify the application and protocol behind it. Once traffic is identified it can be counted, shaped, prioritised, blocked or reported on.
Interkey builds and operates this capability from Riyadh. That matters more than it might sound. DPI sits directly in the path of subscriber traffic, which makes it one of the most sensitive systems an operator runs: both technically, because a failure degrades service for everyone, and legally, because of what it can see. Buying it from a vendor whose nearest engineer is several time zones away is a different proposition from buying it from a team in the same city.
Under the hood
Traffic
Inline, where it can act, or out-of-band, where it only observes; most operators start out-of-band
Classification
Observable flow characteristics, packet sizing and timing, handshake structure, endpoint behaviour, not port numbers or payload alone
Identified traffic
Outcomes
Classification is traffic-dependent: a classifier tuned on one operator’s subscriber mix will not behave identically on another’s, which is why accuracy figures always need a proof of concept against your own traffic.
At carrier scale
Interkey’s own proof-of-concept work in operator networks frames carrier-scale traffic control as three distinct engineering problems, and it is worth naming them, because a vendor conversation that does not address all three is incomplete.
First, identification of encrypted and adversarial applications. The hard cases are not the applications that want to be identified but the ones built to avoid it: in the Android application market alone there are hundreds of VPN applications and variants, many actively disguising themselves as legitimate traffic. Interkey’s approach uses an AI traffic model with multi-modal feature extraction and automated in-network probing, and profiles VPN usage by frequency and behaviour specifically to cut false-positive blocking, because at national scale, wrongly blocking legitimate traffic is as damaging as missing the target.
Second, reliability at terabit scale. A platform sitting in the subscriber path at national traffic volumes has to be engineered for failure: the design uses full-mesh interconnection between control and user planes and layered disaster recovery from the virtual machine up to the resource-pool level. Interkey states 99.999% reliability for this design; like every figure on this page, that is Interkey's own product figure and belongs in your acceptance criteria, not on a poster.
Third, policy that closes the loop in real time. Classification that arrives in tomorrow’s report is archaeology. The platform’s reporting layer (“Live View”) is built for second-level visibility, so that a policy applied to a traffic class can be observed taking effect, measured, and corrected, within the hour rather than within the quarter.
On the 99% figure.
Use cases
Classification is only the input; these are the decisions it feeds. Each one is a place where knowing the application behind the traffic changes what the network does next.
Knowing which applications drive peak-hour load changes how capacity is planned. It is the difference between adding capacity everywhere and adding it where a specific class of traffic is actually saturating a specific part of the network.
Fair-use rules, tiered plans and quality-of-service commitments all depend on being able to identify the traffic they refer to. Without classification, a policy is an intention rather than a control.
Command-and-control traffic, tunnelling and traffic that does not match the application it claims to be are all visible to a classifier in a way they are not to flow records alone. This complements rather than replaces a security operations capability.
Saudi operators report against regulatory requirements that assume the operator can describe its own traffic. DPI is usually the system that makes those reports possible.
The proof of concept
A PoC does not exist to prove the product works; the vendor already believes that. It exists to establish how the platform behaves on your subscriber mix, your application mix and your encrypted share, and to produce numbers your own engineering organisation measured. This is the sequence Interkey scopes, written so it can be lifted into an RFP. Stage durations are agreed at scoping against the operator’s own calendar: a generic week count would be a guess, so none is printed here.
Stage 01
What is being tested, on which traffic, measured how, and what number constitutes a pass, agreed and written down before any equipment moves. A PoC without pre-agreed acceptance criteria is a demonstration.
Stage 02
Where the platform observes traffic, and how the sample is made representative: subscriber mix, peak and off-peak, the application classes the operator cares about. The operator supplies the vantage point; the quality of the PoC is decided here.
Stage 03
The platform observes and classifies without touching the forwarding path. Nothing can degrade service, and the classification output accumulates into a dataset both sides can interrogate.
Stage 04
Classification is compared against traffic the operator can independently verify, and the false-positive rate is measured with the same seriousness as the detection rate. Accuracy is a result the PoC produces, not a figure the vendor asserts.
Stage 05
Policy logic runs first in report-only mode, so its effect can be predicted before it is real. Inline enforcement follows only once the classification has earned it, on the traffic classes and scope the acceptance criteria named.
Stage 06
Results against the criteria from stage one, an honest account of what was not tested, and the sizing implications for a production deployment. The deliverable is evidence an operator’s own engineering leadership can defend internally.
What Interkey will not do in a PoC.
Local by design
Traffic inspection touches subscriber data by definition. Deploying DPI on infrastructure inside the Kingdom, supported by an engineering team in Riyadh, keeps that data inside the operator’s own environment and inside Saudi jurisdiction. It also changes the practical experience of running the system: a classification problem found on a Sunday morning is a local call rather than a support ticket queued against a different working week.
What the platform retains is part of the same conversation, and worth asking any DPI vendor precisely: classification produces metadata, which applications, which volumes, which policies fired, and the design questions are what is stored, for how long, and who can query it. Those answers are written into the deployment design, against the operator’s own data-governance rules, before go-live.
Interkey has operated in Saudi telecommunications since 1999, which is the same period over which the networks this product inspects were built. That context, knowing how these networks are actually put together and who runs them, is difficult to acquire from outside. Local content also stops being an abstraction here: through Interkey Semiconductor the same group manufactures network equipment in Riyadh, and operator procurement teams that score local content can weigh a supplier whose engineering, support and part of whose manufacturing sit inside the Kingdom.
Supply models
Not a product comparison: a comparison of supply models, which is the axis an operator procurement team actually scores. Put the same questions to every supplier on the shortlist.
| Question to score | Global vendor, remote support | In-Kingdom supplier |
|---|---|---|
| Who turns up when classification degrades? | A ticket queue in another working week and time zone | A Riyadh engineering team on the Saudi working week |
| Where does subscriber-adjacent data sit? | Depends on the support and telemetry model; ask precisely | Inside the operator’s environment and Saudi jurisdiction |
| How is the PoC run? | Often remote, on the vendor’s reference traffic | On site, measured against the operator’s own ground truth |
| Local content position | Usually none to offer | Riyadh engineering plus in-Kingdom equipment manufacturing in the same group |
| Escalation language and hours | English, on the vendor’s calendar | Arabic and English, Sunday to Thursday, Riyadh time |
From the insights library
Classification, deployment, data and jurisdiction, and the proof-of-concept and commercial questions, in one place.
PartnerThe 5G and transport infrastructure this platform inspects, integrated by the same Riyadh engineering team.
Product5G CPE, mesh routers, 5G MiFi and ONT assembled in Riyadh, the local-content argument this platform makes alongside.
In Saudi telecommunications since 1999
The networks this platform inspects
Huawei technology partnership
Delivered alongside a global platform partner
In-Kingdom manufacturing in the group
Interkey Semiconductor, Riyadh
Riyadh engineering, Sunday to Thursday
Arabic and English, CR 1010156897
Next step
A sentence on where the visibility gap sits — RAN, core or peering — and whether a live-traffic proof of concept is thinkable this year is enough to start.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia