MDT for NR

MDT stands for Minimization of Drive Tests. The name says what it is for. Operators used to send a car with a test UE around the network to see where the coverage is weak and where calls drop. MDT replaces a large part of that work with measurements that ordinary UEs collect and report to the network. The general concept is the same as in LTE, and you can find it in the LTE MDT page. This page is about how the same idea works in NR, from Release 16 to Release 18.

In NR, MDT and SON are very closely related. They use the same RRC procedure (UE Information) to get data from the UE, and some reports such as the RLF report carry information for both of them. In this page I focus on the MDT side: Logged MDT, Immediate MDT and the accessibility measurement. The reports that are mainly used for SON, such as the RA report, the RLF report for MRO, SHR and SPR, are described in the SON for NR page.

• What is MDT ?
• Immediate MDT and Logged MDT
• Overall Procedure of Logged MDT
• Logged MDT Configuration
• What does UE log ?
• How network retrieves the log ?
• Overall Procedure of Immediate MDT
• Immediate MDT Measurements
• Accessibility Measurement - CEF Report
• MDT Information in RLF Report
• Release Evolution
• Reference

What is MDT ?

Why do we need MDT ? The basic reason is cost. A drive test needs a car, a driver, test equipment and an engineer, and it only covers the roads that the car can drive on. It does not show what happens inside buildings, at different times of the day, or with the real devices that users carry. MDT tries to get the same kind of information from the UEs that are already in the network.

In NR, there is one more reason. NR coverage is not only a matter of cell level signal strength. It also depends on beams. A drive test UE sees the beams only along its own route. With MDT, the network can collect the best beam index, the beam level RSRP and the number of good beams from a large number of UEs at many different locations. This kind of data is very hard to get from a drive test.

Then you may ask whether the UE can just send everything it measures. No, it cannot. The UE has limited battery and limited memory, and the network does not want to spend too much signalling on this. So MDT is built on a couple of constraints. The UE mostly reuses the measurements it already performs for RRM. The time when the UE collects the data is separated from the time when the UE reports it. And the network decides which UEs are selected, where they log, and for how long.

The other constraint is privacy. MDT data can include detailed location information, so it is controlled by user consent. The MDT task is started from the management system as a kind of trace job (TS 32.422), and the collected data is sent to a TCE (Trace Collection Entity). The gNB is the node that selects the UE and talks to it over RRC, but the gNB is not the final user of the data.

• MDT replaces part of the drive test: ordinary UEs collect radio measurements, time stamps and location, and the network collects them.
• NR MDT includes beam information: best SSB index, beam level RSRP/RSRQ and the number of good beams are logged in addition to cell level results.
• MDT is a trace function: it is started from OAM or from the core network, and the data goes to the TCE, not just to the gNB.

Immediate MDT and Logged MDT

There are two modes of MDT, and the mode is decided by the RRC state of the UE. The question is simple. Is the UE connected right now, so that it can report immediately, or is it in idle or inactive, so that it has to keep the measurement and report it later ? The two modes use quite different RRC mechanisms, so it is good to separate them clearly from the beginning.

Figure 1 shows the overall picture. The MDT task comes down to the gNB either from OAM or from the core network. The gNB configures the UE. A UE in RRC_CONNECTED does Immediate MDT using the normal measurement configuration and measurement report. A UE in RRC_IDLE or RRC_INACTIVE does Logged MDT using a separate logging configuration, and it reports the log only after it comes back to RRC_CONNECTED. In both cases the gNB sends the result to the TCE.

Figure 1. Immediate MDT and Logged MDT. Both are started from OAM or from the core network and both end at the TCE. The difference is the UE state, and so the RRC message that carries the result.

