MDT stands for "Minimization of Drive Tests." A conventional drive test uses a vehicle equipped with scanners, test UEs, and positioning equipment to collect radio and service-performance measurements along a planned route.

Drive tests provide controlled and repeatable observations, but they require specialized equipment and personnel and cover only the routes and times included in the campaign. MDT supplements these campaigns with measurements collected by selected, MDT-capable UEs and by RAN nodes during normal network operation.

MDT does not mean that every UE reports data, and it does not eliminate every drive test. Collection depends on UE capability, network configuration, applicable privacy and consent requirements, and the UE state. Depending on the MDT mode, measurements are either reported while the UE is connected or logged for later on-demand retrieval.

The following sections describe the benefits, limitations, configuration, measurements, reporting procedures, and LTE/NR RRC information elements used by MDT.

• Benefits of MDT
• Challenges of MDT
• Implementation of MDT
• Impact of MDT on Network Optimization
• How does the network tell the UE to perform measurement logging?
  • Decoded message example
• Configuration Parameters
• Reporting Parameters
• What measurements and reports can the UE provide?
  • Measurements and reports - LTE
  • Measurements and reports - NR
• Immediate MDT measurements and reporting triggers
• How can the network retrieve the log from the UE?
  • Step 1: UE indicates that a log is available
  • Step 2: Network requests the logged report
  • Step 3: UE returns the logged measurements
• RRC-LTE
  • Release evolution
  • UE capability
  • Logged measurement configuration
  • Requesting stored UE information
  • Returning stored UE information
  • Logged measurement report
  • Failure and mobility diagnostics
• RRC-NR
  • Release evolution
  • UE capability
  • Logged measurement configuration
  • UE information request and response
  • Logged measurement content
  • Release 19 CSI logging
  • Release 18 and 19 mobility diagnostics
• Reference

Benefits of MDT

The main benefit of MDT is simple: it lets the operator observe the network from places and at times that a drive-test vehicle may never cover. It uses standardized measurements from selected UEs and RAN nodes, so the results can complement a planned drive test without requiring a test team to visit every location. This does not remove the need for controlled testing, but it can make optimization work broader, faster, and less expensive.

• Lower collection cost: Existing UEs and RAN measurements can reduce the number and scope of dedicated drive-test campaigns.
• Broader sampling: Selected UEs can provide observations from locations, mobility patterns, and times that a planned vehicle route may not cover.
• Operational visibility: Immediate MDT can provide connected-mode reports when configured reporting conditions are met, while Logged MDT provides measurements collected during idle or inactive operation for later retrieval.
• Repeatable optimization input: Standardized measurements can support coverage analysis, mobility optimization, QoS verification, and troubleshooting.
• User-experience relevance: Measurements originate from commercial UE and network operation, so they can expose conditions encountered by subscribers rather than only by dedicated test equipment.

Challenges of MDT

MDT gives the network more data, but more data does not automatically mean a more accurate conclusion. The samples come from different UE models, radio conditions, locations, and mobility patterns, and only capable and selected UEs participate. For this reason, MDT results should be interpreted together with their collection context, privacy rules, and possible population bias.

• Sampling and accuracy: Results depend on UE capability, implementation, location availability, mobility, radio state, and where subscribers actually travel.
• Privacy and consent: Operators must apply the user-consent, privacy, retention, and access-control requirements relevant to the MDT task and jurisdiction.
• Data volume and correlation: Large numbers of reports must be decoded, routed to the correct Trace Collection Entity (TCE), correlated with configuration and network context, and retained appropriately.
• Capability variation: Optional measurements and later-release features are available only when both the UE and network support them.

Implementation of MDT

From an implementation point of view, MDT is not one isolated RRC message. It is a collection of configuration, measurement, reporting, trace, and OAM procedures standardized across several 3GPP specifications. MDT became a Release 10 feature, building on some Release 9 UE-information and failure-reporting mechanisms, and later releases extended it for LTE, NR, non-public networks, NTN, and additional diagnostics.

The principal specifications used throughout this page are:

• TS 37.320 Radio measurement collection for Minimization of Drive Tests (MDT)   
• TS 32.422 - Telecommunication management; Subscriber and equipment trace; Trace control and configuration management   

TS 37.320 clause 3.1 defines two primary MDT modes:

• Immediate MDT: The UE performs measurements in the connected state and reports them when configured reporting conditions are met. RAN-node measurements can also be collected for MDT purposes.
• Logged MDT: The UE stores measurements in supported idle, inactive, or UTRA paging/FACH states and reports them later when requested by the network. E-UTRA MBSFN measurements may be logged in both idle and connected states.

The network selects the applicable mode and measurements according to the MDT task, UE capability, RRC state, and radio access technology.

Impact of MDT on Network Optimization

Once MDT results reach the operator, the real work is to turn individual samples into a useful picture of network behavior. A single low-RSRP sample may not mean much, but repeated samples with time, location, cell identity, mobility, and failure context can reveal a consistent problem. MDT therefore provides additional evidence for planning, optimization, QoS verification, and troubleshooting.

Typical uses include:

• Identify coverage holes: By analyzing signal strength and quality data, operators can pinpoint areas with poor coverage and take steps to improve it.  
• Optimize network parameters: MDT data can be used to fine-tune network parameters, such as antenna tilt and power levels, to improve overall performance.  
• Troubleshoot performance issues: By analyzing protocol logs and other data, operators can identify the root cause of performance problems and resolve them.  
• Plan network upgrades: MDT data can help prioritize capacity additions, coverage improvements, and parameter changes.

How does the network tell the UE to perform measurement logging?

The first step in Logged MDT is to tell the UE what to collect and for how long. E-UTRAN does this while the UE is in RRC_CONNECTED by sending LoggedMeasurementConfiguration. The UE stores the logging parameters and trace identifiers, starts timer T330 from loggingDuration, and later records the applicable measurements while in RRC_IDLE. MBSFN is a special LTE case because those measurements can be logged in both RRC_IDLE and RRC_CONNECTED.

Signalling direction: E-UTRAN → UE: LoggedMeasurementConfiguration-r10

Decoded message example

A decoded RRC tree is useful, but it can be difficult to follow when every extension level is expanded on screen. The same message is therefore shown below as JSONC, which makes the parent-child relationship between information elements easier to see and allows a short comment beside each value. The zero-valued identities are illustrative test values; they do not represent a production PLMN, cell, or trace session.

{
  "loggedMeasurementConfiguration-r10": {
    "criticalExtensions": {
      "c1": {
        "loggedMeasurementConfiguration-r10": {
          "traceReference-r10": {
            "plmn-Identity-r10": {
              "mcc": null,                       // MCC is not included in this example
              "mnc": [0, 0]                     // Two-digit MNC: 00
            },
            "traceId-r10": "000000"             // Trace identifier within the PLMN
          },
          "traceRecordingSessionRef-r10": "0000", // Trace recording session reference
          "tce-Id-r10": "00",                   // Trace Collection Entity identifier
          "absoluteTimeInfo-r10":
            "000000000000000000000000000000000000000000000000", // 48-bit time reference
          "areaConfiguration-r10": {
            "cellGlobalIdList-r10": [            // Logging is limited to this cell list
              {
                "cellGlobalIdEUTRA": {
                  "plmn-Identity": {
                    "mcc": null,                 // MCC is not included in this example
                    "mnc": [0, 0]               // Two-digit MNC: 00
                  },
                  "cellIdentity": "0000000000000000000000000000" // 28-bit E-UTRA cell ID
                }
              }
            ]
          },
          "loggingDuration-r10": "min10",        // Run T330 for 10 minutes
          "loggingInterval-r10": "ms1280",      // Log every 1.28 seconds when allowed
          "nonCriticalExtension": null           // No later-release extension is present
        }
      }
    }
  }
}

