SIST-TS ETSI/TS 103 280 V2.16.1:2025

TECHNICAL SPECIFICATION
Lawful Interception (LI);
Dictionary for common parameters


2 ETSI TS 103 280 V2.16.1 (2025-08)

Reference
RTS/LI-00292
Keywords
dictionary, lawful interception, 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 103 280 V2.16.1 (2025-08)
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 . 9
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Release management . 10
5 Parameter requirements . 11
5.0 Introduction . 11
5.1 Parameter attributes . 11
5.2 Parameter naming conventions . 11
5.3 Technology conventions . 12
5.4 Regular expression conventions . 12
6 Parameter dictionary. 13
6.1 LIID . 13
6.2 UTCDateTime . 13
6.3 UTCMicrosecondDateTime . 14
6.4 QualifiedDateTime . 14
6.5 QualifiedMicrosecondDateTime . 14
6.6 InternationalE164 . 14
6.7 IMSI . 15
6.8 IMEI . 15
6.9 IMEICheckDigit . 15
6.10 IMEISV . 15
6.11 IPv4Address . 16
6.12 IPv4CIDR . 16
6.13 IPv6Address . 16
6.14 IPv6CIDR . 16
6.15 IPAddress . 17
6.16 IPCIDR . 17
6.17 TCPPort . 17
6.18 TCPPortRange . 18
6.19 UDPPort . 18
6.20 UDPPortRange . 18
6.21 Port . 19
6.22 PortRange . 19
6.23 IPAddressP ort . 19
6.24 IPAddressPortRange . 20
6.25 MACAddress . 20
6.26 EmailAddress . 20
6.27 UUID . 20
6.28 ISOCountryCode . 21
6.29 ShortString . 21
6.30 LongString . 21
6.31 SIPURI . 21
6.32 TELURI . 21
6.33 WGS84CoordinateDecimal . 22
6.34 WGS84LatitudeDecimal . 22
ETSI
4 ETSI TS 103 280 V2.16.1 (2025-08)
6.35 WGS84LongitudeDecimal . 22
6.36 WGS84CoordinateAngular . 22
6.37 WGS84LatitudeAngular . 23
6.38 WGS84LongitudeAngular . 23
6.39 SUPIIMSI . 23
6.40 SUPINAI . 24
6.41 SUCI . 24
6.42 PEIIMEI . 24
6.43 PEIIMEICheckDigit . 24
6.44 PEIIMEISV . 25
6.45 GPSIMSISDN . 25
6.46 GPSINAI . 25
6.47 NAI . 25
6.48 LDID . 26
6.49 InternationalizedEmailAddress . 26
6.50 EUI64 . 26
6.51 CGI . 26
6.52 ECGI . 27
6.53 NCGI . 27
6.54 ICCID . 27
6.55 IPProtocol . 27
6.56 VLANID. 27
6.57 VIN . 28
6.58 ServiceAccessIdentifier . 28
6.59 EUICCID . 28
6.60 APN . 28
6.61 DNN . 29
6.62 H323URI . 29
6.63 IMPU . 29
6.64 IMPI . 29
7 Technical implementation . 30
7.1 XSD . 30
7.2 ASN.1 . 30
7.3 JSON . 30
Annex A (normative): XSD definition . 31
Annex B (normative): ASN.1 definition . 32
Annex C (informative): XSD to JSON schema translation . 33
C.1 Overview . 33
C.2 General translation rules . 33
C.3 Translation of simple types . 33
C.3.1 Translation rules . 33
C.3.2 Restrictions of XSD native simple types . 33
C.3.3 Restrictions of other simple types . 34
C.4 Translation of complex types . 34
C.4.1 Translation rules . 34
C.4.2 Translation of sequences . 34
C.4.3 Translation of choices . 35
Annex D (normative): Translation of instance documents . 36
D.1 Overview . 36
D.2 Root element translation . 36
D.3 General element translation . 36
D.4 List element translation . 36
ETSI
5 ETSI TS 103 280 V2.16.1 (2025-08)
D.5 Attribute translation . 36
Annex E (informative): Change history . 37
History . 39

