ETSI TS 132 421 V15.3.0 (2020-01)

TECHNICAL SPECIFICATION
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Telecommunication management;
Subscriber and equipment trace;
Trace concepts and requirements
(3GPP TS 32.421 version 15.3.0 Release 15)

3GPP TS 32.421 version 15.3.0 Release 15 1 ETSI TS 132 421 V15.3.0 (2020-01)

Reference
RTS/TSGS-0532421vf30
Keywords
GSM,LTE,UMTS
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 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

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
3GPP TS 32.421 version 15.3.0 Release 15 2 ETSI TS 132 421 V15.3.0 (2020-01)
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.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
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
3GPP TS 32.421 version 15.3.0 Release 15 3 ETSI TS 132 421 V15.3.0 (2020-01)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
Introduction . 6
1 Scope . 7
2 References . 8
3 Definitions, symbols and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 11
4 Trace concepts and high-level architecture . 12
4.1 Trace concepts . 12
4.2 Trace high level Architecture . 13
4.3 Service Level Tracing for IMS high level Architecture . 15
5 Trace requirements . 17
5.1 General trace requirements . 17
5.2 Requirements for Trace data . 18
5.3 Requirements for Trace activation . 19
5.3.1 Requirements for Trace Session activation . 19
5.3.2 Requirements for starting a Trace Recording Session . 22
5.4 Requirements for Trace deactivation . 24
5.4.1 Requirements for Trace Session deactivation . 24
5.4.2 Requirements for stopping a Trace Recording Session . 24
5.5 Requirements for Trace Data reporting . 26
5.6 Requirements for Privacy and Security . 28
5.7 Requirements for Charging . 28
5.8 Use cases for Trace. 29
6 Requirements for managing MDT . 30
6.1 Business Level Requirements. 30
6.2 Specification level requirements . 31
6.2.1 Logged MDT and Immediate MDT requirements . 31
6.2.2 Logged MBSFN MDT requirements . 32
7 Requirements for managing RLF and RCEF reports . 34
7.1 Business level requirements . 34
7.2 Specification level requirements . 34
Annex A (informative): Trace use cases . 35
A.1 Use case #1: multi-vendor UE validation . 35
A.1.1 Description . 35
A.1.2 Example of required data for this use case . 35
A.2 Use case #2: subscriber complaint . 35
A.2.1 Description . 35
A.2.2 Example of required data for this use case . 36
A.3 Use case #3: malfunctioning UE . 37
A.3.1 Description . 37
A.3.2 Example of required data for this use case . 37
A.4 Use case #4: checking radio coverage . 37
A.4.1 Description . 37
A.4.2 Example of required data to cover use case #4 . 37
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 4 ETSI TS 132 421 V15.3.0 (2020-01)
A.5 Use case #5: testing a new feature . 38
A.5.1 Description . 38
A.5.2 Example of required data to cover use case #5 . 38
A.6 Use case #6: fine-tuning and optimisation of algorithms/procedures . 39
A.6.1 Description . 39
A.6.2 Example of required data to cover use case #6 . 40
A.7 Use case #7: Automated testing of Service Provider services . 40
A.7.1 Description . 40
A.8 Use case #8: Regression testing following a network fix . 40
A.8.1 Description . 40
A.9 Use case #9: Service fault localization within a Service Provider network . 40
A.9.1 Description . 40
A.10 Use case #10: Service fault localization when a service is hosted by a third party Service Provider . 40
A.10.1 Description . 40
A.11 Use case #11 Analysing drop calls in E-UTRAN . 41
A.11.1 Description . 41
A.11.2 Example of required data to cover use case #11 . 41
A.12 Use case #12 Periodical sampling of network performance . 41
A.12.1 Description . 41
A.12.2 Example of required data to cover use case #12 . 41
A.13 Use case #13 Differentiation of area based MDT data by terminal type. 42
A.13.1 Description . 42
A.13.2 Example of required data to cover use case #13 . 42
A.14 Use case #14 Subscriber complaint about MBMS service in the eUTRAN network . 42
A.14.1 Description . 42
A.14.2 Example of required data to cover use case #14 . 42
A.15 Use case #15 Check MBMS service quality and performance of the eUTRAN Network . 43
A.15.1 Description . 43
A.15.2 Example of required data to cover use case #15 . 43
Annex B (informative): Change history . 44
History . 47