Configuration Parameters

You can think of the Logged MDT configuration as the instruction sheet for one measurement campaign. It tells the UE what to log, which trigger to use, how long to continue, where logging is allowed, and which trace session should receive the result. TS 37.320 clause 5.1.1.1.1 defines these controls, while TS 36.331 and TS 38.331 provide their LTE and NR RRC encoding.

The message is delivered while the UE is connected, but the effective logging behavior depends on the RAT, UE state, configured area, and MDT PLMN or SNPN scope.

• Measurements to log
  • Downlink pilot-strength measurements are supported for UTRA, E-UTRA, and NR.
  • MBSFN measurement logging is specific to E-UTRA.
• Logging trigger
  • Periodic logging uses a configurable interval. For E-UTRAN, the interval is expressed in multiples of 1.28 seconds and is related to the applied idle-mode DRX cycle.
  • Event-based logging is supported for E-UTRAN and NR. Event L1 uses a threshold, hysteresis, and time-to-trigger; out-of-coverage detection is the other supported event type.
  • Periodic and event-based downlink pilot-strength configurations are independent, but only one event type is configured for a given event-based configuration.
• Logging duration
  • The duration timer starts when the UE receives the configuration and continues across state, RAT, and RPLMN changes.
  • At expiry, measurement logging stops and the active configuration is cleared. Trace correlation and time-reference parameters needed to report stored results are retained with the report.
• Trace and routing information
  • The network provides an absolute time reference, Trace Reference, Trace Recording Session Reference, and TCE ID.
  • These values allow the report to be correlated with the OAM trace task and routed to the correct Trace Collection Entity.
• PLMN and logging-area scope
  • An optional MDT PLMN list identifies the PLMNs in which measurement collection and report transfer are permitted.
  • A public-network area can use up to 32 global cell identities or up to 8 tracking, location, or routing areas, depending on the RAT.
  • NR additionally supports inter-frequency cell lists, PNI-NPN and SNPN scopes, and Release 19 NTN geographic areas. An NTN list can contain up to eight polygonal or circular areas.
  • Outside the permitted PLMN or configured area, logging is suspended while the configuration and previously collected log are retained.
• Optional measurement targets
  • NR can identify neighboring frequencies or cells whose measurements should be included.
  • E-UTRA can configure up to eight target MBSFN entries, each containing a carrier frequency and optionally an MBSFN area.
  • WLAN access-point names, Bluetooth beacon names, NR sensor names, and uncompensated barometric-pressure collection can be configured when supported.
  • NR can mark early/idle measurement frequencies as relevant to Logged MDT.
  • NR and E-UTRA can identify the configuration as signalling-based Logged MDT.

Reporting Parameters

Configuration answers the question "what should the UE collect?" Reporting answers the next question: "what context must travel with those measurements so the network can use them?" A raw RSRP value alone is not very helpful, so a Logged MDT report adds time, serving-cell identity, trace correlation, and any available neighbor or location information.

TS 37.320 clause 5.1.1.3.3 defines this report content. Depending on the RAT and configuration, the report can also include sensor, MBSFN, WLAN, or Bluetooth results.

• Serving and neighboring cells
  • Downlink pilot-strength reporting contains the serving-cell measurement quantity and available idle/inactive intra-frequency, inter-frequency, and inter-RAT measurements.
  • Neighbor entries identify the physical cell and carrier frequency. Depending on the RAT, results can include E-UTRA/NR RSRP and RSRQ, UTRA RSCP and Ec/No, GERAN RxLev, or CDMA2000 pilot phase and strength.
  • The UE selects a fixed number of the best cells using the ranking quantity used for cell reselection. A result is included only when available and not already reported.
• Fixed upper limits per frequency or category
  • Up to 6 intra-frequency neighboring cells.
  • Up to 3 inter-frequency cells per frequency and up to 3 cells per applicable inter-RAT frequency.
  • Up to 32 WLAN access points and up to 32 Bluetooth beacons.
  • An NR UE in RRC_IDLE or RRC_INACTIVE does not log UMTS or GSM measurements.
• MBSFN, WLAN, and Bluetooth
  • An E-UTRA MBSFN result can include the MBSFN area identity, carrier frequency, MBSFN RSRP/RSRQ, signalling MCH BLER, and data MCH BLER with its MCH index.
  • A WLAN result can include BSSID, SSID, HESSID, RSSI, and RTT.
  • A Bluetooth result can include the beacon MAC address and RSSI.
• Time information
  • Each measurement entry has a relative timestamp in seconds from receipt of the logged measurement configuration.
  • The UE echoes the network absolute timestamp supplied in the configuration. Together, the absolute and relative values identify when each sample was logged.
• Cell and detailed location
  • The serving ECGI, UTRA Cell-ID, or NCGI is included as applicable.
  • If available at measurement time, detailed location contains latitude and longitude and may also contain altitude, uncertainty, and confidence.
  • Detailed location is associated with the next measurement sample and is then discarded; its implicit validity is one logging interval.
  • Neighbor measurements may also be used as an RF fingerprint for location determination.
• Sensor information
  • Available uncompensated barometric pressure can be included for E-UTRA and NR.
  • NR can additionally include UE speed and orientation.
• Self-contained transfer
  • Each reported part carries enough context to be interpreted without the original logged measurement configuration.
  • Trace and TCE parameters allow the RAN and OAM system to identify and route the report correctly.

What measurements and reports can the UE provide?

There is no single fixed list that every UE always reports. The actual content depends on the RAT, RRC state, UE capability, network request, and whether the task uses Logged or Immediate MDT. It is also useful to distinguish a measurement sample, such as RSRP, from a diagnostic report, such as an RLF report that contains measurements plus failure context.

The following LTE and NR summaries group the principal UE-provided measurement and diagnostic reports defined by TS 36.331 and TS 38.331. A UE includes only information that is requested, supported, and available.

Measurements and reports - LTE

LTE MDT grew over several releases, so the UE Information procedure now carries much more than the original RACH and RLF reports. At a high level, LTE can return logged radio measurements, access and connection-failure details, mobility history, idle-mode results, and selected inter-RAT information. The list below groups these items by purpose instead of by release number.

• Logged measurements
  • LogMeasReport-r10 carries trace references, absolute and relative timestamps, serving-cell identity, serving RSRP/RSRQ, and available neighbor results.
  • Extension groups can add MBSFN, Bluetooth, WLAN, NR-neighbor, in-device coexistence, any-cell-selection, and unavailable/barred-preferred measurement information.
