ETSI TS 103 221-1 V1.4.1 (2019-04)

TECHNICAL SPECIFICATION
Lawful Interception (LI);
Part 1: Internal Network Interface X1 for Lawful Interception


2 ETSI TS 103 221-1 V1.4.1 (2019-04)

Reference
RTS/LI-00170-1
Keywords
interface, lawful interception
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 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
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 at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE 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.
ETSI
3 ETSI TS 103 221-1 V1.4.1 (2019-04)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Overview . 10
4.1 Reference model . 10
4.1.1 Introduction. 10
4.1.2 ADMF deployment model . 10
4.1.3 Triggering deployment model. 11
4.1.4 Mediation function deployment model . 11
4.2 Reference model for X1: requesting and responding . 11
4.3 Overview of security . 12
4.4 Relationship to other standards . 12
4.5 Release management . 13
5 Basic concepts . 13
5.1 The lifecycle of a Task . 13
5.1.1 Start and end of a Task . 13
5.1.2 Identification of a Task . 13
5.1.3 Destinations . 13
5.2 The lifecycle of an X1 request/response . 13
5.2.1 Identification of X1 request/response . 13
5.2.2 Responding to the request . 14
5.2.3 Behaviour if a response is not received . 14
5.3 Warnings and Faults . 14
6 Message Structure and Data Definitions . 15
6.1 X1 Message details . 15
6.2 Message definitions: starting, modifying and stopping tasks . 16
6.2.1 ActivateTask . 16
6.2.1.1 Summary . 16
6.2.1.2 TaskDetails. 16
6.2.2 ModifyTask. 18
6.2.3 DeactivateTask . 19
6.2.4 DeactivateAllTasks . 19
6.3 Message definitions: creating, modifying and removing Destinations . 20
6.3.1 CreateDestination . 20
6.3.1.1 Summary . 20
6.3.1.2 DestinationDetails . 20
6.3.2 ModifyDestination . 21
6.3.3 RemoveDestination . 21
6.3.4 RemoveAllDestinations . 21
6.4 Message details: Getting information from NE . 22
6.4.1 Introduction. 22
6.4.2 GetTaskDetails . 22
6.4.2.1 Summary . 22
6.4.2.2 TaskStatus . 23
6.4.3 GetDestinationDetails . 23
ETSI
4 ETSI TS 103 221-1 V1.4.1 (2019-04)
6.4.3.1 Summary . 23
6.4.3.2 DestinationStatus . 24
6.4.4 GetNEStatus . 24
6.4.4.1 Summary . 24
6.4.5 GetAllDetails . 25
6.4.5.1 Summary . 25
6.4.6 ListAllDetails . 25
6.4.6.1 Summary . 25
6.5 Message details: Reporting issues from the NE . 26
6.5.1 Introduction. 26
6.5.2 ReportTaskIssue on given XID . 26
6.5.2.1 Summary . 26
6.5.2.2 Task report types . 26
6.5.3 ReportDestinationIssue on given DID . 27
6.5.3.1 Summary . 27
6.5.4 ReportNEIssue . 27
6.6 Message details: Pings and Keepalives . 28
6.6.1 Ping . 28
6.6.2 Keepalive . 28
6.7 Protocol error details . 29
7 Transport and Encoding . 30
7.1 Introduction . 30
7.2 Profile A . 31
7.2.1 Encoding . 31
7.2.2 Transport layer . 31
7.2.2.1 HTTPS and HTTP . 31
7.2.2.2 How HTTP is used . 31
7.2.2.3 Profile . 31
8 Security. 32
8.1 Introduction . 32
8.2 Transport Security . 32
8.2.1 Summary . 32
8.2.2 Profile . 32
8.2.3 Key generation, deployment and storage . 32
8.2.4 Authentication . 32
8.3 Additional security measures (beyond transport layer) . 33
Annex A (normative): Requirements . 34
A.1 Basic requirements . 34
A.1.1 Existing standards. 34
A.2 Protocol & Architecture requirements. 34
A.3 Security requirements . 35
A.4 Other requirements . 36
A.4.1 Performance statistics (For Further Study) . 36
A.4.2 Capability detection . 37
A.4.3 Remote triggering . 37
A.4.4 Requirements to be handled by the transport layer . 37
Annex B (normative): Use of extensions . 38
B.1 Introduction . 38
B.2 Extension definitions . 38
Annex C (normative): Using Task Object at Mediation Functions . 39
C.1 Introduction . 39
C.2 TaskDetails . 39
C.2.1 General . 39
ETSI
5 ETSI TS 103 221-1 V1.4.1 (2019-04)
C.2.2 MediationDetails structure . 39
Annex D (informative): Change history . 40
History . 41