• Immediate MDT: there is no special MDT message. The gNB uses the normal MeasConfig and MeasurementReport, and the UE adds location information when it is available. The gNB adds its own measurements, and the time stamp comes from the gNB, not from the UE.
• Logged MDT: the gNB sends LoggedMeasurementConfiguration while the UE is in RRC_CONNECTED. The configuration becomes active only after the UE goes to RRC_IDLE or RRC_INACTIVE. The log is pulled later with UEInformationRequest.
• Accessibility measurement: this is neither immediate nor logged in the strict sense. The UE logs a failed RRC setup or resume without any prior configuration. It is described in Accessibility Measurement - CEF Report.

Signalling based and Management based MDT

The arrows at the top of Figure 1 are two different ways to start the same task, and the difference matters when you look at a trace. Signalling based MDT targets one specific UE, for example by its SUPI or IMEI. The core network sends the MDT configuration to the gNB in NGAP, for example in Initial Context Setup or Trace Start. Management based MDT does not target a specific UE. OAM activates it in a group of cells, and the gNB picks the UEs by itself, among the UEs that the core network marks as allowed (Management Based MDT PLMN List).

This difference also changes what happens at mobility. A signalling based configuration for one UE propagates at intra-PLMN handover, at Secondary Node addition and at UE context retrieval. A management based configuration does not propagate. So if you configure management based MDT in some cells, the UE drops out of the task when it moves to another gNB.

Then you may ask what happens if the UE already has a signalling based logged MDT configuration, and a gNB in a management based task tries to configure it again. The new configuration would overwrite the old one, and the signalling based log would be lost. To avoid this, Release 17 added sigLoggedMeasType in the configuration. The UE remembers that its current configuration is signalling based, and it tells the network about it in sigLogMeasConfigAvailable. Then the gNB knows that it should not overwrite.

Overall Procedure of Logged MDT

Logged MDT is the part that is really new compared to normal RRM. The UE gets the configuration in one RRC connection, does the logging while it is not connected, and reports the log in another RRC connection, possibly in another cell. So the question in this section is how the UE and the network keep track of the configuration and the log over this long time.

Figure 2 shows the whole life of one logging session on a time line. The configuration arrives in RRC_CONNECTED and starts T330. The UE logs at every logging interval while it is in RRC_IDLE or RRC_INACTIVE. When the UE comes back to RRC_CONNECTED, it says that it has a log. The network then asks for the log, and the UE sends it.

Figure 2. Time line of one Logged MDT session. Configuration, logging and reporting happen in three different periods, and T330 is the only thing that ties the logging period together.

• Configuration replaces everything: when the UE receives LoggedMeasurementConfiguration, it first discards the old configuration and the old log, even if the old log was never retrieved. There is only one logged measurement configuration in the UE. So the network has to retrieve any useful log before it sends a new configuration.
• T330 is the logging duration: the UE starts T330 with loggingDuration. When T330 expires, the UE releases VarLogMeasConfig, but it keeps VarLogMeasReport.
• The log survives 48 hours: the UE is allowed to discard the log 48 hours after T330 expiry. The UE also clears everything at power off or deregistration.
• Logging is in RRC_IDLE and RRC_INACTIVE only: in NR, the logging can start in RRC_INACTIVE and continue in RRC_IDLE, or the other way around. While the UE is in RRC_CONNECTED, the logging pauses, but T330 keeps running.
• The report can be partial: if the log is too big for one message, the UE sends the oldest entries first and sets logMeasAvailable to tell that more is left. Retrieving the log does not stop the logging, if T330 is still running.

Logged MDT Configuration

Now let's look at the configuration message itself. LoggedMeasurementConfiguration is a separate DL-DCCH message, and it is not a part of RRCReconfiguration. It is sent on SRB1 and it has no response message. The UE just stores it. So if you look for a "complete" message after it in a log, you would not find one.

There are many fields in this message, but they fall into three groups. The first group is the trace identity, which tells the network where the report should go later. The second group is the scope, which tells the UE where to log. The third group is the timing, which tells the UE when to log and for how long. For now, just pay attention to loggingDuration and reportType. They decide the shape of the log.

Following is based on 38.331 v19.4.0 (Release 19)

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
}