• Random access and connection failure
  • RACH-Report-r16 reports the number of preambles and contention detection; RACH-Report-v1610 adds the initial coverage-enhancement level and EDT fallback.
  • ConnEstFailReport-r11 includes the failed-cell and neighbor measurements, preamble attempts, contention status, maximum-power status, and time since failure.
  • Release 18 can transfer an encoded NR random-access report and associated NR cell identities through the LTE UE Information procedure.
• Radio-link failure
  • RLF-Report-r9 can contain the last serving and neighbor measurements, failed and reconnect cell identities, failure cause, failure timing, and available location information.
  • Later extensions add Bluetooth/WLAN results, NR cell results and reconnection information, and the Release 18 voice-fallback handover indication.
• Mobility and idle measurements
  • MobilityHistoryReport-r12 returns visited-cell information.
  • measResultListIdle-r15, measResultListExtIdle-r16, and measResultListIdleNR-r16 return available idle-mode E-UTRA and NR results.
  • FlightPathInfoReport-r15 can contain aerial-UE waypoints with optional timestamps, and Release 17 can return coarse location information.

Measurements and reports - NR

NR starts with the same basic MDT idea but adds inactive-state logging, beam-oriented measurements, richer dual-connectivity diagnostics, and newer Release 19 collection methods. This means an NR report may describe not only the serving and neighboring cells, but also handover, PSCell, SCG, LTM, or CSI behavior. The summary below follows that progression from conventional logged measurements to the latest additions.

• Logged and idle measurements
  • LogMeasReport-r16 carries trace and time information plus available serving, NR-neighbor, and E-UTRA-neighbor results collected in RRC_IDLE or RRC_INACTIVE.
  • MeasResultIdleNR-r16 and MeasResultIdleEUTRA-r16 return requested idle-mode results.
  • Release 19 logged entries can identify the NSAG and the reselected cell.
• Access, failure, and mobility diagnostics
  • Connection-establishment failure, random-access, radio-link-failure, and mobility-history reports include the applicable cell identities, measurements, causes, counters, timing, and location information.
  • Serving and neighbor results can contain cell-level and beam-level SSB or CSI-RS quantities when the associated report type provides them.
• Release 17 additions
  • Successful-handover reports, multiple connection-establishment-failure reports, coarse location, and in-device coexistence information extend the UE Information procedure.
• Release 18 additions
  • Flight-path information, successful PSCell reports, reselection measurements, and validated-measurement requests add further mobility context.
  • Failure reports add information such as RSSI, attempted BWP, SCG failure details, and additional handover diagnostics where applicable.
• Release 19 additions
  • Connected-mode CSI logging for network-side data collection reports per-cell, per-configuration CSI-RS or SSB L1-RSRP information over SRB6.
  • Mobility diagnostics can include L1 mobility results, LTM recovery information, RACH-less handover indication, and candidate-SCG information.

Immediate MDT measurements and reporting triggers

Immediate MDT is used when measurements can be collected while the UE is connected, without waiting for a later log-retrieval procedure. It reuses normal RRM reporting conditions for several UE measurements, adds an MDT-specific uplink PDCP-delay measurement for QoS verification, and combines these with measurements made directly by the eNB. This is why the table includes both UE-based and network-based items; not every row represents an RRC measurement report sent by the UE.

For M6, the UE omits an uplink PDCP-delay result when no delay is detected according to the configured threshold and reporting interval. A capable EN-DC UE may also be configured to report average uplink PDCP queueing delay. QCI values for contributing radio bearers accompany measurements where TS 37.320 requires that association.

How can the network retrieve the log from the UE?

Logging data in the UE is only half of the procedure; the network still needs a controlled way to retrieve it. LTE uses a simple three-step exchange: the UE first indicates that a log exists, E-UTRAN asks for the stored report, and the UE returns as much information as fits in UEInformationResponse. If more data remains, the same request-response cycle can continue.

The decoded examples below are shown as JSONC so the extension chain and the purpose of each important information element are easy to follow.

Step 1: UE indicates that a log is available

The network should not request a log blindly, so the UE first announces that stored information is available. It sets logMeasAvailable-r10 in an eligible uplink RRC message, such as RRCConnectionSetupComplete or UEInformationResponse. This one-bit indication is only a notification; the measurement entries themselves are not carried in this step.

{
  "rrcConnectionSetupComplete": {
    "rrc-TransactionIdentifier": 0,             // Identifies this RRC transaction
    "criticalExtensions": {
      "c1": {
        "rrcConnectionSetupComplete-r8": {
          "selectedPLMN-Identity": 1,            // First PLMN in the selected PLMN list
          "registeredMME": {
            "plmn-Identity": null,               // Optional PLMN identity is not encoded
            "mmegi": "0000000000000000",        // 16-bit MME Group Identity
            "mmec": "00000000"                  // 8-bit MME Code
          },
          "dedicatedInfoNAS": "<NAS-PDU>",      // NAS payload; collapsed in the decoder
          "nonCriticalExtension": {              // RRCConnectionSetupComplete-v8a0-IEs
            "lateNonCriticalExtension": null,
            "nonCriticalExtension": {            // RRCConnectionSetupComplete-v1020-IEs
              "gumei-Type-r10": null,            // Not included
              "rlf-InfoAvailable-r10": null,     // No RLF report is indicated
              "logMeasAvailable-r10": true,      // Stored logged MDT results are available
              "rn-SubframeConfigReq-r10": null, // Not included
              "nonCriticalExtension": null       // No later extension in this example
            }
          }
        }
      }
    }
  }
}

Step 2: Network requests the logged report

After seeing the availability bit, E-UTRAN decides whether and when to retrieve the log. To request it, the network sends UEInformationRequest-r9 with logMeasReportReq-r10 set to true. The message can request other diagnostic reports independently, but the captured example leaves the RACH and RLF request flags set to false.

{
  "ueInformationRequest-r9": {
    "rrc-TransactionIdentifier": 0,             // Must be echoed by the UE response
    "criticalExtensions": {
      "c1": {
        "ueInformationRequest-r9": {
          "rach-ReportReq-r9": false,            // Do not request an LTE RACH report
          "rlf-ReportReq-r9": false,             // Do not request an LTE RLF report
          "nonCriticalExtension": {              // UEInformationRequest-v930-IEs
            "lateNonCriticalExtension": null,
            "nonCriticalExtension": {            // UEInformationRequest-v1020-IEs
              "logMeasReportReq-r10": true,      // Request the stored logged MDT report
              "nonCriticalExtension": null       // No later request in this example
            }
          }
        }
      }
    }
  }
}

Step 3: UE returns the logged measurements

The UE answers with UEInformationResponse-r9 and places the stored MDT data in LogMeasReport-r10. Each LogMeasInfo-r10 entry represents one logged sample with its relative time, serving-cell context, and available measurements. One response can contain up to 520 entries. If more information remains, the UE keeps logMeasAvailable-r10 set to true, and E-UTRAN can request the next part.

