Lawful intercept architecture: X1, X2, X3 and mediation

Why it exists, and why it is standardised

Nearly every jurisdiction obliges telecoms operators to be able to execute a court-ordered interception. Before standardisation, each agency and each vendor improvised — expensive, unauditable, and easy to get wrong in both directions (missing lawful targets, or over-collecting). The ETSI model (TS 101 331 for the requirements, TS 102 232 for delivery, TS 103 221 for the modern internal interfaces) and its 3GPP counterparts (TS 33.126/127/128) exist so that the capability is bounded: per-warrant, logged, minimised, and invisible to everyone who has no need to know — including the target and nearly all operator staff.

The functional model

Three planes, deliberately separated:

1. Administration. The law-enforcement agency delivers a warrant over HI1 — historically paper, increasingly an electronic interface. The operator's ADMF (administration function) validates it and provisions the network: over X1 it tells specific network functions "intercept this identifier, for this period, deliver to there". The identifier is a network identity — an IMSI, MSISDN, IMPU or SIP URI — never a name; mapping a person to identifiers is the agency's job, not the network's.
2. Collection. The provisioned functions become points of interception (POIs). They produce two distinct streams: X2 carries intercept-related information (IRI) — signalling events: registrations, call attempts, answer, release, location where mandated. X3 carries content of communication (CC) — the media itself. The split matters legally: many warrants authorise IRI only, and the architecture must be able to deliver one without the other.
3. Mediation and handover. Raw internal formats go to mediation functions (MDF2 for IRI, MDF3 for CC), which normalise them into the standardised delivery format and hand them to the agency's LEMF over HI2 and HI3. Every product is tagged with a lawful intercept identifier (LIID) naming the warrant and a correlation number binding each CC stream to its IRI events — an audit trail from court order to delivered packet.

The properties the design must guarantee

• Undetectability. Interception must cause no observable change for the target — no added delay, no altered headers, no different failure behaviour. This is a hard requirement, and it is why intercept functions are copies taken off the media/signalling path rather than devices inserted into it.
• Minimisation. Only the warranted target's traffic, only for the warranted period. The X1 provisioning model — explicit activation with explicit identifiers and expiry — is the enforcement mechanism.
• Separation of knowledge. The engineer who operates the SBC does not see the tap list; LI administration is a separate role, separately logged. In a well-run operator, "is this number being intercepted?" is a question almost nobody can answer, by design.
• Auditability. Every activation, delivery and failure is logged against the LIID, because the output has to survive scrutiny in court.

Where the taps physically sit

In an IMS/VoLTE network the natural POIs follow the architecture: signalling IRI is generated where the signalling already is — at the CSCFs — while content comes from the nodes that touch media: the IMS access gateway, the transition gateway at interconnects, or the SBC anchoring the call. In the packet core, the S-GW/P-GW (or UPF in 5G) play the same role for data sessions. The follow-up page, lawful intercept in a VoIP network, looks at what this means in practice — including what encryption does and does not change.