LoggedPeriodicalReportConfig-r16 ::=            SEQUENCE {
    loggingInterval-r16                             LoggingInterval-r16,
    ...
 }

LoggedEventTriggerConfig-r16 ::=                SEQUENCE {
    eventType-r16                                   EventType-r16,
    loggingInterval-r16                             LoggingInterval-r16,
    ...
}

EventType-r16 ::= CHOICE {
    outOfCoverage     NULL,
    eventL1           SEQUENCE {
        l1-Threshold      MeasTriggerQuantity,
        hysteresis        Hysteresis,
        timeToTrigger     TimeToTrigger
    },
    ...
}

LoggingDuration-r16 ::=   ENUMERATED {
                              min10, min20, min40, min60, min90, min120, spare2, spare1}

LoggingInterval-r16 ::=   ENUMERATED {
                              ms320, ms640, ms1280, ms2560, ms5120, ms10240, ms20480,
                              ms30720, ms40960, ms61440 , infinity}

AreaConfiguration-r16 ::=        SEQUENCE {
    areaConfig-r16                   AreaConfig-r16,
    interFreqTargetList-r16          SEQUENCE(SIZE (1..maxFreq)) OF InterFreqTargetInfo-r16              OPTIONAL  -- Need R
}

AreaConfig-r16 ::=               CHOICE {
    cellGlobalIdList-r16             CellGlobalIdList-r16,
    trackingAreaCodeList-r16         TrackingAreaCodeList-r16,
    trackingAreaIdentityList-r16     TrackingAreaIdentityList-r16
}

AreaConfiguration-r17 ::=        SEQUENCE {
    areaConfig-r17                   AreaConfig-r16                                                      OPTIONAL, -- Need R
    interFreqTargetList-r17          SEQUENCE(SIZE (1..maxFreq)) OF InterFreqTargetInfo-r16              OPTIONAL  -- Need R
}

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

• traceReference / traceRecordingSessionRef / tce-Id: these come from OAM (TS 32.422). The UE does not use them. It just echoes them back in the report, so that any gNB that retrieves the log can route it to the right TCE, even if that gNB never saw the configuration.
• absoluteTimeInfo: the network time when the configuration is given. Every log entry carries only a relativeTimeStamp in seconds from this point. The UE echoes the absolute time back as absoluteTimeStamp.
• areaConfiguration: the logging area. It is a list of up to 32 cell global IDs, or up to 8 TACs / TAIs. If it is absent, the UE logs everywhere in the PLMNs of the MDT PLMN list. interFreqTargetList limits which neighbour frequencies and cells are included in the log.
• plmn-IdentityList: the MDT PLMN list. The UE logs and reports only when the RPLMN is in this list (together with the RPLMN at configuration time).
• bt-NameList / wlan-NameList / sensor-NameList: these ask the UE to also log Bluetooth beacons, WLAN APs and sensor information (barometric pressure, speed, orientation). They are mainly for indoor location.
• loggingDuration: the value of T330, from 10 minutes to 120 minutes.
• reportType: periodical logs at every loggingInterval. eventTriggered logs at every loggingInterval only while the event condition is met. Only one type can be configured at a time.
• eventType: outOfCoverage logs while the UE is in any cell selection state, and once more when it comes back to camped normally. eventL1 logs while the serving cell quantity is below l1-Threshold, with hysteresis and time to trigger.
• sigLoggedMeasType-r17: marks the configuration as signalling based, so that a later management based configuration does not overwrite it.
• earlyMeasIndication-r17: allows the UE to include results on the early measurement frequencies (measIdleCarrierListNR) in the log, in addition to the SIB4 frequencies.
• areaConfiguration-r17: the same structure as the Release 16 one, but areaConfig is now optional. So the network can send only interFreqTargetList without restricting the logging area.
• areaConfiguration-v1800: Release 18 logging area for non-public networks, as a CAG list or an SNPN list.
• areaConfigurationNTN-List-r19: Release 19 geographical logging area (polygon or circle) for NTN. It is outside the Release 16 to 18 scope of this page, but you will see it in the latest ASN.1.

