The aim of this use case is to check how different vendor's UEs are working (e.g. in field testing) in the mobile network or to get detailed information on the UE. The study can be started by an initiative from operator for verification of UE from different vendors (e.g. testing how the UE fulfils the requirements set by the standards). The operator can perform the test using test UEs or tracing subscribers' mobiles.

The Trace parameters required to cover use case #1 are listed below:

• Tracing is needed in the Radio Network (RNC) or in the Core Network (MSS, SGSN);
• The identification of the Trace case shall be IMEI or IMEISV (and possibly IMSI);
• The level of details usually is to get the most important IEs from the signalling messages (Medium Level) or all messages with their encoded IEs (Maximum Level).

The traceable protocols are:

• In RNC: RRC, NBAP, RNSAP, RANAP.
• In MSS/SGSN: DTAP messages.

The aim of this use case is to check how the complaining subscriber's services are working, to get information on the services in order to find out the reason for the complaint. The study can be started after a subscriber is complaining at his/her home or visited operator that some of the service to which he/she subscribed is not working. E.g. the subscriber:

• cannot make calls;
• cannot use some supplementary service;
• does not get the negotiated QoS level (e.g. Mobile subscriber activates video-streaming application to watch the latest sport events and every time the subscriber tries to connect to the service the system disconnects the subscriber's UMTS bearer).

As the Trace is activated for a subscriber, the signalling based Trace Session activation shall be used, as the location of the subscriber is not known.

The Trace parameters required to cover the use case #2 are listed below:

• The list of NEs where tracing may be needed depends on the service being complained about by the subscriber. For this use case, tracing should be possible in all network elements, such as: HSS, MSS, RNC, MGW, SGSN, GGSN.
• The identification of the subscriber in a Trace is IMSI in UTRAN/CS/PS. The identification of the UE in a Trace is IMEI or IMEISV.
• The data includes those Information Elements from the signalling messages, which are related to the service(s) being complained about by the subscriber (Medium Level).

Example cases, which can be the basis for subscriber complaint:

1. The subscriber's CS call is misrouted
   This illustrates an instance where a subscriber complains that his calls are being cross-connected (or misrouted). Such a complaint involves setting up a Trace at all the 3GPP standardised interfaces being handled by the MSC. However, the Trace functionality shall not cover MSC internal or vendor proprietary interfaces. The Trace record shall need to have the dialled number and connected number.
2. The subscriber's call is dropped
   Tracing data is required from the radio network (UTRAN) or from the core network (MSS, SGSN, GGSN). In the radio network the radio coverage shall be checked. See use case #4 (checking radio coverage). Beside the radio coverage, other information can be useful as well, like RLC parameter, power information (OLPC or RRC measurement report), error ratios (BLER / BER, SDU error ratio), etc. Tracing in the core network is needed also, if the problem is not in the radio network. E.g. in case of PS domain the call can be dropped by the application due to the long delays or congestions in TCP layer or due to bad QoS. Thus in SGSN the requested and negotiated QoS parameters should be included in the Trace record.
3. The received QoS level is less than the negotiated level.
   To be able to solve the possible problem Tracing data is required from HSS, SGSN, GGSN, and UTRAN. Furthermore in case of problem in CS calls tracing in MGW shall be performed.
   From HSS Trace data the operator can monitor whether the subscriber's authentication to the network is successful, and what kind of QoS parameters are allowed to the subscriber. From SGSN Trace data the operator can monitor PDP context creation request from mobile. Request seems to contain legal QoS profile (incl. Maximum bandwidth, guaranteed bandwidth etc) and the local resources in SGSN are available to provide the service as requested by the subscriber. From UTRAN Trace data the operator can monitor whether the maximum bandwidth and guaranteed bandwidth, requested by SGSN, acceptable for UTRAN. Thus to check whether UTRAN can provide and maintain the requested radio access bearer services. From GGSN Trace data the operator can monitor PDP context activation between SGSN and GGSN. If the problem is in the CS domain the MGW Trace can provide the QoS data.

The aim of this use case is to check a UE, which is not working correctly. The study can be initiated by the operator when he/she suspects that a UE not working according to the specifications or he/she would like to get more information on a specific UE, which is on the track or block EIR list.

The Trace parameters required to cover the use case #3 are listed below:

• UE Tracing may be needed in the Radio Network (UTRAN) or in the Core Network (MSS, SGSN).
• The identification of the subscriber in a Trace is IMSI. The identification of the UE in a Trace is IMEI or IMEISV.
• The level of details depends on the operator needs (either Minimum Level or Medium Level).

The malfunction of UE in UTRAN can occur in different places. The problem can be in basic RRC and RANAP signalling, Radio Bearer procedures, Handover procedures, Power control etc. Therefore, all RRC, RANAP, NBAP, RNSAP signalling procedures, transmission powers, error ratios (BLER / BER, SDU error ratio) and retransmission can be included in the Trace records.

This use case aims at checking the radio coverage on a particular network area. This study can be started by an initiative from operator for testing radio coverage on a particular geographical area following network extension for instance (e.g. new site installation). The operator can perform a drive test on the new site area, and check that radio coverage is correct, or may collect Cell Traffic Trace data on all of the cells active in the area of interest. The other options for collecting information on radio coverage is to collect RLF reports generated by the UE in an E-UTRAN network. .

The DL radio coverage can be checked using the values of CPICH Ec/No and RSCP measured by the mobile on the cells in the active set and the monitored set. These measurements are sent to the RNC trough the RRC message MEASUREMENT REPORT. For E-UTRAN the RLF reports contained in the UE Information Response message provide the radio condition in terms of RSRP and RSRQ values when the Radio Link failure happened together with a location information. The UTRAN Trace record intra frequency measurement contains the required information. The UTRAN Trace record inter frequency, and inter RAT measurements can also be used to check radio coverage with other frequencies or systems. After a network extension, the operator can check that Ec/No and RSCP levels on the new site area are the expected ones, and there is no coverage hole. The following Trace parameters are required to cover use case #4:

• The type of NE to Trace is RNC or eNB.
• The identification of the subscriber in a Trace is IMSI. The identification of the UE in a Trace is IMEI or IMEISV.
• In the case of a Cell Traffic Trace, the identification of the cells where Trace data is to be collected.
• In case of RLF report collection the list of eNodeBs where the RLF reports are collected.
• The Trace data to retrieve shall contain the messages with all IEs that are relevant for radio coverage.

This use case aims at testing the implementation of a new feature in the network before its general deployment. The functionality can be either a standard feature or a vendor/operator specific feature. This study is started by an initiative from the operator. The operator can perform a drive test on the area where the feature is introduced, and check its good behaviour as well as its benefits, in term of quality or capacity. He can also rely on subscribers' Trace data when they use the feature to be tested.

Depending on the feature, the list of NEs to Trace, as well as the level of details can be different. For a feature concerning Core and UTRAN networks, for instance hard handover, SRNS relocation, or new UMTS bearer service, the operator needs to activate Trace on several NEs. Then, the operator can be interested in:

• Only the protocol messages generated by the feature; or
• The impact of the new feature introduction on the network, for instance, the radio coverage, the capacity, the quality, or the behaviour of the existing algorithms.

In this last case, the operator needs more detailed data, for instance messages with all (Maximum Level) or part of the IEs (Minimum Level). The following Trace parameters are required to cover use case #5:

• The types of NEs to Trace are NEs that can be traced related to the feature.
• The identification of the subscriber in a Trace is IMSI. The identification of the UE in a Trace is IMEI or IMEISV.
• The Trace data to retrieve can be either only the protocol messages (Maximum Level) or the messages with all or part of the IEs (Minimum Level).

Subscriber and UE Trace is part of the optimisation process. Trace data are used to get feedback on the network quality and capacity after optimisation operations like parameter fine-tuning, or new network design. Each intervention to improve the network behaviour can be confirmed both by measurement data and Trace data. This study is started following an initiative from the operator. The operator can perform a drive test on the area and/or activate a Cell Traffic Trace where the optimisation has been performed, and check its good behaviour as well as its impact on the network. He can also rely on subscribers' Trace data when they use the network to be optimised.

Depending on the optimisation operation, the list of NEs to Trace, as well as the level of details can be different. But generally, fine-tuning activities like scrambling code plan, handover and relocation algorithms, or call admission algorithm optimisation concern a very specific part of the network. To cover this use case, the operator is usually searching for the highest level of details, on specific NEs. The following Trace parameters are required to cover use case #6:

• The types of NEs to Trace are any NE that can be traced related to the network to be optimised.
• The identification of the subscriber in a Trace is IMSI. The identification of the UE in a Trace is IMEI or IMEISV.
• In the case of a Cell Traffic Trace, the identification of the cells where Trace data is to be collected.
• The Trace data to retrieve are the messages in encoded format with all (Maximum Level) or part of the IEs (Minimum Level).

For a detailed description of this use-case see OMA Service Provider Environment Requirements [9].

For a detailed description of this use-case see OMA Service Provider Environment Requirements [9].

For a detailed description of this use-case see OMA Service Provider Environment Requirements [9].