{
  "ueInformationResponse-r9": {
    "rrc-TransactionIdentifier": 0,             // Matches the request transaction ID
    "criticalExtensions": {
      "c1": {
        "ueInformationResponse-r9": {
          "rach-Report-r9": {},                 // Present but collapsed in the capture
          "rlf-Report-r9": {},                  // Present but collapsed in the capture
          "nonCriticalExtension": {             // UEInformationResponse-v930-IEs
            "lateNonCriticalExtension": {
              "UEInformationResponse-v9e0-IEs": {
                "rlf-Report-v9e0": null,        // No additional RLF fields are shown
                "nonCriticalExtension": null
              }
            },
            "nonCriticalExtension": {            // UEInformationResponse-v1020-IEs
              "logMeasReport-r10": {
                "absoluteTimeStamp-r10":
                  "000000000000000000000000000000000000000000000000", // 48-bit timestamp
                "traceReference-r10": {
                  "plmn-Identity-r10": {
                    "mcc": null,                 // MCC is not included in this example
                    "mnc": [0, 0]               // Two-digit MNC: 00
                  },
                  "traceId-r10": "000000"       // Trace identifier
                },
                "traceRecordingSessionRef-r10": "0000", // Trace session reference
                "tce-Id-r10": "00",             // Trace Collection Entity identifier
                "logMeasInfoList-r10": [
                  {
                    "locationInfo-r10": null,    // Location information is not included
                    "relativeTimeStamp-r10": 0,  // Seconds relative to the absolute timestamp
                    "servCellIdentity-r10": {
                      "plmn-Identity": {
                        "mcc": null,
                        "mnc": [0, 0]
                      },
                      "cellIdentity": "0000000000000000000000000000" // 28-bit E-UTRA cell ID
                    },
                    "measResultServCell-r10": {
                      "rsrpResult-r10": 0,       // Encoded serving-cell RSRP result
                      "rsrqResult-r10": 0        // Encoded serving-cell RSRQ result
                    },
                    "measResultNeighCells-r10": null // No neighbor results are included
                  }
                ],
                "logMeasAvailable-r10": true     // More logged entries remain in the UE
              },
              "nonCriticalExtension": null       // No later response extension is shown
            }
          }
        }
      }
    }
  }
}

RRC-LTE

The earlier sections described MDT as a procedure. This section looks one level deeper and shows how LTE actually represents that procedure in RRC: one message configures logging, availability bits announce stored data, and the UE Information exchange retrieves logs or related diagnostics. Reading the non-critical-extension chain from top to bottom also shows when each capability was added.

The ASN.1 and descriptions below are updated against 3GPP TS 36.331 V19.2.1 (2026-03), the current Release 19 baseline.

Release evolution

LTE MDT did not appear as one complete feature in a single release. Release 9 supplied the basic UE Information and failure-reporting framework, Release 10 added Logged MDT, and later releases extended the same messages without replacing the original structure. This table gives the overall timeline before we follow the individual ASN.1 chains.

UE capability

Before E-UTRAN configures an optional MDT function, it needs to know whether the UE supports that function. The UE reports these features through UE-EUTRA-Capability, mainly in the versioned UE-BasedNetwPerfMeasParameters containers. The base bit covers ordinary idle-mode logging, while later containers advertise MBSFN, location, WLAN/Bluetooth, delay, event-triggered, pressure, and mobility-protection features.

An absent optional capability bit means that the UE has not advertised support for that feature. It does not remove the capabilities indicated by other fields, so the network evaluates the relevant bits individually.

UE-BasedNetwPerfMeasParameters-r10 ::= SEQUENCE {
    loggedMeasurementsIdle-r10          ENUMERATED {supported} OPTIONAL,
    standaloneGNSS-Location-r10         ENUMERATED {supported} OPTIONAL
}

UE-BasedNetwPerfMeasParameters-v1250 ::= SEQUENCE {
    loggedMBSFNMeasurements-r12         ENUMERATED {supported}
}

UE-BasedNetwPerfMeasParameters-v1430 ::= SEQUENCE {
    locationReport-r14                  ENUMERATED {supported} OPTIONAL
}

UE-BasedNetwPerfMeasParameters-v1530 ::= SEQUENCE {
    loggedMeasBT-r15                    ENUMERATED {supported} OPTIONAL,
    loggedMeasWLAN-r15                  ENUMERATED {supported} OPTIONAL,
    immMeasBT-r15                       ENUMERATED {supported} OPTIONAL,
    immMeasWLAN-r15                     ENUMERATED {supported} OPTIONAL
}

UE-BasedNetPerfMeasParameters-v1610 ::= SEQUENCE {
    ul-PDCP-AvgDelay-r16                ENUMERATED {supported} OPTIONAL
}

UE-BasedNetPerfMeasParameters-v1700 ::= SEQUENCE {
    loggedMeasIdleEventL1-r17           ENUMERATED {supported} OPTIONAL,
    loggedMeasIdleEventOutOfCoverage-r17 ENUMERATED {supported} OPTIONAL,
    loggedMeasUncomBarPre-r17           ENUMERATED {supported} OPTIONAL,
    immMeasUncomBarPre-r17              ENUMERATED {supported} OPTIONAL
}

UE-BasedNetPerfMeasParameters-v1800 ::= SEQUENCE {
    sigBasedEUTRA-LoggedMeasOverrideProtect-r18
        ENUMERATED {supported} OPTIONAL
}

Logged measurement configuration

LoggedMeasurementConfiguration-r10 is the main LTE instruction message for Logged MDT. The Release 10 fields provide trace identity, time reference, area, duration, and interval; each later release attaches optional information through nonCriticalExtension. Following that chain is the easiest way to see how MBSFN, WLAN/Bluetooth, event-triggered logging, and signalling-based logging were added while preserving backward compatibility.

LoggedMeasurementConfiguration-r10 ::= SEQUENCE {
    criticalExtensions CHOICE {
        c1 CHOICE {
            loggedMeasurementConfiguration-r10
                LoggedMeasurementConfiguration-r10-IEs,
            spare3 NULL, spare2 NULL, spare1 NULL
        },
        criticalExtensionsFuture SEQUENCE {}
    }
}