What does UE log ?

The UE has the configuration and it is in RRC_IDLE or RRC_INACTIVE. Then what does the UE actually write in each log entry ? One thing to keep in mind is that the UE does not perform any extra measurement for MDT. It logs the latest results that it already has for cell reselection, as specified in TS 38.133. So the content of the log depends on the reselection configuration in SIB2, SIB4 and SIB5 at that location.

The UE state also matters. In camped normally state, the UE logs normally. In any cell selection state, the UE has no serving cell to measure, so it logs what is available: a time stamp, location and the anyCellSelectionDetected flag. In camped on any cell state, the UE is not required to log at all. Logging resumes when the UE goes back to camped normally, and you would see a jump in the time stamps.

The following listing is the report format. Each LogMeasInfo-r16 is one log entry, and the report is a list of these entries with the trace identity in front.

Following is based on 38.331 v19.4.0 (Release 19)

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
    ]]
}

• relativeTimeStamp: seconds from absoluteTimeInfo. For periodic logging it is the moment the logging interval expires. The range 0 to 7200 s is exactly the 120 minute maximum of loggingDuration.
• locationInfo: detailed location such as GNSS, plus Bluetooth, WLAN and sensor results, if available. The UE uses a location fix only once, with the next log entry, and then discards it. So the validity of one location fix is one logging interval.
• servCellIdentity / measResultServingCell: the camping cell, with RSRP and RSRQ. In NR the serving cell result also includes the best SSB index with its RSRP/RSRQ and the number of good beams above absThreshSS-BlocksConsolidation.
• measResultNeighCells: up to 6 cells on the serving frequency, up to 3 cells per NR neighbour frequency and up to 3 cells per E-UTRA frequency, in order of the reselection ranking. A cell result is included only if it was not already reported.
• anyCellSelectionDetected: the UE could not find a suitable or acceptable cell. For event triggered logging with outOfCoverage, this is the main information of the log.
• inDeviceCoexDetected-r17: when the UE detects an in-device coexistence problem, its measurements may be wrong. The UE sets this flag and suspends the logging from the next interval. It resumes when the problem is resolved. T330 keeps running during the suspension.
• nsag-ID-r19 / reselectedCellId-r19: Release 19 slice based reselection information. The UE could not camp on a cell with the highest priority NSAG and reselected another cell.

The neighbour limits and the "only if not already reported" rule look like small details. But they explain a common question when you read a real log: why the same strong neighbour appears in one entry and disappears in the next one. The UE did not lose the cell. It simply had no new reselection result for it in that interval.

How network retrieves the log ?

The UE now has a log in its memory. But the network does not know this, because the UE may come back in a completely different cell, maybe on a gNB that never configured it. So the retrieval is done in two steps. First the UE says that it has something. Then the network asks for it. This two-step method is not specific to Logged MDT. The same mechanism is used for the RLF report, the CEF report, SHR and SPR, which is why this section is shared with the SON for NR page.

Availability indication

The first step is a set of one bit flags called UE-MeasurementsAvailable-r16. The UE includes them in RRCSetupComplete, RRCResumeComplete, RRCReestablishmentComplete and RRCReconfigurationComplete. The UE sets a flag only when the current RPLMN is allowed for that information. One thing you would notice is that there is no flag for the RA report. The network has to request the RA report without knowing whether the UE has one.

Following is based on 38.331 v19.4.0 (Release 19)

UE-MeasurementsAvailable-r16 ::=              SEQUENCE {
    logMeasAvailable-r16                         ENUMERATED {true}               OPTIONAL,
    logMeasAvailableBT-r16                       ENUMERATED {true}               OPTIONAL,
    logMeasAvailableWLAN-r16                     ENUMERATED {true}               OPTIONAL,
    connEstFailInfoAvailable-r16                 ENUMERATED {true}               OPTIONAL,
    rlf-InfoAvailable-r16                        ENUMERATED {true}               OPTIONAL,
    ...,
    [[
    successHO-InfoAvailable-r17                  ENUMERATED {true}               OPTIONAL,
    sigLogMeasConfigAvailable-r17                BOOLEAN                         OPTIONAL
    ]],
    [[
    successPSCell-InfoAvailable-r18              ENUMERATED {true}               OPTIONAL
    ]]

}