ETSI
6 ETSI TS 103 221-1 V1.4.1 (2019-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, 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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Lawful Interception (LI).
The present document is part 1 of a multi-part deliverable covering the internal network interfaces for Lawful
Interception, as identified below:
Part 1: "Internal Network interface X1 for Lawful Interception";
Part 2: "Internal Network Interface X2/X3 for Lawful Interception".
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.

ETSI
7 ETSI TS 103 221-1 V1.4.1 (2019-04)
1 Scope
The present document defines an electronic interface for the exchange of information relating to the establishment and
management of Lawful Interception. Typically, this interface would be used between a central LI administration
function and the network internal interception points.
Typical reference models for LI define an interface between Law Enforcement Agencies (LEAs) and Communication
Service Providers (CSPs), called the handover interface. They also define an internal network interface within the CSP
domain between administration and mediation functions for lawful interception and network internal functions, which
facilitates the interception of communication. This internal network interface typically consists of three sub-interfaces;
administration (called X1), transmission of intercept related information (X2) and transmission of content of
communication (X3). The present document specifies the administration interface X1.
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 at
https://docbox.etsi.org/Reference/.
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] ETSI TS 133 107: "Universal Mobile Telecommunications System (UMTS); LTE; Digital cellular
telecommunications system (Phase 2+) (GSM); 3G security; Lawful interception architecture and
functions (3GPP TS 33.107)".
[2] IETF RFC 4122: "A Universally Unique Identifier (UUID) URN Namespace".
[3] W3C Recommendation 28 October 2004: "XML Schema Part 2: Datatypes Second Edition".
[4] ETSI TS 103 280: "Lawful Interception (LI); Dictionary for common parameters".
[5] Recommendation ITU-T E.212: "The international identification plan for public networks and
subscriptions".
[6] ETSI TS 123 003: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Numbering, addressing and identification (3GPP
TS 23.003)".
[7] IETF RFC 3261: "SIP: Session Initiation Protocol".
[8] IETF RFC 3966: "The tel URI for Telephone Numbers".
[9] IETF RFC 3508: "H.323 Uniform Resource Locator (URL) Scheme Registration".
[10] IETF RFC 7542: "The Network Access Identifier".
[11] IETF RFC 2865: "Remote Authentication Dial In User Service (RADIUS)".
[12] IETF RFC 2818: "HTTP over TLS".
[13] IETF RFC 7230: "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
ETSI
8 ETSI TS 103 221-1 V1.4.1 (2019-04)
[14] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
NOTE: Obsoleted by IETF RFC 8446.
[15] IETF RFC 6176: "Prohibiting Secure Sockets Layer (SSL) Version 2.0".
[16] IETF RFC 7525: "Recommendations for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)".
[17] IETF RFC 6125: "Representation and Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of
Transport Layer Security (TLS)".
[18] IETF RFC 4519: "Lightweight Directory Access Protocol (LDAP): Schema for User
Applications".
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 are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] OWASP TLS Cheat Sheet.
NOTE: Available at https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet.
[i.2] ETSI TR 103 308: "CYBER; Security baseline regarding LI and RD for NFV and related
platforms".
[i.3] ETSI GS NFV-SEC 009: "Network Functions Virtualisation (NFV); NFV Security; Report on use
cases and technical approaches for multi-layer host administration".
[i.4] ETSI GS NFV-SEC 012: "Network Functions Virtualisation (NFV) Release 3; Security; System
architecture specification for execution of sensitive NFV components".
[i.5] OWASP XML Security Cheat Sheet.
NOTE: Available at https://www.owasp.org/index.php/XML_Security_Cheat_Sheet.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
destination: point to which IRI and/or CC is delivered by the NE
Destination IDentifier (DID): identifier to uniquely identify a Destination internally to the X1 interface
protocol error: error at the X1 protocol level (rather than any fault with ADMF or NE)
NOTE: In the present document, the term "error" in general refers to a protocol error, whereas issues with
systems not behaving correctly are called "faults".
task: continuous instance of interception at a single NE carried out against a set of target identifiers, identified by an X1
Identifier, starting from an activate command and ending with a deactivate command or terminating fault
ETSI
9 ETSI TS 103 221-1 V1.4.1 (2019-04)
terminating fault: fault signalled from NE to ADMF which terminates the specific Task
X1: LI interfaces internal to the CSP for management tasking
X2: LI interfaces internal to the CSP for IRI delivery
X3: LI interfaces internal to the CSP for CC delivery
X1 Identifier (XID): identifier to uniquely identify a Task internally to the X1 interface
X1 Transaction ID: identifier used to identify a specific request/response pair
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADMF ADMinistration Function
AVP Attribute-Value Pair
CC Content of Communication
CIDR Classless Inter Domain Routing
CSP Communication Service Provider
DID Destination IDentifier
FQDN Full Qualified Domain Name
FTP File Transfer Protocol
GTP-C GPRS Tunnel Protocol (Control plane)
GTP-U GPRS Tunnel Protocol (User plane)
HI Handover Interface
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPS HTTP over TLS
IMEI International Mobile Equipment Identity
IMPI IP Multimedia Private Identity
IMPU IP Multimedia PUblic identity
IMSI International Mobile Station Identity
IP Internet Protocol
IRI Intercept Related Information
LEA Law Enforcement Agency
LEMF Law Enforcement Monitoring Facility
LI Lawful Interception
MAC Media Access Control
NAI Network Access Identifier
NAT Network Address Translation
NE Network Element
NOTE: The element or function performing the interception.
NF Network Function
NFV Network Functions Virtualisation
OWASP Open Web Application Security Project
RADIUS Remote Authentication Dial In User Service
SGSN Serving GPRS Support Node
SIP Session Initiation Protocol
SNMP Simple Network Management Protocol
TCP Transmission Control Protocol
TISPAN Telecommunication and Internet converged Services and Protocols for Advanced Networking
TLS Transport Layer Security
TPM Trusted Platform Module
ETSI
10 ETSI TS 103 221-1 V1.4.1 (2019-04)
UDP User Datagram Protocol
UID Unique IDentifier
URI Uniform Resource Identifier
UTF UCS Transformation Formats
UUID Universally Unique IDentifier
XID X1 IDentifier
XML eXtended Markup Language
XSD XML Schema Definition
4 Overview
4.1 Reference model
4.1.1 Introduction
The X1 interface is based on communication between two entities; the controlling function (e.g. a CSP Administration
Function (ADMF)), and the controlled function (e.g. a Network Element (NE) performing interception or mediation).
The X1 reference model is shown in figure 1.
X1
Controlled Function Controlling Function

