PROVIDER-SIDE DPI
DPI for Network Operators: Enriched Lawful Interception Data
Extract and enrich metadata for the ordered target at the point of interception. Deliver it in addition to the complete copy, strictly separated from commercial DPI.
DPI for network operators is target-specific deep packet inspection at the point of interception. The operator extracts metadata from the ordered target’s traffic, enriches it with network context and delivers it in addition to the complete, unaltered copy. The result is enriched IRI that agencies could not rebuild on their own.
Key facts
- Addition, not replacement: the full copy is always delivered.
- Target-only: DPI processes only the traffic of ordered targets, triggered by the LIMS.
- Network context: LIID, subscriber, NAT mapping, cell and IMEI attached to each flow.
- Strict separation from commercial DPI, in line with Regulation (EU) 2015/2120.
- Acceptance-ready: enrichment and formats are documented in the operator’s acceptance concept.
Why provider-side deep packet inspection?
The operator holds context that never reaches the agency in raw packets. Provider-side deep packet inspection attaches this context where it exists, close to the traffic.
- Correct attribution: subscriber identity and NAT mappings stay linked to each flow, even behind CGNAT.
- Location and device: cell IDs and IMEIs show where and with which device an activity took place.
- Speed: metadata is available in near real time, even while the full copy is still being analyzed.
- Encrypted traffic: pre-classified sessions and fingerprints help analysts focus.
- Fewer follow-up requests for basic context, where the order allows it.
Where is the legal line for DPI for network operators?
Provider-side DPI is lawful only within clear limits. ICS designs every project around them.
- Full copy first. The operator must deliver a complete, unaltered copy of the target’s communication. In Germany this follows from § 170 TKG and the TKÜV. Filtering is allowed only where the order limits the scope.
- Only ordered targets. Processing covers only the target’s traffic and only for the purpose of the interception. Untargeted analysis is not permitted.
- Separation from commercial DPI. Regulation (EU) 2015/2120 restricts DPI for traffic management but allows measures required by law. LI processing runs in a separate, access-controlled environment.
- Confidentiality. Staff and systems are bound by telecommunications secrecy, and the subscriber must not notice the measure.
- Acceptance concept. Everything the operator delivers must be part of the technical concept accepted by the BNetzA, following the TR TKÜV.
Reference architecture
A target-specific DPI chain has six stages, built on the X1, X2 and X3 interfaces and a mediation function.
1
Traffic access
Optical TAPs, router or BNG mirroring, or virtual mirror ports in cloud cores feed a packet broker.
2
Target triggering
The LIMS activates the target. RADIUS, Diameter, DHCP or packet gateway events tell the DPI node which IP addresses currently belong to it.
3
Target-specific DPI node
Only the target’s packets are processed, using high-performance packet processing such as DPDK or FPGA-based network cards.
4
Enrichment
Each flow receives the LIID, subscriber and line identifiers, NAT mapping, cell ID or location, and the IMEI where available.
5
Mediation and delivery
The full copy goes out as CC via HI3, for example per ETSI TS 102 232-3 or -7. The enriched metadata follows via HI2 or an agreed channel.
6
Audit
Outputs are kept only as long as delivery requires, and every configuration and signature version is logged.
What metadata can DPI for network operators extract?
| Metadata | Source | Investigative value |
|---|---|---|
| Flow records (5-tuple, start, end, bytes, packets) | Packet headers | Complete activity overview |
| DNS queries and responses | Unencrypted DNS | Domains and services used |
| TLS SNI, ALPN, JA4 fingerprints | TLS and QUIC handshakes | Application and device identification |
| Application classification | DPI signatures and behavior | Messenger, VoIP, streaming, VPN, Tor |
| Activity type | Packet size and timing | Message, call or file transfer |
| SIP and RTP parameters | Unencrypted VoIP | Third-party calls with participants and duration |
| HTTP host and user agent | Unencrypted HTTP | Services and client software |
| NAT mapping | CGNAT logs | Public IP and port linked to the target |
| Cell ID, IMEI, access line | Network and device data | Where and with which device an activity happened |
JA4 is licensed under BSD 3-Clause, while JA4S and the other JA4+ methods fall under the FoxIO License 1.1 and need an OEM license in commercial products. The operator removes only encryption it applied itself. End-to-end encrypted content stays encrypted, and DPI works on headers, handshakes and patterns.
How is enriched data handed over?
There is no universal ETSI record type for DPI results, so three handover models are used in practice.
01
Additional IRI records
Detected events, such as a VoIP call or an app session, are sent via HI2. Standard fields are used where possible, with agreed national extensions where needed.
02
Separate analytics stream
Structured flow or event records travel over a secured channel. They are clearly labeled and correlated with the LIID and the CC.
03
Service-level records
Where explicitly required, events are delivered at service level, similar to the service-specific parts of ETSI TS 102 232.
Evidence quality
Enriched IRI is only useful if agencies can trust and verify it. Whatever the handover model, the format must be documented, versioned and agreed with the agencies and the regulator.
- Record the DPI engine and signature version for every result.
- Use synchronized, high-precision timestamps that align with HI2 and HI3.
- Provide confidence indicators for behavioral classifications.
- Keep a complete audit trail of activation, configuration changes and deliveries.
- Test with reference traffic after every signature update.
- Keep enriched data verifiable against the full copy at all times.
ICS services for DPI for network operators
ICS supports operators from the first design to daily operation.
01
Architecture and legal-technical design
We design provider-side DPI that fits your national framework, your network and your acceptance concept.
02
Target-triggered enrichment
We integrate DPI with RADIUS, Diameter, DHCP, CGNAT logging and packet core events.
03
Passive probes and cloud mirroring
We deploy passive probes and virtual mirror ports, including in hosted and cloud cores.
04
Mediation and ETSI handover
Enriched data and the full copy are delivered through our LI Mediation Platform and LIMS.
06
Custom development
We build extractors, classifiers and delivery formats to your requirements. Learn more
Why ICS
01
Operator and agency view
We run passive probes and mediation for providers and build ICS LEMF for agencies.
02
Acceptance experience
More than 20 years in lawful interception and multiple BNetzA acceptances for interception solutions.
03
Security-cleared staff
Our team is security-cleared by the German Federal Ministry of the Interior and may handle classified information.
Frequently Asked Questions
What is DPI for network operators?
DPI for network operators is target-specific deep packet inspection at the point of interception. The operator extracts metadata such as flows, DNS, TLS fingerprints and application types from the ordered target’s traffic. It enriches this data with subscriber, NAT, cell and device context and delivers it to the agency in addition to the complete, unaltered copy.
Is provider-side deep packet inspection allowed for lawful interception?
Yes, when it is limited to the ordered target, serves the purpose of the interception order and is covered by national technical rules and the operator’s accepted concept. In Germany this means the TKÜV, the TR TKÜV and the BNetzA acceptance. Untargeted processing or commercial use of lawful interception data is not allowed.
Does DPI replace the full copy of the communication?
No. The operator must deliver a complete, unaltered copy of the target’s communication, unless the order explicitly limits the scope. DPI-based metadata is only delivered in addition. Agencies can therefore always verify enriched IRI against the original traffic, which matters for evidence in court.
What is enriched IRI?
Enriched IRI is intercept-related information with additional context extracted or attached at the provider. Examples are the NAT mapping behind a flow, the cell ID, the IMEI, a detected application or a TLS fingerprint. It is delivered via HI2 or an agreed analytics channel and linked to the measure through the LIID.
Can an operator decrypt a target’s HTTPS or messenger traffic?
No. The operator removes only encryption it applied itself in its own network. End-to-end and application-level encryption remain intact. Provider-side DPI works on unencrypted headers, handshakes and traffic patterns, which still reveal the application, the timing and often the type of activity.
How does provider-side DPI stay separate from commercial DPI?
LI processing runs on dedicated, access-controlled systems that handle only traffic of ordered targets. Results flow only into the mediation and handover chain, never into traffic management, analytics or marketing systems. This separation reflects Regulation (EU) 2015/2120 and telecommunications secrecy, and it is documented in the acceptance concept.
Is provider-side enrichment right for your network?
Our experts review your legal framework, architecture and acceptance concept and recommend a practical design.