• logMeasAvailable: the UE has a Logged MDT log. The BT and WLAN variants mean the log has Bluetooth or WLAN results.
• connEstFailInfoAvailable: the UE has a CEF report. See Accessibility Measurement - CEF Report.
• rlf-InfoAvailable: the UE has an RLF report. See RLF Report in the SON page.
• successHO-InfoAvailable-r17 / successPSCell-InfoAvailable-r18: the UE has an SHR or an SPR. See SHR and SPR in the SON page.
• sigLogMeasConfigAvailable-r17: the UE has a signalling based logged MDT configuration, or an unretrieved signalling based log. This is the flag that protects it from being overwritten by management based MDT.

UEInformationRequest and UEInformationResponse

The second step is the UE Information procedure. The network sends UEInformationRequest with one request flag per report type, and the UE answers with UEInformationResponse. The network should start this only after security activation, and the UE answers only after security activation. You may notice that every report type has its own request flag, so the network can ask for one report or for several at once.

Following is based on 38.331 v19.4.0 (Release 19)

UEInformationRequest-r16 ::=     SEQUENCE {
    rrc-TransactionIdentifier        RRC-TransactionIdentifier,
    criticalExtensions               CHOICE {
        ueInformationRequest-r16         UEInformationRequest-r16-IEs,
        criticalExtensionsFuture         SEQUENCE {}
    }
}

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 ::=        SEQUENCE {
    rrc-TransactionIdentifier            RRC-TransactionIdentifier,
    criticalExtensions                   CHOICE {
        ueInformationResponse-r16            UEInformationResponse-r16-IEs,
        criticalExtensionsFuture             SEQUENCE {}
    }
}

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
}

• logMeasReportReq / logMeasReport: Logged MDT. The UE includes entries from the oldest one, and adds logMeasAvailable inside the report if some entries are left. The network can send another request to get the rest.
• connEstFailReportReq / connEstFailReport: accessibility measurement. Release 17 adds connEstFailReportList-r17 for up to 4 reports.
• ra-ReportReq / rlf-ReportReq / successHO-ReportReq / successPSCell-ReportReq: the SON reports. The content is explained in the SON for NR page.
• mobilityHistoryReportReq: the list of recently visited cells and the time spent in each. This is also used for SON (UE History Information).
• idleModeMeasurementReq: the early measurement results collected in idle or inactive for fast CA/DC setup. This is not MDT, but it uses the same message.
• coarseLocationRequest-r17, flightPathInfoReq-r18, csi-LogMeasReportReq-r19: other information that later releases put into the same container. The CSI logging of Release 19 is for network side data collection (AI/ML beam prediction).

Which SRB carries the response ? This is easy to miss. If logMeasReport is included, the UE sends UEInformationResponse on SRB2, because a log can be big and it is not urgent. If csi-LogMeasReport is included, it goes on SRB6. Otherwise it goes on SRB1. The UE discards a report from its memory only after the lower layers confirm the delivery, so a lost response does not lose the log.

Overall Procedure of Immediate MDT

Logged MDT needs its own configuration message, its own timer and its own retrieval. Immediate MDT has none of these. So you may wonder whether there is any procedure to talk about at all. There is, but most of it happens on the network side. The RRC part reuses the normal measurement framework, and the interesting questions are how the MDT task reaches the gNB, what the gNB does with it, and where the results go.

Figure 3 shows a signalling based Immediate MDT session for one UE. The MDT configuration comes from the AMF inside the Trace Activation IE. The gNB turns the UE part of it into a normal measurement configuration in RRCReconfiguration. The UE reports in MeasurementReport and PHR, as it would for RRM. The gNB adds its own counters and the time stamp, and sends the records to the TCE. For management based MDT, step 1 comes from OAM instead of the AMF, and the gNB picks the UE by itself.