ETSI
3GPP TS 32.421 version 15.3.0 Release 15 5 ETSI TS 132 421 V15.3.0 (2020-01)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 6 ETSI TS 132 421 V15.3.0 (2020-01)
Introduction
The present document is part of a TS-family covering the 3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Telecommunication management, as identified below:
TS 32.421: "Subscriber and equipment trace: Trace concepts and requirements";
TS 32.422: "Subscriber and equipment trace: Trace control and configuration management";
TS 32.423: "Subscriber and equipment trace: Trace data definition and management";
Subscriber and equipment trace provide very detailed information at call level on one or more specific mobile(s).
This data is an additional source of information to Performance Measurements and allows going further in monitoring
and optimisation operations.
Contrary to Performance measurements, which are a permanent source of information, trace is activated on user
demand for a limited period of time for specific analysis purposes.
Trace plays a major role in activities such as determination of the root cause of a malfunctioning mobile, advanced
troubleshooting, optimisation of resource usage and quality, RF coverage control and capacity improvement, dropped
call analysis, Core Network and Access Network end-to-end procedure validation.
The capability to log data on any interface at call level for a specific user (e.g. IMSI) or mobile type (e.g. IMEI or
IMEISV), or service initiated by a user allows getting information which cannot be deduced from Performance
measurements such as perception of end-user QoS during his call (e.g. requested QoS vs. provided QoS), correlation
between protocol messages and RF measurements, or interoperability with specific mobile vendors.
Moreover, performance measurements provide values aggregated on an observation period; Subscriber and UE Trace
give instantaneous values for a specific event (e.g. call, location update, etc.).
If performance measurements are mandatory for daily operations, future network planning and primary trouble
shooting; Subscriber and UE Trace is the easy way to go deeper into investigation and network optimisation.
In order to produce this data, Subscriber and UE Trace are carried out in the NEs, which comprise the network. The
data can then be transferred to an external system (e.g. an Operations System (OS) in TMN terminology, for further
evaluation).
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 7 ETSI TS 132 421 V15.3.0 (2020-01)
1 Scope
The present document describes the requirements for the management of Trace and the reporting of Trace data
(including FDD mode and TDD mode) across UMTS, EPS or 5G networks as it refers to subscriber tracing (tracing of
IMSI or Public User Identity) and equipment tracing (tracing of IMEI or IMEISV). Trace also includes the ability to
trace all active calls in a cell or multiple cells (Cell Traffic Trace). The present document also includes the description
of Service Level Tracing (tracing of a specific service). It defines the administration of Trace Session
activation/deactivation by the management system, the network or User Equipment (UE) itself via signalling, the
generation of Trace results in the Network Elements (NEs) and UE and the transfer of these results to one or more
Operations Systems.
GSM Trace is outside of the scope of this specification (see [7]).
The present document also describes the requirements for the management of Minimization of Drive Tests (MDT) across
UMTS networks, EPS networks or 5G networks and Radio Link Failure (RLF) reporting across EPS networks and 5G
networks.
The present document is built upon the basic Subscriber and UE Trace concept described in clause 4.
The high-level requirements for Trace data, Trace Session activation/deactivation and Trace reporting are defined in
clause 5. Clause 5 also contains an overview of use cases for Trace (the use cases are described in Annex A). Clause 6
defines the requirements for managing MDT. Clause 7 defines the requirements for managing RLF reports.Trace
control and configuration management are described in 3GPP TS 32.422 [2], and Trace data definition and management
are described in 3GPP TS 32.423 [3].
The present document does not cover any Trace capability limitations within a NE (e.g. maximum number of
simultaneous traced mobiles for a given NE) or any functionality related to these limitations (e.g. NE aborting a Trace
Session due to resource limitations).
The objectives of the Trace specifications are:
a) to provide the descriptions for a standard set of Trace and MDT data;
b) to produce a common description of the management technique for Trace, MDT and RLF administration and
result reporting;
c) to define a method for the reporting of Trace, MDT and RLF results across the management interfaces.
The following is beyond the scope of the present document, and therefore the present document does not describe:
- tracing non-Subscriber or non-UE related events within an NE;
- tracing of all possible parties in a multi-party call (although multiple calls related to the IMSI specified in the
Trace control and configuration parameters are traceable).
The definition of Trace and MDT data is intended to result in comparability of Trace and MDT data produced in a
multi-vendor wireless UMTS, EPS and/or 5G network(s), for those Trace control and configuration parameters that can
be standardised across all vendors' implementations.
Vendor specific extensions to the Trace control and configuration parameters and Trace and MDT data are discussed in
3GPP TS 32.422 [2] and 3GPP TS 32.423 [3].
All functions (trace, MDT etc.) specified in this specification support Network Sharing, with the following conditions:
- It is accepted that the recorded information from the shared nodes is available to the Master Operator. Recorded
information that is collected in a non shared node or cell will only be available to the operator managing the non
shared node or cell.
- It is accepted that the recorded information from the shared network shall be delivered to the Participating
Operator whose PLMN recording is requested, taking user consent into account. Operators must also agree on
sharing the information, but how that agreement is done is outside the scope of this specification. The mapping
of TCE IP addresses and TCE addresses must be coordinated among the operators that shares the network. How
that coordination is done is outside the scope of this specification.
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 8 ETSI TS 132 421 V15.3.0 (2020-01)
- It is accepted that the inter-PLMN recorded information for Logged MDT from the non-shared nodes
of Participating Operators may be available to the Master Operator.
- For signalling based activation, the operators that share a network must coordinate the TCE IP addresses and the
TCE address mapping must be coordinated. How that coordination´ is done is outside the scope of this
specification.
- The 3GPP Managment reference model, 3GPP TS 32.101 [1] is followed.

