SIST-TS ETSI/TS 102 232-4 V3.8.1:2025
(Main)Lawful Interception (LI) - Handover Interface and Service-Specific Details (SSD) for IP delivery - Part 4: Service-specific details for Layer 2 services
Lawful Interception (LI) - Handover Interface and Service-Specific Details (SSD) for IP delivery - Part 4: Service-specific details for Layer 2 services
The present document specifies Lawful Interception for an Access Provider that has access to layer 2 session information and that is not required to have layer 3 information. In this case, the focus of Lawful Interception (LI) for IP Network Access is on the portion of the network, commonly referred to as "layer 2 interception", that facilitates subscriber access to the Public IP network. The present document describes the LI at the interception domain of the access network. The present document contains:
• a stage 1 description of the Lawful Interception service;
• a stage 2 description of the information flows between the functional entities (including the information elements involved) and triggering events; and
• a stage 3 description of the protocol and procedures to be used in mapping from stage 2 information flows and elements to Intercept Related Information (IRI) and Content of Communication (CC). The present document is consistent with the definition of the Handover Interface, as described in ETSI TS 102 232-1 [2].
NOTE 1: Layer 3 interception is described in ETSI TS 102 232-3 [12].
NOTE 2: Layer 2 interception is not applicable to the PS domain of the GSM/UMTS networks (3GPP TS 23.060 [15]).
Zakonito prestrezanje (LI) - Izročilni vmesnik in storitveno specifične podrobnosti (SSD) za IP-dostavo vsebin - 4. del: Storitveno specifične podrobnosti za storitve na 2. sloju
Ta dokument določa zakonito prestrezanje za ponudnika dostopa, ki ima dostop do informacij o seji na 2. ravni in ne potrebuje informacij na 3. ravni. V tem primeru je poudarek zakonitega prestrezanja (LI) za dostop do omrežja IP na delu omrežja, ki se običajno imenuje »prestrezanje na 2. ravni« in omogoča naročniku dostop do javnega omrežja IP. Ta dokument opisuje zakonito prestrezanje na domeni za prestrezanje v dostopovnem omrežju. Ta dokument vsebuje: • opis 1. stopnje storitve zakonitega prestrezanja; • opis 2. stopnje tokov informacij med funkcionalnimi entitetami (vključno z elementi z informacijami) in sprožilnimi dogodki; ter • opis 3. stopnje protokola in postopkov za preslikavanje iz tokov informacij in elementov z informacijami 2. stopnje v podatke o prestreženi komunikaciji (IRI) ali vsebino komunikacije (CC). Ta dokument je skladen z definicijo izročilne specifikacije, kot je opisano v standardu ETSI TS 102 232-1 [2]. OPOMBA 1: Prestrezanje na 3. ravni je opisano v standardu ETSI TS 102 232-3 [12]. OPOMBA 2: Prestrezanje na 2. ravni se ne uporablja za domeno PS v omrežju GSM/UMTS (3GPP TS 23.060 [15]).
General Information
Standards Content (Sample)
TECHNICAL SPECIFICATION
Lawful Interception (LI);
Handover Interface and
Service-Specific Details (SSD) for IP delivery;
Part 4: Service-specific details for Layer 2 services
2 ETSI TS 102 232-4 V3.8.1 (2025-08)
Reference
RTS/LI-00288-4
Keywords
IP, Lawful Interception, layer 2, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2025.
All rights reserved.
ETSI
3 ETSI TS 102 232-4 V3.8.1 (2025-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 General . 9
4.1 Access network . 9
4.1.0 Overview . 9
4.1.1 Scenario 1 . 9
4.1.2 Scenario 2 . 10
4.1.3 Scenario 3 . 11
4.1.4 Scenario 4 . 11
4.2 Lawful Interception (LI) requirements . 12
4.2.0 Introduction. 12
4.2.1 Target identity . 12
4.2.2 Result of interception . 12
4.2.3 Intercept related information messages. 13
4.2.4 Time constraints . 13
5 System model . 13
5.1 Reference configuration . 13
5.2 Reference states . 14
5.2.1 Logon . 14
5.2.2 Data transport . 14
5.2.3 Logoff . 15
5.2.4 Unexpected connection loss . 15
5.2.5 Interception without network session events . 15
5.2.6 Mediation session expiry . 15
6 Intercept Related Information . 16
6.1 IRI events . 16
6.2 HI2 attributes . 17
7 Content of Communication (CC) . 18
7.1 CC events . 18
7.2 HI3 attributes . 18
7.3 HI3 truncated attributes . 18
8 ASN.1 for IRI and CC . 18
8.1 ASN.1 specification. 18
Annex A (normative): Reference network topologies . 19
A.0 Introduction . 19
A.1 xDSL access . 19
A.1.0 Overview . 19
A.1.1 Events and information . 19
ETSI
4 ETSI TS 102 232-4 V3.8.1 (2025-08)
A.2 Cable modem access . 25
A.3 WLAN access . 25
Annex B (informative): Stage 1 - RADIUS characteristics . 26
B.0 Introduction . 26
B.1 Network topology . 26
B.1.0 RADIUS deployment options. 26
B.1.1 RADIUS proxy . 26
Annex C (informative): Change history . 28
History . 30
ETSI
5 ETSI TS 102 232-4 V3.8.1 (2025-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI).
The present document is part 4 of a multi-part deliverable. Full details of the entire series can be found in part 1 [2].
The ASN.1 module is available as an electronic attachment to the present document (see clause 8.1 for more details).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The present document focuses on layer 2 interception of IP-encoded information. It is to be used in conjunction with
ETSI TS 102 232-1 [2], in which the handling of the intercepted information is described.
ETSI
6 ETSI TS 102 232-4 V3.8.1 (2025-08)
1 Scope
The present document specifies Lawful Interception for an Access Provider that has access to layer 2 session
information and that is not required to have layer 3 information. In this case, the focus of Lawful Interception (LI) for IP
Network Access is on the portion of the network, commonly referred to as "layer 2 interception", that facilitates
subscriber access to the Public IP network.
The present document describes the LI at the interception domain of the access network.
The present document contains:
• a stage 1 description of the Lawful Interception service;
• a stage 2 description of the information flows between the functional entities (including the information
elements involved) and triggering events; and
• a stage 3 description of the protocol and procedures to be used in mapping from stage 2 information flows and
elements to Intercept Related Information (IRI) and Content of Communication (CC).
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
NOTE 1: Layer 3 interception is described in ETSI TS 102 232-3 [12].
NOTE 2: Layer 2 interception is not applicable to the PS domain of the GSM/UMTS networks (3GPP
TS 23.060 [15]).
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] Void.
[2] ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 1: Handover specification for IP delivery".
[3] IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers".
[4] IETF RFC 1570: "PPP LCP Extensions".
[5] IETF RFC 3046: "DHCP Relay Agent Information Option".
[6] Recommendation ITU-T X.680: "Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation".
[7] Recommendation ITU-T E.164: "The international public telecommunication numbering plan".
[8] IETF RFC 2341: "Cisco Layer Two Forwarding (Protocol) "L2F"".
[9] IETF RFC 2637: "Point-to-Point Tunneling Protocol (PPTP)".
ETSI
7 ETSI TS 102 232-4 V3.8.1 (2025-08)
[10] IETF RFC 2661: "Layer Two Tunneling Protocol "L2TP"".
[11] IETF RFC 1661: "The Point-to-Point Protocol (PPP)".
[12] ETSI TS 102 232-3: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 3: Service-specific details for internet access services".
[13] ETSI TS 102 232-2: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 2: Service-specific details for messaging services".
[14] ETSI TS 101 331: "Lawful Interception (LI); Requirements of Law Enforcement Agencies".
[15] ETSI TS 123 060: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service
description; Stage 2 (3GPP TS 23.060)".
[16] Void.
[17] Void.
[18] Void.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI TR 102 503: "Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and
Retained data handling Specifications".
[i.2] ETSI TS 101 909-20-1: "Digital Broadband Cable Access to the Public Telecommunications
Network; IP Multimedia Time Critical Services; Part 20: Lawful Interception; Sub-part 1: CMS
based Voice Telephony Services".
[i.3] ETSI TS 101 909-20-2: "Digital Broadband Cable Access to the Public Telecommunications
Network; IP Multimedia Time Critical Services; Part 20: Lawful Interception; Sub-part 2:
Streamed multimedia services".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 102 232-1 [2], ETSI TS 102 232-3 [12] and the
following apply:
Access Provider (AP): Communication Service Provider (CSP), providing access to networks
NOTE 1: APs generally provide dial-up access through a modem and PPP connection, though companies that offer
Internet access with other devices, such as cable modems or wireless connections, could also be
considered APs.
NOTE 2: In the context of the present document, the network access is defined as IP-based network access to the
Internet.
ETSI
8 ETSI TS 102 232-4 V3.8.1 (2025-08)
access service: set of access methods provided to a user to access a service and/or a supplementary service
NOTE: In the context of the present document, the service to be accessed is defined as the Internet.
Application Service Provider (ASP): third-party entity that manages and distributes software-based services and
solutions to customers across a wide area network from a central data centre
NOTE: In the context of the present document, a company that offers services that are accessible to users who
have connectivity via the Internet.
interconnect network: network connecting the AP and the IAP, across which the layer 2 tunnel is established
Internet Access Provider (IAP): company that provides access to the Internet
NOTE: The IAP provides subscribers a username, password and an IP address that enables subscribers to log onto
the Internet for virtual connectivity to Application Service Providers.
layer 2: link layer
NOTE: As defined in IETF RFC 1122 [3].
layer 2 interception: lawful interception using technology that can access layer 2 information
Physical Line Termination Point (PLTP): point in the access provider's infrastructure where the physical line to the
customer is terminated
EXAMPLE: xDSL-line termination point, Cable-line termination point, Ethernet-line termination point.
tunnel router: router that is an endpoint of a layer 2 tunnel; there are at least two tunnel routers for each layer 2 tunnel
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA Authentication, Authorization and Accounting
ADSL Asymmetric Digital Subscriber Line
AP Access Provider
ASN.1 Abstract Syntax Notation 1
ASP Application Service Provider
ATM Asynchronous Transfer Mode
CC Content of Communication
CIN Communication Identity Number
CMTS Cable Modem Termination System
CPE Customer Premises Equipment
CR Change Request
CSP Communications Service Provider
DF Delivery Function
DHCP Dynamic Host Configuration Protocol
HI1 Handover Interface 1 (for Administrative Information)
HI2 Handover Interface 2 (for Intercept Related Information)
HI3 Handover Interface 3 (for Content of Communication)
IAP Internet Access Provider
IAS Internet Access Service
IP Internet Protocol
IRI Intercept Related Information
ISDN Integrated Services Digital Network
L2CC Layer 2 Content of Communication
L2F Layer 2 Forwarding
L2TP Layer 2 Tunnelling Protocol
ETSI
9 ETSI TS 102 232-4 V3.8.1 (2025-08)
LAES Lawful Authorized Electronic Surveillance
LAN Local Area Network
LCP Link Control Protocol
LEA Law Enforcement Agency
LEMF Law Enforcement Monitoring Facility
LI Lawful Interception
LIID Lawful Interception IDentifier
MAC Media Access Control
MD Mediation Device
MF Mediation Function
MOC Mandatory/Optional/Conditional
NAS Network Access Server
OID Object IDentifier
PDU Protocol Data Unit
PLTP Physical Line Termination Point
PPP Point-to-Point Protocol
PPTP Point-to-Point Tunnelling Protocol
PS Packet Switched
PSTN Public Switched Telephone Network
RADIUS Remote Authentication Dial In User Service
RFC IETF Request For Comment
SP Service Provider
TC Technical Committee
VoIP Voice over Internet Protocol
WLAN Wireless Local Area Network
xDSL Digital Subscriber Line technologies
4 General
4.1 Access network
4.1.0 Overview
An access network provides layer 2 connectivity from the Physical Line Termination Point (PLTP) for end-users to an
Application Service Provider (ASP) through an Internet Access Provider (IAP). The access provided may be via a
telephone, cable, or wireless-network. The present document describes the LI at the access network.
The figures contained in the following clauses do not necessarily refer to physical configurations but identify the
business roles associated with various scenarios to provide services. A provider can have one or more of following
roles: Access Provider (AP), Internet Access Provider (IAP) and Application Provider.
Lawful interception of communications has to accommodate a multitude of scenarios for public telecommunications.
Four representative scenarios are described below.
4.1.1 Scenario 1
This scenario reflects the situation in which the three identified provider roles are provisioned by independent providers.
For example, an ASP provides Call Control for VoIP service, and is using the transport facilities of an IAP for
connectivity to the AP.
In this scenario, the specifications of the present document are relevant to the AP, while the IAP and ASP may be
involved with interception according to the specifications of ETSI TS 102 232-2 [13] and ETSI TS 102 232-3 [12].
ETSI
10 ETSI TS 102 232-4 V3.8.1 (2025-08)
Figure 1: Scenario in which access, transport and application services
are offered by three different providers
4.1.2 Scenario 2
This scenario reflects the situation in which a network operator is acting only as an AP, and not as an IAP or ASP.
In this scenario, the specifications of the present document are relevant to the AP, while the IAP/ASP may be involved
with interception according to the specifications of ETSI TS 102 232-2 [13] and ETSI TS 102 232-3 [12].
Figure 2: Scenario in which access is offered by a provider separate from the one
that is offering Internet transport and application service
ETSI
11 ETSI TS 102 232-4 V3.8.1 (2025-08)
4.1.3 Scenario 3
This scenario reflects the situation in which the AP and IAP roles are offered by a single provider.
In this scenario the Service Provider (SP), having roles as an AP and an IAP, may be involved with interception
according to ETSI TS 102 232-3 [12] and layer 2 interception is not preferred.
Figure 3: Scenario in which access and Internet transport are offered by a
single provider that does not offer application service
4.1.4 Scenario 4
This scenario reflects the situation in which the AP, IAP and ASP roles are offered by a single provider.
In this scenario the service provider, having roles as an AP, an IAP and an ASP, may be involved with interception
according to ETSI TS 102 232-2 [13] and ETSI TS 102 232-3 [12], and layer 2 interception is not preferred.
Figure 4: Scenario in which access, transport and application services
are offered by the same provider
ETSI
12 ETSI TS 102 232-4 V3.8.1 (2025-08)
4.2 Lawful Interception (LI) requirements
4.2.0 Introduction
Clause 4.2 lists the requirements for Lawful Interception (LI). These requirements are derived from higher-level
requirements listed in ETSI TS 101 331 [14] and ETSI TS 102 232-1 [2] and are specific to Internet Access Services
(IAS). These requirements focus on both the administrative part of Internet Access for delivery over HI2 as well as
capturing traffic for delivery over HI3.
4.2.1 Target identity
Where the special properties of a given service, and the justified requirements of the LEAs, necessitate the use of
various identifying characteristics for determination of the traffic to be intercepted, the provider (CSP) shall ensure that
the traffic can be intercepted on the basis of these characteristics. The target identity known by the layer 2 mechanisms
is not an application or network identity; therefore, layer 2 interception has to be registered against a known layer 2
identity. The access network shall identify targeted activity by other means, e.g. the termination point of the xDSL-line
or the Cable-line.
In each case the characteristics shall be identifiable without unreasonable effort and shall be such that they allow clear
determination of the traffic to be intercepted.
The target identity should uniquely identify the target in the provider's network. The target identity will be dependent on
the access mechanism used and the parameters available with the AP. The target identity could be based on:
a) MAC address or vMAC. For example, the MAC address of the cable modem which is identified by the CMTS
can be requested to identify the target identity.
b) xDSL-line termination point, including, e.g. the IP-address of the Network Access Server (NAS), and the NAS
port; the NAS port is identified by the ATM virtual path, virtual channel and port number (slot, sub-slot and
port).
c) Cable-line termination point (including e.g. IP address, interface information of the CMTS).
d) DHCP option 82, circuit Id and remote Id, as defined in IETF RFC 3046 [5].
e) Calling party number (Recommendation ITU-T E.164 [7], Network-provided or User-provided, verified and
passed).
f) Other unique identifier agreed between AP and LEA.
4.2.2 Result of interception
The network operator shall provide Intercept Related Information (IRI), in relation to each target service:
a) when an attempt is made by the target to utilize the network;
b) when an attempt is made to reach the target from the network;
c) when an access to the network is permitted;
d) when an access to the network is not permitted;
e) when an access to the network is terminated.
The IRI shall contain:
a) identities used by or associated with the target identity;
b) details of services used and their associated parameters;
c) information relating to status;
d) timestamps.
ETSI
13 ETSI TS 102 232-4 V3.8.1 (2025-08)
Content of Communication (CC) shall be provided for every layer 2 datagram sent through the access network that is
addressed to, or sent from, the line termination point of the target.
The CC shall be a bit-exact copy of every intercepted layer 2 datagram.
4.2.3 Intercept related information messages
IRI shall be conveyed to the LEMF in IRI data records. Four types of IRI data records are defined:
1) IRI-BEGIN record at the first event of a communication attempt, opening the IRI transaction;
2) IRI-END record at the end of a communication attempt, closing the IRI transaction;
3) IRI-CONTINUE record at any time during a communication attempt within the IRI transaction;
4) IRI-REPORT record used in general for non-communication related events.
For a description of the use and purpose of the various IRI data records refer to ETSI TS 102 232-1 [2]. Which IRI
events are available for the different IRI data record types are described in clause 6.1.
4.2.4 Time constraints
Intercept Related Information shall be transmitted without undue delay. This delay should only be caused by the access
protocol handling and the automated forwarding of this information to the delivery function.
5 System model
5.1 Reference configuration
Figure 5 contains the reference configuration for the lawful interception.
HI1
INI1
Layer 2
Admistration Function
Authentication
Server
INI1
INI1
HI2
INI2
Mediation
Layer 2
Function 2
LEMF
CPE
Access
LEMF
INI1
HI3
Layer 2
INI3
Mediation
Interception
function Function 3
AP domain
IAP / ASP
Figure 5: Reference configuration for lawful interception
The reference configuration is only a logical representation of the entities involved in lawful interception and does not
mandate separate physical entities. This allows for higher levels of integration.
ETSI
14 ETSI TS 102 232-4 V3.8.1 (2025-08)
The messages sent in an implementation-specific manner between the Administrative Function and the other Access
Provider domain entities may contain:
• target identities;
• correlation information;
• information whether the CC shall be provided;
• the address of Mediation Function 2 for IRI;
• the address of Mediation Function 3 for the intercepted CC;
• the address for delivery of IRI (= LEMF address);
• the address of delivery for CC (= LEMF address);
• Lawful Interception Identifier (LIID).
The messages sent in an implementation-specific manner between the Interception Function and Mediation Function 2
contains the IRI.
The messages sent in an implementation-specific manner between the Interception Function and Mediation Function 3
contains the CC.
5.2 Reference states
5.2.1 Logon
If the xDSL-line or cable line is not owned by the party that provides the authentication server, then user identification
takes place in the network of the AP and the user identity and access request are forwarded to the authentication server
of the IAP. To exchange data between the user and IAP, a layer 2 tunnel is established, e.g. a L2TP tunnel per IETF
RFC 2661 [10]. All data between the IAP and the user is transported via this tunnel. If access is granted, an IP address
is provided by the IAP and communicated to the user via the layer 2 tunnel and then the user can communicate with the
Internet via the layer 2 tunnel.
If a layer 2 tunnel to an IAP is established, other users may be using the same tunnel, as only one tunnel is established
typically to each IAP.
5.2.2 Data transport
While having an active, virtual IP connection, the CPE can transmit IP datagrams towards any IP-enabled destination
connected to the Internet. These datagrams may contain other, higher-level IP-based protocols. Similarly, the CPE can
receive IP datagrams directed towards it from any IP-enabled source connected to the Internet.
It is possible that the CPE is connected to an Access Network that does not provide the Internet Access, e.g. if the AP
and the IAP are different parties as demonstrated in clauses 4.1.1 and 4.1.2. The AP provides the xDSL-line and routes
all datagrams that are destined to the IAP through a layer 2 tunnel via a gateway to the network of the IAP. Thus, all
datagrams from the user CPE are encapsulated in a specific layer 2 protocol (e.g. L2TP IETF RFC 2661 [10]) and
transmitted by the AP to the IAP.
ETSI
15 ETSI TS 102 232-4 V3.8.1 (2025-08)
Figure 6: Layer 2 tunnel shared by multiple users
Figure 6 shows the usage of a layer 2 tunnel. It is possible that only the traffic associated with one PLTP connected to
the CPE of one target is intercepted, as represented by the white IP-stream in figure 6. The other connections through
the tunnel are not intercepted. If the target session is terminated and the other connections are not terminated, the layer 2
tunnel stays online.
It is also possible that the communication of more than one target may be intercepted via the same layer 2 tunnel.
Furthermore, it is possible that a single IP-stream may be the subject of multiple, simultaneous lawful interceptions;
therefore, that single, intercepted IP-stream may be delivered to multiple LEMFs, or multiple copies of the stream may
have to be delivered to the same LEMF (once for each interception authorization).
5.2.3 Logoff
When a user logs off, the client running on the CPE will negotiate the closure of the session with the NAS of the AP.
For example, a PPP session may be closed through an exchange of LCP Terminate packets (see IETF RFC 1570 [4] for
LCP and IETF RFC 1661 [11] for PPP). Next, the NAS informs the authentication server in the IAP of the session
closure and may provide statistics on the session as well.
5.2.4 Unexpected connection loss
During an active data session, the virtual connection may terminate unexpectedly for reasons such as loss of carrier, link
quality failure, or the expiration of an idle-period timer. In such cases there can be no user-provided logoff indication,
and it is up to the NAS to detect the connection loss and to propagate the session closure towards the accounting server
of the IAP.
5.2.5 Interception without network session events
Apart from the reference scenarios previously described in clause 5.2, interception may occur in parts of a network
where a network session context is not available. An example could be a point of interception where layer 2 packets are
passively copied into an MF. That MF is then only aware of the layer 2 packets it has to intercept and not of the session
context pertaining to those packets.
Subject to national agreement, this scenario may be implemented as the following option:
1) An interception session with IRI generated by the MF, using appropriate IRI event types (see clause 6.1) based
on other events such as LI activation and deactivation. These IRI sessions may be started either on LI
activation or upon first layer 2 packet received after LI activation, subject to national agreement.
5.2.6 Mediation session expiry
Certain fault conditions in the interception process may require the MF to terminate an interception session without an
explicit network session event (e.g. DHCP or RADIUS) from the NAS, in order to prevent the interception sessions
consuming MF resources indefinitely. These fault conditions may include the non-receipt of a specific multiple of
expected regular network session events from the NAS.
NOTE: This is separate to an endReason (see annex A.1.1) of connectionTimeout, which may have a direct
mapping to a specific network event's service-specific parameter.
ETSI
16 ETSI TS 102 232-4 V3.8.1 (2025-08)
6 Intercept Related Information
6.1 IRI events
The following IRI-Events are applicable, if the traffic to and from the target is through the network of the AP.
Figure 7 shows the life cycle of a generic internet access session.
Access attempt
IRI-REPORT
accessAttempt
New CIN value
Access reject
(per national agreement)
Logged off IRI-REPORT Logging on
accessReject
Access failed
IRI-REPORT
accessFailed
Access end
Access accept
IRI-END
IRI-BEGIN
accessEnd
accessAccept
New CIN value
(per national agreement)
Session active
Interim update
End Intercept
IRI-CONTINUE
IRI-REPORT
interimUpdate
endOfInterceptionWithSessionActive, or
endOfInterceptionWithoutNetworkSession
Start intercept
IRI-BEGIN
Session expiry
startOfInterceptionWithSessionActive, or
IRI-REPORT
startOfInterceptionWithoutNetworkSession
sessionExpired
New CIN value
Start intercept End intercept
NOTE 1: Depending on the signalling implementation, there may be duplicate events due to resends. Resends of
events are be ignored as far as state-changes are concerned; this is not depicted in the diagram.
NOTE 2: Session expiry may occur from any state for an existing interception session.
Figure 7: State diagram for an Internet session
Subject to agreement on a national level, it is acceptable to perform the CIN allocation on the accessAccept rather than
the accessAttempt. If this option is chosen, the CSPs shall allocate a new CIN only on the IRI-BEGIN messages; and
send accessAttempt, accessReject and accessFailed as standalone messages not associated with any other CC or IRI.
Figure 7 allows for a model where detailed information is available regarding the identification and authentication
process as well as for a simple model where just a session start notification is available.
The IRI events depicted in figure 7 are described in table 1.
ETSI
17 ETSI TS 102 232-4 V3.8.1 (2025-08)
Table 1: IRI events (Layer 2)
IRI Event Description IRI Record
A target requests access to the Internet Access
accessAttempt REPORT
Service (IAS).
The network elements are triggered to erect a layer 2
accessAccept BEGIN
tunnel between the user and the foreign IAP network.
accessReject The access is refused. REPORT
accessFailed The accessAttempt timed-out or failed otherwise. REPORT
interimUpdate Intermediate status report on service status or usage. CONTINUE
The communication between the user and the IAP
network terminated. This may be for numerous
accessEnd reasons that are not visible to the AP (e.g. the user END
logs off or shortage of network capacity between the
AP and the IAP) (see note).
As sessions can be active over longer periods, it is
startOfInterceptionWithSessionActive not unlikely for an intercept to start after a user BEGIN
session has started already.
As sessions can be active over longer periods, it is
endOfInterceptionWithSessionActive not unlikely for an intercept to end whilst a user REPORT
session remains active.
The interception session is started by the MF without
startOfInterceptionWithoutNetworkSession BEGIN
a network session event.
The interception session is ended by the MF without a
endOfInterceptionWithoutNetworkSession REPORT
network session event.
sessionExpired The interception session is expired by the MF. REPORT
NOTE: If there are other connections still using the same tunnel, the tunnel remains available.
When LI is activated during an already active internet session, which the IAP is aware of, it is recommended that an
IRI-BEGIN message is generated to mark the start of interception and the specific event type of
startOfInterceptionWithSessionActive shall be used.
When LI is deactivated during an already active internet session, which the IAP is aware of, as a national option the MF
may choose to either generate an IRI-REPORT message to mark the end of interception and shall use the specific event
type of endOfInterceptionWithSessionActive, or not to generate an IRI-REPORT message and only communicate the
end of interception by other means (e.g. HI1 liDeactivated message).
When LI is activated without a network session context (see clause 5.2.5), as a national option the MF may generate an
IRI-BEGIN message to mark the start of interception and the specific event type of
startOfInterceptionWithoutNetworkSession shall be used (see clause 5.2.5 option 1).
When LI is deactivated without a network session context (see clause 5.2.5), as a national option the MF may generate
an IRI-REPORT message to mark the end of interception and the specific event type of
endOfInterceptionWithoutNetworkSession shall be used (see clause 5.2.5 option 1).
When the MF terminates an interception session due to an interception expiry condition (see clause 5.2.6), the MF shall
generate an IRI-REPORT message to mark the end of interception of that interception session and shall use the specific
event type of sessionExpired.
6.2 HI2 attributes
The attributes of IRI information for layer 2 interception is dependent upon the type of access technology utilized.
Annex A defines for each technology that is relevant to the present document in which of the IRI messages a parameter
value has to be provided.
ETSI
18 ETSI TS 102 232-4 V3.8.1 (2025-08)
7 Content of Communication (CC)
7.1 CC events
CC is provided for every layer 2 datagram sent through the AP's network that is addressed to, or sent from, the line
termination point of the target.
NOTE: The ASN.1 definition for CC is presented as the L2CC PDU in clause 8 ASN.1 for IRI and CC.
7.2 HI3 attributes
The CC payload contains a copy of the intercepted layer 2 datagram.
7.3 HI3 truncated attributes
Subject to national agreement the CC payload may also contain a truncated copy of the intercepted layer 2 datagram
when a LEA explicitly requests delivery of only a specified number of the first octets of all the intercepted layer 2
datagrams pertaining to the target. In this case only truncated layer 2 datagrams are delivered via HI3 using the
L2T
...
SLOVENSKI STANDARD
01-november-2025
Zakonito prestrezanje (LI) - Izročilni vmesnik in storitveno specifične podrobnosti
(SSD) za IP-dostavo vsebin - 4. del: Storitveno specifične podrobnosti za storitve
na 2. sloju
Lawful Interception (LI) - Handover Interface and Service-Specific Details (SSD) for IP
delivery - Part 4: Service-specific details for Layer 2 services
Ta slovenski standard je istoveten z: ETSI TS 102 232-4 V3.8.1 (2025-08)
ICS:
35.240.95 Spletne uporabniške rešitve Internet applications
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
TECHNICAL SPECIFICATION
Lawful Interception (LI);
Handover Interface and
Service-Specific Details (SSD) for IP delivery;
Part 4: Service-specific details for Layer 2 services
2 ETSI TS 102 232-4 V3.8.1 (2025-08)
Reference
RTS/LI-00288-4
Keywords
IP, Lawful Interception, layer 2, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871
Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.
Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2025.
All rights reserved.
ETSI
3 ETSI TS 102 232-4 V3.8.1 (2025-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 General . 9
4.1 Access network . 9
4.1.0 Overview . 9
4.1.1 Scenario 1 . 9
4.1.2 Scenario 2 . 10
4.1.3 Scenario 3 . 11
4.1.4 Scenario 4 . 11
4.2 Lawful Interception (LI) requirements . 12
4.2.0 Introduction. 12
4.2.1 Target identity . 12
4.2.2 Result of interception . 12
4.2.3 Intercept related information messages. 13
4.2.4 Time constraints . 13
5 System model . 13
5.1 Reference configuration . 13
5.2 Reference states . 14
5.2.1 Logon . 14
5.2.2 Data transport . 14
5.2.3 Logoff . 15
5.2.4 Unexpected connection loss . 15
5.2.5 Interception without network session events . 15
5.2.6 Mediation session expiry . 15
6 Intercept Related Information . 16
6.1 IRI events . 16
6.2 HI2 attributes . 17
7 Content of Communication (CC) . 18
7.1 CC events . 18
7.2 HI3 attributes . 18
7.3 HI3 truncated attributes . 18
8 ASN.1 for IRI and CC . 18
8.1 ASN.1 specification. 18
Annex A (normative): Reference network topologies . 19
A.0 Introduction . 19
A.1 xDSL access . 19
A.1.0 Overview . 19
A.1.1 Events and information . 19
ETSI
4 ETSI TS 102 232-4 V3.8.1 (2025-08)
A.2 Cable modem access . 25
A.3 WLAN access . 25
Annex B (informative): Stage 1 - RADIUS characteristics . 26
B.0 Introduction . 26
B.1 Network topology . 26
B.1.0 RADIUS deployment options. 26
B.1.1 RADIUS proxy . 26
Annex C (informative): Change history . 28
History . 30
ETSI
5 ETSI TS 102 232-4 V3.8.1 (2025-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI).
The present document is part 4 of a multi-part deliverable. Full details of the entire series can be found in part 1 [2].
The ASN.1 module is available as an electronic attachment to the present document (see clause 8.1 for more details).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
The present document focuses on layer 2 interception of IP-encoded information. It is to be used in conjunction with
ETSI TS 102 232-1 [2], in which the handling of the intercepted information is described.
ETSI
6 ETSI TS 102 232-4 V3.8.1 (2025-08)
1 Scope
The present document specifies Lawful Interception for an Access Provider that has access to layer 2 session
information and that is not required to have layer 3 information. In this case, the focus of Lawful Interception (LI) for IP
Network Access is on the portion of the network, commonly referred to as "layer 2 interception", that facilitates
subscriber access to the Public IP network.
The present document describes the LI at the interception domain of the access network.
The present document contains:
• a stage 1 description of the Lawful Interception service;
• a stage 2 description of the information flows between the functional entities (including the information
elements involved) and triggering events; and
• a stage 3 description of the protocol and procedures to be used in mapping from stage 2 information flows and
elements to Intercept Related Information (IRI) and Content of Communication (CC).
The present document is consistent with the definition of the Handover Interface, as described in ETSI
TS 102 232-1 [2].
NOTE 1: Layer 3 interception is described in ETSI TS 102 232-3 [12].
NOTE 2: Layer 2 interception is not applicable to the PS domain of the GSM/UMTS networks (3GPP
TS 23.060 [15]).
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found in the
ETSI docbox.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] Void.
[2] ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 1: Handover specification for IP delivery".
[3] IETF RFC 1122: "Requirements for Internet Hosts - Communication Layers".
[4] IETF RFC 1570: "PPP LCP Extensions".
[5] IETF RFC 3046: "DHCP Relay Agent Information Option".
[6] Recommendation ITU-T X.680: "Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation".
[7] Recommendation ITU-T E.164: "The international public telecommunication numbering plan".
[8] IETF RFC 2341: "Cisco Layer Two Forwarding (Protocol) "L2F"".
[9] IETF RFC 2637: "Point-to-Point Tunneling Protocol (PPTP)".
ETSI
7 ETSI TS 102 232-4 V3.8.1 (2025-08)
[10] IETF RFC 2661: "Layer Two Tunneling Protocol "L2TP"".
[11] IETF RFC 1661: "The Point-to-Point Protocol (PPP)".
[12] ETSI TS 102 232-3: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 3: Service-specific details for internet access services".
[13] ETSI TS 102 232-2: "Lawful Interception (LI); Handover Interface and Service-Specific Details
(SSD) for IP delivery; Part 2: Service-specific details for messaging services".
[14] ETSI TS 101 331: "Lawful Interception (LI); Requirements of Law Enforcement Agencies".
[15] ETSI TS 123 060: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); General Packet Radio Service (GPRS); Service
description; Stage 2 (3GPP TS 23.060)".
[16] Void.
[17] Void.
[18] Void.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] ETSI TR 102 503: "Lawful Interception (LI); ASN.1 Object Identifiers in Lawful Interception and
Retained data handling Specifications".
[i.2] ETSI TS 101 909-20-1: "Digital Broadband Cable Access to the Public Telecommunications
Network; IP Multimedia Time Critical Services; Part 20: Lawful Interception; Sub-part 1: CMS
based Voice Telephony Services".
[i.3] ETSI TS 101 909-20-2: "Digital Broadband Cable Access to the Public Telecommunications
Network; IP Multimedia Time Critical Services; Part 20: Lawful Interception; Sub-part 2:
Streamed multimedia services".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 102 232-1 [2], ETSI TS 102 232-3 [12] and the
following apply:
Access Provider (AP): Communication Service Provider (CSP), providing access to networks
NOTE 1: APs generally provide dial-up access through a modem and PPP connection, though companies that offer
Internet access with other devices, such as cable modems or wireless connections, could also be
considered APs.
NOTE 2: In the context of the present document, the network access is defined as IP-based network access to the
Internet.
ETSI
8 ETSI TS 102 232-4 V3.8.1 (2025-08)
access service: set of access methods provided to a user to access a service and/or a supplementary service
NOTE: In the context of the present document, the service to be accessed is defined as the Internet.
Application Service Provider (ASP): third-party entity that manages and distributes software-based services and
solutions to customers across a wide area network from a central data centre
NOTE: In the context of the present document, a company that offers services that are accessible to users who
have connectivity via the Internet.
interconnect network: network connecting the AP and the IAP, across which the layer 2 tunnel is established
Internet Access Provider (IAP): company that provides access to the Internet
NOTE: The IAP provides subscribers a username, password and an IP address that enables subscribers to log onto
the Internet for virtual connectivity to Application Service Providers.
layer 2: link layer
NOTE: As defined in IETF RFC 1122 [3].
layer 2 interception: lawful interception using technology that can access layer 2 information
Physical Line Termination Point (PLTP): point in the access provider's infrastructure where the physical line to the
customer is terminated
EXAMPLE: xDSL-line termination point, Cable-line termination point, Ethernet-line termination point.
tunnel router: router that is an endpoint of a layer 2 tunnel; there are at least two tunnel routers for each layer 2 tunnel
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA Authentication, Authorization and Accounting
ADSL Asymmetric Digital Subscriber Line
AP Access Provider
ASN.1 Abstract Syntax Notation 1
ASP Application Service Provider
ATM Asynchronous Transfer Mode
CC Content of Communication
CIN Communication Identity Number
CMTS Cable Modem Termination System
CPE Customer Premises Equipment
CR Change Request
CSP Communications Service Provider
DF Delivery Function
DHCP Dynamic Host Configuration Protocol
HI1 Handover Interface 1 (for Administrative Information)
HI2 Handover Interface 2 (for Intercept Related Information)
HI3 Handover Interface 3 (for Content of Communication)
IAP Internet Access Provider
IAS Internet Access Service
IP Internet Protocol
IRI Intercept Related Information
ISDN Integrated Services Digital Network
L2CC Layer 2 Content of Communication
L2F Layer 2 Forwarding
L2TP Layer 2 Tunnelling Protocol
ETSI
9 ETSI TS 102 232-4 V3.8.1 (2025-08)
LAES Lawful Authorized Electronic Surveillance
LAN Local Area Network
LCP Link Control Protocol
LEA Law Enforcement Agency
LEMF Law Enforcement Monitoring Facility
LI Lawful Interception
LIID Lawful Interception IDentifier
MAC Media Access Control
MD Mediation Device
MF Mediation Function
MOC Mandatory/Optional/Conditional
NAS Network Access Server
OID Object IDentifier
PDU Protocol Data Unit
PLTP Physical Line Termination Point
PPP Point-to-Point Protocol
PPTP Point-to-Point Tunnelling Protocol
PS Packet Switched
PSTN Public Switched Telephone Network
RADIUS Remote Authentication Dial In User Service
RFC IETF Request For Comment
SP Service Provider
TC Technical Committee
VoIP Voice over Internet Protocol
WLAN Wireless Local Area Network
xDSL Digital Subscriber Line technologies
4 General
4.1 Access network
4.1.0 Overview
An access network provides layer 2 connectivity from the Physical Line Termination Point (PLTP) for end-users to an
Application Service Provider (ASP) through an Internet Access Provider (IAP). The access provided may be via a
telephone, cable, or wireless-network. The present document describes the LI at the access network.
The figures contained in the following clauses do not necessarily refer to physical configurations but identify the
business roles associated with various scenarios to provide services. A provider can have one or more of following
roles: Access Provider (AP), Internet Access Provider (IAP) and Application Provider.
Lawful interception of communications has to accommodate a multitude of scenarios for public telecommunications.
Four representative scenarios are described below.
4.1.1 Scenario 1
This scenario reflects the situation in which the three identified provider roles are provisioned by independent providers.
For example, an ASP provides Call Control for VoIP service, and is using the transport facilities of an IAP for
connectivity to the AP.
In this scenario, the specifications of the present document are relevant to the AP, while the IAP and ASP may be
involved with interception according to the specifications of ETSI TS 102 232-2 [13] and ETSI TS 102 232-3 [12].
ETSI
10 ETSI TS 102 232-4 V3.8.1 (2025-08)
Figure 1: Scenario in which access, transport and application services
are offered by three different providers
4.1.2 Scenario 2
This scenario reflects the situation in which a network operator is acting only as an AP, and not as an IAP or ASP.
In this scenario, the specifications of the present document are relevant to the AP, while the IAP/ASP may be involved
with interception according to the specifications of ETSI TS 102 232-2 [13] and ETSI TS 102 232-3 [12].
Figure 2: Scenario in which access is offered by a provider separate from the one
that is offering Internet transport and application service
ETSI
11 ETSI TS 102 232-4 V3.8.1 (2025-08)
4.1.3 Scenario 3
This scenario reflects the situation in which the AP and IAP roles are offered by a single provider.
In this scenario the Service Provider (SP), having roles as an AP and an IAP, may be involved with interception
according to ETSI TS 102 232-3 [12] and layer 2 interception is not preferred.
Figure 3: Scenario in which access and Internet transport are offered by a
single provider that does not offer application service
4.1.4 Scenario 4
This scenario reflects the situation in which the AP, IAP and ASP roles are offered by a single provider.
In this scenario the service provider, having roles as an AP, an IAP and an ASP, may be involved with interception
according to ETSI TS 102 232-2 [13] and ETSI TS 102 232-3 [12], and layer 2 interception is not preferred.
Figure 4: Scenario in which access, transport and application services
are offered by the same provider
ETSI
12 ETSI TS 102 232-4 V3.8.1 (2025-08)
4.2 Lawful Interception (LI) requirements
4.2.0 Introduction
Clause 4.2 lists the requirements for Lawful Interception (LI). These requirements are derived from higher-level
requirements listed in ETSI TS 101 331 [14] and ETSI TS 102 232-1 [2] and are specific to Internet Access Services
(IAS). These requirements focus on both the administrative part of Internet Access for delivery over HI2 as well as
capturing traffic for delivery over HI3.
4.2.1 Target identity
Where the special properties of a given service, and the justified requirements of the LEAs, necessitate the use of
various identifying characteristics for determination of the traffic to be intercepted, the provider (CSP) shall ensure that
the traffic can be intercepted on the basis of these characteristics. The target identity known by the layer 2 mechanisms
is not an application or network identity; therefore, layer 2 interception has to be registered against a known layer 2
identity. The access network shall identify targeted activity by other means, e.g. the termination point of the xDSL-line
or the Cable-line.
In each case the characteristics shall be identifiable without unreasonable effort and shall be such that they allow clear
determination of the traffic to be intercepted.
The target identity should uniquely identify the target in the provider's network. The target identity will be dependent on
the access mechanism used and the parameters available with the AP. The target identity could be based on:
a) MAC address or vMAC. For example, the MAC address of the cable modem which is identified by the CMTS
can be requested to identify the target identity.
b) xDSL-line termination point, including, e.g. the IP-address of the Network Access Server (NAS), and the NAS
port; the NAS port is identified by the ATM virtual path, virtual channel and port number (slot, sub-slot and
port).
c) Cable-line termination point (including e.g. IP address, interface information of the CMTS).
d) DHCP option 82, circuit Id and remote Id, as defined in IETF RFC 3046 [5].
e) Calling party number (Recommendation ITU-T E.164 [7], Network-provided or User-provided, verified and
passed).
f) Other unique identifier agreed between AP and LEA.
4.2.2 Result of interception
The network operator shall provide Intercept Related Information (IRI), in relation to each target service:
a) when an attempt is made by the target to utilize the network;
b) when an attempt is made to reach the target from the network;
c) when an access to the network is permitted;
d) when an access to the network is not permitted;
e) when an access to the network is terminated.
The IRI shall contain:
a) identities used by or associated with the target identity;
b) details of services used and their associated parameters;
c) information relating to status;
d) timestamps.
ETSI
13 ETSI TS 102 232-4 V3.8.1 (2025-08)
Content of Communication (CC) shall be provided for every layer 2 datagram sent through the access network that is
addressed to, or sent from, the line termination point of the target.
The CC shall be a bit-exact copy of every intercepted layer 2 datagram.
4.2.3 Intercept related information messages
IRI shall be conveyed to the LEMF in IRI data records. Four types of IRI data records are defined:
1) IRI-BEGIN record at the first event of a communication attempt, opening the IRI transaction;
2) IRI-END record at the end of a communication attempt, closing the IRI transaction;
3) IRI-CONTINUE record at any time during a communication attempt within the IRI transaction;
4) IRI-REPORT record used in general for non-communication related events.
For a description of the use and purpose of the various IRI data records refer to ETSI TS 102 232-1 [2]. Which IRI
events are available for the different IRI data record types are described in clause 6.1.
4.2.4 Time constraints
Intercept Related Information shall be transmitted without undue delay. This delay should only be caused by the access
protocol handling and the automated forwarding of this information to the delivery function.
5 System model
5.1 Reference configuration
Figure 5 contains the reference configuration for the lawful interception.
HI1
INI1
Layer 2
Admistration Function
Authentication
Server
INI1
INI1
HI2
INI2
Mediation
Layer 2
Function 2
LEMF
CPE
Access
LEMF
INI1
HI3
Layer 2
INI3
Mediation
Interception
function Function 3
AP domain
IAP / ASP
Figure 5: Reference configuration for lawful interception
The reference configuration is only a logical representation of the entities involved in lawful interception and does not
mandate separate physical entities. This allows for higher levels of integration.
ETSI
14 ETSI TS 102 232-4 V3.8.1 (2025-08)
The messages sent in an implementation-specific manner between the Administrative Function and the other Access
Provider domain entities may contain:
• target identities;
• correlation information;
• information whether the CC shall be provided;
• the address of Mediation Function 2 for IRI;
• the address of Mediation Function 3 for the intercepted CC;
• the address for delivery of IRI (= LEMF address);
• the address of delivery for CC (= LEMF address);
• Lawful Interception Identifier (LIID).
The messages sent in an implementation-specific manner between the Interception Function and Mediation Function 2
contains the IRI.
The messages sent in an implementation-specific manner between the Interception Function and Mediation Function 3
contains the CC.
5.2 Reference states
5.2.1 Logon
If the xDSL-line or cable line is not owned by the party that provides the authentication server, then user identification
takes place in the network of the AP and the user identity and access request are forwarded to the authentication server
of the IAP. To exchange data between the user and IAP, a layer 2 tunnel is established, e.g. a L2TP tunnel per IETF
RFC 2661 [10]. All data between the IAP and the user is transported via this tunnel. If access is granted, an IP address
is provided by the IAP and communicated to the user via the layer 2 tunnel and then the user can communicate with the
Internet via the layer 2 tunnel.
If a layer 2 tunnel to an IAP is established, other users may be using the same tunnel, as only one tunnel is established
typically to each IAP.
5.2.2 Data transport
While having an active, virtual IP connection, the CPE can transmit IP datagrams towards any IP-enabled destination
connected to the Internet. These datagrams may contain other, higher-level IP-based protocols. Similarly, the CPE can
receive IP datagrams directed towards it from any IP-enabled source connected to the Internet.
It is possible that the CPE is connected to an Access Network that does not provide the Internet Access, e.g. if the AP
and the IAP are different parties as demonstrated in clauses 4.1.1 and 4.1.2. The AP provides the xDSL-line and routes
all datagrams that are destined to the IAP through a layer 2 tunnel via a gateway to the network of the IAP. Thus, all
datagrams from the user CPE are encapsulated in a specific layer 2 protocol (e.g. L2TP IETF RFC 2661 [10]) and
transmitted by the AP to the IAP.
ETSI
15 ETSI TS 102 232-4 V3.8.1 (2025-08)
Figure 6: Layer 2 tunnel shared by multiple users
Figure 6 shows the usage of a layer 2 tunnel. It is possible that only the traffic associated with one PLTP connected to
the CPE of one target is intercepted, as represented by the white IP-stream in figure 6. The other connections through
the tunnel are not intercepted. If the target session is terminated and the other connections are not terminated, the layer 2
tunnel stays online.
It is also possible that the communication of more than one target may be intercepted via the same layer 2 tunnel.
Furthermore, it is possible that a single IP-stream may be the subject of multiple, simultaneous lawful interceptions;
therefore, that single, intercepted IP-stream may be delivered to multiple LEMFs, or multiple copies of the stream may
have to be delivered to the same LEMF (once for each interception authorization).
5.2.3 Logoff
When a user logs off, the client running on the CPE will negotiate the closure of the session with the NAS of the AP.
For example, a PPP session may be closed through an exchange of LCP Terminate packets (see IETF RFC 1570 [4] for
LCP and IETF RFC 1661 [11] for PPP). Next, the NAS informs the authentication server in the IAP of the session
closure and may provide statistics on the session as well.
5.2.4 Unexpected connection loss
During an active data session, the virtual connection may terminate unexpectedly for reasons such as loss of carrier, link
quality failure, or the expiration of an idle-period timer. In such cases there can be no user-provided logoff indication,
and it is up to the NAS to detect the connection loss and to propagate the session closure towards the accounting server
of the IAP.
5.2.5 Interception without network session events
Apart from the reference scenarios previously described in clause 5.2, interception may occur in parts of a network
where a network session context is not available. An example could be a point of interception where layer 2 packets are
passively copied into an MF. That MF is then only aware of the layer 2 packets it has to intercept and not of the session
context pertaining to those packets.
Subject to national agreement, this scenario may be implemented as the following option:
1) An interception session with IRI generated by the MF, using appropriate IRI event types (see clause 6.1) based
on other events such as LI activation and deactivation. These IRI sessions may be started either on LI
activation or upon first layer 2 packet received after LI activation, subject to national agreement.
5.2.6 Mediation session expiry
Certain fault conditions in the interception process may require the MF to terminate an interception session without an
explicit network session event (e.g. DHCP or RADIUS) from the NAS, in order to prevent the interception sessions
consuming MF resources indefinitely. These fault conditions may include the non-receipt of a specific multiple of
expected regular network session events from the NAS.
NOTE: This is separate to an endReason (see annex A.1.1) of connectionTimeout, which may have a direct
mapping to a specific network event's service-specific parameter.
ETSI
16 ETSI TS 102 232-4 V3.8.1 (2025-08)
6 Intercept Related Information
6.1 IRI events
The following IRI-Events are applicable, if the traffic to and from the target is through the network of the AP.
Figure 7 shows the life cycle of a generic internet access session.
Access attempt
IRI-REPORT
accessAttempt
New CIN value
Access reject
(per national agreement)
Logged off IRI-REPORT Logging on
accessReject
Access failed
IRI-REPORT
accessFailed
Access end
Access accept
IRI-END
IRI-BEGIN
accessEnd
accessAccept
New CIN value
(per national agreement)
Session active
Interim update
End Intercept
IRI-CONTINUE
IRI-REPORT
interimUpdate
endOfInterceptionWithSessionActive, or
endOfInterceptionWithoutNetworkSession
Start intercept
IRI-BEGIN
Session expiry
startOfInterceptionWithSessionActive, or
IRI-REPORT
startOfInterceptionWithoutNetworkSession
sessionExpired
New CIN value
Start intercept End intercept
NOTE 1: Depending on the signalling implementation, there may be duplicate events due to resends. Resends of
events are be ignored as far as state-changes are concerned; this is not depicted in the diagram.
NOTE 2: Session expiry may occur from any state for an existing interception session.
Figure 7: State diagram for an Internet session
Subject to agreement on a national level, it is acceptable to perform the CIN allocation on the accessAccept rather than
the accessAttempt. If this option is chosen, the CSPs shall allocate a new CIN only on the IRI-BEGIN messages; and
send accessAttempt, accessReject and accessFailed as standalone messages not associated with any other CC or IRI.
Figure 7 allows for a model where detailed information is available regarding the identification and authentication
process as well as for a simple model where just a session start notification is available.
The IRI events depicted in figure 7 are described in table 1.
ETSI
17 ETSI TS 102 232-4 V3.8.1 (2025-08)
Table 1: IRI events (Layer 2)
IRI Event Description IRI Record
A target requests access to the Internet Access
accessAttempt REPORT
Service (IAS).
The network elements are triggered to erect a layer 2
accessAccept BEGIN
tunnel between the user and the foreign IAP network.
accessReject The access is refused. REPORT
accessFailed The accessAttempt timed-out or failed otherwise. REPORT
interimUpdate Intermediate status report on service status or usage. CONTINUE
The communication between the user and the IAP
network terminated. This may be for numerous
accessEnd reasons that are not visible to the AP (e.g. the user END
logs off or shortage of network capacity between the
AP and the IAP) (see note).
As sessions can be active over longer periods, it is
startOfInterceptionWithSessionActive not unlikely for an intercept to start after a user BEGIN
session has started already.
As sessions can be active over longer periods, it is
endOfInterceptionWithSessionActive not unlikely for an intercept to end whilst a user REPORT
session remains active.
The interception session is started by the MF without
startOfInterceptionWithoutNetworkSession BEGIN
a network session event.
The interception session is ended by the MF without a
endOfInterceptionWithoutNetworkSession REPORT
network session event.
sessionExpired The interception session is expired by the MF. REPORT
NOTE: If there are other connections still using the same tunnel, the tunnel remains available.
When LI is activated during an already active internet session, which the IAP is aware of, it is recommended that an
IRI-BEGIN message is generated to mark the start of interception and the specific event type of
startOfInterceptionWithSessionActive shall be used.
When LI is deactivated during an already active internet session, which the IAP is aware of, as a national option the MF
may choose to either generate an IRI-REPORT message to mark the end of interception and shall use the specific event
type of endOfInterceptionWithSessionActive, or not to generate an IRI-REPORT message and only communicate the
end of interception by other means (e.g. HI1 liDeactivated message).
When LI is activated without a network session context (see clause 5.2.5), as a national option the MF may generate an
IRI-BEGIN message to mark the start of interception and the specific event type of
startOfInterceptionWithoutNetworkSession shall be used (see clause 5.2.5 option 1).
When LI is deactivated without a network session context (see clause 5.2.5), as a national option the MF may generate
an IRI-REPORT message to mark the end of interception and the spec
...










Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...