ETSI
6 ETSI TS 103 280 V2.16.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 ASN.1, JSON Schema and XSD technical implementations are both available as an electronic attachment to the
present document.
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 280 V2.16.1 (2025-08)
1 Scope
The present document defines a dictionary of parameters that are commonly used in multiple TC LI specifications.
Aside from defining a dictionary, the present document aims to provide technical means for other specifications to use.
It is encouraged to use the present document in the development of new specifications.
It is foreseen that regular maintenance of the present document is required. As such, release management requirements
will be defined.
Before accepting any new common parameter, the present document will provide a set of requirements the parameter
has to comply to in order to become a common parameter.
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] 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". ®
[2] W3C Recommendation 5 April 2012: "W3C XML Schema Definition Language (XSD) 1.1
Part 2: Datatypes".
[3] Recommendation ITU-T X.680: "Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation".
[4] Recommendation ITU-T E.164: "The international public telecommunication numbering plan".
[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); LTE; 5G; Numbering, addressing and identification
(3GPP TS 23.003)".
[7] ETSI TS 102 657: "Lawful Interception (LI); Retained data handling; Handover interface for the
request and delivery of retained data".
[8] IETF RFC 791: "Internet Protocol".
[9] IETF RFC 4632: "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and
Aggregation Plan".
[10] IETF RFC 8200: "Internet Protocol, Version 6 (IPv6) Specification".
[11] IETF RFC 4291: "IP Version 6 Addressing Architecture".
[12] IETF RFC 9293: "Transmission Control Protocol (TCP)".
[13] IETF RFC 768: "User Datagram Protocol".
ETSI
8 ETSI TS 103 280 V2.16.1 (2025-08)
[14] IEEE 802.3™: "IEEE Standard for Ethernet".
[15] IETF RFC 5322: "Internet Message Format".
[16] WHATWG community: "HTML Living standard".
[17] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[18] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions — Part 1:
Country codes".
[19] Void.
[20] ISO/IEC 7812-1:2017: "Identification cards — Identification of issuers — Part 1: Numbering
system".
[21] IETF RFC 3261: "SIP: Session Initiation Protocol".
[22] IETF RFC 3966: "The tel URI for Telephone Numbers".
[23] DMA Technical Report 8350.2: "Department of Defense World Geodetic System 1984, Its
Definition and Relationships With Local Geodetic Systems".
[24] ETSI TS 123 501: "5G; System architecture for the 5G System (5GS) (3GPP TS 23.501)".
[25] ETSI TS 133 501: "5G; Security architecture and procedures for 5G System (3GPP TS 33.501)".
[26] IETF RFC 7542: "The Network Access Identifier".
[27] ETSI TS 124 501: "5G; Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3
(3GPP TS 24.501)".
[28] ETSI TS 103 120: "Lawful Interception (LI); Interface for warrant information". ®
[29] W3C Recommendation 16 August 2006: "Extensible Markup Language (XML) 1.1 (Second
Edition)".
[30] IETF RFC 6530: "Overview and Framework for Internationalized Email".
[31] IETF RFC 9542: "IANA Considerations and IETF Protocol and Documentation Usage for
IEEE 802 Parameters".
[32] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics".
[33] ETSI TS 129 571: "5G; 5G System; Common Data Types for Service Based Interfaces; Stage 3
(3GPP TS 29.571)".
[34] IANA: "Assigned Internet Protocol Numbers".
[35] IETF Draft draft-bhutton-json-schema-01: "JSON Schema: A Media Type for Describing JSON
Documents". ®
[36] ECMA-262: "ECMAScript 2023 Language Specification".
[37] IEEE 802.1Q™-2014: "IEEE Standard for Local and metropolitan area networks -- Bridges and
Bridged Networks".
[38] ISO 3779:2009: "Road vehicles — Vehicle identification number (VIN) — Content and structure".
[39] GSMA SGP.02: "Remote Provisioning Architecture for Embedded UICC Technical
Specification".
[40] IETF RFC 3508: "H.323 Uniform Resource Locator (URL) Scheme Registration".
ETSI
9 ETSI TS 103 280 V2.16.1 (2025-08)
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.
Not applicable.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
APN Access Point Name
ASCII American Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation One
CC Content of Communication
CGI Cell Global Identification
CI Cell Identity
CIDR Classless Inter-Domain Routing
CSP Communications Service Provider
DNN Data Network Name
ECGI E-UTRAN Cell Global Identification
ECI E-UTRAN Cell Identity
EID eUICC IDentifier
EUI Extended Unique Identifier
eUICC Embedded Universal Integrated Circuit Card
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GPSI Generic Public Subscription Identifier
HEX HEXadecimal
HI Handover Interface
HI1 Handover Interface port 1 (for administrative information)
HI2 Handover Interface port 2 (for Intercept Related Information)
HI3 Handover Interface port 3 (for Content of Communication)
IANA Internet Assigned Numbers Authority
ICCID Integrated Circuit Card IDentifier
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IEI Information Element Identifier
IETF Internet Engineering Task Force
IMEI International Mobile station Equipment Identity
ETSI
10 ETSI TS 103 280 V2.16.1 (2025-08)
IMEISV International Mobile station Equipment Identity and Software Version number
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IRI Intercept Related Information
ISO International Organization for Standardization
ITU-T International Telecommunication Union - Telecommunication
JSON JavaScript Object Notation
LAC Location Area Code
LDID Lawful Disclosure IDentifier
LEA Law Enforcement Agency
LIID Lawful Interception IDentifier
LTE Long-Term Evolution
MAC Media Access Control
MCC Mobile Country Code
MNC Mobile Network Code
NAI Network Access Identifier
NCGI NR Cell Global Identification
NCI NR Cell Identity
NR New Radio
PEI Permanent Equipment Identifier
RFC Request For Comments
SIP Session Initialization Protocol
SMF Session Management Function
SUCI Subscription Concealed Identifier
SUPI Subscription Permanent Identifier
TCP Transmission Control Protocol
UDP User Datagram Protocol
UPF User Plane Function
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTC Coordinated Universal Time
UUID Universally Unique IDentifier
VIN Vehicle Identification Number
VLAN Virtual Local Area Network
WGS84 World Geodetic System 1984
XML eXtended Markup Language
XSD XML Schema Definition
4 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.
ETSI
11 ETSI TS 103 280 V2.16.1 (2025-08)
5 Parameter requirements
5.0 Introduction
This clause describes the requirements a parameter should comply to in order to be specified as a common parameter.
5.1 Parameter attributes
Name
• The parameter should be assigned a unique name. The naming conventions used are described in clause 5.2.
Description
• A description of the parameter should be provided.
Usage guidance
• If there are circumstances in which additional usage guidance is applicable, use cases may be described in this
attribute.
References to other specifications
• If the parameter is specified in another specification (such as an RFC), a reference to that specification shall be
provided. If possible, the reference should point to the exact clause in the specification.
EXAMPLE: Specify one or more sample values of the parameter.
Technical means to define and validate the parameter
• If possible, provide a regular expression to specify the value that is accepted by this parameter.
Implementations may be required to perform additional validation on the value. The regular expression is
defined per clause 5.4. Define the parameter in the XSD [2] in clause 7.1. When converting a regular
expression to an XSD [2] pattern, escape any XML [29] markup characters in the regular expression per
XML [29], section 2.4 to create a valid XSD [2] pattern.
• Define the parameter in the ASN.1 [3] in clause 7.2.
• Define the parameter in the JSON Schema [35] in clause 7.3. Unless otherwise specified, the JSON definition
shall be a translation of the XSD definition, following the translation given in annex C.
5.2 Parameter naming conventions
Allowed characters
• The following character classes are allowed: A-Z, a-z and 0-9.
Camel casing
• The name of the parameter is to be CamelCased, where the first character is uppercased. Any acronyms should
be uppercased.
EXAMPLE:
- IPv4Address.
- SIPURI.
- EmailAddress.
ETSI
12 ETSI TS 103 280 V2.16.1 (2025-08)
5.3 Technology conventions
The used technologies defined in clause 7 may impose requirements that conflict with the requirements in clauses 5.1
and 5.2. In the case of a conflict and in exceptional cases, it is allowed to deviate from the requirements above.
5.4 Regular expression conventions
Regular expressions used for validation shall be limited to the regular expression capabilities supported by both
XSD [2] patterns and ECMAScript regular expressions (see ECMA-262 [36], section 22.2.1, as used by JSON
Schema [35] patterns).
Given the high disparity of regular expression implementations, the regular expressions should be limited to the
following features (inspired by JSON Schema [35], section 6.4):
1) Individual Unicode characters. Unicode characters for XSD [2] need to be encoded using an appropriate
XML [29] entity.
2) Character classes: "[abc]" (simple character classes), and "[a-z]" (range character classes).
3) Negated character classes: "[^abc]" (negated simple character classes), and "[^a-z]" (negated range
character classes).
4) Simple quantifiers: "*" (zero or more occurrences), "+" (one or more occurrence), and "?" (zero or one
occurrence).
5) Range quantifiers: "{n}" (exactly n occurrences), "{n,m}" (between n and m occurrences), and "{n,}" (at
least n occurrences).
6) Grouping and alternation: "(" and ")" (simple grouping), and "|" (alternation).
7) Simple atoms: "." (any character except new line and line feed).
As XSD [2] patterns are matched to the entire value, regular expressions shall not start with the anchor "^" or end with
the anchor "$". When regular expressions are mapped to a JSON Schema [35] pattern per table C.2, the anchors are
required.
ETSI
13 ETSI TS 103 280 V2.16.1 (2025-08)
6 Parameter dictionary
6.1 LIID
Name LIID
Description
For each target identity related to an interception measure, the authorized CSP operator shall
assign a special Lawful Interception IDentifier (LIID), which has been agreed between the LEA
and the CSP. It is used within parameters of all HI interface ports.