2 References
The following documents contain provisions, which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements".
[2] 3GPP TS 32.422: "Telecommunication management; Subscriber and equipment trace: Trace
control and configuration management".
[3] 3GPP TS 32.423: "Telecommunication management; Subscriber and equipment trace: Trace data
definition and management".
[4] 3GPP TS 23.002: "Network architecture".
[6] 3GPP TS 29.207: "Policy control over Go interface".
[7] 3GPP TS 52.008: "Telecommunication management; GSM subscriber and equipment trace".
[8] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[9] OMA Service Provider Environment Requirements, OMA-RD-OSPE-V1_0-20050614-C, The
Open Mobile Alliance™ (URL:http://www.openmobilealliance.org/).
[10] 3GPP TS 33.401: "System Architecture Evolution (SAE); Security architecture".
[11] 3GPP TS 37.320 : "Universal Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial
Radio Access (E-UTRA); Radio measurement collection for Minimization of Drive Tests (MDT);
Overall description, Stage 2".
[12] 3GPP TS 32.450: "Key Performance Indicators (KPI) for Evolved Universal Terrestrial Radio
Access Network (E-UTRAN): Definitions".
[13] 3GPP TS 32.130: "Network sharing; Concepts and requirements".
[14] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[15] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[16] 3GPP TS 38.300: "NR and NG-RAN Overall Description; Stage 2".
[17] 3GPP TS 38.401: "NG-RAN; Architecture Description".
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 9 ETSI TS 132 421 V15.3.0 (2020-01)
[18] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource
Control (RRC); Protocol Specification".
[19] 3GPP TS 25.331: "Radio Resource Control (RRC); protocol specification".
NOTE: Overall management principles are defined in 3GPP TS 32.101 [1].
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 21.905 [8] , 32.130 [13], 23.501 [15],
38.300 [16] and the following apply:
Cell Traffic Trace: The ability to trace one or more active calls in one or more cells.
Collection Period: Period that indicates the measurement results collection interval.
NOTE: The measurement results can refer to the MeasResults IE defined in clause 6.3.5, 3GPP TS 36.331 [18]
for LTE or MeasuredResults IE defined in clause 11.3, 3GPP TS 25.331[19] for UMTS.
End user visible events: Refer to OMA Service Provider Requirements [9].
Immediate MDT: See 3GPP TS 37.320 [11].
Logged MDT: See 3GPP TS 37.320 [11].
management activation/deactivation: Trace Session is activated/deactivated in different NEs directly from the EM
using the management interfaces of those NEs.
MDT Measurements: See 3GPP TS 37.320 [11].
MBSFN Area: See 3GPP TS 36.300 [14].
MBSFN Area Reserved Cell: See 3GPP TS 36.300 [14].
Signalling Based Activation/Deactivation: Trace Session is activated/deactivated in different NEs using the signalling
interfaces between those elements so that the NEs may forward the activation/deactivation originating from the EM
System Context: two different realisations of the telecommunication management architecture. System Context A has
the Itf-N between a Network Manager and an Element Manger. System Context B has the Itf-N between a Network
Manager and a Network Element that has an embedded Element Manager. See figure 1 in TS 32.101 [1].
Measurement Period: Period that indicates the performance measurement reporting interval.
Trace: general term used for Subscriber, Equipment and Service Trace.
Trace record: in the NE a Trace record is a set of Traceable data collected as determined by the Trace control and
configuration parameters.
Trace Recording Session: time interval within a Trace Session while trace records are generated for the Subscriber,
UE or Service being traced. The triggering events starting and stopping a Trace Recording Session are defined in 3GPP
TS 32.422 [2] (see figure 1).
Trace Recording Session Reference: identifies a Trace Recording Session within a Trace Session (see figure 1)
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 10 ETSI TS 132 421 V15.3.0 (2020-01)
Trace
Trace
Recording
Recording
Session
Session
Reference
Reference
#2
#1
Call/Session #2
Call/Session #1
Time
Start Stop Start Stop
trigger trigger trigger trigger
event event event event
Trace Session
Figure 1: Trace Recording Session
Note that overlapping calls/sessions are possible for e.g. Cell Traffic Trace.
Trace Reference: identifies a Trace Session and is globally unique (see figure 2)
Trace Session: time interval started with a Trace Session Activation and lasts until the Deactivation of that specific
Trace Session (see figure 2)
Activation Deactivation
- IMSI or IMEI(SV) or Public ID - Trace Reference
- Trace Reference
- Trace control and configuration
parameters
Time
Trace Session
Figure 2: Trace Session
Trace Parameter Configuration: a technique whereby a request for tracing a certain Subscriber, UE or Service is sent
by the EM to the NE for execution.
Trace Parameter Propagation: a technique by which the NE processes the trace configuration (received from the EM
or another NE) and sends it to the relevant Network Element(s) via signalling interface(s).
Service Level Tracing: Refer to OMA Service Provider Requirements [9].
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 11 ETSI TS 132 421 V15.3.0 (2020-01)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 21.905 [8], 32.101 [1] , 32.130 [13] , 23.501 [15],
38.300 [16] and the following apply:
MBSFN MBMS over a Single Frequency Network
MBMS Multimedia Broadcast Multicast Services
MDT Minimization of Drive Tests
RCEF RRC Connection Establishment Failure
RLF Radio Link FailureTCE Trace Collection Entity
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 12 ETSI TS 132 421 V15.3.0 (2020-01)
4 Trace concepts and high-level architecture
4.1 Trace concepts
The diversity of Trace requirements makes it difficult to identify and anticipate all the operator's specific needs. Thus,
the objective of this TS is not to list an exhaustive set of information to meet all the requirements. Rather, Trace data is
defined without any limitation on the 2 following dimensions:
- Trace scope: NEs and signalling interfaces to Trace.
- Trace depth: level of details of Trace data.
In order not to have any limitation of Trace data, there are six levels of details defined: Maximum, Minimum, Medium,
MaximumWithoutVendorSpecificExtension, MinimumWithoutVendorSpecificExtension and
MediumWithoutVendorSpecificExtension. The first three levels allow for vendor specific information to be traced and
sent in the trace report file.
The Maximum (or MaximumWithoutVendorSpecificExtension) Levels allow all Trace data to be recorded. The other
Levels provide a decoded subset of the data in the Maximum Level and allow an operator the flexibility in selecting the
appropriate Trace data to record.
The Trace Depth, specified at the Trace Session activation, is used to choose the level of detail of information to be
retrieved.
The Maximum (or MaximumWithoutVendorSpecificExtension) Levels of detail allow for retrieval of signalling
interface messages within the Trace Scope in encoded format (see figure 4.1.1).

TTrraceace scope scope
Encoded Encoded
MaxMaxiimmuumm
levleveel ofl of de details:tails:
mmeessassaggeess
AAlll ml meessssaaggeess ar are pe prroovvidideded in in
theirtheir e enncoded coded forformmat.at.
DecodeDecodedd
IEsIEs
TrTracace dee depthpth
SSppececifificic s seet ot off  IEIEss ffrroomm e ennccodeoded d
mmeessssaaggeess c caann be be de decodcodeed d byby a ann
exexteterrnnalal sy systestemm.

Figure 4.1.1: Maximum (or MaximumWithoutVendorSpecificExtension) Levels of details of Trace
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 13 ETSI TS 132 421 V15.3.0 (2020-01)
The Minimum (or MinimumWithoutVendorSpecificExtension) Levels of detail allow for retrieval of a decoded subset
of the IEs contained in the signalling interface messages (see figure 4.1.2).

TTrrace scopeace scope
Encoded Encoded
mmeessagssageess
DecodedDecoded
IEIEss
MinimumMinimum levleveel of l of
details: details:
A subset of decodedA subset of decoded IEIEss
is provis provided to covided to cover the er the
mmoost usual use cases.st usual use cases.
Trace deptTrace depthh
Figure 4.1.2: Minimum (or MinimumWithoutVendorSpecificExtension) Levels of detail of Trace
The Medium (or MediumWithoutVendorSpecificExtension) Levels of detail allow for retrieval of the decoded subset of
the IEs contained in the signalling interface messages in the Minimum Level plus a selected set of decoded radio
measurement IEs.
The Trace data recorded at each Level is defined in 3GPP TS 32.423 [3].
4.2 Trace high level Architecture
There are two types of activation, management based activation and signalling based activation.
Figure 4.2.1 represents the high-level view of the architecture of Trace Management Based Activation/Deactivation.
Figure 4.2.1 is only showing the interfaces in principle a high-level view. Details of Trace activation/deactivation are
defined in 3GPP TS 32.422 [2].

Figure 4.2.1: Architecture for Management Based Activation/Deactivation
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 14 ETSI TS 132 421 V15.3.0 (2020-01)
Figure 4.2.2 represents the high-level view of the architecture of Signalling Based Activation/Deactivation (non-shared
scenario). Figure 4.2.2 is only showing the interfaces in principle. Details of Trace activation/deactivation are defined in
3GPP TS 32.422 [2].
Figure 4.2.2: Architecture for Signalling Based Activation/Deactivation
Figure 4.2.3 represents the high-level view of the architecture of Trace Reporting (non-shared scenario). Figure 4.2.3 is
only showing the interfaces in principle.

Figure 4.2.3: Architecture for High-level view of Trace Reporting in System Context A

NOTE: The placement of the Trace Collection Entity is a deployment matter for the operator. If it is placed
outside the operator's secure zone, it is up to the operator to use secure connections to and from the Trace
Collection Entity.
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 15 ETSI TS 132 421 V15.3.0 (2020-01)
4.3 Service Level Tracing for IMS high level Architecture
There are two ways in which to activate service level trace for IMS:
a) Trace activation at the UE, and
b) Trace activation at an IMS NE.
Figure 4.3.1 represents the high-level view of the architecture of Signalling Based Activation/Deactivation at the UE
required to support Service Level Tracing for IMS. Figure 4.3.1 is only showing the interfaces in principle. Details of
Service Level Trace Activation/Deactivation are defined in 3GPP TS 32.422 [2].