Figure 3. Signalling based Immediate MDT. RRC carries only a normal measurement configuration and normal reports. The MDT session itself is between the core network, the gNB and the TCE.

• Trace Activation carries the MDT task: in NGAP, the MDT Configuration IE is an extension of the Trace Activation IE. It can arrive in INITIAL CONTEXT SETUP REQUEST, TRACE START or HANDOVER REQUEST (38.413).
• MDT Activation says which mode: the values are immediate-MDT-only, logged-MDT-only and immediate-MDT-and-Trace. For the two MDT-only values, the gNB ignores the Interfaces To Trace and Trace Depth IEs.
• Measurements to Activate is a bitmap: 8 bits. The first bit is M1, then M2, M4, M5, M6 and M7. The seventh bit asks the gNB to log M1 from the event triggered reports of the existing RRM configuration. M1 Configuration gives the trigger (periodic, a2eventtriggered or a2eventtriggered-periodic), with the A2 threshold and the periodic reporting parameters.
• Area scope is checked by the gNB: cell based, TA based, TAI based or PLMN wide. The gNB configures the UE only while the UE is connected to a cell inside the area scope. The UE is not told about the area.
• The UE does not know it is MDT: steps 3 to 6 are normal RRM signalling. The only hints are the location and delay related fields in the report configuration, shown below.
• The time stamp comes from the gNB: Immediate MDT reports have no UE time stamp. The gNB stamps the records, and the TCE correlates them with the other MDT data by time.

Then how is a measurement configuration for MDT different from a normal one ? The difference is a few Release 16 and Release 17 fields in the report configuration. They ask the UE to attach location, WLAN, Bluetooth and sensor results to its reports, or to measure the UL PDCP delay. Following is PeriodicalReportConfig. EventTriggerConfig has the same location fields, so an A2 based M1 report can carry location too.

Following is based on 38.331 v19.4.0 (Release 19)

PeriodicalReportConfig ::=                  SEQUENCE {
    rsType                                      NR-RS-Type,
    reportInterval                              ReportInterval,
    reportAmount                                ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity},
    reportQuantityCell                          MeasReportQuantity,
    maxReportCells                              INTEGER (1..maxCellReport),
    reportQuantityRS-Indexes                    MeasReportQuantity                                             OPTIONAL,   -- Need R
    maxNrofRS-IndexesToReport                   INTEGER (1..maxNrofIndexesToReport)                            OPTIONAL,   -- Need R
    includeBeamMeasurements                     BOOLEAN,
    useAllowedCellList                          BOOLEAN,
    ...,
    [[
    measRSSI-ReportConfig-r16                   MeasRSSI-ReportConfig-r16                                      OPTIONAL,   -- Need R
    includeCommonLocationInfo-r16               ENUMERATED {true}                                              OPTIONAL,   -- Need R
    includeBT-Meas-r16                          SetupRelease {BT-NameList-r16}                                 OPTIONAL,   -- Need M
    includeWLAN-Meas-r16                        SetupRelease {WLAN-NameList-r16}                               OPTIONAL,   -- Need M
    includeSensor-Meas-r16                      SetupRelease {Sensor-NameList-r16}                             OPTIONAL,   -- Need M
    ul-DelayValueConfig-r16                     SetupRelease { UL-DelayValueConfig-r16 }                       OPTIONAL,   -- Need M
    reportAddNeighMeas-r16                      ENUMERATED {setup}                                             OPTIONAL    -- Need R
    ]],
    [[
    ul-ExcessDelayConfig-r17                    SetupRelease { UL-ExcessDelayConfig-r17 }                      OPTIONAL,   -- Need M
    coarseLocationRequest-r17                   ENUMERATED {true}                                              OPTIONAL,   -- Need R
    reportQuantityRelay-r17                     SL-MeasReportQuantity-r16                                      OPTIONAL    -- Need R
    ]]
}