LoggedMeasurementConfiguration-r10-IEs ::= SEQUENCE {
    traceReference-r10                  TraceReference-r10,
    traceRecordingSessionRef-r10        OCTET STRING (SIZE (2)),
    tce-Id-r10                          OCTET STRING (SIZE (1)),
    absoluteTimeInfo-r10                AbsoluteTimeInfo-r10,
    areaConfiguration-r10               AreaConfiguration-r10 OPTIONAL,
    loggingDuration-r10                 LoggingDuration-r10,
    loggingInterval-r10                 LoggingInterval-r10,
    nonCriticalExtension                LoggedMeasurementConfiguration-v1080-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1080-IEs ::= SEQUENCE {
    lateNonCriticalExtension-r10        OCTET STRING OPTIONAL,
    nonCriticalExtension                LoggedMeasurementConfiguration-v1130-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1130-IEs ::= SEQUENCE {
    plmn-IdentityList-r11                PLMN-IdentityList3-r11 OPTIONAL,
    areaConfiguration-v1130             AreaConfiguration-v1130 OPTIONAL,
    nonCriticalExtension                LoggedMeasurementConfiguration-v1250-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1250-IEs ::= SEQUENCE {
    targetMBSFN-AreaList-r12            TargetMBSFN-AreaList-r12 OPTIONAL,
    nonCriticalExtension                LoggedMeasurementConfiguration-v1530-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1530-IEs ::= SEQUENCE {
    bt-NameList-r15                     BT-NameList-r15 OPTIONAL,
    wlan-NameList-r15                   WLAN-NameList-r15 OPTIONAL,
    nonCriticalExtension                LoggedMeasurementConfiguration-v1700-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1700-IEs ::= SEQUENCE {
    loggedEventTriggerConfig-r17        LoggedEventTriggerConfig-r17 OPTIONAL,
    measUncomBarPre-r17                 ENUMERATED {true} OPTIONAL,
    nonCriticalExtension                LoggedMeasurementConfiguration-v1800-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1800-IEs ::= SEQUENCE {
    sigLoggedMeasType-r18               ENUMERATED {true} OPTIONAL,
    nonCriticalExtension                SEQUENCE {} OPTIONAL
}

Requesting stored UE information

UEInformationRequest-r9 is a general request container rather than an MDT-only message. The base Release 9 fields ask for RACH or RLF information, and Release 10 adds logMeasReportReq-r10 for the stored MDT log. Later extensions reuse the same message to request connection-failure, mobility-history, idle measurement, flight-path, coarse-location, and NR random-access information.

UEInformationRequest-r9 ::= SEQUENCE {
    rrc-TransactionIdentifier           RRC-TransactionIdentifier,
    criticalExtensions CHOICE {
        c1 CHOICE {
            ueInformationRequest-r9     UEInformationRequest-r9-IEs,
            spare3 NULL, spare2 NULL, spare1 NULL
        },
        criticalExtensionsFuture SEQUENCE {}
    }
}

UEInformationRequest-r9-IEs ::= SEQUENCE {
    rach-ReportReq-r9                   BOOLEAN,
    rlf-ReportReq-r9                    BOOLEAN,
    nonCriticalExtension                UEInformationRequest-v930-IEs OPTIONAL
}

UEInformationRequest-v930-IEs ::= SEQUENCE {
    lateNonCriticalExtension            OCTET STRING OPTIONAL,
    nonCriticalExtension                UEInformationRequest-v1020-IEs OPTIONAL
}

UEInformationRequest-v1020-IEs ::= SEQUENCE {
    logMeasReportReq-r10                ENUMERATED {true} OPTIONAL,
    nonCriticalExtension                UEInformationRequest-v1130-IEs OPTIONAL
}

UEInformationRequest-v1130-IEs ::= SEQUENCE {
    connEstFailReportReq-r11            ENUMERATED {true} OPTIONAL,
    nonCriticalExtension                UEInformationRequest-v1250-IEs OPTIONAL
}

UEInformationRequest-v1250-IEs ::= SEQUENCE {
    mobilityHistoryReportReq-r12        ENUMERATED {true} OPTIONAL,
    nonCriticalExtension                UEInformationRequest-v1530-IEs OPTIONAL
}

UEInformationRequest-v1530-IEs ::= SEQUENCE {
    idleModeMeasurementReq-r15          ENUMERATED {true} OPTIONAL,
    flightPathInfoReq-r15               FlightPathInfoReportConfig-r15 OPTIONAL,
    nonCriticalExtension                UEInformationRequest-v1710-IEs OPTIONAL
}

UEInformationRequest-v1710-IEs ::= SEQUENCE {
    coarseLocationReq-r17               ENUMERATED {true} OPTIONAL,
    nonCriticalExtension                UEInformationRequest-v1800-IEs OPTIONAL
}

UEInformationRequest-v1800-IEs ::= SEQUENCE {
    rach-ReportReqNR-r18                ENUMERATED {true} OPTIONAL,
    nonCriticalExtension                SEQUENCE {} OPTIONAL
}

Returning stored UE information

The response mirrors the request: UEInformationResponse-r9 includes the requested report only when the corresponding information is available. LTE Logged MDT data appears in logMeasReport-r10, while later extension levels carry connection failures, mobility history, idle measurements, flight paths, coarse location, and NR RACH information. Keeping these reports in one extensible container lets a newer UE communicate with an older network without changing the original message.

UEInformationResponse-r9 ::= SEQUENCE {
    rrc-TransactionIdentifier           RRC-TransactionIdentifier,
    criticalExtensions CHOICE {
        c1 CHOICE {
            ueInformationResponse-r9    UEInformationResponse-r9-IEs,
            spare3 NULL, spare2 NULL, spare1 NULL
        },
        criticalExtensionsFuture SEQUENCE {}
    }
}

UEInformationResponse-r9-IEs ::= SEQUENCE {
    rach-Report-r9                      RACH-Report-r16 OPTIONAL,
    rlf-Report-r9                       RLF-Report-r9 OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v930-IEs OPTIONAL
}

UEInformationResponse-v9e0-IEs ::= SEQUENCE {
    rlf-Report-v9e0                     RLF-Report-v9e0 OPTIONAL,
    nonCriticalExtension                SEQUENCE {} OPTIONAL
}

UEInformationResponse-v930-IEs ::= SEQUENCE {
    lateNonCriticalExtension            OCTET STRING
        (CONTAINING UEInformationResponse-v9e0-IEs) OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1020-IEs OPTIONAL
}

UEInformationResponse-v1020-IEs ::= SEQUENCE {
    logMeasReport-r10                   LogMeasReport-r10 OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1130-IEs OPTIONAL
}

UEInformationResponse-v1130-IEs ::= SEQUENCE {
    connEstFailReport-r11               ConnEstFailReport-r11 OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1250-IEs OPTIONAL
}

UEInformationResponse-v1250-IEs ::= SEQUENCE {
    mobilityHistoryReport-r12           MobilityHistoryReport-r12 OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1530-IEs OPTIONAL
}

UEInformationResponse-v1530-IEs ::= SEQUENCE {
    measResultListIdle-r15              MeasResultListIdle-r15 OPTIONAL,
    flightPathInfoReport-r15            FlightPathInfoReport-r15 OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1610-IEs OPTIONAL
}

UEInformationResponse-v1610-IEs ::= SEQUENCE {
    rach-Report-v1610                   RACH-Report-v1610 OPTIONAL,
    measResultListExtIdle-r16           MeasResultListExtIdle-r16 OPTIONAL,
    measResultListIdleNR-r16            MeasResultListIdleNR-r16 OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1710-IEs OPTIONAL
}

UEInformationResponse-v1710-IEs ::= SEQUENCE {
    coarseLocationInfo-r17              OCTET STRING OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1800-IEs OPTIONAL
}

UEInformationResponse-v1800-IEs ::= SEQUENCE {
    rach-ReportNR-r18                   RACH-ReportNR-r18 OPTIONAL,
    nonCriticalExtension                SEQUENCE {} OPTIONAL
}

RACH-ReportNR-r18 ::= SEQUENCE {
    rach-ReportListNR-r18               OCTET STRING,
    cellIdListNR-r18                    CellIdListNR-r18
}

CellIdListNR-r18 ::=
    SEQUENCE (SIZE (1..maxCellRAReportNR-r18)) OF CellIdNR-r18

CellIdNR-r18 ::= CHOICE {
    cellGlobalId-r18                    CellGlobalIdNR-r16,
    pci-arfcn-r18 SEQUENCE {
        physCellId-r18                  PhysCellIdNR-r15,
        carrierFreq-r18                 ARFCN-ValueNR-r15
    }
}

Logged measurement report

LogMeasReport-r10 is the part that contains the actual LTE Logged MDT payload. The fields at the top identify the trace session and establish the absolute time reference; logMeasInfoList-r10 then carries the individual samples. Each sample adds a relative timestamp, serving-cell identity, serving result, and any available neighbor information, while extension groups add newer measurement categories.

LogMeasReport-r10 ::= SEQUENCE {
    absoluteTimeStamp-r10               AbsoluteTimeInfo-r10,
    traceReference-r10                  TraceReference-r10,
    traceRecordingSessionRef-r10        OCTET STRING (SIZE (2)),
    tce-Id-r10                          OCTET STRING (SIZE (1)),
    logMeasInfoList-r10                 LogMeasInfoList-r10,
    logMeasAvailable-r10                ENUMERATED {true} OPTIONAL,
    ...,
    [[ logMeasAvailableBT-r15           ENUMERATED {true} OPTIONAL,
       logMeasAvailableWLAN-r15         ENUMERATED {true} OPTIONAL ]]
}

LogMeasInfoList-r10 ::=
    SEQUENCE (SIZE (1..maxLogMeasReport-r10)) OF LogMeasInfo-r10

LogMeasInfo-r10 ::= SEQUENCE {
    locationInfo-r10                    LocationInfo-r10 OPTIONAL,
    relativeTimeStamp-r10               INTEGER (0..7200),
    servCellIdentity-r10                CellGlobalIdEUTRA,
    measResultServCell-r10 SEQUENCE {
        rsrpResult-r10                  RSRP-Range,
        rsrqResult-r10                  RSRQ-Range
    },
    measResultNeighCells-r10 SEQUENCE {
        measResultListEUTRA-r10         MeasResultList2EUTRA-r9 OPTIONAL,
        measResultListUTRA-r10          MeasResultList2UTRA-r9 OPTIONAL,
        measResultListGERAN-r10         MeasResultList2GERAN-r10 OPTIONAL,
        measResultListCDMA2000-r10      MeasResultList2CDMA2000-r9 OPTIONAL
    } OPTIONAL,
    ...,
    [[ measResultListEUTRA-v1090        MeasResultList2EUTRA-v9e0 OPTIONAL ]],
    [[ measResultListMBSFN-r12          MeasResultListMBSFN-r12 OPTIONAL,
       measResultServCell-v1250         RSRQ-Range-v1250 OPTIONAL,
       servCellRSRQ-Type-r12            RSRQ-Type-r12 OPTIONAL,
       measResultListEUTRA-v1250        MeasResultList2EUTRA-v1250 OPTIONAL ]],
    [[ inDeviceCoexDetected-r13         ENUMERATED {true} OPTIONAL ]],
    [[ measResultServCell-v1360         RSRP-Range-v1360 OPTIONAL ]],
    [[ logMeasResultListBT-r15          LogMeasResultListBT-r15 OPTIONAL,
       logMeasResultListWLAN-r15        LogMeasResultListWLAN-r15 OPTIONAL ]],
    [[ anyCellSelectionDetected-r15     ENUMERATED {true} OPTIONAL ]],
    [[ measResultListNR-r16             MeasResultCellListNR-r15 OPTIONAL ]],
    [[ measResultListNR-v1640 SEQUENCE {
           carrierFreqNR-r16            ARFCN-ValueNR-r15
       } OPTIONAL,
       measResultListExtNR-r16          MeasResultFreqListNR-r16 OPTIONAL ]],
    [[ uncomBarPreMeasResult-r17        OCTET STRING OPTIONAL ]]
}

Failure and mobility diagnostics

Radio measurements become much more useful when the network knows what happened around them. For that reason, the LTE UE Information procedure can also return random-access, connection-establishment, handover, radio-link-failure, mobility-history, and aerial-path context. These are diagnostic reports rather than ordinary periodic MDT samples, but they help explain why a call or mobility procedure succeeded or failed.

The table highlights the core purpose of each report and the newest additions retained by the Release 19 LTE RRC baseline.

RRC-NR

NR keeps the same basic MDT loop as LTE: configure the UE, collect measurements in idle or inactive operation, indicate availability, and retrieve the result after the UE is connected. The NR design starts later, at Release 16, so its base messages already include concepts such as RRC_INACTIVE, NR beam measurements, and a broader UE Information framework. Later releases then add private-network areas, richer mobility diagnostics, NTN areas, and network-side CSI logging.

The ASN.1 and descriptions below are updated through 3GPP TS 38.331 V19.3.0 (2026-06), Release 19.

Release evolution

Because NR Logged MDT begins in Release 16, its release history is shorter but changes quickly. Release 17 improves reporting context, Release 18 adds private-network and dual-connectivity details, and Release 19 introduces NTN areas and CSI logging for network-side collection. The table provides a map of those additions before the detailed message definitions.

UE capability

NR reports its main MDT feature support in UE-BasedPerfMeas-Parameters-r16 within UE-NR-Capability. One base bit advertises ordinary Logged MDT in RRC_IDLE and RRC_INACTIVE; separate bits cover optional measurements, protection behavior, private-network scope, and Release 19 geographic or slicing features. Related aerial and network-side data-collection capabilities are carried in their own NR capability containers.

The network uses these bits as a configuration guard. For example, support for ordinary Logged MDT does not by itself imply support for WLAN logging, SNPN scope checking, flight-path reporting, or Release 19 CSI data collection.

UE-BasedPerfMeas-Parameters-r16 ::= SEQUENCE {
    barometerMeasReport-r16             ENUMERATED {supported} OPTIONAL,
    immMeasBT-r16                       ENUMERATED {supported} OPTIONAL,
    immMeasWLAN-r16                     ENUMERATED {supported} OPTIONAL,
    loggedMeasBT-r16                    ENUMERATED {supported} OPTIONAL,
    loggedMeasurements-r16              ENUMERATED {supported} OPTIONAL,
    loggedMeasWLAN-r16                  ENUMERATED {supported} OPTIONAL,
    orientationMeasReport-r16           ENUMERATED {supported} OPTIONAL,
    speedMeasReport-r16                 ENUMERATED {supported} OPTIONAL,
    gnss-Location-r16                   ENUMERATED {supported} OPTIONAL,
    ulPDCP-Delay-r16                    ENUMERATED {supported} OPTIONAL,
    ...,
    [[
    sigBasedLogMDT-OverrideProtect-r17  ENUMERATED {supported} OPTIONAL,
    multipleCEF-Report-r17              ENUMERATED {supported} OPTIONAL,
    excessPacketDelay-r17               ENUMERATED {supported} OPTIONAL,
    earlyMeasLog-r17                    ENUMERATED {supported} OPTIONAL
    ]],
    [[
    loggedMDT-PNI-NPN-r18               ENUMERATED {supported} OPTIONAL,
    loggedMDT-SNPN-r18                  ENUMERATED {supported} OPTIONAL
    ]],
    [[
    geoAreaScopeChecking-r19            ENUMERATED {supported} OPTIONAL,
    loggedMDT-Slicing-r19               ENUMERATED {supported} OPTIONAL
    ]]
}

Logged measurement configuration

The network sends LoggedMeasurementConfiguration-r16 on SRB1 while the UE is connected, but the configured radio logging normally takes place later in RRC_IDLE or RRC_INACTIVE. The base message combines the trace, area, target, duration, and trigger information in one structure. Release 17 and Release 18 extend the permitted area types, and Release 19 can restrict logging to polygonal or circular NTN geographic areas.

LoggedMeasurementConfiguration-r16 ::= SEQUENCE {
    criticalExtensions CHOICE {
        loggedMeasurementConfiguration-r16 LoggedMeasurementConfiguration-r16-IEs,
        criticalExtensionsFuture SEQUENCE {}
    }
}

LoggedMeasurementConfiguration-r16-IEs ::= SEQUENCE {
    traceReference-r16                  TraceReference-r16,
    traceRecordingSessionRef-r16        OCTET STRING (SIZE (2)),
    tce-Id-r16                          OCTET STRING (SIZE (1)),
    absoluteTimeInfo-r16                AbsoluteTimeInfo-r16,
    areaConfiguration-r16               AreaConfiguration-r16 OPTIONAL, -- Need R
    plmn-IdentityList-r16               PLMN-IdentityList2-r16 OPTIONAL, -- Need R
    bt-NameList-r16                     SetupRelease {BT-NameList-r16} OPTIONAL, -- Need M
    wlan-NameList-r16                   SetupRelease {WLAN-NameList-r16} OPTIONAL, -- Need M
    sensor-NameList-r16                 SetupRelease {Sensor-NameList-r16} OPTIONAL, -- Need M
    loggingDuration-r16                 LoggingDuration-r16,
    reportType CHOICE {
        periodical                          LoggedPeriodicalReportConfig-r16,
        eventTriggered                      LoggedEventTriggerConfig-r16,
        ...
    },
    lateNonCriticalExtension            OCTET STRING OPTIONAL,
    nonCriticalExtension                LoggedMeasurementConfiguration-v1700-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1700-IEs ::= SEQUENCE {
    sigLoggedMeasType-r17               ENUMERATED {true} OPTIONAL, -- Need R
    earlyMeasIndication-r17             ENUMERATED {true} OPTIONAL, -- Need R
    areaConfiguration-r17               AreaConfiguration-r17 OPTIONAL, -- Need R
    nonCriticalExtension                LoggedMeasurementConfiguration-v1800-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1800-IEs ::= SEQUENCE {
    areaConfiguration-v1800             AreaConfiguration-v1800 OPTIONAL, -- Need R
    nonCriticalExtension                LoggedMeasurementConfiguration-v1900-IEs OPTIONAL
}

LoggedMeasurementConfiguration-v1900-IEs ::= SEQUENCE {
    areaConfigurationNTN-List-r19       AreaConfigurationNTN-List-r19 OPTIONAL, -- Cond logAreaNTN
    nonCriticalExtension                SEQUENCE {} OPTIONAL
}

AreaConfiguration-v1800 ::= CHOICE {
    cag-ConfigList-r18                  CAG-ConfigList-r18,
    snpn-ConfigList-r18                 SNPN-ConfigList-r18
}

AreaConfigurationNTN-List-r19 ::=
    SEQUENCE (SIZE (1..maxNrofAreaNTN-r19)) OF AreaConfigurationNTN-r19

AreaConfigurationNTN-r19 ::= SEQUENCE {
    areaCoordinates-r19 CHOICE {
        polygonArea-r19                 OCTET STRING,
        circleArea-r19 SEQUENCE {
            circularAreaReferenceLocation-r19 ReferenceLocation-r17,
            circularAreaRadius-r19      INTEGER (1..65535)
        }
    }
}

UE information request and response

NR uses UEInformationRequest and UEInformationResponse as a common envelope for many stored reports. The network selects the desired items with individual request flags, so it can ask for a Logged MDT report without also requesting every failure or mobility report. The request travels over DCCH using SRB1; a response containing ordinary logged measurement information uses SRB2, while Release 19 CSI log information for network-side data collection uses SRB6.

UEInformationRequest-r16-IEs ::= SEQUENCE {
    idleModeMeasurementReq-r16          ENUMERATED {true} OPTIONAL, -- Need N
    logMeasReportReq-r16                ENUMERATED {true} OPTIONAL, -- Need N
    connEstFailReportReq-r16            ENUMERATED {true} OPTIONAL, -- Need N
    ra-ReportReq-r16                    ENUMERATED {true} OPTIONAL, -- Need N
    rlf-ReportReq-r16                   ENUMERATED {true} OPTIONAL, -- Need N
    mobilityHistoryReportReq-r16        ENUMERATED {true} OPTIONAL, -- Need N
    lateNonCriticalExtension            OCTET STRING OPTIONAL,
    nonCriticalExtension                UEInformationRequest-v1700-IEs OPTIONAL
}

UEInformationRequest-v1700-IEs ::= SEQUENCE {
    successHO-ReportReq-r17             ENUMERATED {true} OPTIONAL, -- Need N
    coarseLocationRequest-r17           ENUMERATED {true} OPTIONAL, -- Need N
    nonCriticalExtension                UEInformationRequest-v1800-IEs OPTIONAL
}

UEInformationRequest-v1800-IEs ::= SEQUENCE {
    flightPathInfoReq-r18               FlightPathInfoReportConfig-r18 OPTIONAL, -- Need N
    successPSCell-ReportReq-r18         ENUMERATED {true} OPTIONAL, -- Need N
    reselectionMeasurementReq-r18       ENUMERATED {true} OPTIONAL, -- Need N
    validatedMeasurementsReq-r18        ENUMERATED {true} OPTIONAL, -- Need N
    nonCriticalExtension                UEInformationRequest-v1900-IEs OPTIONAL
}

UEInformationRequest-v1900-IEs ::= SEQUENCE {
    csi-LogMeasReportReq-r19            ENUMERATED {true} OPTIONAL, -- Need N
    nonCriticalExtension                SEQUENCE {} OPTIONAL
}

UEInformationResponse-r16-IEs ::= SEQUENCE {
    measResultIdleEUTRA-r16             MeasResultIdleEUTRA-r16 OPTIONAL,
    measResultIdleNR-r16                MeasResultIdleNR-r16 OPTIONAL,
    logMeasReport-r16                   LogMeasReport-r16 OPTIONAL,
    connEstFailReport-r16               ConnEstFailReport-r16 OPTIONAL,
    ra-ReportList-r16                   RA-ReportList-r16 OPTIONAL,
    rlf-Report-r16                      RLF-Report-r16 OPTIONAL,
    mobilityHistoryReport-r16           MobilityHistoryReport-r16 OPTIONAL,
    lateNonCriticalExtension            OCTET STRING OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1700-IEs OPTIONAL
}

UEInformationResponse-v1700-IEs ::= SEQUENCE {
    successHO-Report-r17                SuccessHO-Report-r17 OPTIONAL,
    connEstFailReportList-r17           ConnEstFailReportList-r17 OPTIONAL,
    coarseLocationInfo-r17              OCTET STRING OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1800-IEs OPTIONAL
}

UEInformationResponse-v1800-IEs ::= SEQUENCE {
    flightPathInfoReport-r18            FlightPathInfoReport-r18 OPTIONAL,
    successPSCell-Report-r18            SuccessPSCell-Report-r18 OPTIONAL,
    measResultReselectionNR-r18         MeasResultIdleNR-r16 OPTIONAL,
    nonCriticalExtension                UEInformationResponse-v1900-IEs OPTIONAL
}

UEInformationResponse-v1900-IEs ::= SEQUENCE {
    csi-LogMeasReport-r19               CSI-LogMeasReport-r19 OPTIONAL,
    nonCriticalExtension                SEQUENCE {} OPTIONAL
}

Logged measurement content

The conventional NR logged report follows a familiar pattern: identify the trace, provide an absolute time reference, and send a list of samples with relative timestamps. Within a sample, the UE can include serving-cell, NR-neighbor, E-UTRA-neighbor, location, and cell-selection information when available. Release 17 adds in-device coexistence context, and Release 19 can identify the NSAG and the cell to which the UE reselected.

LogMeasReport-r16 ::= SEQUENCE {
    absoluteTimeStamp-r16               AbsoluteTimeInfo-r16,
    traceReference-r16                  TraceReference-r16,
    traceRecordingSessionRef-r16        OCTET STRING (SIZE (2)),
    tce-Id-r16                          OCTET STRING (SIZE (1)),
    logMeasInfoList-r16                 LogMeasInfoList-r16,
    logMeasAvailable-r16                ENUMERATED {true} OPTIONAL,
    logMeasAvailableBT-r16              ENUMERATED {true} OPTIONAL,
    logMeasAvailableWLAN-r16            ENUMERATED {true} OPTIONAL,
    ...
}

LogMeasInfo-r16 ::= SEQUENCE {
    locationInfo-r16                    LocationInfo-r16 OPTIONAL,
    relativeTimeStamp-r16               INTEGER (0..7200),
    servCellIdentity-r16                CGI-Info-Logging-r16 OPTIONAL,
    measResultServingCell-r16           MeasResultServingCell-r16 OPTIONAL,
    measResultNeighCells-r16 SEQUENCE {
        measResultNeighCellListNR           MeasResultListLogging2NR-r16 OPTIONAL,
        measResultNeighCellListEUTRA        MeasResultList2EUTRA-r16 OPTIONAL
    },
    anyCellSelectionDetected-r16        ENUMERATED {true} OPTIONAL,
    ...,
    [[
    inDeviceCoexDetected-r17            ENUMERATED {true} OPTIONAL
    ]],
    [[
    nsag-ID-r19                         NSAG-ID-r17 OPTIONAL,
    reselectedCellId-r19                CGI-Info-Logging-r16 OPTIONAL
    ]]
}

Release 19 CSI logging

Release 19 adds a different kind of log for network-side data collection: connected-mode CSI logging. Instead of using the conventional idle/inactive Logged MDT sample format, the UE groups results first by cell and then by the CSI logging configuration that produced them. Each entry can contain per-resource CSI-RS or SSB L1-RSRP measurements, and csi-MoreLogMeasAvailable-r19 tells the network that another report part is still available.

CSI-LogMeasReport-r19 ::= SEQUENCE {
    csi-LogMeasInfoCellList-r19         CSI-LogMeasInfoCellList-r19,
    csi-MoreLogMeasAvailable-r19        ENUMERATED {true} OPTIONAL,
    ...
}

CSI-LogMeasInfoCell-r19 ::= SEQUENCE {
    cellId-r19 CHOICE {
        cellGlobalId-r19                    CGI-Info-Logging-r16,
        pci-arfcn-r19                       PCI-ARFCN-NR-r16
    },
    csi-LogMeasInfoConfigList-r19
        SEQUENCE (SIZE (1..maxNrofLoggedMeasurementConfigurations-r19))
        OF CSI-LogMeasInfoConfig-r19,
    ...
}

CSI-LogMeasInfoConfig-r19 ::= SEQUENCE {
    refCSI-LoggedMeasurementConfigId-r19 CSI-LoggedMeasurementConfigId-r19,
    csi-LogMeasInfoList-r19
        SEQUENCE (SIZE (1..maxLogCSI-MeasReport-r19)) OF CSI-LogMeasInfo-r19,
    ...
}

CSI-LogMeasInfo-r19 ::= SEQUENCE {
    csi-RS-MeasResultList-r19
        SEQUENCE (SIZE (1..maxNrofNZP-CSI-RS-Resources))
        OF CSI-RS-MeasResult-r19 OPTIONAL,
    ssb-MeasResultList-r19
        SEQUENCE (SIZE (1..maxNrofSSBs-r16))
        OF SSB-MeasResult-r19 OPTIONAL,
    timeGap-r19                         ENUMERATED {true} OPTIONAL,
    ...
}

Release 18 and 19 mobility diagnostics

Modern NR mobility can involve the MCG, SCG, PSCell changes, conditional procedures, and L1/LTM-based mobility. A simple success or failure flag is therefore not enough to explain what the UE experienced. The UE Information exchange returns detailed reports that correlate measurements with handover, PSCell, SCG, recovery, and timing behavior.

The table focuses on the Release 18 and Release 19 fields that add this newer mobility context.

Reference

The descriptions on this page combine the MDT stage-2 procedure in TS 37.320 with the LTE and NR RRC encodings in TS 36.331 and TS 38.331. TS 32.422 supplies the trace-management context, while the remaining references provide additional background or examples. For exact requirements and field conditions, use the cited 3GPP versions as the authoritative source.

• TS 37.320 V19.2.0 (2026-03) Radio measurement collection for Minimization of Drive Tests (MDT), especially clause 5.1.4 for UE capabilities.
• TS 36.331 V19.2.1 (2026-03) E-UTRA; Radio Resource Control (RRC); Protocol specification, especially clauses 5.6.5, 5.6.6, 6.2.2, and 6.3.6.
• TS 38.331 V19.3.0 (2026-06) NR; Radio Resource Control (RRC); Protocol specification, especially clauses 5.3.15, 5.7.5, 6.2.2, and 6.3.2.
• TS 32.422 Telecommunication management; Subscriber and equipment trace; Trace control and configuration management.
• Wireless Channel Characterization based on Crowdsourced Data and Geographical Features
• Quality Of Experience & Minimization of Drive Tests - Arimas
• Improving the Minimization Drive Tests using Voice Quality Index - (2013)
• Minimization of Drive Tests (MDT) in Mobile Communication Networks - (2014)
• 3GPP SON Series: Minimization of Drive Testing (MDT) - SlideShare (2022)