Figure 1: X1 reference model
While the present document uses the terms "NE", the term is intended to represent any given Network Function (NF)
which is intended to be given information regarding interception or mediation. Similarly, the term "ADMF" is intended
to represent any given network function that controls interception or mediation in other functions.
4.1.2 ADMF deployment model
Figure 2 shows a deployment model for X1 where a CSP ADMF uses X1 to provision a number of NEs to perform
interception.
NENE
NENE X1
X1
ADMF Law Enforcement
NENE X1
Tasking interface
X1
e.g. HI-1
NENE
(out of scope)
Figure 2: X1 reference model
Only one ADMF shall make changes by X1 to a given NE. This is called the ADMF which is "responsible" for that NE.
Onward delivery of information from the NE is called X2 (for IRI) and X3 (for CC). The choice of protocols for X2 and
X3 are out of scope of the present document.
ETSI
11 ETSI TS 103 221-1 V1.4.1 (2019-04)
Some deployments may involve multiple ADMFs for redundancy or other purposes; where multiple ADMFs are
required, the NE shall be implemented such that it presents itself as a separate NE to each ADMF.
ADMF and NE shall implement time synchronization where possible; in situations where it is not possible, the ADMF
shall maintain knowledge of the timing offset between the ADMF and NE.
NOTE: The present document may be used in direct delivery scenarios, in which the NE delivers directly to the
LEMF. Any consequences of using direct delivery are out of scope of the present document.
4.1.3 Triggering deployment model
Figure 3 shows another possible deployment model for X1, where the X1 protocol is used to trigger interception by one
in a second network function. In this deployment model, the "Triggering Function" takes on the role of the ADMF in
the previous deployment model, while the "Triggered Function" takes on the role of the NE.
X1
Triggered Function Triggering Function
(plays role of “NE”) (plays role of “ADMF”)