Not every field in this listing is about MDT, and this is easy to get wrong because they all sit in the same extension groups. Only six fields are MDT related. The fields before the ... marker are ordinary RRM reporting fields. M1 reuses them, but they existed before MDT and they are not MDT fields. The table below lists the six MDT fields and the MDT measurement each one serves.

The other fields in the extension groups look similar, but they belong to other features. One of them I could not place with confidence, so I mark it as such rather than guess.

• Base fields are RRM: rsType, reportInterval, reportAmount, reportQuantityCell, maxReportCells, the RS index fields, includeBeamMeasurements and useAllowedCellList are normal periodic reporting. An MDT specific M1 configuration uses them for its period and quantities, but they are not MDT fields.
• measRSSI-ReportConfig-r16 is NR-U: RSSI and channel occupancy measurement for unlicensed operation. It is RRM, even though the name contains RSSI like M8.
• coarseLocationRequest-r17 is NTN: it asks for coarse UE location, the most significant bits of the GNSS coordinates with an accuracy of about 2 km (38.300 clause 16.14.8). It is location, but not MDT location.
• reportQuantityRelay-r17 is sidelink relay: the measurement quantity of an L2 U2N relay UE.
• reportAddNeighMeas-r16 is not confirmed: 38.331 only says that the UE includes the best neighbour cells per serving frequency. Neither 37.320 nor 38.300 names it as an MDT field, so it is left out of the table above.

What happens to the session at handover ? Immediate MDT measurements follow the normal rules for RRM measurements at handover. The target gNB releases any MDT measurement that its own trace configuration no longer needs. The way the session was started decides whether the target gets that trace configuration. As described in Signalling based and Management based MDT, a signalling based configuration is passed on in the Trace Activation IE of HANDOVER REQUEST. A management based configuration is not passed on. So at the boundary of the management based area, the target simply stops configuring the UE for MDT.

Immediate MDT Measurements

Immediate MDT does not have its own RRC message, so the question here is a different one. Which measurements are counted as Immediate MDT, and who performs each of them ? Some of them are performed by the UE and reported over RRC or MAC. Others are performed by the gNB alone. The gNB combines them with the time stamp and the location and sends them to the TCE.

TS 37.320 names them M1 to M10. The table below lists them together with what triggers the collection. Look at the second column first. Only M1, M2, M8, M9 and M10 involve the UE. The rest are network side counters per DRB.

• M1 is just RRM measurement reporting: the gNB can reuse the reports it gets for handover, or add a measurement configuration only for MDT. Detailed location is added to the report when the UE has it.
• M2 comes from MAC, not RRC: PHR is a MAC CE, so the normal PHR configuration applies.
• M4 to M7 can be for MR-DC: they apply to MN terminated and SN terminated MCG, SCG and split bearers. For the UL PDCP delay of a split bearer, only the terminating node configures it and gets the result.
• M10 is a newer item: it is immediate MDT with logging of L1 measurements in RRC_CONNECTED, used for beam prediction data collection. It belongs to Release 19 work.

In MR-DC, the MN and the SN can configure Immediate MDT independently. In signalling based MDT, the MN gets the configuration for both nodes and forwards the NR part to the SN. If OAM gives an "MN only" indication, only the MN does it.

Accessibility Measurement - CEF Report

Logged MDT and Immediate MDT need a configuration first. But some of the most important problems happen when the UE cannot even get connected. Think of a UE that sends RRCSetupRequest again and again and never gets RRCSetup. There is no RRC connection, so nobody can configure anything for it. How can the network learn about this failure ?

The answer is the Connection Establishment Failure (CEF) report. The UE creates the log by itself, without any configuration, when an RRC setup or an RRC resume fails. In NR the trigger is T300 expiry for setup and T319 expiry for resume. The UE reports it in a later connection, when the network asks with connEstFailReportReq.

