The general high-level requirements for Trace, common to both Management activation/deactivation and Signalling Based Activation/Deactivation, are as follows:

• for the Maximum Level: Trace data encompassing all signalling messages on the different interfaces dedicated to the events of the traced subscriber or UE with their entire content (all IEs) shall be retrieved. The operator can then use an external system (e.g. an Operations System (OS) in TMN terminology) and decode specific information in line with operator requirements.
• for the Minimum Level: a selected subset of IEs shall be retrieved from the signalling interface messages. The Minimum Level provides support for the most common use cases (described in annex A).
• for the Medium Level: a selected Minimum Level subset of IEs from the signalling interface messages and a selected set of radio measurement IEs shall be retrieved.
• for the MaximumWithoutVendorSpecificExtension Level: it is the same as for Maximum level without vendor specific data.
• for the MediumWithoutVendorSpecificExtension Level: it is the same as for Medium level without vendor specific data.
• for the MinimumWithoutVendorSpecificExtension Level: it is the same as for Minimum level without vendor specific data.

The high-level requirements for Trace, specific for Service Level Tracing for IMS are as follows: The following high-level OMA Service Level Tracing requirements apply. (refer to OMA Service Provider Environment Requirements [9]).

• [SLT-HL-1] with the following clarification:
  • The OMA term OMA Service Provider Environment (OSPE) shall be understood as PLMN.
• [SLT-HL-5] with the following clarification:
  • In the context of Service Level Tracing for IMS a Minimum and Maximum level of detail of trace only applies. Trace data for Service Level Tracing at Minimum and Maximum level of detail shall include information associated to end user visible events
• [SLT-HL-6] with the following clarification:
  • The OMA term service chain shall be understood as the relationship between appropriate IMS elements needed to support a service. The term service chain does not imply a strict sequence of events.
  • The source of the logged trace information (e.g. IMS element including S-CSCF) shall be identifiable when the retrieved trace information is analyzed.
• [SLT-HL-10] with the following clarification:
  • IMS elements that do not support Service Level Tracing shall not prohibit the propagation of the Trace Parameter Propagation.