Figure 3: X1 deployment model for Triggering Functions
If this deployment model is used, then in the following clauses references to the ADMF should be interpreted as
applying to the Triggering Function, while references to the NE should be interpreted as references to the Triggered
Function.
4.1.4 Mediation function deployment model
Figure 4 shows another possible deployment model for X1, where the X1 protocol is used to manage a CSP mediation
function. In this deployment model, the MF takes on the role of the NE in the previous deployment model.
X1
Mediation Function
ADMF
(plays role of “NE”)
Figure 4: X1 deployment model for Mediation Functions
If this deployment model is used, then in the following clauses references to the NE should be interpreted as applying to
the MF.
4.2 Reference model for X1: requesting and responding
X1 transactions consist of a request followed by a response.
Requests may be sent in either direction i.e. with the ADMF or NE initiating the request. The side initiating the request
is called the "Requester"; this term is used when it is not specified whether it is the ADMF or NE making the request.
The other side is called the "Responder".
ETSI
12 ETSI TS 103 221-1 V1.4.1 (2019-04)
Request
Requester Responder
(could be (could be
ADMF or NE) ADMF or NE)
Response
Figure 5: Showing generic terminology
It is likely that in most situations, the ADMF will initiate the message i.e. to distribute information or request status.
However, it is possible that the NE will initiate the request in order to deliver fault reports, etc.
Request
CSP
Network Element
Administration
(NE)
Function (ADMF)
Response
ADMF is Requester
Request
CSP
Network Element
Administration
(NE)
Function (ADMF)
Response
NE is Requester
Figure 6: Showing two situations with either ADMF or NE as the requester
4.3 Overview of security
Security is based on creating public/private keys for the ADMF and each NE for which it is responsible. All
transactions over X1 are performed using the security procedures in clause 8, which provide assurance that
communication only takes place between an NE and ADMF which have been populated with the relevant key material.
NE implementers are strongly discouraged from exposing additional interfaces for controlling the LI functionality of the
NE other than by X1 e.g. via a local administrative interface at the NE. If such additional interfaces exist, any such
action performed on the NE shall be captured on the NE audit/logging, and any consequences of such actions shall be
able to be seen and controlled by the ADMF that is responsible for the NE i.e. the ADMF shall be able to use the X1
interface to stop or undo any changes made over a local administrative interface. There may be broader consequences
that are not covered by the present document if an NE is tasked independently of the X1 interface (e.g. security
concerns).
4.4 Relationship to other standards
The present document forms part of a family of internal interface documents covering all of X1, X2 and X3 which are
handled as separate standards.
Some models of LI (e.g. ETSI TS 133 107 [1]) define interfaces between ADMF and functions which perform
mediation and delivery of content and IRI, (e.g. X1_2 and X1_3 defined by ETSI TS 133 107 [1]). The present
document is designed to fulfil the requirements for X1_1 as defined in ETSI TS 133 107 [1].
ETSI
13 ETSI TS 103 221-1 V1.4.1 (2019-04)
4.5 Release management
This clause describes the release management requirements. The requirements are:
• The version of the present document is defined as ...
• The major version should be incremented when making a backwards incompatible change.
• The minor version should be incremented when adding backwards compatible functionality.
• The patch version should be incremented when fixing a backwards compatible bug.
Once a major version has been incremented, the previous major version will be supported for 2 years after publication
of the new version. Change requests issued to a version that is no longer supported will need to be issued for the latest
supported major version.
5 Basic concepts
5.1 The lifecycle of a Task
5.1.1 Start and end of a Task
A Task relates to a single target identifier, and goes from the point an ActivateTask Request is sent by the ADMF to the
time a DeactivateTask Request is sent by the ADMF, a "terminating fault" occurs, or (for Tasks with the
"ImplicitDeactivationAllowed" flag set) the NE determines that it has completed.
The present document does not define which situations are categorized as "terminating faults". Local recovery
procedures should be followed before a Task is ended with a "terminating fault". In general, irrecoverable failures with
an interception, or major security issues at an NE should be considered terminating faults, and certain outcomes with
keepalives are also terminating faults (where defined in clause 6.6.2).
5.1.2 Identification of a Task
Each Task on X1 is uniquely identified by an X1 Identifier (XID) and it is handled independently of all others. The
ADMF shall assign the XID as a version 4 UUID as per IETF RFC 4122 [2]. The ADMF is responsible for correlating
the XID to any LI instance identifiers used to communicate with Law Enforcement.
In addition, the XID is released once the Task has ended.
5.1.3 Destinations
Intercepted traffic is delivered by the NE to a Destination. Each Destination is uniquely identified by a Destination
Identifier (DID), and is handled independently from details of the Task. Each Task is associated with one or more
Destinations. Prior to associating a Task with a given DID, it is required that a Destination with the DID has already
been created (as described in clause 6.3) but there is no requirement that a connection has been successfully established
for that DID. Checks regarding availability and status of downstream delivery of information are outside the scope of
the present document.
5.2 The lifecycle of an X1 request/response
5.2.1 Identification of X1 request/response
Each request and response shall be identified by an X1TransactionID. The requester (may be ADMF or NE) shall assign
an X1TransactionID as a version 4 UUID as per IETF RFC 4122 [2].
ETSI
14 ETSI TS 103 221-1 V1.4.1 (2019-04)
5.2.2 Responding to the request
The response shall be sent without undue delay and shall be sent within TIME1 of receiving the request. TIME1 shall
be configurable and by default TIME1 shall be five seconds. TIME2, the time a requester waits for a response, shall be
configurable, it shall be at least twice TIME1 and by default shall be fifteen seconds.
An error response shall be sent if the request is not compliant syntactically (it does not match the schema) or
semantically (it is not compliant or consistent with the existing state of the NE e.g. activating an existing XID).
If the request is compliant, one of the following responses shall be sent:
• "OK - Acknowledged and Completed" response shall be sent if the request is fully understood, compliant and
the request has been successfully completed. If the request was a request for information then all the
information shall be delivered together as part of the "OK - Acknowledged and Completed" response. The NE
and ADMF shall be designed so that information requested (status and Task information) is in a data store
which is readily available without undue delay and within TIME1.
• If the action requested cannot be completed within TIME1, an "OK - Acknowledged" response shall be sent.
A status report shall be sent by the NE as soon as the action is completed or if it is unsuccessful (see
clause 6.5.2.2). This status report shall be sent as a new request/response pair, using the same XID but the
status report shall have its own X1TransactionID. The "OK - Acknowledged" response shall only be used for
responding to requests which are Activating, Modifying or Deleting Tasks and Destinations (those in
clauses 6.2 and 6.3) and they shall not be used to respond to other request types.
5.2.3 Behaviour if a response is not received
If the requester has not received a response after TIME2 (as defined in clause 5.2.2), or if a status report on the
completion of the whole request following an "OK - Acknowledge" has not been received in a timely fashion, the
requester may assume that either the request or response failed to get through. For example, the requester may consider
requesting the status of the XID in question to see whether the prior request has been actioned (e.g. ActivateTask,
ModifyTask, DeactivateTask or DeactivateAllTasks) or the requester may re-send the original request (as a new
request, with a new X1TransactionID).
5.3 Warnings and Faults
The present document uses the term "error" to mean a protocol error within the X1 protocol as defined in clause 6.7.
All other problems are categorized as warnings or faults:
• Warnings are one-off problems i.e. sent by the NE and then not referred to again over X1. Warnings shall not
be used for issues which are affecting traffic (i.e. losing content or intercept-related information). For example,
warnings may include resources being nearly exhausted but not yet traffic-affecting. Warnings should include
that keys/certificates are about to expire.
• Faults are problems which the NE will continue to be aware of and which the NE is trying to manage and/or
rectify. Any issue which loses traffic is categorized as a fault.
Warnings are reported using issue-reporting messages (clause 6.5) but then are not included in any future Status-Getting
messages (see clause 6.4). The NE shall log any warnings for audit reasons.
The NE shall remember which of the XIDs are in fault and whether the NE itself is in a fault situation. An issue report
(see clause 6.5) is required at the start of the fault. The NE shall report faults when responding to the Status-Getting
message defined in clause 6.4. The NE shall also indicate that a fault has been cleared (see clauses 6.5.2 and 6.5.3)
unless otherwise configured.
ETSI
15 ETSI TS 103 221-1 V1.4.1 (2019-04)
6 Message Structure and Data Definitions
6.1 X1 Message details
X1 messages contain information as defined in table 1 (the information is Mandatory, Optional or Conditional as shown
in the last column).
Table 1: Message details
Field Description Format Mandatory (M),
Optional (O) or
Conditional (C)
ADMF Identifier Identifies the ADMF uniquely to the NE. Token as per [3], M
Required to match the details provided by section 3.4.2. Definition
the ADMF's X.509 certificate (see clause 8) and assignment of
identifiers is a
deployment issue
NE Identifier Uniquely identifies the NE to the ADMF. Token as per [3], M
Required to match the details provided by section 3.4.2.
the NE's X.509 certificate (see clause 8) Definition and
assignment of
identifiers is a
deployment issue
MessageTimestamp Timestamp indicating the time the message See ETSI TS 103 280 M
was sent by the requester [4] Qualified
Microsecond Date Time
Version Version of the present document used for See clause 4.5 M
encoding the message
X1TransactionID Used to correlate Request and Response. An ID as defined in C
Shall be omitted for "TopLevelError" clause 5.2
situations as defined below this table but
otherwise is mandatory
In addition to the information in the table above, the X1 Request shall indicate the type of request being made (see
clauses 6.2 to 6.6), and contain the appropriate request parameters
...