Using an indirect identification, pointing to a target identity makes it easier to keep the
knowledge about a specific interception target limited within the authorized CSP operators and
the handling agents at the LEA.

The Lawful Interception IDentifier LIID is a component of the CC delivery procedure and of the
IRI records. It shall be used within any information exchanged at the Handover Interfaces HI2
and HI3 for identification and correlation purposes.

The LIID format shall consist of alphanumeric characters. It might for example, among other
information, contain a lawful authorization reference number, and the date, when the lawful
authorization was issued.
The authorized CSP shall either enter a unique LIID for each target identity of the interception
subject or as a national option a single LIID for multiple target identities all pertaining to the
same interception subject.
EXAMPLE: The interception subject has a telephony service with three telephone numbers.
The CSP enters for each telephone number an own LIID, or optionally enters one
LIID for all three telephone numbers.

If more than one LEA intercepts the same target identity, there shall be unique LIIDs assigned,
relating to each LEA.
Usage guidance The LIID is defined as an OCTET STRING in ASN.1. This means it is possible to use binary
octets or ASCII printable characters to express the LIID. To correctly handle this, the parameter
accepts both variations.
References ETSI TS 102 232-1 [1], clause 5.2.2.
Example ZZZ123 (ASCII printable LIID)
46565527098f6bcd4621d373cade4e832627b4f6ff00ff00ff (Binary LIID,
represented in HEX)
([!-~]{1,25})|([0-9a-f]{26,50})
Regular expression
XSD
LIID, simpleType
ASN.1 LIID, OCTET STRING (SIZE(1.25))

