Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 32.421  Word version:  19.0.0

Top   Top   Up   Prev   None
0…   4…   4.2   4.3   5…   6…   A…   A.10… 
A.10 Use case #10: Service fault localization when a service is hosted by a third party Service Provider  A.11 Use case #11 Analysing drop calls in E-UTRAN  A.12 Use case #12 Periodical sampling of network performance  A.13 Use case #13 Differentiation of management based MDT data by terminal type  A.14 Use case #14 Subscriber complaint about MBMS service in the eUTRAN network  A.15 Use case #15 Check MBMS service quality and performance of the eUTRAN Network  A.16 Use case #16 Collecting Cell and UE data for analytics  A.17 Use case #17 Collecting subscriber and equipment trace data for near-real-time diagnostics and troubleshooting  A.18 Use case #18 Collecting RRC reports for analytics  $ Change history 

 

A.10  Use case #10: Service fault localization when a service is hosted by a third party Service Provider |R12|  p. 42

A.10.1  Description  p. 42

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

A.11  Use case #11 Analysing drop calls in E-UTRAN |R11|  p. 43

A.11.1  Description  p. 43

One of the important KPIs in an operator's network is the call drop KPI. A call drop KPI is defined also in TS 32.450. The call drop KPI indicates in percentage of how many successfully established calls have been dropped. This is a crucial indicator about the quality of the network that has clear effects to the user experience.
Therefore one of the most important targets for operator is to minimize the value of the Call drop rate KPI. The root cause of a dropped call is typically a radio link failure or a handover failure. Both of these failures currently reported by the UE in the RLF reports, which additionally contain the radio conditions at the time the failure happened. Therefore the RLF reports are very important input for operators to determine the reasons for degradations in Call Drop KPI. In addition the RLF reports combines the radio conditions with location information, therefore it can serve as a valueable input for analysis how to decrease the Call Drop KPI.
Up

A.11.2  Example of required data to cover use case #11  p. 43

For further analysis of drop calls information is required about the radio conditions of the radio network when the drop calls happens. In E-UTRAN the ideal data can be collected by utilising the RLF reports defined in TS 37.320. RLF reports contain the RSRP and RSRQ values of the radio conditions at the time when the Radio Link Failure happens that can lead in most of the cases to a drop call. The RLF report contains also the time and location of the RLF event.
Up

A.12  Use case #12 Periodical sampling of network performance |R11|  p. 43

A.12.1 Description
For management purpose, an operator need to measure statistical network performance e.g. overall coverage status, overall voice call and data session performance and so on. The data collected could include measurements, such as Ec/No and RSCP for case of UMTS and RSRP and RSRQ for case of E-UTRAN, and statistical business level KPIs such as sampled call drop rate and application layer throughput. By periodically sampling these network performance data, managers of the operator can monitor overall performance of the network and compare performance differences between areas or periods. The statistical data sampling can be performed periodically e.g. weekly or monthly. The drive test fleet's scale makes the amount of data samples under operators control.
MDT can be used to replace or reduce drive test in this case. It is necessary for the MDT task to collect measurements in a way similar as the drive test do. To prevent unnecessary waste of network resources, operators need to specify the desired maximum number and amount of data samples collected through an MDT task. There is no need to notify the operator when the max number or amount is reached because that will not trigger any action of the operator. It is necessary for the operators to specify the desired minimum number of UEs and amount of data samples collected in a MDT job so that the data collected can meet the business and management requirements. If a MDT job can not collect minimum amount of data in a given period of time, the operator need to be notified quickly at the end of the time period given by the operator so he can decide if he will need to send a drive test team in the field to replace the MDT job.
A.12.2 Example of required data to cover use case #12
Ideally, the data collected should include all measurements taking place in a drive test, such as Ec/No and RSCP for UMTS and RSRP and RSRQ for E-UTRAN, and statistical business level KPIs such as sampled call drop rate and application layer throughput. It is not possible to ask a normal UE to perform similar task. To make MDT a basic replacement for drive test, UE measurement such as Ec/No and RSCP for UMTS and RSRP/RSRQ for E-UTRAN should be reported.
It shall also be possible for MDT to facilitate the introduction of future technology to collect business level KPIs e.g. sampled call drop rate and application layer throughput.
Up