• [SLT-OSR-1
  • Multiple Service Level Trace instances shall be simultaneously supported by the PLMN and the UE (e.g. several services initiated from the same UE may each have a Trace Recording Session Reference)

The high level requirements for Trace data, common to both Management activation/deactivation and Signalling Based Activation/Deactivation, are as follows:

• The Trace records have to contain Information Elements or signalling messages from control signalling and/or the characteristics of the user data. The following list contains the Network Elements and the Traceable interfaces in the NEs where tracing is needed:
  • MSC Server: A, Iu-CS, Mc and MAP (G, B, E, F, D, C) interfaces; CAP
  • MGW: Mc, Nb-UP, Iu-UP
  • HSS: MAP (C, D, Gc, Gr) Cx, S6a, S6d, Sh, N70, N71 and NU1 interfaces and location and subscription information
  • EIR: MAP(F), S13, S13', MAP (Gf)
  • SGSN: Gb, Iu-PS, Gn, MAP (Gr, Gd, Gf), CAP (Ge) Gs, S6d, S4, S3 and S13' interfaces
  • GGSN: Gn, Gi and Gmb interfaces
  • S-CSCF: Mw, Mg, Mr and Mi interfaces
  • P-CSCF: Gm and Go interfaces
  • RNC: Iu-CS, Iu-PS, Iur, Iub and Uu interfaces
  • BM-SC: Gmb interface
  • eNB/en-gNB: S1-MME, X2, Uu, F1-C, E1
  • MME: S1-MME, S3, S6a, S10, S11, S13, N26
  • Serving Gateway: S4, S5, S8, S11
  • PDN Gateway: S2a, S2b, S2c, S5, S6b, Gx, S8, SGi
  • AUSF: N12, N13
  • AMF: N1, N2, N8, N11, N12, N14, N15, N20, N22, N26
  • NEF: N29, N30, N33
  • NRF: N27
  • NSSF: N22, N31
  • PCF: N5, N7, N15
  • SMF: N4, N7, N10, N11, S5-C
  • SMSF: N20, N21
  • UDM: N8, N10, N13, N21, NU1
  • UPF: N4
  • AF: N5, N33
  • ng-eNB: NG-C, Xn-C, Uu
  • gNB-CU-CP: NG-C, Xn-C, Uu, F1-C, E1, X2-C
  • gNB-CU-UP: E1
  • gNB-DU: F1-C
• A unique ID within a Trace Session shall be generated for each Trace Recording Session. This is called the Trace Recording Session Reference.

The high level requirements for Trace data applicable for Signalling Based Activation/Deactivation for Service Level Tracing for IMS, are as follows:

• In the context of Service Level Tracing for IMS Trace records have to contain Information Elements or signalling messages or end user visible event from control signalling and/or the characteristics of the user data. The following list contains the IMS NEs and the Traceable interfaces in the NEs where tracing is needed:
  • HSS: Sh and Cx interfaces and location and subscription information;
  • S-CSCF: ISC, Mw, Mg, Mr and Mi interfaces;
  • P-CSCF: Gm and Go interfaces;
  • I-CSCF: Mw and Cx interfaces;
  • SIP AS: ISC interface;
  • MRF: Mr interfaces;
  • MGCF: Mg interfaces;
  • BGCF: Mi interfaces;
• A unique ID within a Trace Session shall be generated for each Trace Recording Session. This is called the Trace Recording Session Reference. In the context of Service Level Tracing for IMS the Trace Recording Session shall be unique across all IMS NEs within a PLMN.

Changes to existing NEs and interfaces above may be required. These changes would be dependent upon various 3GPP working groups and possibly other non-3GPP industry groups for completion of Trace Session Activation/Deactivation. For a detailed description of NEs and interfaces above see TS 23.002.

The high level requirements for Trace Data reporting, common to both Management activation/deactivation and Signalling Based Activation/Deactivation, are as follows (Trace record contents, file formats and file transfer mechanisms are defined in TS 32.423):

• Trace records should be generated in each NE where a Trace Session has been activated and a Trace Recording Session has been started.
• Format of the Trace records shall be XML or GPB based on the Schema in TS 32.423.
• In UMTS or EPS trace, the trace records should be transferred on the Itf-N to the Network Manager using one of two approaches: direct transfer from NE to NM or transfer from NE to NM via EM.
• Trace records may also be transferred to an external IP address (received in Trace Control and Configuration Parameters) in 3 ways:
  1. Direct transfer from NE to IP address
  2. Transfer from NE to IP address via management system
  3. Transfer from NE to management system. The management system notifies the holder of the IP address that collects the files.
• The Trace Records in a shared node for a Participating Operator's trace request should be collected by the Primary Operator's NE and may be delivered through the Primary Operator's management system. The Trace records shall be made available to the Participating Operator's management system.

The high-level requirements for stopping a Trace Recording Session, specific for Service Level Tracing for IMS are as follows: The following high-level OMA Service Level Tracing requirements apply [9]. [SLT-HL-4] with the following clarification:

• Encoded trace information shall be Standard File Format. Standard File Format may not be applicable for encoded trace information at the UE.

[SLT-HL-7] with the following clarification:

• An instance of a service level trace across a PLMN shall be uniquely identifiable using the Trace Recording Session Reference.

[SLT-HL-8] [SLT-COM-1] with the following clarification:

• Time stamping alone to determine the sequence of IMS NEs performing trace within the service chain shall not be used;
• Statistical information shall not be included as part of IMS NE characteristics;
• Service Level Tracing shall apply only to the IMS session layer and not the underlying transport layers.

[SLT-COM-4] with the following clarification:

• An IMS NE, in addition to providing trace information specific to a service that it has traced, may also make available other information, for example, timestamp and throughput information.

[SLT-NI-1] with the following clarification:

• The UE shall expose a standardised interface for Trace Parameter Configuration and the retrieval of trace information. This interface may not be standardized by 3GPP.

[SLT-NI-2] with the following clarification:

• An IMS NE shall transfer Trace records in Standard File Formats.

The high-level requirements for Trace Data reporting in case of file-based trace reporting are as follows:

• For transfer of Trace records FTP or secure FTP shall be used.

The high-level requirements for Trace Data reporting in case of streaming trace reporting are as follows:

• The same connection between data producer and data consumer may be used for the reporting of Trace data under all Trace Recording Sessions of the same Trace Session reported by the same data producer.
• A connection from the data producer to the consumer shall be established and information about Trace Session shall be provided to the data consumer.
• Binary encoding shall be used for the transfer of all Trace data from data producer to the data consumer.
• The periodicity and amount of data in each data burst from data producer to data consumer shall maintain the data relevance while minimizing the amount of transport overhead.
• The data producer shall re-establish connection to the data consumer and provide the information about Trace Session upon unexpected connection termination (e.g. in cases such as re-start of data producer).
• It shall be possible to specify format of trace records based on GPB Schema in TS 32.423.

The high-level requirements for privacy and security, specific for Service Level Tracing for IMS are as follows: The following high-level OMA Service Level Tracing requirements apply [9]. [SLT-PRV-1] with the following clarification:

• Privacy shall be applied across the appropriate Trace Itf-N.

[SLT-SEC-1] [SLT-SEC-2] [SLT-SEC-3] with the following clarification:

• It may not be possible to retrieve Trace information from IMS NEs from outside the PLMN where the IMS NEs reside.

[SLT-IOP-1] with the following clarification:

• The propagation of the Trace Parameter Configuration and the Start Trigger event shall be prohibited by the PLMN when e.g. the SIP AS is hosted outside a PLMN.

As the radio access nodes in E-UTRAN are outside an operator's secure domain, the following requirement applies for E-UTRAN as described in TS 33.401: [SET-SEC-1] Keys stored inside eNBs shall never leave a secure environment within the eNB. When security key(s) transported on control signalling messages are included in the trace file, the key value(s) shall be removed and replaced with the value "Unavailable". As the radio access nodes in NG-RAN are outside an operator's secure domain, the following requirement applies for NG-RAN as described in TS 38.401: [SET-SEC-2] Keys stored inside NG-RAN node shall never leave a secure environment within the NG-RAN node. When security key(s) transported on control signalling messages are included in the trace file, the key value(s) shall be removed and replaced with the value "Unavailable". The high-level requirements for privacy and security in case of streaming trace reporting are as follows:

• The connection between data producer and data consumer shall provide the data privacy.
• The connection between data producer and data consumer shall provide the data integrity.

The high-level requirements for charging, specific for Service Level Tracing for IMS are as follows: The following high-level OMA Service Level Tracing requirements apply [9]. [SLT-CRG-1]

The operator can use Subscriber and UE Trace for numerous purposes. However, the use cases for Trace can be divided into two basic categories:

• Troubleshooting use cases cover situations where the operator is solving an existing problem in his network;
• Validation testing use cases cover situations where the operator is not solving a known problem but merely analysing, fine-tuning or optimising his network.

A more detailed description for the following use cases for Subscriber and UE Trace can be found in annex A:

• Interoperability checking between UE from different vendors;
• QoS profile checking for a subscriber after a subscriber complaint;
• Malfunctioning UE;
• Checking radio coverage in a certain area;
• Testing new features;
• Fine-tuning and optimisation of algorithms or procedures.

The operator can use Service Level Tracing for IMS for numerous purposes. However, the use cases for Trace can be divided into two basic categories:

• Troubleshooting use cases cover situations where the operator is solving existing problems with services offered to their subscribers.
• Validation testing use cases cover situations where the operator is not solving a known problem but performing service regression and automated service testing.

A more detailed description of the following use cases for Service Level Tracing can be found in annex A:

• Automated testing of service provider services;
• Regression testing following a network fix;
• Service fault localization within a Service Provider's network;
• Service fault localization when a service is hosted by a third party Service Provider.

The high-level requirements for throttled Trace Recording Session are as following:

• It shall be possible for the NE to start a throttled trace recording session if there are insufficient resources available within the NE.
• It shall be possible for the NE to indicate an ongoing trace recording session that is throttled if there are insufficient resources available within the NE.

The high-level requirements for clearing up a throttled Trace Recording Session are as following:

• It shall be possible for the NE to clear up a throttled trace recording session if there are sufficient resources available within the NE.