Figure 4.3.1: Architecture for Signalling Based Activation/Deactivation required for Service Level
Tracing for IMS at the UE
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 16 ETSI TS 132 421 V15.3.0 (2020-01)
Figure 4.3.2 represents the high-level view of the architecture of Signalling Based Activation/Deactivation at an IMS
NE required to support Service Level Tracing for IMS. Figure 4.3.2 is only showing the interfaces in principle. Details
of Service Level Trace Activation/Deactivation are defined in 3GPP TS 32.422 [2].

Figure 4.3.2 : Architecture for Signalling Based Activation/Deactivation required for
Service Level Tracing for IMS at the IMS NE
Figure 4.3.3 represents the high-level view of the architecture of Trace Reporting for System Context A.
Figure 4.3.3 illustrates the reporting context for Service Level Tracing for IMS from the UE and is only showing the
interfaces in principle. The reporting context for Service Level Tracing for IMS from the IMS NE is illustrated in
Figure 4.2.3: Architecture for High-level view of Trace Reporting in System Context A

Figure 4.3.3: Architecture for Trace Reporting from UE to support Service Level Tracing for IMS
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 17 ETSI TS 132 421 V15.3.0 (2020-01)
5 Trace requirements
5.1 General trace requirements
The general high-level requirements for Trace, common to both Management activation/deactivation and Signalling
Based Activation/Deactivation, are as follows:
- for the Maximum Level: Trace data encompassing all signalling messages on the different interfaces dedicated to
the events of the traced subscriber or UE with their entire content (all IEs) shall be retrieved. The operator can
then use an external system (e.g. an Operations System (OS) in TMN terminology) and decode specific
information in line with operator requirements.
- for the Minimum Level: a selected subset of IEs shall be retrieved from the signalling interface messages. The
Minimum Level provides support for the most common use cases (described in annex A).
- for the Medium Level: a selected Minimum Level subset of IEs from the signalling interface messages and a
selected set of radio measurement IEs shall be retrieved.
- for the MaximumWithoutVendorSpecificExtension Level: it is the same as for Maximum level without vendor
specific data.
- for the MediumWithoutVendorSpecificExtension Level: it is the same as for Medium level without vendor
specific data.
- for the MinimumWithoutVendorSpecificExtension Level: it is the same as for Minimum level without vendor
specific data.
The high-level requirements for Trace, specific for Service Level Tracing for IMS are as follows:
The following high-level OMA Service Level Tracing requirements apply. (refer to OMA Service Provider
Environment Requirements [9]).
NOTE: Each referenced OMA requirement utilizes its OMA unique identifier within square brackets.
Clarification provided to each requirement should be considered applicable to other OMA requirements
using the same concepts.
- [SLT-HL-1] with the following clarification:
- The OMA term OMA Service Provider Environment (OSPE) shall be understood as PLMN.
- [SLT-HL-5] with the following clarification:
- In the context of Service Level Tracing for IMS a Minimum and Maximum level of detail of trace only
applies. Trace data for Service Level Tracing at Minimum and Maximum level of detail shall include
information associated to end user visible events
- [SLT-HL-6] with the following clarification:
- The OMA term service chain shall be understood as the relationship between appropriate IMS elements
needed to support a service. The term service chain does not imply a strict sequence of events.
- The source of the logged trace information (e.g. IMS element including S-CSCF) shall be identifiable
when the retrieved trace information is analyzed.
- [SLT-HL-10] with the following clarification:
- IMS elements that do not support Service Level Tracing shall not prohibit the propagation of the Trace
Parameter Propagation.
- [SLT-OSR-1
- Multiple Service Level Trace instances shall be simultaneously supported by the PLMN and the UE (e.g.
several services initiated from the same UE may each have a Trace Recording Session Reference)
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 18 ETSI TS 132 421 V15.3.0 (2020-01)
5.2 Requirements for Trace data
The high level requirements for Trace data, common to both Management activation/deactivation and Signalling Based
Activation/Deactivation, are as follows:
- The Trace records have to contain Information Elements or signalling messages from control signalling and/or the
characteristics of the user data. The following list contains the Network Elements and the Traceable interfaces in the
NEs where tracing is needed:
- MSC Server: A, Iu-CS, Mc and MAP (G, B, E, F, D, C) interfaces; CAP
- MGW: Mc, Nb-UP, Iu-UP
- HSS: MAP (C, D, Gc, Gr) Cx, S6a and S6d interfaces and location and subscription information
- EIR: MAP(F), S13, S13’, MAP (Gf)
- SGSN: Gb, Iu-PS, Gn, MAP (Gr, Gd, Gf), CAP (Ge) Gs, S6d, S4, S3 and S13' interfaces
- GGSN: Gn, Gi and Gmb interfaces
- S-CSCF: Mw, Mg, Mr and Mi interfaces
- P-CSCF: Gm and Go interfaces
- RNC: Iu-CS, Iu-PS, Iur, Iub and Uu interfaces
- BM-SC: Gmb interface
- eNB/en-gNB: S1-MME, X2, Uu, F1-C, E1
- MME: S1-MME, S3, S6a, S10, S11, S13, N26
- Serving Gateway: S4, S5, S8, S11
- PDN Gateway: S2a, S2b, S2c, S5, S6b, Gx, S8, SGi
- AUSF: N12, N13
- AMF: N1, N2, N8, N11, N12, N14, N15, N20, N22, N26
- NEF: N29, N30, N33
- NRF: N27
- NSSF: N22, N31
- PCF: N5, N7, N15
- SMF: N4, N7, N10, N11, S5-C
- SMSF: N20, N21
- UDM: N8, N10, N13, N21
- UPF: N4
- AF: N5, N33
ng-eNB: NG-C, Xn-C, Uu
- gNB-CU-CP: NG-C, Xn-C, Uu, F1-C, E1, X2-C
- gNB-CU-UP: E1
- gNB-DU: F1-C
ETSI
3GPP TS 32.421 version 15.3.0 Release 15 19 ETSI TS 132 421 V15.3.0 (2020-01)
- A unique ID within a Trace Session shall be generated for each Trace Recording Session. This is called the Trace
Recording Session Reference.
The high level requirements for Trace data applicable for Signalling Based Activation/Deactivation for Service Level
Tracing for IMS, are as follows:
- In the context of Service Level Tracing for IMS Trace records have to contain Information Elements or signalling
messages or end user visible event from control signalling and/or the characteristics of the user data. The following list
contains the IMS NEs and the Traceable interfaces in the NEs where tracing is needed:
- HSS: Sh and Cx interfaces and location and subscription information;
- S-CSCF: ISC, Mw, Mg, Mr and Mi interfaces;
- P-CSCF: Gm and Go interfaces;
- I-CSCF: Mw and Cx interfaces;
- SIP AS: ISC interface;
- MRF: Mr interfaces;
- MGCF: Mg interfaces;
- BGCF: Mi interfaces;
- A unique ID within a Trace Session shall be generated for each Trace Recording Session. This is called the
Trace Recordin
...