A.12.1  Description  p. 43

A.12.2  Example of required data to cover use case #12  p. 43

A.13  Use case #13 Differentiation of management based MDT data by terminal type |R11|  p. 44

A.13.1  Description  p. 44

For analysis of management based MDT data, it's useful to differentiate the MDT data which are collected from different terminal types. For example, it allows operators to analyze whether the poor network performance is caused by a specific terminal type.
For privacy consideration of MDT data, operator shall also be able to select whether the MDT data should be reported with or without the user terminal type information.

A.13.2  Example of required data to cover use case #13  p. 44

The IMEI-TAC could be used together with MDT data and operators could use the information to analyze whether the poor network performance is caused by network or specific terminal types.

A.14  Use case #14 Subscriber complaint about MBMS service in the eUTRAN network |R13|  p. 44

A.14.1  Description  p. 44

When a subscriber complains about their MBMS service, signalling based MDT for that particular user can be triggered to analyse and troubleshoot the issue. Operator may also want to analyse the performance or issues in the network by looking at per subscriber MBSFN measurements.

A.14.2  Example of required data to cover use case #14  p. 44

The MBSFN MDT measurements defined in TS 37.320 are required for analysing MBMS service quality in the indicated area and for trouble shooting per user MBMS service. The measurement quantities for E-UTRA MBSFN measurement logging are fixed and consist of MBSFN RSRP, MBSFN RSRQ, BLER for signalling and BLER for data per MCH, in addition to the measurement quantities for downlink pilot strength measurements.
The MBSFN measurement results consist of, per MBSFN area where MBMS service is received:
  • MBSFN area identity.
  • Carrier frequency.
  • MBSFN RSRP.
  • MBSFN RSRQ.
  • MCH BLER for signalling.
  • MCH BLER for data, and related MCH index.
Up

A.15  Use case #15 Check MBMS service quality and performance of the eUTRAN Network |R13|  p. 44

A.15.1  Description  p. 44

The operator needs information for analysing signal strength, signal quality and block error rates for MBMS reception and quality. Logged MBSFN MDT data is needed to support network verification, re-planning of MBSFN areas, and optimization of MBSFN operation parameters.

A.15.2  Example of required data to cover use case #15  p. 45

The MBSFN MDT measurements defined in TS 37.320 are required for analysing MBMS QoS in the indicated area and for trouble shooting per user MBMS service. The measurement quantities for E-UTRA MBSFN measurement logging are fixed and consist of MBSFN RSRP, MBSFN RSRQ, BLER for signalling and BLER for data per MCH, in addition to the measurement quantities for downlink pilot strength measurements.
The MBSFN measurement results consist of, per MBSFN area where MBMS service is received:
  • MBSFN area identity.
  • Carrier frequency.
  • MBSFN RSRP.
  • MBSFN RSRQ.
  • MCH BLER for signalling.
  • MCH BLER for data, and related MCH index.
Up

A.16  Use case #16 Collecting Cell and UE data for analytics |R16|  p. 45

A.16.1  Goal  p. 45

Being able to analyse and optimize the mobility management and traffic handling behaviour for on-going sessions is important, as it offers an opportunity to address potential problems before it's "too late" (while something can be done to mitigate them or prevent the problem from happening).
Cell Traffic Trace, Immediate MDT, RLF reports and RCEF reports are the examples of RAN data relevant to this goal.

A.16.2  Pre-conditions  p. 45

The consumers (e.g. specific instances of MDAS producers, NWDAF) and producers (e.g. specific E-UTRAN or NG-RAN nodes) of data have been identified and are operational.
The data to be collected (e.g. particular call processing events, relevant interfaces, signalling messages and IEs, MDT measurements, UE location information, failure reports) has been selected.

