ࡱ > / o p ~ f g N o d
n p E
] o q r + R j M o o bjbj zfzfq - - M. M. M. D . . . / < M1 L . P 6 -@ p @ @ @ C . H] ,e ( $ B M. k B @ C k k - - @ @ ' k - 8 @ M. @ ( k ( 5. @ PL]@Q q H ` P ( w 8 M. 0 i i r 2j \ j J i i i 6 i i i P k k k k i i i i i i i i i
, :
3GPP TS 32.422 V8.910.0 (20132020-0607)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
Telecommunication management;
Subscriber and equipment trace;
Trace control and configuration management
(Release 8)
EMBED Word.Picture.8
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Keywords
UMTS, management
3GPP
Postal address
3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org
Copyright Notification
No part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.
20132020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
UMTS is a Trade Mark of ETSI registered for the benefit of its members
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational PartnersLTE is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM and the GSM logo are registered and owned by the GSM Association
Contents
TOC \o "1-9" Foreword PAGEREF _Toc44683171 \h 6
Introduction PAGEREF _Toc44683172 \h 6
1 Scope PAGEREF _Toc44683173 \h 7
2 References PAGEREF _Toc44683174 \h 7
3 Abbreviations PAGEREF _Toc44683175 \h 8
4 Trace activation and deactivation PAGEREF _Toc44683176 \h 8
4.1 Trace session activation / deactivation PAGEREF _Toc44683177 \h 8
4.1.1 Management activation PAGEREF _Toc44683178 \h 8
4.1.1.1 General PAGEREF _Toc44683179 \h 8
4.1.1.2 UTRAN activation mechanisms PAGEREF _Toc44683180 \h 9
4.1.1.3 PS Domain activation mechanisms PAGEREF _Toc44683181 \h 10
4.1.1.4 CS Domain activation mechanisms PAGEREF _Toc44683182 \h 10
4.1.1.5 IP Multimedia Subsystem activation mechanisms PAGEREF _Toc44683183 \h 11
4.1.1.6 E-UTRAN activation mechanisms PAGEREF _Toc44683184 \h 11
4.1.1.7 EPC Domain activation mechanisms PAGEREF _Toc44683185 \h 11
4.1.2 Signalling activation PAGEREF _Toc44683186 \h 11
4.1.2.1 General PAGEREF _Toc44683187 \h 11
4.1.2.2 Intra PLMN signalling activation PAGEREF _Toc44683188 \h 13
4.1.2.3 Inter PLMN Signalling Activation PAGEREF _Toc44683189 \h 14
4.1.2.4 UTRAN activation mechanisms PAGEREF _Toc44683190 \h 16
4.1.2.5 PS Domain activation mechanisms PAGEREF _Toc44683191 \h 16
4.1.2.6 CS Domain activation mechanisms PAGEREF _Toc44683192 \h 20
4.1.2.7 Void PAGEREF _Toc44683193 \h 21
4.1.2.8 Tracing roaming subscribers PAGEREF _Toc44683194 \h 21
4.1.2.9 Void PAGEREF _Toc44683195 \h 21
4.1.2.9.1 Void PAGEREF _Toc44683196 \h 21
4.1.2.9.2 Void PAGEREF _Toc44683197 \h 21
4.1.2.9.3 Void PAGEREF _Toc44683198 \h 21
4.1.2.9.4 Void PAGEREF _Toc44683199 \h 21
4.1.2.10 EPC activation mechanism PAGEREF _Toc44683200 \h 22
4.1.2.11 E-UTRAN activation mechanisms PAGEREF _Toc44683201 \h 26
4.1.3 Management deactivation PAGEREF _Toc44683202 \h 27
4.1.3.1 UTRAN deactivation mechanisms PAGEREF _Toc44683203 \h 27
4.1.3.2 PS Domain deactivation mechanisms PAGEREF _Toc44683204 \h 27
4.1.3.3 CS Domain deactivation mechanisms PAGEREF _Toc44683205 \h 27
4.1.3.4 IP Multimedia Subsystem deactivation mechanisms PAGEREF _Toc44683206 \h 27
4.1.3.5 E-UTRAN deactivation mechanisms PAGEREF _Toc44683207 \h 28
4.1.3.6 EPC Domain deactivation mechanisms PAGEREF _Toc44683208 \h 29
4.1.4 Signalling deactivation PAGEREF _Toc44683209 \h 30
4.1.4.1 General PAGEREF _Toc44683210 \h 30
4.1.4.2 UTRAN deactivation mechanisms PAGEREF _Toc44683211 \h 30
4.1.4.3 PS Domain deactivation mechanisms PAGEREF _Toc44683212 \h 33
4.1.4.4 CS Domain deactivation mechanisms PAGEREF _Toc44683213 \h 33
4.1.4.5 Void PAGEREF _Toc44683214 \h 34
4.1.4.6 Void PAGEREF _Toc44683215 \h 34
4.1.4.6.1 Void PAGEREF _Toc44683216 \h 34
4.1.4.6.2 Void PAGEREF _Toc44683217 \h 34
4.1.4.6.2.1 Void PAGEREF _Toc44683218 \h 34
4.1.4.6.2.2 Void PAGEREF _Toc44683219 \h 34
4.1.4.6.2.3 Void PAGEREF _Toc44683220 \h 34
4.1.4.6.3 Void PAGEREF _Toc44683221 \h 34
4.1.4.7 EPC deactivation mechanisms PAGEREF _Toc44683222 \h 34
4.1.4.8 E-UTRAN deactivation mechanisms PAGEREF _Toc44683223 \h 35
4.2 Trace recording session Start / Stop triggering PAGEREF _Toc44683224 \h 36
4.2.1 General PAGEREF _Toc44683225 \h 36
4.2.2 Starting a trace recording session - management based PAGEREF _Toc44683226 \h 36
4.2.2.1 UTRAN starting mechanisms PAGEREF _Toc44683227 \h 36
4.2.2.2 PS Domain starting mechanisms PAGEREF _Toc44683228 \h 36
4.2.2.3 CS Domain starting mechanisms PAGEREF _Toc44683229 \h 36
4.2.2.4 Void PAGEREF _Toc44683230 \h 37
4.2.2.5 E-UTRAN starting mechanism PAGEREF _Toc44683231 \h 37
4.2.2.6 EPC Domain starting mechanisms PAGEREF _Toc44683232 \h 39
4.2.3 Starting a trace recording session - signalling based PAGEREF _Toc44683233 \h 40
4.2.3.1 UTRAN starting mechanisms PAGEREF _Toc44683234 \h 40
4.2.3.2 PS Domain starting mechanisms PAGEREF _Toc44683235 \h 42
4.2.3.3 CS Domain starting mechanisms PAGEREF _Toc44683236 \h 43
4.2.3.4 Void PAGEREF _Toc44683237 \h 45
4.2.3.5 Void PAGEREF _Toc44683238 \h 45
4.2.3.5.1 Void PAGEREF _Toc44683239 \h 45
4.2.3.5.2 Void PAGEREF _Toc44683240 \h 45
4.2.3.5.3 Void PAGEREF _Toc44683241 \h 45
4.2.3.5.4 Void PAGEREF _Toc44683242 \h 45
4.2.3.6 E-UTRAN starting mechanism PAGEREF _Toc44683243 \h 45
4.2.3.7 EPC starting mechanisms PAGEREF _Toc44683244 \h 45
4.2.4 Stopping a trace recording session - management based PAGEREF _Toc44683245 \h 47
4.2.4.1 UTRAN stopping mechanisms PAGEREF _Toc44683246 \h 47
4.2.4.2 PS Domain stopping mechanisms PAGEREF _Toc44683247 \h 47
4.2.4.3 CS Domain stopping mechanisms PAGEREF _Toc44683248 \h 49
4.2.4.4 Void PAGEREF _Toc44683249 \h 49
4.2.4.5 E-UTRAN stopping mechanisms PAGEREF _Toc44683250 \h 49
4.2.4.6 EPC Domain stopping mechanisms PAGEREF _Toc44683251 \h 50
4.2.5 Stopping a trace recording session - signalling based PAGEREF _Toc44683252 \h 51
4.2.5.1 UTRAN stopping mechanisms PAGEREF _Toc44683253 \h 51
4.2.5.2 PS Domain stopping mechanisms PAGEREF _Toc44683254 \h 51
4.2.5.3 CS Domain stopping mechanisms PAGEREF _Toc44683255 \h 54
4.2.5.4 Void PAGEREF _Toc44683256 \h 55
4.2.5.5 Void PAGEREF _Toc44683257 \h 55
4.2.5.5.1 Void PAGEREF _Toc44683258 \h 55
4.2.5.5.2 Void PAGEREF _Toc44683259 \h 55
4.2.5.5.3 Void PAGEREF _Toc44683260 \h 55
4.2.5.6 Void PAGEREF _Toc44683261 \h 55
4.2.5.7 E-UTRAN stopping mechanisms PAGEREF _Toc44683262 \h 55
4.2.5.8 EPC Domain stopping mechanisms PAGEREF _Toc44683263 \h 55
5 Trace control and configuration parameters PAGEREF _Toc44683264 \h 56
5.1 Triggering events (M) PAGEREF _Toc44683265 \h 56
5.2 Void PAGEREF _Toc44683266 \h 61
5.3 Trace Depth (M) PAGEREF _Toc44683267 \h 61
5.4 List of NE types (M) PAGEREF _Toc44683268 \h 61
5.5 List of interfaces (O) PAGEREF _Toc44683269 \h 63
5.6 Trace Reference (M) PAGEREF _Toc44683270 \h 64
5.7 Trace Recording Session Reference (M) PAGEREF _Toc44683271 \h 65
5.8 Trace Collection Entity Address PAGEREF _Toc44683272 \h 65
5.9 IP Address of Trace Collection Entity (M) PAGEREF _Toc44683273 \h 65
Annex A (normative): Trace failure notification file format PAGEREF _Toc44683274 \h 66
A.1 Global structure PAGEREF _Toc44683275 \h 66
A.2 XML elements fileHeader and fileFooter PAGEREF _Toc44683276 \h 66
A.2.1 XML elements fileHeader PAGEREF _Toc44683277 \h 66
A.2.2 XML element fileFooter PAGEREF _Toc44683278 \h 66
A.3 Trace failure notification specific XML elements PAGEREF _Toc44683279 \h 66
A.4 Trace IRP XML File Name Conventions PAGEREF _Toc44683280 \h 66
A.5 Trace failure notification file XML schema PAGEREF _Toc44683281 \h 66
Annex B (informative): Change history PAGEREF _Toc44683282 \h 68
Foreword
This Technical Specification has been produced by the 3rd 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.
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";
Additionally, there is a GSM only Subscriber and Equipment Trace specification: 3GPP TS 52.008 [5].
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, UTRAN, EPC and E-UTRAN UMTS 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) 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 Equipment 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 Equipment Trace is the easy way to go deeper into investigation and network optimisation.
In order to produce this data, Subscriber and Equipment 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).
1 Scope
The present document describes the mechanisms used for the control and configuration of the Trace functionality at the EMs, NEs and UEs. It covers the triggering events for starting/stopping of subscriber/UE activity traced over 3GPP standardized signalling interfaces, the types of trace mechanisms, configuration of a trace, level of detail available in the trace data, the generation of Trace results in the Network Elements (NEs) and User Equipment (UE) and the transfer of these results to one or more EM(s) and/or Network Manager(s) (NM(s)).
The mechanisms for Trace activation/deactivation are detailed in clause 4; clause 5 details the various Trace control and configuration parameters and the triggering events that can be set in a network. Trace concepts and requirements are covered in 3GPPTS32.421 [2] while Trace data definition and management is covered in 3GPP TS 32.423 [3].
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 nonspecific.
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.
NOTE: Overall management principles are defined in 3GPP TS 32.101 [1].
[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements".
[2] 3GPP TS 32.421: "Telecommunication management; Subscriber and equipment trace: Trace concepts and requirements".
[3] 3GPP TS 32.423: "Telecommunication management; Subscriber and equipment trace: Trace data definition and management".
[4] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[5] 3GPP TS 52.008: "Telecommunication management; GSM subscriber and equipment trace".
[6] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description; Stage 2".
[7] 3GPP TS 23.205: "Bearer-independent circuit-switched core network; Stage 2".
[8] 3GPP TS 23.108: "Mobile radio interface layer 3 specification core network protocols; Stage 2 (structured procedures)".
[9] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description".
[10] 3GPP TS 29.232: "Media Gateway Controller (MGC) - Media Gateway (MGW); interface; Stage3".
[11] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[12] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface".
[13] 3GPP TS 25.413: "UTRAN Iu interface RANAP signalling".
[14] 3GPP TS 23.218: "IP Multimedia (IM) session handling; IM call model; Stage 2".
[15] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".
[16] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents".
[17] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message contents".
[18] Void.
[19] Void.
[20] Void.
[21] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".
[22] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".
[23] 3GPP TS 36.401: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture description".
[24] 3GPP TS 32.442: "Telecommunication management; Trace management; Integration Reference Point (IRP) Information Service (IS)".
[25] 3GPP TS 29.273: "Evolved Packet System (EPS);3GPP EPS AAA interfaces".
[26] 3GPP TS 29.272: "Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol".
[27] 3GPP TS 32.615: "Telecommunication management; Configuration Management (CM); Bulk CM Integration Reference Point (IRP): eXtensible Markup Language (XML) definitions".
[28] 3GPP TS 32.342: "Telecommunication management; File Transfer (FT) Integration Reference Point (IRP): Information Service (IS)".
[29] 3GPP TS 29.212: " Policy and Charging Control over Gx reference point".
3 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [4], 3GPP TS 32.101 [1] and the following apply:
AS Application Server
BGCF Breakout Gateway Control Function
CSCF Call Session Control Function
I-CSCF Interrogating-CSCF
IM CN SS IP Multimedia Core Network Subsystem
MRFC Multimedia Resource Function Controller
P-CSCF Proxy - CSCF
S-CSCF Serving-CSCF
TAU Tracking Area Update
4 Trace activation and deactivation
4.1 Trace session activation / deactivation
4.1.1 Management activation
4.1.1.1 General
In Management activation, the Trace Control and Configuration parameters are sent directly to the concerned NE (by its EM). This NE shall not propagate the received data to any other NE's - whether or not it is involved in the actual recording of the call.
Once the parameters have been provided, the NE looks for the IMSI or IMEI (IMEISV) passing through it. If it does not have them, these shall be provided to the NE (that performs the trace recording) as part of traffic signalling by the CN.
The following figure represents the management based trace functionality within a PLMN. The figure represents a typical PLMN network. A dotted arrow with "Trace Parameter Configuration" represents the availability of the management based trace functionality at the EM for that domain.
NOTE: There is no propagation of trace parameters in management based trace activation.
EMBED Visio.Drawing.6
Figure 4.1.1.1.1: Overview of management activation for an UMTS system
If the NE failed to activate the Trace Session, a Trace failure notification shall be sent to the TCE, and the Trace failure notification has the the same parameters as the notification notifyTraceRecordingSessionFailure defined in 3GPP TS 32.442[24], the Trace failure notification file XML schema is defined in Annex A.
4.1.1.2 UTRAN activation mechanisms
When an RNC receives Trace Session activation from the EM it shall start a Trace Session. The trace control and configuration parameters of the Trace Session are received in Trace Session activation from the EM. The RNC shall not forward these trace control and configuration parameters to other nodes. The received trace control and configuration parameters shall be saved and used to determine when and how to start a Trace Recording Session. (Starting a Trace Recording Session is described in subclause 4.2.2.1). A Trace Session may be requested for a limited geographical area.
Since a RNC has visibility of an IMSI, it can start an IMSI Trace all by itself when a Trace session is requested for an IMSI or a list of IMSIs. However, a RNC does not have visibility of the IMEI(SV). Hence, when a Trace session is requested for an IMEI(SV) or a list of IMEI(SV), the RNC shall send the requested IMEI(SV) / list of IMEI(SV)s in an 'Uplink Information Exchange Request' message to the interacting MSC Server(s) and SGSN(s). The MSC Servers and SGSNs shall store the requested IMEI(SV)s per RNC. For each subscriber/UE activity the MSC Servers and SGSNs shall request IMEI(SV), if it is not already provided. For each subscriber/UE activity the MSC server/SGSN shall check whether a trace request is active in an RNC for the IMEI(SV). If a match is found, the MSC Server/SGSN shall inform the RNC about the IMEI(SV) in CN Invoke Trace, so that the RNC can trace the control signalling according to the trace control and configuration parameters that are received from its EM.
If an Inter-MSC SRNS Relocation or an Inter-SGSN SRNS relocation occurs, the anchor MSC Server or source SGSN shall transfer the IMSI and IMEI(SV) for the subscriber/UE activity to the non anchor MSC Server or target SGSN. The non anchor MSC Server/target SGSN shall check whether it has received a trace request from the target RNC for the transferred IMEI(SV). If a match is found on the IMEI(SV) in the non anchor MSC Server/target SGSN, the MSC Server/SGSN shall inform the RNC about the IMEI(SV) in the CN Invoke Trace. The IMSI shall be transferred from the non anchor MSC Server/target SGSN to the target RNC in Relocation Request. The RNC can then trace the subscriber/UE activity according to the trace control and configuration parameters that are received from its EM.
4.1.1.3 PS Domain activation mechanisms
When a SGSN, GGSN or BM-SC receives Trace Session activation from the EM it shall start a Trace Session. The trace control and configuration parameters of the Trace Session are received in the Trace Session activation from the EM. The SGSN/GGSN/BM-SC shall not forward these trace control and configuration parameters to other nodes. The received trace control and configuration parameters shall be saved and used to determine when and how to start a Trace Recording Session. (Starting a Trace Recording Session is described in subclause 4.2.2.2)
4.1.1.4 CS Domain activation mechanisms
When a MSC Server receives Trace Session activation from the EM it shall start a Trace Session. The trace control and configuration parameters of the Trace Session are received in the Trace Session activation from the EM. The MSC Server shall not forward these trace control and configuration parameters to other nodes. The received trace control and configuration parameters shall be saved and used to determine when and how to start a Trace Recording Session. (Starting a Trace Recording Session is described in subclause 4.2.2.3)
4.1.1.5 IP Multimedia Subsystem activation mechanisms
When a S-CSCF/P-CSCF receives Trace Session activation from EM, the S-CSCF/P-CSCF shall start a Trace Session. The Trace control and configuration parameters of the Trace Session, received from EM in the Trace Session activation, shall be saved. The Trace control and configuration parameters define when the S-CSCF and P-CSCF shall start and stop a Trace Recording Session. For detailed information on starting and stopping Trace Recording Session in IMS see sub clauses 4.2.2.4 and 4.2.4.4.
The following figure illustrates the Trace Session activation in S-CSCF and in P-CSCF in case of Management based activation.
EMBED Word.Picture.8
Figure 4.1.1.5.1: Trace Session activation in IMS
4.1.1.6 E-UTRAN activation mechanisms
In E-UTRAN the Management Based Trace Activation can be fulfilled with the E-UTRAN Cell Traffic trace functionality. In this case the Trace Session Activation is done to one or a list E-UTRAN cells within one eNodeB, where Trace Session is activated.
When eNodeB receives the Trace Session Activation message from the EM for a given or a list of E-UTRAN cell(s) the eNodeB shall start a Trace Session for the given or list of E-UTRAN cell(s).
4.1.1.7 EPC Domain activation mechanisms
When a MME or SGW receives Trace Session activation from the EM it shall start a Trace Session. The trace control and configuration parameters of the Trace Session are received in the Trace Session activation from the EM. The MME/SGW shall not forward these trace control and configuration parameters to other nodes. The received trace control and configuration parameters shall be saved and used to determine when and how to start a Trace Recording Session. (Starting a Trace Recording Session is described in subclause 4.2.2.6)
4.1.2 Signalling activation
4.1.2.1 General
In Signalling activation, the Trace Activation shall be carried out from the Core Network EM only [EM (PS), EM (CS), EM (HSS) and EM(EPC) are generally considered to be in the Core Network. A Core Network EM can be any of these or their combinations].
In case of home subscriber trace (i.e. in the HPLMN) the Trace Session activation shall go to the HSS / MSC Server / SGSN / MME. Instances where the home subscriber is roaming in a VPLMN, the HSS may initiate a trace in that VPLMN. The VPLMN may reject such requests.
In case of foreign subscriber trace (i.e. the HPLMN operator wishes to trace foreign subscribers roaming in his PLMN) the Trace Session activation shall go the MSC Server/VLR, SGSN / MME. Depending on the Trace Control and Configuration parameters received, the Core Network shall propagate the activation to selected NE's in the entire network RAN and Core Network.
If the NE failed to activate the Trace Session, a Trace failure notification shall be sent to the TCE, and the Trace failure notification has the the same parameters as the notification notifyTraceRecordingSessionFailure defined in 3GPP TS 32.442 [24], the Trace failure notification file XML schema is defined in Annex A.
4.1.2.2 Intra PLMN signalling activation
The following figure represents the signalling based trace functionality within a PLMN. The figure represents a typical PLMN network. A dotted arrow with "Trace Parameter Configuration" represents the availability of the trace functionality at the EM for that domain. E.g. you cannot invoke a Signalling Trace at the EM (UTRAN) because there is no such arrow shown in the figure. You can however do it from the EM (CS Domain). Similarly "Trace Parameter Propagation" is allowed only for the interfaces indicated in the figure. E.g. there is no parameter propagation over Iu-B.
NOTE: For tracing on the basis of IMEI(SV), the signalling based activation can be only initiated from the MSC/VLR or SGSN.
EMBED Visio.Drawing.6
Figure 4.1.2.2.1: Overview of Intra-PLMN Signalling Activation
4.1.2.3 Inter PLMN Signalling Activation
The following figure represents the signalling based trace functionality between PLMNs. This is particularly useful when a roaming subscriber needs to be traced in a network. The figure represents a typical PLMN network and its connections with another PLMNs HSS. A dotted arrow with "Trace Parameter Configuration" represents the availability of the trace functionality at the EM for that domain. E.g. you cannot invoke a Signalling Trace at the EM (UTRAN) because there is no such arrow shown in the figure. You can however do it from the EM (CS Domain). Similarly "Trace Parameter Propagation" is allowed only for the interfaces indicated in the figure. E.g. there is no parameter propagation over Iu-B.
NOTE: There is no intention to allow tracing of a home subscriber roaming in a foreign network i.e. the trace function is limited to a single PLMN.
EMBED Visio.Drawing.6
Figure 4.1.2.3.1: Overview of Inter-PLMN Signalling Activation
4.1.2.4 UTRAN activation mechanisms
See subclause 4.2.3.1.
4.1.2.5 PS Domain activation mechanisms
The following figure shows the Trace Session activation in the PS domain. The figure is an example of tracing PDP context.
EMBED Visio.Drawing.6
Figure 4.1.2.5.1: Trace session activation in PS domain for PDP Context
When a UE registers with the network by sending an ATTACH_REQUEST message to the SGSN, it updates the location information in the HSS by sending the UPDATE_GPRS_LOCATION message to the HSS. The HSS checks if the UE is being traced. If it is being traced, the HSS shall propagate the trace control and configuration parameters to the SGSN by sending a MAP-ACTIVATE_TRACE_MODE - see 3GPP TS 29.002 [11] message to the SGSN. When an inter-SGSN routing area update occurs, HSS shall send the MAP-ACTIVATE_TRACE_MODE message to the new SGSN.
When SGSN receives the MAP-ACTIVATE_TRACE_MODE message it shall store the trace control and configuration parameters and shall start a Trace Session.
When any of the triggering events defined in the trace control and configuration parameters occur, (e.g. PS session is started (i.e. a ACTIVATE PDP CONTEXT REQUEST message is received from the UE)) the SGSN shall propagate the trace control and configuration parameters to the GGSN (by sending a GTP-CREATE_PDP_CONTEXT_REQUEST message) and to the radio network (by sending a RANAP-CN_INVOKE_TRACE message), if it is defined in the trace control and configuration parameters (NE types to trace). The Trace Session activation to UTRAN is described in clauses 4.1.2.4.
When HSS sends the MAP-ACTIVATE_TRACE_MODE message to SGSN it shall include the following parameters to the message:
IMSI (M).
Trace reference (M).
Triggering events for SGSN (M) and GGSN (M).
Trace Depth (M).
List of NE types to trace (M).
List of interfaces for SGSN (O), GGSN (O) and/or RNC (O).
When the SGSN sends the GTP-CREATE_PDP_CONTEXT_REQUEST message to GGSN it shall include the following parameters to the message:
IMSI or IMEI (SV) (M).
Trace reference (M).
Trace Recording Session Reference (M).
Triggering events for GGSN (M).
Trace Depth (M).
List of interfaces for GGSN (O).
The following figure is an example of tracing for MBMS Context.
EMBED Word.Picture.6
Figure 4.1.2.5.2: Trace session activation in PS domain for MBMSContext
When HSS receives a Trace Session activation from its EMS, it shall store the received trace control and configuration parameters. At this point a Trace Session shall be started in the HSS.
When a UE registers with the network by sending an ATTACH_REQUEST message to the SGSN, it updates the location information in the HSS by sending the UPDATE_GPRS_LOCATION message to the HSS. The HSS checks if the UE is being traced. If it is being traced, the HSS shall propagate the trace control and configuration parameters to the SGSN by sending a MAP-ACTIVATE_TRACE_MODE message to the SGSN. When an inter-SGSN routing area update occurs, HSS shall send the MAP-ACTIVATE_TRACE_MODE message to the new SGSN.
When SGSN receives the MAP-ACTIVATE_TRACE_MODE message it shall store the trace control and configuration parameters and shall start a Trace Session.
When any of the triggering events defined in the trace control and configuration parameters occur, (i.e. an ACTIVATE MBMS CONTEXT REQUEST message is sent to the UE)) the SGSN shall propagate the trace control and configuration parameters to the GGSN (by sending a GTP-CREATE_MBMS_CONTEXT_REQUEST message) and to the radio network (by sending a RANAP-CN_INVOKE_TRACE message), if it is defined in the trace control and configuration parameters (NE types to trace). The Trace Session activation to UTRAN is described in clauses 4.1.2.4.
The GGSN shall propagate the trace control and configuration parameters to the BM-SC (by sending a Diameter Gmb AAR message) if the BM-SC is defined in the trace control and configuration parameters (NE types to trace).
When HSS sends the MAP-ACTIVATE_TRACE_MODE message to SGSN it shall include the following parameters in the message:
IMSI (M).
Trace reference (M).
Triggering events for SGSN (M), GGSN (M) and BM-SC (M).
Trace Depth (M).
List of NE types to trace (M).
List of interfaces for SGSN (O), GGSN (O), BM-SC (O) and/or RNC (O).
When the SGSN sends the GTP-CREATE_MBMS_CONTEXT_REQUEST message to GGSN it shall include the following parameters in the message:
IMSI or IMEI (SV) (M).
Trace reference (M).
Trace Recording Session Reference (M).
Triggering events for GGSN (M) and BM-SC (M).
Trace Depth (M).
List of interfaces for GGSN (O) and BM-SC (O).
When the GGSN sends the Diameter Gmb AAR message to the BM-SC it shall include the following parameters in the message:
IMSI or IMEI (SV) (M).
Trace reference (M).
Trace Recording Session Reference (M).
Triggering events for BM-SC (M).
Trace Depth (M).
List of interfaces for BM-SC (O).
4.1.2.6 CS Domain activation mechanisms
The following figure shows the Trace Session activation in the CS domain. The figure is an example of tracing Mobile Originating Call.
EMBED Visio.Drawing.6
Figure 4.1.2.6.1: Trace Session Activation in CS domain
When HSS receives Trace Session activation from the EMS it should store the trace control and configuration parameters associated to the Trace Session.
If the UE registers to the network, by sending a LOCATION UPDATING REQUEST message to the MSC/VLR, the MSC Server/VLR updates the location information in the HSS by sending the MAP-UPDATE_LOCATION message to the HSS. After receiving the UPDATE_LOCATION message HSS shall propagate the trace control and configuration parameters by sending a MAP-ACTIVATE_TRACE_MODE message to the MSC Server/VLR.
When the MSC Server/VLR receives the MAP-ACTIVATE_TRACE_MODE message from the HSS, it shall store the trace control and configuration parameters.
When any of the triggering event, defined in the trace control and configuration parameters, occurs (e.g. in case of Mobile Originating Call is started (i.e. the MSC Server receives the CM_SERVICE_REQUEST message with service type set to originating call establishment)) the MSC Server should propagate the trace control and configuration parameters to the MGW (by sending an ADD command with a trace package - see 3GPP TS 29.232 [10]) and to the radio network if it is defined in the trace control and configuration parameters (NE types to trace). Trace Session activation for UTRAN is described in clauses 4.1.2.4. In case of inter-MSC Server handover the MSC Server-A should propagate the trace control and configuration parameters to the MSC Server-B.
When HSS sends the MAP-ACTIVATE_TRACE_MODE message to MSC Server it shall include the following parameters to the message:
IMSI (M).
Trace reference (M).
Triggering events for MSC Server (M) and MGW (M) .
Trace Depth (M).
List of NE types to trace (M).
List of interfaces for MSC Server (O), MGW (O) and/or RNC (O).
When the MSC Server sends the ADD command with trace package to MGW it shall include the following parameters to the message:
IMSI or IMEI (SV) (M).
Trace reference (M).
Trace Recording Session Reference (M).
Triggering events for MGW (M).
Trace Depth (M).
List of interfaces for MGW (O).
4.1.2.7 Void
4.1.2.8 Tracing roaming subscribers
If a HPLMN operator activates a Trace Session for a home subscriber, while it (MS) is roaming in a VPLMN, it (HSS) may restrict the propagation of the Trace Session activation message to a MSC Server/VLR or to a SGSN located in the VPLMN.
Also, a MSC Server/VLR or a SGSN located in a VPLMN may accept any Trace Session activation message(s) coming from an HSS located in another PLMN. However, there shall be a capability to reject activations from another PLMN.
4.1.2.9 Void
4.1.2.9.1 Void
4.1.2.9.2 Void
4.1.2.9.3 Void
4.1.2.9.4 Void
4.1.2.10 EPC activation mechanism
Figure 4.1.2.10.1 summarizes the Trace Session activation procedure in EPC:
EMBED Word.Picture.6
Figure 4.1.2.10.1: Trace Session activation procedure in EPC with GTP based S5 interface:
The Trace Session activation in MME can come for a home subscriber trace from HSS via the S6a interface or for a foreign subscriber from the EM of MME.
When the UE makes an attach request to the MME, it updates the location information in the HSS. The HSS checks if the UE is being traced. If it is being traced, the HSS shall propagate the trace control and configuration data to the MME by including the trace control and configuration parameters into the S6a-Insert subscriber data message or the S6a-Update Location Answer message. If the traced UE has already attached before receiving the Trace Session Activation from the EM/NM, the HSS shall also propagate the trace control and configuration data to the MME by either S6a-Insert subscriber data message or the S6a-Update Location Answer message. When MME receives the trace control and configuration data from the HSS it shall store the information and shall start a Trace Session.
During inter-MME TAU, the MME shall propagate the trace control and configuration parameters to the target MME within an S10- Context Response as part of inter-MME TAU procedures. During attach procedures where the context information is requested from the target MME, the MME shall propagate the trace control and configuration parameters within an S10-Identification Response message. During inter-MME handover, the MME shall propagate the trace control and configuration parameters to the target MME within an S10- Forward Relocation Request message as part of inter-MME handover procedures.
If the List of NE Types parameter specifies tracing in the SGW and/or Tracing in the PGW, MME shall propagate the trace control and configuration parameters via the S11 interface to the SGW per one of the following messages:
if a default bearer connection has not been established, via the S11: Create Session Request message
otherwise via the S11-Trace Session Activation message
The SGW upon receiving the trace control and configuration parameters shall start a trace session.
If the List of NE Types parameter specifies Tracing in the PGW, SGW shall propagate the trace control and configuration parameters via the S5 interface to the PGW per one of the following messages:
if a default bearer connection has not been established, via the S5: Create Session Request message
otherwise via the S5-Trace Session Activation message
The PGW upon receiving the trace control and configuration parameters shall start a trace session.
When a triggering events, defined in the trace control and configuration data occur (i.e. a session is started) a Trace Recording Session should be started and the trace control and configuration data should be propagated to the radio network to the eNB if the List of NE Types parameter specifies eNB tracing. However if the triggering events parameter at MME indicates that all events should be traced, Trace Recording Session shall be started only when the user specific S1 association is setup to the eNB and the Trace Recording Session is kept as long as the user specific S1 association is released or the Trace Session is deactivated. See section 4.2.3.6.
When HSS activates the trace to the MME the following trace control and configuration parameters shall be included in the message:
IMSI or IMEISV
Trace Reference
Triggering events for MME, Serving GW, PDN GW
Trace Depth
List of NE types to trace
List of Interfaces for MME, Serving GW, PDN GW, eNB
IP address of Trace Collection Entity
When MME activates the trace to the SGW the following trace control and configuration parameters shall be included in the message::
IMSI or IMEISV
Trace Reference
Triggering events for Serving GW, PDN GW
Trace Depth
List of NE types to trace
List of Interfaces for Serving GW, PDN GW
IP address of Trace Collection Entity
When SGW activates the trace to the PGW the following trace control and configuration parameters shall be included in the message:
IMSI or IMEISV
Trace Reference
Triggering events for PDN GW
Trace Depth
List of Interfaces for PDN GW
IP address of Trace Collection Entity
When MME sends the trace control and configuration parameters to the eNB the following information shall be included in the message:
Trace Reference
Trace Recording Session Reference
Trace Depth
IP Address of Trace Collection Entity
and the following information may be included in the message:
List of Interfaces for eNB
Figure 4.1.2.10.1.A illustrates the Trace Session activation in case of PMIP based S5 interface. The figure contains only the difference compare to the GTP based S5 interface
EMBED Word.Picture.6
Figure 4.1.2.10.1.A Trace Session Activation from SWG to PGW in case of PMIP based S5 interface
When the SGW receives the Trace Session activation message and the List of NE Type to trace parameter specifies Tracing in the PDN GW , SGW shall send Trace Session Activation to PDN GW via the PCRF. The Trace Session activation can be done as part of the IP CAN session establishment or as a standalone procedure [29].
The Trace Session Activation shall include the following information:
IMSI or IMEISV
Trace reference
Trace Recording Session Reference
Trace Depth
Triggering events for PDN GW
List of Interfaces for PDN GW
IP address of Trace Collection Entity
When the PCRF receives the Trace Session Activation it shall forward the same trace control and configuration parameters to the PDN GW [29].
Figure 4.1.2.10.2 illustrates the Trace Session activation when the UE is attached from a non-3GPP access network.
Figure 4.1.2.10.2 Trace Session activation procedure to PGW in case of UE attaches from non-3GPP access network
When the UE attaches to the EPC network via a non-3GPP access network the Trace Session activation to the PGW can be done only via HSS and AAA server. Therefore when the UE attach is signalled to the HSS via non-3GPP access network, the HSS shall send the the Trace control and configuration parameters to the AAA server as part of the user profile download [25]. The following information shall be included in the downloaded user data:
IMSI, or IMEI(SV)
Trace Reference
Triggering event for PGW
Trace Depth
List of interface for PGW
IP address of Trace Collection Entity
When the AAA server receives the user profile, which contains also the trace control and configuration parameters, it shall store the received trace control and configuration parameters. The AAA server shall forward the received trace control and configuration parameters in the authorization when it receives the authorization request from the PGW during the PDN connectivity.
The event, which triggers the authorization in the PDN GW depend on the used IP mobility protocol:
In case of DSMIP (option A), it is a binding update received from the UE,
In case of PMIP (Option B), it is a proxy binding update request received from the Trusted Non-3GPP GW or ePDG playing the role of the Mobile Access Gateway (MAG)
If the UE is already registered to the HSS by a AAA server via the SWx interface, Trace Session activation shall also be possible from the HSS to the PDN GW via the AAA server. In that case the HSS sends the Trace Session activation message with a push profile request.
The AAA server shall examine the received user profile and if Trace Session activation is needed in the PDN GW, it shall initiate a re-authorization procedure towards the the PDN GW. The Trace Session is activated to te PDN GW using this re-authorization procedure. When PDN GW receives the Trace Session activation message, it shall save the received trace control and configuration parameters.
4.1.2.11 E-UTRAN activation mechanisms
The Trace Session should be activated in in an eNB when the eNB receives the TRACE START, INITIAL CONTEXT SETUP REQUEST or HANDOVER REQUEST message with the IE Trace Activation from the MME and if some activities have been started on the interfaces that have been requested to be traced.
If the subscriber or equipment which is traced makes a handover to a target eNB using the X2 interface, the source eNB should propagate the trace control and configuration parameters further to the target eNB by using the HANDOVER REQUEST message. When the target eNB receives the HANDOVER REQUEST message it should immediately start a Trace Session according to the trace control and configuration parameters received in the HANDOVER REQUEST message.
If the subscriber or equipment which is traced makes a handover to a target eNB using the S1 interface, it is the MME's responsibility to propagate the trace control and configuration parameters to the target eNB.
Interaction with Relocation
If the tracing shall continue also after the relocation has been performed, the CN Invoke Trace procedure shall be re-initiated from the CN towards the future eNB after the Relocation Resource Allocation procedure has been executed successfully.
The TRACE START, INITIAL CONTEXT SETUP REQUEST or HANDOVER REQUEST message that is received from the MME contains the following information:
Trace Reference (including Trace Recording Session Reference)
Trace Depth
List of interfaces for eNB
IP address of Trace Collection Entity
4.1.3 Management deactivation
4.1.3.1 UTRAN deactivation mechanisms
When last Trace session is requested to be ended for an IMEI(SV) or a list of IMEI(SV), the RNC shall send the requested IMEI(SV)/list of IMEI(SV)s in 'Uplink Information Exchange Request' to the interacting MSC Server(s) and SGSN(s). The MSC Servers and SGSNs shall remove the requested IMEI(SV)s for the RNC in question.
4.1.3.2 PS Domain deactivation mechanisms
When a SGSN, GGSN or BM-SC receives a Trace Session Deactivation from its EM, the Trace Session identified by the Trace Reference, shall be deactivated in SGSN/GGSN/BM-SC.
If a Trace Recording Session is active at the time of receiving a Trace Session deactivation from the EM, the SGSN/GGSN/BM-SC may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the SGSN/GGSN/BM-SC shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session.
4.1.3.3 CS Domain deactivation mechanisms
When a MSC Server receives a Trace Session Deactivation from its EM, the Trace Session identified by the Trace Reference, shall be deactivated in MSC Server.
If a Trace Recording Session is active at the time of receiving a Trace Session deactivation from the EM, the MSC Server may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the MSC Server shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session.
4.1.3.4 IP Multimedia Subsystem deactivation mechanisms
When a S-CSCF/P-CSCF receives a Trace Session deactivation from the EM, the Trace Session identified by the Trace Reference, shall be deactivated.
If a Trace Recording Session is active at the time of receiving a Trace Session deactivation from the EM, the S-CSCF/P-CSCF may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the S-CSCF/P-CSCF shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session.
The following figure illustrates how the Trace Session is deactivated when a Trace Recording Session is going on (e.g. a SIP INVITE method is being traced in S-CSCF).
EMBED Word.Picture.8
Figure 4.1.3.4.1: Trace session deactivation in IMS
4.1.3.5 E-UTRAN deactivation mechanisms
In E-UTRAN the Cell Traffic trace functionality can be deactivated when the eNodeB receives the Trace Session Deactivation message from the EM. At this time the eNodeB shall deactivate the Trace Session for those E-UTRAN Cells that have been indicated in the Trace Session Deactivation message received from the EM.
4.1.3.6 EPC Domain deactivation mechanisms
When a MME or a SGW receives a Trace Session Deactivation from its EM, the Trace Session identified by the Trace Reference, shall be deactivated in the MME or the SGW.
If a Trace Recording Session is active at the time of receiving a Trace Session deactivation from the EM, the MME may choose to continue the Trace Session and the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the MME shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session.
4.1.4 Signalling deactivation
4.1.4.1 General
In Signalling deactivation, the Trace Deactivation shall always be carried out from the Core Network EM only [EM (PS), EM (CS), EM(EPC) and EM (HSS) are generally considered to be in the Core Network. A Core Network EM can be any of these or their combinations]. In case of home subscriber trace (i.e. in the HPLMN) the Trace Session deactivation shall go to the HSS, MSC Server/VLR, SGSN or MME. In case of foreign subscriber trace (i.e. the HPLMN operator wishes to deactivate tracing on foreign subscribers roaming in his PLMN) the Trace Session deactivation shall go the MSC Server/VLR SGSN or MME. The Management System shall deactivate the Trace Session in the same NE where it activated the Trace Session.
When an HSS receives a Trace Session deactivation from its Management system, it shall deactivate the active Trace Session corresponding to the Trace Reference received in the deactivation message. The HSS shall delete all trace control and configuration parameters associated with this Trace Session. If a Trace Recording Session is active at the time of receiving a Trace Session deactivation message from the EM, the HSS may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the HSS shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session.
4.1.4.2 UTRAN deactivation mechanisms
When RNC receives the CN_DEACTIVATE_TRACE message it shall deactivate the Trace Session for the indicated Trace Reference in the CN_DEACTIVATE_TRACE message. In case of simultaneous CS/PS connections, the trace session for the indicated trace reference shall be closed upon reception of the CN DEACTIVATE TRACE message from any of the CN domain, whether it was the one which initiated trace session activation or not.
The Trace Session is also deactivated in the RNC when the Iu connection to the Core Network is released.
If CN_INVOKE_TRACE message is received for only one Iu connection (either CS or PS) the Trace Session shall be deactivated in the RNC when the IU_RELEASE_COMMAND message is received from the Core Network for that Iu connection where the CN_INVOKE_TRACE message is sent.
The following figure shows this behaviour:
EMBED Visio.Drawing.6
Figure 4.1.4.2.1: Trace session deactivation (Signalling) in UTRAN 1
If CN_INVOKE_TRACE message is received by the RNC for both Iu-CS and Iu-PS connection with the same Trace Reference number than the Trace Session shall not be deactivated in the RNC when any of the Iu connection is released (when the first IU_RELEASE_COMMAND message is received). The Trace Session shall be deactivated when the second Iu connection is released (the second IU_RELEASE_COMMAND message is received). The following figure shows the situation.
EMBED Visio.Drawing.6
Figure 4.1.4.2.2: Trace session deactivation (Signalling) in UTRAN 2
Interaction with Soft-handover
The Trace Session should be deactivated in a Drift RNC when the DRNC receives the IUR_DEACTIVATE_TRACE message or the Iur connection is released.
When an RNC deactivates a Trace Session the Trace Recording Session shall also be stopped at the same time.
NOTE: In RNC the Trace Session and the Trace Recording Session always the same.
4.1.4.3 PS Domain deactivation mechanisms
When an HSS receives a Trace Session deactivation from the Management System it shall send a MAP_DEACTIVATE_TRACE_MODE message to the SGSN.
When the SGSN receives a MAP_DEACTIVATE_TRACE_MODE message it shall deactivate the Trace Session identified by the Trace reference received in the MAP_DEACTIVATE_TRACE_MODE message.
If a Trace Recording Session is active at the time of receiving a deactivation message (in SGSN it is the MAP-DEACTIVATE_TRACE_MODE, in GGSN it is the GTP Update PDP Context Request or the Update MBMS Context Request, in BM-SC it is the Diameter Gmb STR message), the SGSN and/or the GGSN and/or the BM-SC may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the SGSN/GGSN/BM-SC shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session. When the SGSN deactivates the Trace Session, it shall delete all trace control and configuration parameters associated with the corresponding Trace Session.
If SGSN deactivates the Trace Session during the Trace Recording Session, the SGSN should deactivate the trace to the RNC by using the CN_DEACTIVATE_TRACE RANAP message and should deactivate the trace to the GGSN by sending the GTP Update PDP Context Request or the Update MBMS Context Request message with Trace Activity Control set to Trace Deactivation.
If the GGSN deactivates the Trace Session during the Trace Recording Session, the GGSN should deactivate the trace to the BM-SC (by sending a Diameter Gmb STR message).
4.1.4.4 CS Domain deactivation mechanisms
When an HSS receives Trace Session deactivation from the Management System it shall send a MAP_DEACTIVATE_TRACE_MODE message to the MSC Server.
When the MSC Server receives a MAP_DEACTIVATE_TRACE_MODE message it shall deactivate the Trace Session identified by the Trace reference received in the MAP_DEACTIVATE_TRACE_MODE message.
If a Trace Recording Session is active at the time of receiving a MAP_DEACTIVATE_TRACE_MODE message from the HSS, the MSC Server may choose to continue the Trace Recording Session till it ends gracefully or may stop it immediately. In all cases, the MSC Server shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session. When the MSC Server deactivates the Trace Session it shall delete all trace control and configuration parameters associated with the corresponding Trace Session. .
If MSC Server deactivates the Trace Session during a Trace Recording Session, it should deactivate the trace to the RNC by sending the CN_DEACTIVATE_TRACE RANAP message and should deactivate the trace to the MGW.
4.1.4.5 Void
4.1.4.6 Void
4.1.4.6.1 Void
4.1.4.6.2 Void
4.1.4.6.2.1 Void
4.1.4.6.2.2 Void
4.1.4.6.2.3 Void
4.1.4.6.3 Void
4.1.4.7 EPC deactivation mechanisms
When an HSS receives a Trace Session Deactivation from the Management System it shall send an S6a-Delete Subscriber Data Request message to the MME at which the UE is currently registered if MME is included in the NE types for Tracing, via the S6a interface to remove the trace data from subscription data (see 3GPP TS 29.272[26]). The HSS shall deactivate trace if trace is active at the HSS.
When the MME receives the S6a-Delete Subscriber Data Request message to remove the trace data from subscription data (see 3GPP TS 29.272 [26]) or the Trace Session is deactivated directly from the EM it shall deactivate the Trace Session identified by the Trace Reference.
If the UE was registered to the HSS by an MME via the S6a interface, (.e. the user is attached to a 3GPP access network), the Trace Session shall be deactivated to the MME via the S6a interface.
If the user was registered by a AAA server via the SWx interface (i.e. the user is attached to a non-3GPP network) the HSS shall send the Trace Session deactivation request with a push profile request.
The AAA server shall examine the received user profile and if it detects that the Trace Session shall be deactivated, it shall initiate a re-authorization procedure towards the PDN GW. The Trace Session is deactivated in the PDN GW by using this re-authorization procedure.
When the PDN GW receives the updated authorization data with trace information that represents Trace Session deactivation request, it shall deactivate the Trace Session identified by the Trace Reference.
The following figure illustrates the Trace Session deactivation when the user is attached to a non-3GPP access network.
SHAPE \* MERGEFORMAT
Figure 4.1.4.7.1 Trace Session deactivation in case UE attached from non-3GPP access network.
When the MME receives the S6a-Delete Subscriber Data Request message to remove the trace data from subscription data (see 3GPP TS 29.272 [26]) or the Trace Session is deactivated directly from the EM it shall deactivate the Trace Session identified by the Trace Reference.
If a Trace Recording Session is active at the time of receiving a deactivation message, the MME may choose to continue the Trace Recording Session until it ends gracefully or may stop it immediately. In all cases, the MME shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session. When the MME deactivates the Trace Session, it shall delete all trace control and configuration parameters associated with the corresponding Trace Session.
If MME deactivates the Trace Session during the Trace Recording Session, the MME should deactivate the trace at the eNB by sending the S1-Deactivate Trace message to the eNodeB via the S1 interface and should deactivate the trace at the SGW by sending an S11-Trace Session Deactivation message to the SGW via the S11 interface. The message sent by MME shall include the Trace Reference to identify the Trace Session that is to be deactivated.
When SGW receives an S11-Trace Session Deactivation message from the MME, the SGW may choose to continue the Trace Recording Session until it ends gracefully or may stop it immediately. In all cases, the SGW shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session. If SGW deactivates the Trace Session during the Trace Recording Session, the SGW should deactivate the trace at the PDN GW by sending the S5-Trace Session Deactivation message to the PGW via the GTP based S5 interface. In case of PMIP based S5 interface the SGW should deactivate the trace to the PDN GW using PCC signalling, i.e. by sending a Trace Deactivation message to the PCRF and PCRF forwards the trace deactivation message to the PDN GW [29].When the SGW deactivates the Trace Session, it shall delete all trace control and configuration parameters associated with the corresponding Trace Session.
When PGW receives an S5-Trace Session Deactivation message from the SGW, , or it receives the Trace Session Deactivation message from PCRF in case of PMIP based S5, the PDN GW may choose to continue the Trace Recording Session until it ends gracefully or may stop it immediately. In all cases, the PDN GW shall deactivate the requested Trace Session immediately at the end of the Trace Recording Session. When the PDN GW deactivates the Trace Session, it shall delete all trace control and configuration parameters associated with the corresponding Trace Session.
When a Trace Session Deactivation message is sent on any interface the Trace Reference that identifies the Trace Session shall be included to the Trace Session Deactivation message.
4.1.4.8 E-UTRAN deactivation mechanisms
There are two different events that deactivate a Trace Session:
When eNB receives the S1- Deactivate Trace message it shall deactivate the Trace Session for the indicated Trace Reference.
When the eNB releases the UE context the Trace Recording Session shall be stopped and the Trace Session is deactivated at the eNB.
4.2 Trace recording session Start / Stop triggering
4.2.1 General
Editor's Note: For further study.
The Trace Session activation contains the triggering events parameter. The actual start/stop triggering events corresponding to the values of the triggering events parameter are defined in triggering events tables in sub-clause 5.1 in the present document.
If the NE failed to start the Trace Recording Session, a Trace failure notification shall be sent to the TCE, and the Trace failure notification has the the same parameters as the notification notifyTraceRecordingSessionFailure defined in 3GPP TS 32.442[24], the Trace failure notification file XML schema is defined in Annex A.
4.2.2 Starting a trace recording session - management based
4.2.2.1 UTRAN starting mechanisms
In an RNC, a Trace Recording Session should start after the reception of the CN_INVOKE_TRACE message from the CN and if some activities have been started on the interfaces that have been requested to be traced. The RNC shall record those signalling messages in the interfaces that are defined in the list of interfaces parameter. Trace depth defines whether entire signalling messages or just some IEs needs to be recorded.
The RNC may not start a Trace Recording Session if there are insufficient resources available for the recording.
When RNC starts a Trace Recording Session it shall assign a Trace Recording Session Reference for the Trace Recording Session.
4.2.2.2 PS Domain starting mechanisms
In a SGSN/GGSN/BM-SC, a Trace Recording Session should start after the reception of a Trace Session Activation from EM and if any of the defined start triggering events occur. During the Trace Recording Session, the SGSN/GGSN/BM-SC shall record those signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter defines whether entire signalling messages or just some IEs need to be recorded.
The IMSI and IMEISV shall be available in the SGSN, in the GGSN and in the BM-SC for at least those connections which shall be traced.
The SGSN/GGSN/BM-SC may not start a Trace Recording Session if there are insufficient resources available for the recording.
If the SGSN/GGSN/BM-SC receives the Trace Session Activation during an established session (e.g. during an active PDP context or an active MBMS context), it may start the Trace Recording Session immediately. However, if any of the start triggering events occur in the SGSN/GGSN/BM-SC after receiving the Trace Session Activation, it shall start the Trace Recording Session.
When a Trace Recording Session is started, the SGSN/GGSN/BM-SC shall assign a Trace Recording Session Reference for the Trace Recording Session.
4.2.2.3 CS Domain starting mechanisms
In a MSC Server, a Trace Recording Session shall start after the reception of a Trace Session Activation from EM and if any of the defined start triggering events occur. During the Trace Recording Session, the MSC Server shall record those signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter defines whether entire signalling messages or just some IEs needs to be recorded.
The IMSI and the IMEISV shall be available in the MSC Server for at least those connections which shall be traced.
The MSC Server may not start a Trace Recording Session if there are insufficient resources available for the recording.
If the MSC Server receives the Trace Session Activation during an established call, it may start the Trace Recording Session immediately. However, if any of the start triggering events occurs in MSC Server after receiving the Trace Session Activation, it shall start the Trace Recording Session.
When a Trace Recording Session is started, the MSC Server shall assign a Trace Recording Session Reference for the Trace Recording Session.
4.2.2.4 IP Multimedia Subsystem starting mechanismsVoid
Editor's Note: For further study.
4.2.2.5 E-UTRAN starting mechanism
In E-UTRAN, after theCell Traffic Trace has been activated in the monitored cell(s), the eNodeB shall start a Trace Recording Sessionfornew call(s)/session(s)and for already existing call(s)/session(s) (events for existing call(s)/session(s) are not requiredto berecorded prior to the activation of the cell traffic trace). When the eNodeB starts a Trace Recording Session it shall allocate a Trace Recording Session Reference for the given call or session. The eNodeB shall send the allocated Trace Recording Session Reference, and the Trace Reference and the Trace Collection Entity address in the CELL TRAFFIC TRACE message to the MME via the S1 connection.
When MME receives this new S1 signalling message containing the Trace Recording Session Reference and Trace Reference, the MME shall look up the IMSI/IMEI(SV) of the given call from its database and shall send the IMSI/IMEI(SV) numbers together with the Trace Recording Session Reference and Trace Reference to the Trace Collection Entity.
The format of the file sent to the TCE from the MME is defined in 3GPP TS 32.423 A.2.2.
The figure 4.2.2.5.1 illustrates the procedure
EMBED Word.Picture.8
Figure 4.2.2.5.1
4.2.2.6 EPC Domain starting mechanisms
In a MME or a SGW, a Trace Recording Session should start after the reception of a Trace Session Activation from EM and if any of the defined start triggering events occur. During the Trace Recording Session, the MME or the SGW shall record those signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter defines whether entire signalling messages or just some IEs need to be recorded.
The IMSI and IMEISV shall be available in the MME and in the SGW for at least those connections which shall be traced.
The MME or the SGW may not start a Trace Recording Session if there are insufficient resources available for the recording.
If the MME or the SGW receives the Trace Session Activation during an established session (e.g. during an active PDP context), it may start the Trace Recording Session immediately. However, if any of the start triggering events occur in the MME or the SGW after receiving the Trace Session Activation, it shall start the Trace Recording Session.
When a Trace Recording Session is started, the MME or the SGW shall assign a Trace Recording Session Reference for the Trace Recording Session.
4.2.3 Starting a trace recording session - signalling based
4.2.3.1 UTRAN starting mechanisms
In an RNC the Trace Recording Session will always be the same as the Trace Session as no triggering events are defined in UTRAN. Therefore a Trace Recording Session should be started in an SRNC when the SRNC receives the CN_INVOKE_TRACE message from the Core Network and if some activities have been started on the interfaces that have been requested to be traced. If the SRNC receives a second CN_INVOKE_TRACE message from the CN with the same Trace Reference that have been received in the first CN_INVOKE_TRACE message, a new Trace Recording Session should not be started as it is already started.
The CN_INVOKE_TRACE message that is received from the Core Network (MSC Server or SGSN) contains the following information:
Trace Reference
UE identity (IMSI or IMEI(SV)
Trace Recording Session Reference
Trace Depth
List of interfaces for RNC
If the SRNC does not have enough resources it may not start a Trace Recording Session.
The Trace Recording Session Reference shall be the same as received in the CN_INVOKE_TRACE message.
In a DRNC the Trace Recording Session should be started when the DRNC receives the IUR_INVOKE_TRACE message. If the DRNC does not have enough resources it may not start a Trace Recording Session.
The Trace Session is activated to the RNC by sending a CN_INVOKE_TRACE message from the CN (MSC Server or SGSN). When RNC receives the CN_INVOKE_TRACE message it should immediately start a Trace Session and a Trace Recording Session according to the trace control and configuration parameters received in the CN_INVOKE_TRACE message.
If there are not enough resources in RNC to start a Trace Recording Session, the RNC may reject to start a Trace Recording Session. However the RNC shall start the Trace Session.
In the case RNC receives multiple CN INVOKE TRACE messages for the same subscriber or equipment (e.g. simultaneous CS/PS connections):
If the Trace Reference is equal to an existing one, a new trace session and trace recording session shall not be started;
If the Trace Reference is not equal to an existing one, a new trace session and trace recording session may be started.
The following figure shows an example for a CS call how the Trace Session is activated to RNC. In the example it is assumed that there is no PS connection at all during the CS call.
EMBED Visio.Drawing.5
Figure 4.2.3.1.1: Starting a Trace Recording Session (Signalling) in UTRAN
Interaction with soft-handovers
If the subscriber or equipment, which is traced, makes a soft handover the SRNC should propagate the trace control and configuration parameters further to the DRNC by using the IUR_INVOKE_TRACE message. When the DRNC receives the IUR_INVOKE_TRACE message it should immediately start a Trace Session and a Trace Recording Session according to the trace control and configuration parameters received in the IUR_INVOKE_TRACE message.
If there are insufficient resources in the DRNC, the DRNC may not start a Trace Recording Session.
The Trace Recording Session Reference sent by the SRNC to the DRNC shall be the same what SRNC has received in the CN_INVOKE_TRACE message from the CN.
Interaction with Relocation
If the tracing shall continue also after the relocation has been performed, the CN Invoke Trace procedure shall be re-initiated from the CN towards the future SRNC after the Relocation Resource Allocation procedure has been executed successfully.
4.2.3.2 PS Domain starting mechanisms
In SGSN/GGSN/BM-SC a Trace Recording Session should start after the reception of a Trace Session Activation message (in SGSN it is the MAP-ACTIVATE_TRACE_MODE, in GGSN it is the GTP-Create PDP Context request or Update PDP Context request, in BM-SC it is the Diameter Gmb AAR message) and if any of the defined start triggering events occur. During the Trace Recording Session, the SGSN/GGSN/BM-SC shall record the signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter defines whether entire signalling messages or just some IEs need to be recorded.
The SGSN/GGSN/BM-SC may not start a Trace Recording Session if there are insufficient resources available for the recording.
In case of an established session, the SGSN may start the Trace Recording Session immediately after the reception of the Trace Session Activation message. However, if any of the start triggering events occurs in SGSN after receiving the Trace Session activation message, it shall start the Trace Recording.
When a Trace Recording Session is started in SGSN, it shall assign a Trace Recording Session Reference for the Trace Recording Session. When the SGSN propagates the Trace control and configuration parameters to GGSN or to UTRAN (I.e. activates a Trace Session in GGSN/UTRAN), it shall include the assigned Trace Recording Session Reference in the Trace Session Activation message. When an SGSN starts a Trace Recording Session and the list of NE types parameter requires GGSN tracing, it shall send the GTP- Update PDP Context Request or Create PDP Context Request message for activating the Trace Session to GGSN. When a GGSN starts a Trace Recording Session and the list of NE types parameter requires BM-SC tracing, it shall send a Diameter Gmb AAR message to the BM-SC in order to activate a Trace Session in the BM-SC. Also, when an SGSN starts a Trace Recording Session and the list of NE types parameter requires RNC tracing, it shall send the CN_INVOKE_TRACE message to the RNC in order to activate a Trace Session in RNC. In both cases the Trace Session and the Trace Recording Session in the receiving NE should start at the same time.
In case of SRNS relocation the SGSN shall send the CN_INVOKE_TRACE message to the new SRNC after the successful Relocation Resource Allocation procedure.
SGSN has to find the identity of the mobile before it activates a Trace Session towards other NE. The IMEI(SV) can be got from the Mobile by using the Identification procedure on the Iu interface.
When the SGSN sends the Trace Session activation (CN_INVOKE_TRACE) message to RNC it shall include the following parameters to the message:
IMSI or IMEI (SV) (M).
Trace reference (M).
Trace Recording Session Reference (M).
Trace Depth (M).
List of interfaces (O).
4.2.3.3 CS Domain starting mechanisms
In MSC Server/MGW a Trace Recording Session should start after the reception of a Trace Session Activation message (MAP-ACTIVATE TRACE MODE in MSC Server and ADD/MOD command with Trace package in MGW) and if any of the defined start triggering events occur. During the Trace Recording Session the MSC Server/MGW shall record the signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter defines whether entire signalling messages or just some IEs need to be recorded.
The MSC Server may not start a Trace Recording Session if there are insufficient resources available for the recording.
In case of an established call, the MSC Server may start the Trace Recording Session immediately after the reception of the MAP-ACTIVATE_TRACE_MODE message. However, if any of the start triggering events occur in the MSC Server after receiving the Trace Session activation message, it shall start the Trace Recording Session.
When a Trace Recording Session is started in MSC Server, it shall assign a Trace Recording Session Reference for the Trace Recording Session. When the MSC Server propagates the Trace control and configuration parameters to MGW or to UTRAN (I.e. activates a Trace Session in MGW/UTRAN) it shall include the assigned Trace Recording Session Reference in the Trace Session Activation message.
When an MSC Server starts a Trace Recording Session and the list of NE types parameter requires MGW tracing, it shall send the ADD/MOD command with trace package to MGW in order to activate the trace in MGW. Also, when an MSC Server starts a Trace Recording Session and the list of NE types parameter requires RNC tracing, it shall send the CN_INVOKE_TRACE message to the RNC. In both cases the Trace Session and the Trace Recording Session in the receiving NE should start at the same time.
MSC Server has to find the identity of the mobile before it activates a Trace Session towards other NE. The IMEI(SV) can be got from the Mobile by using the Identification procedure on the Iu interface.
In case of SRNS relocation the MSC Server shall send the CN_INVOKE_TRACE message to the new SRNC after the successful Relocation Resource Allocation procedure. The following figure shows an example how the Trace Session is activated with CN_INVOKE_TRACE message in case of relocation.
EMBED Visio.Drawing.5
Figure 4.2.3.3.1: Starting a Trace Recording Session (Signalling) in CS Domain
When the new SRNC receives the CN_INVOKE_TRACE message it should start immediately a Trace Session and a Trace Recording session according to the trace control and configuration parameters received in the CN_INVOKE_TRACE message. The Trace Session shall automatically be deactivated in the old RNC when the Iu connection is released.
When the MSC Server sends the Trace Session activation (CN_INVOKE_TRACE) message to RNC it shall include the following parameters to the message:
IMSI or IMEI (SV) (M).
Trace reference (M).
Trace Recording Session Reference (M).
Trace Depth (M).
List of interfaces to trace (O).
4.2.3.4 Void
4.2.3.5 Void
4.2.3.5.1 Void
4.2.3.5.2 Void
4.2.3.5.3 Void
4.2.3.5.4 Void
4.2.3.6 E-UTRAN starting mechanism
In an eNB the Trace Recording Session will always be the same as the Trace Session as no triggering events are defined in eNB.
Tracing starts immediately at eNodeB upon reception of the trace control and configuration parameters. The eNodeB may not start a Trace Recording Session if there are insufficient resources available for the recording.
The Trace Recording Session shall be started at the eNB when it receives trace control and configuration parameters via one of the following messages:
via an S1-Initial Context Setup Request message from the MME in response to an S1-Initial UE Message
via an S1-Trace Start message from the MME in response to an S1-Initial UE Message or when an established S1AP connection exists
via an S1-Handover Request message from the target MME as part of intra/inter-MME handover procedures via S1
via an X2-Handover Request message from a source eNodeB as part of inter-eNodeB handover procedures via X2
4.2.3.7 EPC starting mechanisms
In MME/SGW/PGW a Trace Recording Session should start after the reception of a Trace Session Activation message and if any of the defined start triggering events occur. During the Trace Recording Session, the MME/SGW/PGW shall record the signalling messages in the interfaces that are defined in the list of interfaces parameter. The Trace Depth parameter defines whether entire signalling messages or just some IEs need to be recorded.
The MME/SGW/PGW may not start a Trace Recording Session if there are insufficient resources available for the recording.
In case of an established session, the MME/SGW/PGW may start the Trace Recording Session immediately after the reception of the trace control and configuration parameters. However, if any of the start triggering events occurs in MME/SGW/PGW after receiving the trace control and configuration parameters, it shall start the Trace Recording Session.
When a Trace Recording Session is started in MME, it shall assign a Trace Recording Session Reference for the Trace Recording Session. When the MME propagates the Trace control and configuration parameters to E-UTRAN (I.e. activates a Trace Session in eNB), it shall include the assigned Trace Recording Session Reference in the Trace Session Activation message.
Also, when an MME starts a Trace Recording Session and the list of NE types parameter requires eNB tracing, it shall propagate the trace control and configuration parameters including the Trace Recording Session Reference via the S1 interface to the eNodeB per one of the following messages:
if an S1 connection exists, via the S1-Trace Start message
if the S1 connection doesnt exist, via the S1-Trace Start message prior to S1 connection setup or downlink NAS transport, or via the S1-Initial Context Setup Request message during S1 connection setup
during intra/inter-MME handover via S1-Handover Request message
for the cases when neither of the above conditions(1-3) is met, e.g. successful TAU without active flag, and some failed procedures (like TAU failure, Attach failure) for which S1-Initial Context Setup Request is not sent to the eNB, via an S1-DOWNLINK NAS TRANSPORT message
In both cases the Trace Session and the Trace Recording Session in the receiving NE should start at the same time.
4.2.4 Stopping a trace recording session - management based
4.2.4.1 UTRAN stopping mechanisms
Editor's Note: The Trace Recording Session in the RNC shall be stopped when the last connection, which belongs to the traced subscriber/mobile, is released.
4.2.4.2 PS Domain stopping mechanisms
In SGSN, GGSN and BM-SC a Trace Recording Session shall be stopped when any of the defined stop triggering events occur. If Trace Session deactivation is received during the Trace Recording Session, the SGSN is allowed to finish tracing of the on-going procedures (e.g. session). In this case the Trace Recording Session shall be stopped between the reception of the Trace Session deactivation and the appropriate stop-triggering event.
The following figure illustrates the successful case in tracing a PDP context when a Trace Recording Session is stopped.
EMBED Word.Picture.8
Figure 4.2.4.2.1: Stopping a Trace Recording Session for a PDP Context (Management Based) - PS domain
The following figure illustrates the successful case in tracing a MBMS context when a Trace Recording Session is stopped.
EMBED Word.Picture.8
Figure 4.2.4.2.2: Stopping a Trace Recording Session for a MBMS Context (Management Based) - PS domain
4.2.4.3 CS Domain stopping mechanisms
In MSC Server a Trace Recording Session shall be stopped when any of the defined stop triggering events occur. If Trace Session deactivation is received during the Trace Recording Session, the MSC Server is allowed to finish tracing of the on-going procedures (e.g. calls). In this case the Trace Recording Session shall be stopped in MSC Server between the reception of the Trace Session deactivation and the appropriate stop-triggering event.
The following figure illustrates the successful case in tracing a call and the time of stopping a Trace Recording Session.
EMBED Word.Picture.8
Figure 4.2.4.3.1: Stopping a Trace Recording Session (Management Based) - CS domain
4.2.4.4 IP Multimedia Subsystem stopping mechanismsVoid
Editor's Note: For further study.
4.2.4.5 E-UTRAN stopping mechanisms
The Trace Recording Session in the eNodeB shall be stopped when the call/session is ended in the cell under trace or the call/session is haneded over to another cell. If the Trace Session is deactivated at a time when there are ongoing sessions the trace recording session may be stopped immediately or gracefully when the session ends.
4.2.4.6 EPC Domain stopping mechanisms
In MME and SGW a Trace Recording Session shall be stopped when any of the defined stop triggering events occur. If Trace Session deactivation is received from its EM during the Trace Recording Session, the MME and the SGW are allowed to finish tracing of the on-going procedures (e.g. session). In this case the Trace Recording Session shall be stopped between the reception of the Trace Session deactivation and the appropriate stop-triggering event.
4.2.5 Stopping a trace recording session - signalling based
4.2.5.1 UTRAN stopping mechanisms
In an RNC the Trace Recording Session will always be the same as the Trace Session as no triggering events are defined in UTRAN. Therefore a Trace Recording Session shall always be stopped in an RNC when the RNC deactivates the Trace Session. For more information on Trace Session deactivation in UTRAN see subclause 4.1.4.2.
4.2.5.2 PS Domain stopping mechanisms
A Trace Recording Session shall be stopped when the SGSN/GGSN/BM-SC detect any of the stop triggering events.
However, if a SGSN receives a Trace Session deactivation either from its EM (in case of tracing roaming subscribers) or from HSS (in case of tracing home subscribers) during an ongoing Trace Recording Session, it may stop it immediately or at any time until the occurrence of an appropriate stop-triggering event.
A GGSN shall stop a Trace Recording Session when it receives a Trace Session deactivation message (GTP- Update PDP Context Request and Trace Activity Control is set to Trace Deactivation )from the SGSN or at any time until the occurrence of an appropriate stop-triggering event.
A BM-SC shall stop a Trace Recording Session when it receives a Diameter Gmb STR message from the GGSN or at any time until the occurrence of an appropriate stop-triggering event.
When a Trace Recording Session is stopped in a SGSN, the SGSN shall send a Trace Session deactivation message to the NEs where tracing was required, as defined in the "List of NE types" configuration parameter, received in the Trace Session activation message. The Trace Reference, used for the deactivation procedure, shall be the same as used in the SGSN for the activation of the Trace Session.
The following figure illustrates a successful case in tracing a PDP context, when a Trace Recording Session is stopped. (Reference 3GPP TS 23.060 [6].)
EMBED Visio.Drawing.6
NOTE: The activation to SGSN can come from EM-SGSN (in the figure just EM) or from the HSS.
Figure 4.2.5.2.1: Stopping a Trace Recording Session for a PDP Context (Signalling based) - PS domain
The following figure illustrates a successful case in tracing a MBMS context, when a Trace Recording Session is stopped. (Reference 3GPP TS 23.246 [9].)
EMBED Word.Picture.6
Figure 4.2.5.2.2: Stopping a Trace Recording Session for a MBMS Context (Signalling based) - PS domain
4.2.5.3 CS Domain stopping mechanisms
A Trace Recording Session shall be stopped when the MSC Server and MGW detect any of the stop triggering events.
However, if a MSC Server receives a Trace Session deactivation either from its EM (in case of tracing roaming subscribers) or from HSS (in case of tracing home subscribers) during an ongoing Trace Recording Session, it may stop it immediately or at any time until the occurrence of an appropriate stop-triggering event.
A MGW shall stop a Trace Recording Session when it receives a MOD command with trace package (indicating Trace Deactivation) from the MSC Server or at any time until the occurrence of an appropriate stop-triggering event.
When a Trace Recording Session is stopped in a MSC Server, the MSC Server shall send a Trace Session deactivation message to the NEs where tracing was required, as defined in the "List of NE types" configuration parameter, received in the Trace Session activation message. The Trace Reference, used for the deactivation procedure, shall be the same as used in the MSC Server for the activation of the Trace Session.
The following figure illustrates a successful case in tracing a call, when a Trace Recording Session is stopped. (Reference 3GPPTS 23.205 [7] and 3GPP TS 23.108 [8].)
EMBED Word.Picture.8
Figure 4.2.5.3.1: Stopping a Trace Recording Session (Signalling based) - CS domain
4.2.5.4 Void
4.2.5.5 Void
4.2.5.5.1 Void
4.2.5.5.2 Void
4.2.5.5.3 Void
4.2.5.6 Void
4.2.5.7 E-UTRAN stopping mechanisms
In an eNB the Trace Recording Session will always be the same as the Trace Session as no triggering events are defined in E-UTRAN. Therefore a Trace Recording Session shall always be stopped in an eNB when the eNB deactivates the Trace Session. For more information on Trace Session deactivation in E-UTRAN, see subclause 4.1.4.8.
4.2.5.8 EPC Domain stopping mechanisms
A Trace Recording Session shall be stopped when the MME/SGW/PGW detect any of the stop triggering events. Detection of a stop trigger event results in MME/SGW/PGW immediately stopping the trace recording session.
However, if an MME receives a Trace Session deactivation either from its EM (in case of tracing roaming subscribers) or from HSS (in case of tracing home subscribers) during an ongoing Trace Recording Session, it may stop it immediately or at any time until the occurrence of an appropriate stop-triggering event.
When a Trace Recording Session is stopped in an MME, the MME shall send a S1-Deactivate Trace message to the eNB where tracing was required, as defined in the "List of NE types" configuration parameter, received in the Trace Session activation message. The Trace Reference, used for the deactivation procedure, shall be the same as used in the MME for the activation of the Trace Session. This only applies to the eNB as the PGW and SGW have their own triggering criteria.
5 Trace control and configuration parameters
5.1 Triggering events (M)
This mandatory parameter defines when to start a Trace Recording Session and which message shall be recorded first, when to stop a Trace Recording Session and which message shall be recorded last respectively. The messages in the start triggering event tables indicate the transaction to be recorded first and the starting time of the Trace Recording Session within a Trace Session for the traced MS/subscriber in the given NE.
The messages in the stop triggering event tables indicate the transaction to be recorded last and the stopping time of the Trace Recording Session.
MSC ServerStart triggering eventsStop triggering eventsMobile Originated CallReceipt of the CM SERVICE-REQUEST message with service type set to originating call establishmentReception of CC-RELEASE COMPLETE or CM-SERVICE ABORT messageMobile Terminated CallSending of PAGING REQUEST messageReception of CC-RELEASE COMPLETE or CM-SERVICE ABORT messageMobile Originated SMSReceipt of the CM SERVICE-REQUEST message with service type set to Short Message serviceTransmission of RP-ACK/RP-NACK messageMobile Terminated SMSSending of PAGING REQUEST messageReception of RP-ACK/RP-NACK messageIMSI AttachReceipt of the MM-LOCATION UPDATING REQUEST messageSending of MM-LOCATION-UPDATING ACCEPT or MM-LOCATION-UPDATING-REJECT messageLocation UpdateReceipt of the MM-LOCATION UPDATING REQUEST messageSending of MM-LOCATION-UPDATING ACCEPT or MM-LOCATION-UPDATING-REJECT messageIMSI DetachReceipt of the MM-IMSI DETACH INDICATION messageReception of MM-IMSI DETACH INDICATION messageHandoverReceipt of the BSSMAP-HANDOVER-REQUIRED message in case of GSM or RANAP-RELOCATION-REQUIRED message in case of UMTSReception of BSSMAP-CLEAR COMPLETE message in case of GSM or RANAP-IU RELEASE COMPLETE message in case of UMTS or BSSMAP-HANDOVER FAILURE in case of GSM or RANAP-RELOCATION FAILURE in case of UMTS.Supplementary ServiceTBDTBD
MGWStart triggering eventsStop triggering eventsContext Reception of H.248-ADD command, or reception of H.248 MODIFY commandSending of H.248- SUBTRACT reply
SGSNStart triggering eventsStop triggering eventsPDP Context Reception of SM-ACTIVATE PDP CONTEXT REQUEST or sending SM-REQUEST PDP CONTEXT ACTIVATION or reception of SM- MODIFY PDP CONTEXT REQUESTReception or sending of SM- DEACTIVATE PDP CONTEXT REQUEST or sending SM-ACTIVATE PDP CONTEXT REJECTMobile Originated SMSReceipt of RP-DATA messageTransmission of RP-ACK/RP-NACK messageMobile Terminated SMSTransmission of RP-DATA messageReception of RP-ACK/RP-NACK messageGPRS AttachReception of MM-ATTACH-REQUESTSending MM-ATTACH-ACCEPT or MM-ATTACH-REJECTRouting Area UpdateReception of MM-ROUTING AREA UPDATE REQUESTSending MM-ROUTING AREA UPDATE ACCEPT or MM-ROUTING AREA UPDATE REJECTGPRS DetachReception MM-DETACH REQUESTReception of MM-DETACH ACCEPTMBMS ContextSending SM-Request MBMS Context Activation or reception of SM-Update MBMS Context RequestSending of SM-Deactivate MBMS Context Request or sending of SM-Activate MBMS Context Reject
GGSNStart triggering eventsStop triggering eventsPDP Context Reception of GTP Create PDP context request or reception of GTP Update PDP context requestSending of GTP Delete PDP context responseMBMS ContextReception of GTP Create MBMS Context Request or reception of GTP Update MBMS Context RequestSending of GTP Delete MBMS Context Response
IMS Network ElementStart triggering eventsStop triggering eventsSIP session or standalone transactionReception of an initial SIP request that matches the start trigger event configured by the Management System via the Trace IRP TS 32.442 [24]Sending of a SIP final response to a SIP BYE or other request (originating or terminating), timer expiry or other event that matches the stop trigger event configured by the Management System via the Trace IRP TS 32.442 [24].
BM-SCStart triggering eventsStop triggering eventsMBMS Multicast service activationReception of MBMS Authorization RequestReception of Deactivation Indication for user deactivation or sending of Session Stop Request for service deactivation
MME Start triggering eventsStop triggering eventsService request Reception of NAS: Service Request message or S11: Downlink Data NotificationReception of S11: Modify Bearer Response or sending of NAS: SERVICE REJECT UE initiated PDN connectivityReception of NAS: PDN connectivity Request message Reception of S11: Create Session ResponsemessageInitial Attach, Tracking area update, DetachInitial Attach: Reception of the NAS: ATTACH REQUEST
Tracking Area Update: Reception of the NAS: TRACKING AREA UPDATE REQUEST
Detach: Reception of the NAS: DETACH REQUEST or Detach Notification or Cancel Location.
Note: Cancel location location shall not trigger new Trace Recording Session if it is sent as part of the tracking area update procedure.Initial Attach: Reception of the NAS: ATTACH COMPLETE or sending of the NAS: ATTACH REJECT
Tracking Area Update: Reception of the NAS: TRACKING AREA UPDATE COMPLETE or sending of NAS: TRACKING AREA UPDATE REJECT
Detach: Reception or sending of NAS: DETACH ACCEPTUE initiated PDN disconnectionSending of the S11: Delete Session Request
Note: The S11 Delete Session Request message shall not start a new Trace Recording Session if this message is sent as part of the Attach/Tracking Area Update/Detach/Handover procedures.Reception of S11: Delete Session Response
Note: The S11 Delete Session Response message shall not stop the Trace Recording Session if this message is sent as part of the Attach/Tracking Area Update/Detach/Handover proceduresBearer Activation/Modification/DeactivationBearer Activation: Reception of S11: Create Bearer Request or NAS: BEARER RESOURCE MODIFICATION REQUEST
Bearer Modification: Sending of S11: Modify Bearer Request or reception of S11: Update Bearer Request
Bearer Deactivation: Reception of S1AP: SAE Bearer Release Resource or NAS: BEARER RESOURCE MODIFICATION REQUESTBearer Activation: Sending of S11: Create Bearer Response
Bearer Modification: Reception of S11: Modify Bearer Response or sending of S11: Update Bearer Response
Bearer Deactivation: Sending of S11: Delete Bearer ResponseHandoverInter-eNB/Intra-MME: Reception of S1AP: Path Switch Request
Inter-eNB/Inter-MME: Reception of S1AP: Handover Required or S10: Forward Relocation RequestInter-eNB/Intra-MME: Sending of S1AP: Path Switch Request Acknowledge or S1AP: Path Switch Request Failure
Inter-eNB/inter-MME: Sending of S10: Forward Relocation Complete Acknowledge or S1AP: Handover Preparation Failure or S1AP: Handover Cancel Acknowledge
SGW Start triggering eventsStop triggering eventsPDN connection creationReception of the S11: Create Session RequestSending of the S11: Create Session ResponsePDN connection terminationReception of the S11: Delete Session RequestSending of the S11: Delete Session ResponseBearer Activation/Modification/DeactivationBearer Activation: Reception of the S5: Create Bearer Request or S11: Bearer Resource Command
Bearer Modification: Reception of the S11: Modify Bearer Request or S5: Update Bearer Request
Bearer Deletion: Reception of the S11: Deactivate Bearer Command or S5: Delete Bearer RequestBearer Activation: Sending of the S5: Create Bearer Response
Bearer Modification: Sending of the S11: Modify Bearer Response or S5: Update Bearer Response
Bearer Deletion: Sending of S5: Delete Bearer Response
PGWStart triggering eventsStop triggering eventsPDN connection creationReception of S5(GTP): Create Session Request or Proxy Binding Update Sending of S5: Create Session Response or Proxy Binding Update AckPDN connection terminationReception of the S5: Delete Session Request or Proxy Binding UpdateSending of the S5: Delete Session Response or Proxy Binding Update ACK
Bearer Activation/Modification/Deactivation
Note: this is applicable only to GTP based S5 interface.Bearer Activation: Sending of the S5: Create Bearer Request
Bearer Modification: Reception of the S5: Modify Bearer Request or sending of the S5: Update Bearer Request
Bearer Deletion: Reception of the S5: Deactivate Bearer Command or sending of S5: Delete Bearer RequestBearer Activation: Reception of the S5: Create Bearer Response
Bearer Modification: Sending of the S5: Modify Bearer Response or reception of the S5: Update Bearer Response
Bearer Deletion: Reception of the S5: Delete Bearer Response
Bit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1MSC ServerMGWSGSNGGSNBM-SCMMEPGWSGW
MSC ServerBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1sparespareSSHandoversLU, IMSI attach, IMSI detachMO and MT SMSMO and MT callsspare
MGWBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1sparespareContext
SGSNBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1spareMBMS ContextRAU, GPRS attach, GPRS detachMO and MT SMSPDP contextReserved
GGSNBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1spareMBMS ContextPDP Context
MMEBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1spareSpareHandoverBearer
Activation
Modification
DeletionUE initiated PDN disconnectionInitial Attach, Tracking area update, DetachService requestsUE initiated PDN connectivity request
PGWSGWBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1spareBearer
Activation
Modification
DeletionPDN connection terminationPDN connection creationSpareBearer
Activation
Modification
DeletionPDN connection terminationPDN Connection creation
If a bit is set to 1 the given event shall be traced, i.e. a Trace Recording Session shall be started for that event.
If a bit is set to 0 the given event should not be traced, i.e. Trace Recording Session should not be started.
5.2 Void
5.3 Trace Depth (M)
This mandatory parameter defines how detailed information should be recorded in the Network Element. The Trace Depth is a paremeter for Trace Session level, i.e., the Trace Depth is the same for all of the NEs to be traced in the same Trace Session.
The following table describes the values of the Trace Depth parameter.
Trace DepthMeaningMinimumRecording of some IEs in the signalling messages plus any vendor specific extensions to this definition, in decoded format. MediumRecording of some IEs in the signalling messages together with the radio measurement IEs plus any vendor specific extensions to this definition, in decoded format. MaximumRecording entire signalling messages plus any vendor specific extensions to this definition, in encoded format. MinimumWithoutVendorSpecificExtensionRecording of some IEs in the signalling messages in decoded format. MediumWithoutVendorSpecificExtensionRecording of some IEs in the signalling messages together with the radio measurement IEs in decoded format. MaximumWithoutVendorSpecifcExtensionRecording entire signalling messages in encoded format.
At least one of Minimum, Medium or Maximum trace Depth shall be supported depending on the NE type (see trace record description in TS 32.423 [3] for details).
Trace depth shall be an enumerated parameter with the following possible values:
0 Minimum,
1 Medium
2 Maximum
3 MinimumWithoutVendorSpecificExtension
4 MediumWithoutVendorSpecificExtension
5 - MaximumWithoutVendorSpecificExtension
5.4 List of NE types (M)
This mandatory parameter defines the Network Element types where Trace Session activation is needed. This parameter has meaning only in the signalling based activation mechanism and it is used to determine whether the Trace Session Activation shall be propagated further to other Network Elements. In the management based activation mechanism, and in the signalling based activation mechanism for IMS, this parameter is not needed.
The following list contains the Network Element types:
MSC Server
MGW
RNC
SGSN
GGSN
BM-SC
MME
SGW
PDN GW
eNB
Bit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1SGWMMEBM-SCRNCGGSNSGSNMGWMSC-SspareeNBPDN GW
If a bit is set to 1, Trace Session to that Network Element shall be activated.
If a bit is set to 0, Trace Session is not needed in that Network Element.
5.5 List of interfaces (O)
This is an optional parameter, which defines the interfaces to be recorded in the Network Element.
The following list contains the list of interfaces in each Network Element:
MSC Server: A, Iu-CS, Mc and MAP (G, B, E, F, D, C) interfaces, CAP.
MGW: Mc, Nb-UP, Iu-UP.
RNC: Iu-CS, Iu-PS, Iur, Iub and Uu interfaces.
SGSN: Gb, Iu-PS, Gn, MAP (Gr, Gd, Gf), CAP (Ge), Gs, S6d, S4, S3 interfaces.
GGSN: Gn, Gi and Gmb interfaces.
S-CSCF: Mw, Mg, Mr and Mi interfaces.
P-CSCF: Gm and Mw interfaces.
I-CSCF: Cx, Dx, Mg, Mw.
MRFC: Mp, Mr.
MGCF: Mg, Mj, Mn.
IBCF: Ix, Mx.
E-CSCF: Mw, Ml, Mm, Mi/Mg.
BGCF: Mi, Mj, Mk.
AS: Dh, Sh, ISC, Ut.
HSS: MAP (C, D, Gc, Gr), Cx, S6d interfaces, S6a and location and subscription information.
BM-SC: Gmb interface.
MME: S1-MME, S3, S6a, S10, S11
SGW: S4, S5, S8, S11, Gxc
PDN GW: S2a, S2b, S2c, S5, S6b, Gx, S8, SGi
eNB: S1-MME, X2, Uu
NOTE: For IMS Network Elements other than P-CSCF and S-CSCF the interfaces included in the Trace Job for a particular type of IMS session are configured in the Management System via the Trace IRP (TS 32.442) [24].
Editor's note: The S13 interface for MME is FFS.
Bit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1MSC ServerMGWSGSNGGSNRNCBM-SCMMESGWPDN GWeNB
MSC ServerBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1CAPMAP-FMAP-EMAP-BMAP-GMcIuAspareMAP-CMAP-D
SGSNBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1GeGsMAP-GfMAP-GdMAP-GrGnIuGbspareS3S4S6d
MGWBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1SpareIu-UPNb-UPMc
GGSNBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1spareGmbGiGn
RNCBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1SpareUuIubIurIu
BM-SCBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1spareGmb
MMEBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1SpareS11S10S6aS3S1-MME
SGWBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1SpareGxcS11S8bS5S4
PDN GWBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1SGiS8bGxS6bS5S2cS2bS2a
eNBBit 8Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1SpareUuX2S1-MME
If a bit is set to 1, the interface should be traced in the given Network Element.
If a bit is set to 0, that interface should not be traced in the given Network Element.
5.6 Trace Reference (M)
The Trace Reference parameter shall be globally unique, therefore the Trace Reference shall compose as follows:
MCC+MNC+Trace ID, where the MCC and MNC are coming with the Trace activation request from the EM/NM to identify one PLMN containing the EM/NM, and Trace ID is a 3 byte Octet String.
NOTE: Trace ID referred here is the same as Trace reference in previous releases
NOTE: The MCC+MNC being part of the Trace Reference from Rel-8 onwards (e.g. ignored by Rel-6 / Rel-7 UTRAN Network Elements), the uniqueness of the Trace Reference may not be guaranteed with Rel-6 / Rel-7 Network Element(s) involved in the Trace.
5.7 Trace Recording Session Reference (M)
This parameter shall be a 2 byte Octet String.
5.8 Trace Collection Entity Address
This parameter shall contain the address to the Trace Collection Entity. The address is an IP address.
5.9 IP Address of Trace Collection Entity (M)
This is a mandatory parameter which defines the IP address to which the Trace records shall be transferred. IPv4 and/or IPv6 address(es) may be signalled.
Annex A (normative):Trace failure notification file format
A.1 Global structure
See 3GPP TS 32.615 [27]
The following XML namespaces are potentially used in Trace failure notification XML files:
- traceFailureNotification.xsd (see A.5)
A.2 XML elements fileHeader and fileFooter
A.2.1 XML elements fileHeader
See 3GPP TS 32.615 [27]
A.2.2 XML element fileFooter
See 3GPP TS 32.615 [27]
A.3 Trace failure notification specific XML elements
See A.5.
A.4 Trace IRP XML File Name Conventions
For Trace failure notification XML File Name Conventions the generic file name definitions as specified by the FT IRP apply (see [28]).
A.5 Trace failure notification file XML schema
Annex B (informative):Change history
Change historyDateTSG#TSG Doc.CRRevSubject/CommentCatOldNewJun 2006SA_32SP-0602610021--Introduction of Service Level Tracing for IMSB6.5.07.0.0Sep 2006SA_33SP-0605520022--Add general mechanism for starting trace recording sessions at IMS Network Elements and UE - to support end-to-end Service Level Tracing for IMSB7.0.07.1.0Sep 2006SA_33SP-0605520023--Add definition of Service Level Tracing Start Triggering EventB7.0.07.1.0Sep 2006SA_33SP-0605520024--Clarification of Trace session deactivation mechanismF7.0.07.1.0Sep 2006SA_33SP-0605520025--Add sending of trace control and configuration parameters for service level tracingB7.0.07.1.0Sep 2006SA_33SP-0605520026--Add starting trace recording at IMS network elementsB7.0.07.1.0Sep 2006SA_33SP-0605520027--Add charging concepts for Service Level Tracing for IMSB7.0.07.1.0Sep 2006SA_33SP-0605520028--Add stopping trace recording mechanism for service level tracingB7.0.07.1.0Dec 2006SA_34SP-0607270029--Clarification to the sending of optional trace parametersF7.1.07.2.0Dec 2006SA_34SP-0607270030--Network initiated re-authentication for SLTB7.1.07.2.0Dec 2006SA_34SP-0607270031--Trace Session Deactivation at an IMS NEB7.1.07.2.0Dec 2006SA_34SP-0607270032--Service level trace processes at the UEB7.1.07.2.0Dec 2006SA_34SP-0607270033--Reception of SLT Start Trigger Event at an IMS NEB7.1.07.2.0Dec 2006SA_34SP-0607270034--Service level tracing for IMS starting mechanismB7.1.07.2.0Dec 2006SA_34SP-0607270035--Consistent usage of Service Level Tracing Start Triggering EventD7.1.07.2.0Dec 2006SA_34SP-0607270036--Retrieval of Trace Records from a UEB7.1.07.2.0Mar 2008SA_39SP-0800690037--Add Signalling Based Trace Activation procedures to EPC and E-UTRANB7.2.08.0.0Jun 2008SA_40SP-0802870038--Add definition of Trace control and configuration parameters for EPC and E-UTRANB8.0.08.1.0Jun 2008SA_40SP-0802870039--Add Trace Session deactivation proceduresB8.0.08.1.0Jun 2008SA_40SP-0802870040--Add procedures for starting/stopping a trace recording session in EPC and E-UTRANB8.0.08.1.0Sep 2008SA_41SP-0812110041--Providing subscriber identities for Cell Traffic Trace - ProceduresB8.1.08.2.0Dec 2008SA_42SP-0808460044-Identifying IMS network elements and interfaces for traceF8.2.08.3.0Dec 2008SA_42SP-0808460045-Trace starting and stopping trigger events for IMSF8.2.08.3.0Dec 2008SA_42SP-0808460042-Introduction of EPS in 32.422B8.2.08.3.0Dec 2008SA_42SP-0808460043-Fix inconsistencies in the definition of trace levels, trace reference parameterF8.2.08.3.0Mar 2009SA_43SP-0902070046-Refinement of the Trace ReferenceF8.3.08.4.0Mar 2009SA_43SP-0902070047-Enhancement of trigger events in 3GPP TS 32.423 - align with 29.274, 29.272F8.3.08.4.0Mar 2009SA_43SP-0902070048-Trace Session activation/deactivation to PGW in case of non-3GPP access networkB8.3.08.4.0Mar 2009SA_43SP-0902070049-Add reference and definitions for trace failure notifications in 32.422F8.3.08.4.0Mar 2009SA_43SP-0902070050-Use S1-DOWNLINK NAS TRANSPORT for the trace for TAU and some failed proceduresF8.3.08.4.0Mar 2009SA_43SP-0902070051-EPC signalling activation mechanismsF8.3.08.4.0Mar 2009SA_43SP-0902070052-EPC and E-UTRAN signalling deactivation mechanismsF8.3.08.4.0Mar 2009SA_43SP-0902070053- Add the missing PGW to EPC trace recording session stopping mechanismF8.3.08.4.0Jun 2009SA_44SP-0902890054-Corrections on XML file format of the trace failure notificationsF8.4.08.5.0Jun 2009SA_44SP-0902890055-Correcting Trace activation/deactivation flow to P-GW in case of PMIP based S5 interfaceF8.4.08.5.0Jun 2009SA_44SP-0902890056-Add missing Trace Interface listF8.4.08.5.0Sep 2009SA_45SP-09054257-Clarification on Trace depth levelF8.5.08.6.0Sep 2009SA_45SP-09054258-Alignment of EPS Trace with TS 36.413F8.5.08.6.0Sep 2009SA_45SP-09053461-Add reference to file format for sending IMSI/IMEI information from the MMEF8.5.08.6.0Sep 2009SA_45SP-09053462-Misleading statement on when cell traffic trace should be startedF8.5.08.6.0Dec 2010SA_50SP-10083175-Add missing interfaces S3, S4 and S6d in the interface table of SGSNF8.6.08.7.0June-2012SA_56SP-12036702021Correcting the Trace Recording Session stopping mechanism at eNBF8.7.08.8.0June 2013SA_60SP-1303020254-Remove IMS Service Level TraceA8.8.08.9.0
Change historyDateMeetingTDocCRRevCatSubject/CommentNew version2020-07SA#808eSP-20048803261FClean up of the editor notes8.10.0
STYLEREF ZA 3GPP TS 32.422 V8.910.0 (20132020-0607)
PAGE 18
STYLEREF ZGSM Release 8
3GPP
STYLEREF ZA 3GPP TS 32.422 V8.910.0 (20132020-0607)
PAGE 68
STYLEREF ZGSM Release 8
3GPP
EMBED Visio.Drawing.11
" # % & ' ( ) A e
/ 躥~vh^ hx mH nH sH j hx UmH nH sHhx B*ph j hx U
hx 6CJ
hx 0J "H hh|] CJ mH nH u ( hx h|] CJ cH dhmH nH u hx CJ mH nH u H hh|] mH nH u $ hx h|] cH dhmH nH u hx mH nH u hx CJ@ mH nH u hx ) A e 3 4 . $&@#$]^a$. $ &@#$&d P ]^a$ $a$ L $ a$ ;&P#$+Dd
; $
'+DAa$ : 9 8 / 0 1 2 3 4 h j
, / A J ^ _ v
ȸήΣήή}tttt hx mH nH uhx 56OJ QJ mH nH uhx CJ OJ QJ mHsH hx mHsH hx 56OJ QJ hx CJ OJ QJ hx mH nH u
hx CJ H*
hx CJ hx j hx UmH nH sHjb hx UmH nH sH!jɂL
hx UVmH nH tH + A J ^ _ v
t h . $=1&P#$+Da$. $ =1&P#$&d +DP a$ $a$ . $ &@#$]^a$. $ &@#$&d P ]^a$ . $&@#$]^a$. $&@#$&d P ]^a$ . $ &@#$]^a$
b
x
8 d ) t ! i M . =1&P#$+D . $=1&P#$+Da$
P
Q
R
S
U
V
W
b
x
M ] x # 2 3 4 5 6 7 8 E F G O ^ _ x $hx h+U OJ QJ aJ mH nH tH jj h+U Uh+U j h+U Uhx ( hx h|] CJ cH dhmH nH u "H hh|] CJ mH nH u "H hh|] CJ mH nH u ( hx h|] CJ cH dhmH nH u hx CJ mH nH u -_ ` a b c d e f l m n v
# $ % & ' ( ) , j2m h+U Ujl h+U Uj