Following is based on 38.331 v19.4.0 (Release 19)

ConnEstFailReport-r16 ::=            SEQUENCE {
    measResultFailedCell-r16             MeasResultFailedCell-r16,
    locationInfo-r16                     LocationInfo-r16                    OPTIONAL,
    measResultNeighCells-r16             SEQUENCE {
        measResultNeighCellListNR            MeasResultList2NR-r16               OPTIONAL,
        measResultNeighCellListEUTRA         MeasResultList2EUTRA-r16            OPTIONAL
    },
    numberOfConnFail-r16                 INTEGER (1..8),
    perRAInfoList-r16                            PerRAInfoList-r16,
    timeSinceFailure-r16                 TimeSinceFailure-r16,
    ...
}

• measResultFailedCell: the global cell ID and the latest measurement of the cell that the UE tried to access, including the SSB beam results.
• numberOfConnFail: the number of consecutive failures in the same cell, independent of RRC state transitions. One bad attempt and eight bad attempts are very different problems.
• perRAInfoList: the RACH attempt details, in the same format as the RA report. For each tried SSB, the UE tells how many preambles it sent, whether contention was detected, and whether the SSB RSRP was above rsrp-ThresholdSSB. The format is explained in RACH Report in the SON page.
• timeSinceFailure: seconds since the failure, set when the UE sends the report.

Release 17 extended this to up to 4 CEF reports (maxCEFReport-r17). Why more than one ? The typical case is UL/DL imbalance. The UE sees a strong DL from several cells, and it fails the access in one cell after another because its UL cannot reach any of them. One report shows only the last cell. With a list, the network can see that the failure is moving from cell to cell. Failures in different cells become separate entries. Repeated failures in the same cell stay in one entry and increase numberOfConnFail.

The CEF report is listed under MDT in TS 37.320, but you can see that it is equally useful for RACH optimization. This is one of many places where the line between MDT and SON is not sharp.

MDT Information in RLF Report

The RLF report is usually explained as a SON tool, and it is described in detail in RLF Report in the SON page. But TS 37.320 also defines the RLF report as an MDT measurement. So which part of it is MDT ? Basically, it is the part that tells where the UE was and what the radio looked like when the connection failed.

The MDT content of the NR RLF report is the following. These are the fields that the TCE uses to put the failure on a coverage map. The MRO part, such as which cell the UE came back to and how long after the handover the failure happened, is used by the gNB for parameter tuning, and it is explained on the SON page.

• Last radio measurements: results of the serving cell and neighbour cells, including SSB / CSI-RS index level results. The quantities are RSRP, RSRQ and SINR, sorted by the same RS type when available.
• RLM beams: csi-rsRLMConfigBitmap-v1650 shows which CSI-RS beams were configured for RLM. Without it, you cannot tell whether the beam that failed was the one the UE was monitoring.
• No suitable cell found: noSuitableCellFound is set when T311 expires. This means the UE was really out of coverage, not just on a bad cell.
• Location and sensors: latitude and longitude, with altitude, velocity, uncertainty, confidence and direction when available. Sensor results, WLAN and Bluetooth results can also be included.
• RACH failure details: when the RLF cause is random access problem or beam failure recovery failure, the report includes ra-InformationCommon with the tried beams and the attempt details.
• CHO candidates: for CHO, the latest measurements of the candidate target cells (Release 17).

Release Evolution

NR MDT came in Release 16 together with NR SON, in the same work item. Release 17 and Release 18 did not change the basic architecture. They filled the gaps that operators found in the first version: overwriting between management and signalling based MDT, NPN support, and better coverage of newer features. The table below is a summary from Release 16 to Release 18. The Release 19 items in the latest ASN.1 are listed in the last row only for reference.

Reference

• 3GPP TS 37.320 V19.4.0 : Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2
• 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. Clause 5.5a (Logged Measurements), Clause 5.7.10 (UE Information)
• 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 15.5
• MDT for LTE (ShareTechnote)
• SON for NR (ShareTechnote)