A.16.3  Description/steps  p. 45

  1. 3GPP Management System configures/activates the data producers with appropriate Trace measurement control and configuration parameters.
  2. The data producer establishes connection to the data consumer and exchanges the data collection session metadata (e.g. identity of the data producer, nature of the data being collected, Trace Reference).
  3. While the Trace Session is active on the data producer, the data producer performs UE selection (see clauses 4.1.1.6a and 4.1.1.9 in TS 32.422), receives RLF and RCEF reports (see clauses 4.3 and 4.8 in TS 32.422), starts trace recording sessions (see clauses 4.2.2.5 and 4.2.2.10 in TS 32.422), enables MDT measurements (see clause 4.2.2.7 in TS 32.422).
  4. Periodically, upon the data availability, the data producer sends the collected data to the data consumer. The periodicity and the amount of data in each burst sent from producer to consumer may be standardized, made configurable or left implementation-specific. But the key point here is that the data is being delivered to the consumer while it's still relevant to the analytical task performed by the consumer.
  5. 3GPP Management System configures/deactivates the data producers.
  6. The data producer terminates the connection to the data consumer and potentially informs it that the data collection task has been completed and no further data is expected.
The use case ends upon successful termination of the data collection task.
Up

A.16.4  Post-conditions  p. 46

The data consumer has the necessary data to perform the analytical tasks. The data (reported per UE) may include, but is not limited to:
  • LTE MDT measurements (see TSs 37.320 [11] and 32.422 [2]) such as:
    • M1: RSRP and RSRQ measurement by UE with Periodic, event A2 as reporting triggers;
    • M2: Power Headroom (PH) measurement by UE;
    • M3: Received Interference Power measurement by eNB;
    • M4: Data Volume measurement separately for DL and UL by eNB;
    • M5: Scheduled IP Throughput measurement separately for DL and UL by eNB.
  • Radio Link Failure reports;
  • RRC Connection Establishment Failure reports;
  • Raw signalling messages (see clauses 4.13 and 4.29 of TS 32.423 for additional details);
  • UE location information (see clause 4.16.2 of TS 32.423 for additional details).
The specific methods for analysing and/or correlating the captured data, as well as any actions that may be triggered by such analysis are out of scope of the present use case.
Up

A.17  Use case #17 Collecting subscriber and equipment trace data for near-real-time diagnostics and troubleshooting |R16|  p. 46

A.17.1  Goal  p. 46

