Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · Management

Logged MDT

Logged Minimization of Drive Tests

Management →

Logged MDT is a 3GPP feature where user equipment logs measurement data while idle or inactive for later network reporting, minimizing manual drive tests by using devices as mobile sensors for optimization.

Introduced
Rel-10
Where
Management
Specifications
3 specs
Logged MDT Description Purpose What changed Neighbours Detected Changes Specifications

Description

Logged Minimization of Drive Tests (Logged MDT) is a key feature within the 3GPP Minimization of Drive Tests (MDT) framework, designed to automate the collection of network performance data. It involves measurement logging by the UE in various states—IDLE mode, INACTIVE state, CELL_PCH, URA_PCH states, and CELL_FACH state when the second DRX cycle is used (for UTRA)—for reporting to the eNB, RNC, or gNB at a later point in time. Additionally, it includes the logging of MBSFN (Multimedia Broadcast multicast service Single Frequency Network) measurements by E-UTRA UEs in IDLE and CONNECTED modes. The logged data is stored in the UE and transmitted to the network when a suitable reporting opportunity arises, typically when the UE transitions to connected mode or when a specific reporting trigger is met.

The architecture of Logged MDT involves several key components. The UE is configured with MDT parameters by the network, including the logging interval, the duration of the logging session, and the specific measurements to be logged. These measurements can include signal strength and quality of the serving cell and neighboring cells, as well as location information if available. The UE logs these measurements along with timestamps and, optionally, location data. The logged data is then reported to the network via Radio Resource Control (RRC) signaling. In LTE, the reporting is done using the UEInformationRequest/UEInformationResponse procedure, while in 5G NR, similar mechanisms are used. The receiving node—eNB, RNC, or gNB—forwards the data to the Element Manager (EM) or Network Manager (NM) for further processing and analysis.

The management aspects of Logged MDT are specified in 3GPP TS 32.421 and TS 32.422, which define the management architecture, configuration parameters, and reporting mechanisms. TS 37.320 provides the overall MDT stage 2 and stage 3 specifications, detailing the UE procedures and the interaction between the UE and the network. The feature supports both signaling-based and management-based activation. In signaling-based activation, the MDT configuration is sent to the UE via RRC signaling, often tied to a specific subscriber or group. In management-based activation, the network management system configures the MDT parameters directly on the network elements, which then propagate the configuration to the UEs.

Logged MDT is particularly valuable for coverage optimization, mobility optimization, and capacity optimization. By collecting measurements from a large number of UEs across different locations and times, operators can identify coverage holes, weak signal areas, and areas with high interference without the need for expensive and time-consuming drive tests. The data can also be used to optimize handover parameters, reduce call drops, and improve overall network performance. The inclusion of MBSFN measurements allows operators to assess the quality of broadcast/multicast services and optimize their delivery.

The definition of Logged MDT has evolved over successive 3GPP releases. In Rel-10, it was introduced with a focus on IDLE mode, CELL_PCH, and URA_PCH states for UTRA. Rel-12 expanded the definition to include CELL_FACH state when the second DRX cycle is used, and added MBSFN measurement logging for E-UTRA UEs. Rel-16 further expanded the definition to include the INACTIVE state and to specify reporting to gNB, reflecting the introduction of 5G NR. The definition remained stable through Rel-17, Rel-18, and Rel-19. In Rel-20, the definition was replaced with a reference to TS 37.320, indicating a change in how the term is documented, though the change cannot be fully assessed from the available wording.

Purpose & Motivation

Logged MDT was created to address the high cost and logistical challenges of traditional drive tests. Before its introduction, network operators relied on manual drive tests—driving vehicles equipped with specialized measurement equipment along predefined routes—to assess network coverage, quality, and performance. This approach was expensive, time-consuming, and limited in scope, as it could only cover a small fraction of the network at any given time. It also failed to capture the real-world experience of actual users, who might be indoors, in moving vehicles, or in locations not covered by the drive test routes.

The motivation for Logged MDT was to leverage the ubiquitous presence of user devices as mobile sensors. By enabling UEs to log measurements autonomously and report them later, operators could gather vast amounts of real-world data at a fraction of the cost. This data could be used to identify coverage holes, optimize handover parameters, and improve network performance in a continuous, automated manner. The feature also supports the growing need for network optimization in heterogeneous networks, where small cells and complex deployments make manual testing even more challenging.

The evolution of Logged MDT reflects the changing landscape of mobile networks. The initial focus on UTRA and E-UTRA in Rel-10 was expanded in Rel-12 to include additional states and MBSFN measurements, addressing the need for more comprehensive data. The inclusion of the INACTIVE state and gNB reporting in Rel-16 reflects the advent of 5G NR and the need to support new radio technologies. Throughout its evolution, Logged MDT has remained a cost-effective and scalable solution for network optimization, enabling operators to make data-driven decisions without the overhead of traditional drive tests.

What changed in its specifications

The latest release-to-release comparison of specifications that define Logged MDT. Each summary describes the whole specification, not only this term.

TS 32.421Rel-18 → Rel-19

Rel-19 adds RRC report collection to TS 32.421 for NG-RAN, covering RLF, RCEF, RA, SHR, SPR and MHI reports. It also introduces new clauses, definitions and requirements for subscriber and equipment trace and QoE collection management.

Full comparison in TS 32.421 →
TS 32.422Rel-18 → Rel-19

C-MDT for non-split and split RAN architectures, RRC reporting trace sessions, trace failure notification, and new parameters.

Full comparison in TS 32.422 →

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-17 1 change
  • Correction to Logged MDT type handling TS 37.320CR0121
Rel-18 1 change
  • Correction of availability indication of logged MDT report for SNPN TS 37.320CR0132

Defining Specifications

3GPP specifications that define or reference Logged MDT, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 32.421 vj40 Subscriber & Equipment Trace Concepts & Requirements Rel-19 read
TS 32.422 vk30 Trace, MDT and UE Measurement Control Rel-20 read
TS 37.320 vj40 MDT Overall Description (Stage 2) Rel-19 read