6.2 UTCDateTime
Name UTCDateTime
Description
A UTC timestamp with second precision
Usage guidance -
References W3C XML Schema Definition Language [2], section 3.3.7
2015-12-27T13:37:00Z
Example
[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z
Regular expression
XSD UTCDateTime, simpleType
ASN.1
Not defined
ETSI
14 ETSI TS 103 280 V2.16.1 (2025-08)
6.3 UTCMicrosecondDateTime
Name
UTCMicrosecondDateTime
Description A UTC timestamp with microsecond precision
Usage guidance -
References W3C XML Schema Definition Language [2], section 3.3.7
2015-12-27T13:37:00.012345Z
Example
[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{6}Z
Regular expression
XSD
UTCMicrosecondDateTime, simpleType
ASN.1
Not defined
6.4 QualifiedDateTime
Name QualifiedDateTime
Description
A timestamp with second precision and timezone qualifier
Usage guidance
-
References W3C XML Schema Definition Language 1.1 Part 2: Datatypes [2], section 3.3.7
Example XML 2015-12-27T13:37:00+02:00
20151227133700+0200
Example ASN.1
[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|[+-]
Regular expression
[0-9]{2}:[0-9]{2})
XSD QualifiedDateTime, simpleType
ASN.1
QualifiedDateTime, GeneralizedTime
Timestamps shall be provided with a timezone qualifier. The fractional part of a second shall not
be present. Local time format shall not be used

6.5 QualifiedMicrosecondDateTime
Name
QualifiedMicrosecondDateTime
Description A timestamp with microsecond precision and timezone qualifier
Usage guidance -
References W3C XML Schema Definition Language 1.1 Part 2: Datatypes [2], section 3.3.7
2015-12-27T13:37:00.012345+02:00
Example XML
20151227133700.012345+0200
Example ASN.1
Regular expression [0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{6}(Z|
[+-][0-9]{2}:[0-9]{2})
XSD
QualifiedMicrosecondDateTime, simpleType
ASN.1
QualifiedMicrosecondDateTime, GeneralizedTime
Timestamps shall be provided with a timezone qualifier. The fractional part of a second with no
more than 6 digits shall be present. Local time format shall not be used

6.6 InternationalE164
Name InternationalE164
Description E.164 Number in fully international format, written as decimal digits
Usage guidance -
References Recommendation ITU-T E.164 [4], clause 6
Example
Regular expression [0-9]{1,15}
XSD InternationalE164, simpleType
ASN.1 NumericString (SIZE(1.15))

ETSI
15 ETSI TS 103 280 V2.16.1 (2025-08)
6.7 IMSI
Name
IMSI
Description International Mobile Subscriber Identity, written as decimal digits
Usage guidance -
References Recommendation ITU-T E.212 [5], clause 6.1
3GPP TS 23.003 [6], clauses 2.2 and 2.3
Example 999999123456789
Regular expression [0-9]{6,15}
XSD IMSI, simpleType
ASN.1 NumericString (SIZE(6.15))

6.8 IMEI
Name IMEI
Description International Mobile station Equipment Identity, written as decimal digits without the Luhn check
digit, annex B of ISO/IEC 7812-1 [20]
Usage guidance To avoid implementation issues, the IMEI parameter explicitly excludes the Luhn check digit,
annex B of ISO/IEC 7812-1 [20]
(See notes 1 and 2)
References 3GPP TS 23.003 [6], clause 6
Example 00997123456789
Regular expression [0-9]{14}
XSD IMEI, simpleType
ASN.1 NumericString (SIZE(14))
NOTE 1: ETSI TS 102 657 [7], clause E.3 identifies potential issues with the inclusion/exclusion of the check digit. As
such, the IMEI parameter is explicitly specified without the check digit.
NOTE 2: The IMEICheckDigit parameter can be used when the check digit is explicitly required.

6.9 IMEICheckDigit
Name IMEICheckDigit
Description International Mobile station Equipment Identity, written as decimal digits with the Luhn check
digit, annex B of ISO/IEC 7812-1 [20]
Usage guidance -
References 3GPP TS 23.003 [6], clause 6
Example
Regular expression [0-9]{15}
XSD IMEICheckDigit, simpleType
ASN.1 NumericString (SIZE(15))

6.10 IMEISV
Name
IMEISV
Description International Mobile station Equipment Identity and Software Version Number as defined in
3GPP TS 23.003 [6], clause 6.2.2, written as decimal digits including a software version number
instead of a Luhn check digit
Usage guidance -
References
3GPP TS 23.003 [6], clause 6.2.2
Example 0099712345678999
Regular expression [0-9]{16}
XSD IMEISV, simpleType
ASN.1 NumericString (SIZE(16))

ETSI
16 ETSI TS 103 280 V2.16.1 (2025-08)
6.11 IPv4Address
Name
IPv4Address
Description IPv4 address, written in dotted decimal notation
Usage guidance -
References IETF RFC 791 [8]
192.0.2.1
Example
((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4]
Regular expression
[0-9]|[01]?[0-9]?[0-9])
XSD IPv4Address, simpleType
ASN.1
Not defined
6.12 IPv4CIDR
Name IPv4CIDR
Description IPv4 CIDR, written in dotted decimal notation followed by CIDR notation
Usage guidance
-
References IETF RFC 791 [8] and IETF RFC 4632 [9]
Example 192.0.2.0/24
((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4]
Regular expression
[0-9]|[01]?[0-9]?[0-9])/([1-2]?[0-9]|3[0-2])
XSD IPv4CIDR, simpleType
ASN.1 Not defined
6.13 IPv6Address
Name IPv6Address
Descr
...