Being able to diagnose and troubleshoot various problems reported by subscribers (e.g. as described in clauses A.2 - A.14) for on-going sessions is important, as it offers an opportunity to investigate and address potential problems while they are happening, and to evaluate the corrective actions (e.g. based on subscriber's feedback or automated algorithms).
Subscriber and equipment Trace with Signalling Based Activation performed on RAN and Core NEs are the examples of trace data relevant to this goal.
Up

A.17.2  Pre-conditions  p. 46

The consumers (e.g. management applications and/or functions) and producers (e.g. specific NG-RAN and 5GC nodes) of data have been identified and are operational.
The subscriber or equipment to be traced has been identified.
The data to be collected (e.g. triggering events, trace depth, relevant NE types, relevant interfaces, signalling messages and IEs, MDT measurements, UE location information, failure reports) has been selected.

A.17.3  Description/steps  p. 47

  1. Management system configures/activates the Trace Session to the UDM. UDM stores the trace control and configuration parameters.
  2. As UE (to be traced) registers with the network, the AMF starts a new Trace Session according to the configuration parameters received from UDM (see steps 3-8 in clause 4.1.2.15.1 of TS 32.422).
  3. AMF establishes connection to the Trace data consumer and exchanges the Trace data collection session metadata (e.g. identity of the AMF, nature of the data being collected, Trace Session Reference).
  4. While the Trace Session is active on the AMF, AMF starts the Trace Recording Sessions and collects the Trace data prescribed by Trace configuration received from the UDM.
  5. Periodically, upon the Trace data availability, the AMF sends the collected data to the data consumer. The periodicity and the amount of data in each burst sent from AMF to data consumer may be standardized, made configurable or left implementation-specific. But the key point here is that the data is being delivered to the consumer while it's still relevant to the diagnostic/troubleshooting task performed by the consumer.
  6. In parallel to the step 5, AMF sends the Trace Start message to the NG-RAN node (see steps 9-11 in clause 4.1.2.15.1 of TS 32.422 and additional details in TS 38.413). NG-RAN node starts the Trace Session and establishes connection to the Trace data consumer. NG-RAN node and Trace data consumer exchange the Trace data collection session metadata (e.g. identity of the NG-RAN node, nature of the data being collected, Trace Session Reference).
  7. While the Trace Session is active on the NG-RAN node, NG-RAN node collects the Trace data prescribed by Trace configuration received from the AMF.
  8. Periodically, upon the Trace data availability, the NG-RAN node sends the collected data to the data consumer. The periodicity and the amount of data in each burst sent from NG-RAN node to data consumer may be standardized, made configurable or left implementation-specific. But the key point here is that the data is being delivered to the consumer while it's still relevant to the diagnostic/troubleshooting task performed by the consumer.
  9. In parallel with steps 3-5, AMF activates the Trace sessions on PCF and SMF (see steps 12-17 in clause 4.1.2.15.1 of TS 32.422). The PCF and SMF start Trace sessions and establish connections to the Trace data consumer. PCF and SMF exchange Trace data collection session metadata (e.g. identity of PCF or SMF, nature of the data being collected, Trace Session Reference).
  10. Periodically, upon the Trace data availability, the PCF and SMF send the collected data to the data consumer. The data is being delivered to the consumer while it's still relevant to the diagnostic/troubleshooting task performed by the consumer.
  11. When traced UE hands-over from one NG-RAN node to another (e.g. Xn handover), the Trace configuration is propagated in the Trace activation IE of the HANDOVER REQUEST message (see TS 38.423). The target NG-RAN node starts the Trace Session and establishes connection to the Trace data consumer. The target NG-RAN node and Trace data consumer exchange the Trace data collection session metadata (e.g. identity of the NG-RAN node, nature of the data being collected, Trace Session Reference).
  12. While the Trace Session is active on the target NG-RAN node, target NG-RAN node collects the Trace data prescribed by Trace configuration received from the source NG-RAN node.
  13. The target NG-RAN node reports the collected trace data to the data consumer (performs the actions described in the step 8 above).
  14. 3GPP Management System configures/deactivates the Trace session at the UDM. It triggers the Trace deactivation process on all NEs where the Trace session was active (see clause 4.1.4.11 in TS 32.422 for additional details).
  15. Upon the Trace session deactivation, the NEs / Trace data producers terminate the connection to the Trace data consumer and potentially inform it that the data collection tasks have been completed and no further data is expected.
The use case ends upon successful termination of the Trace session and of the data collection tasks on all NEs.
Up

A.17.4  Post-conditions  p. 48

The data consumer has the necessary data to perform the near-real-time diagnostics and troubleshooting tasks.
The specific methods for analysing and/or correlating the captured data, as well as any actions that may be triggered by such analysis are out of scope of the present use case.

A.18  Use case #18 Collecting RRC reports for analytics |R19|  p. 48

A.18.1  Goal  p. 48

Improving and optimising mobility management configuration in network nodes is important to reduce handover failures, poor coverage and low QoE. These improvements and optimisations can be done in the network nodes and also in the OAM system.
To aid this optimisation, RAN3 has defined a set of RRC TS 38.331 reports that can be generated by the UE and retrieved by a network node (for example a gNB). These reports consist of the RLF, RCEF, RA, SHR, SPR, MHI and VisitedCellInfoList reports for NR.
These reports can be used by network nodes themselves for use by, for example, a decentralized SON function. In rel-18, two of these reports (RLF and RCEF) can also be used by a consumer of Trace reports, for example a centralised SON function or an AI/ML function in the OAM system.
The goal is to make all reports (RLF, RCEF, RA, SHR, SPR, MHI and VisitedCellInfoList) available to MnS consumers, for example centralised SON functions, MDAS or NWDAF.
Up

A.18.2  Pre-conditions  p. 48

The consumers of the data are operational.
The consumers have subscribed to one or many of the RLF, RCEF, RA, SHR, SPR, MHI and VisitedCellInfoList reports.

A.18.3  Description/steps  p. 48

  1. The consumer(s) subscribe to Trace job(s), indicating one, many or all of the RLF, RCEF, RA, SHR, SPR, MHI and VisitedCellInfoList reports from network nodes.
  2. When consumer(s) no longer are interested in the reports, the consumer(s) stops subscribing to the trace(s).

A.18.4  Post-conditions  p. 48

Consumers no longer retrieve RRC reports.

$  Change history  p. 49

Up   Top