5 Functions and procedures
37.3203GPPOverall descriptionRadio measurement collection for Minimization of Drive Tests (MDT)Release 17Stage 2TS
5.1 General procedures
5.1.1 Logged MDT procedures
Support of Logged MDT complies with the principles for IDLE and INACTIVE state measurements in the UE specified in TS 25.133[2], TS 36.133 [3] and TS 38.133 [16] and principles for IDLE and CONNECTED mode MBSFN measurements in the UE specified in TS 36.133 [3].
NOTE: It should be noted the established principles may result in different logged information in different UEs.
Furthermore, measurement logging is differentiated based on UE states in idle mode i.e. camped normally, any cell selection or camped on any cell. The UE shall perform measurement logging in "camped normally" state and "any cell selection" state. In "camped on any cell" state the UE is not required to perform MDT measurement logging (including time and location information).
For Logged MDT, the configuration will always be done in cells of the same RAT type. However, measurements included in the logged MDT report comprises of measurements from the same RAT type (serving cell measurements, intra-frequency and inter-frequency neighbor cell measurements) and different RAT types (inter-RAT neighbor cell measurements).
Logging of MBSFN measurements is only applicable to E-UTRA.
5.1.1.1 Measurement configuration
Logged MDT measurements are configured with a MDT Measurement Configuration procedure, as shown in Figure 5.1.1.1-1.
Figure 5.1.1.1-1: MDT measurement configuration for Logged MDT
Network initiates the procedure to UE in RRC Connected by sending LoggedMeasurementConfiguration message, which is used to transfer configuration parameters for Logged MDT. This is a unidirectional RRC signalling procedure.
A release operation for logged measurement configuration in the UE is realized only by configuration replacement when the configuration is overwritten or by configuration clearance in case a duration timer stopping or expiration condition is met.
5.1.1.1.1 Configuration parameters
The logged measurement configuration consists of:
– configuration of downlink pilot strength measurements logging for (E-)UTRA and NR.
– configuration of MBSFN measurement logging for E-UTRA.
– configuration of the triggering of logging events:
– for (E-)UTRAN:
– periodic measurement trigger is supported, for which the logging interval is configurable. The parameter specifies the periodicity for storing MDT measurement results. It should be configured in seconds in multiples of the applied IDLE mode DRX, i.e. multiples of 1.28s which is either a factor or multiple of the IDLE mode DRX. The UE behaviour is unspecified when the UE is configured with a DRX cycle larger than the logging interval.
– for NR:
– periodic measurement trigger is supported, for which the logging interval is configurable. The parameter specifies the periodicity for storing MDT measurement results.
– for E-UTRAN and NR:
– event-based trigger is supported, for which the logging interval is configurable, which determines periodical logging of available data (e.g. time stamp, location information), and the following two types of events are supported:
– measurement quantity-based event L1, for which the event threshold, hysteresis, and time to trigger are configurable. If the configured time to trigger is not a multiple of the DRX cycle, then the UE uses the next multiple of DRX cycle duration that is larger than the time to trigger for evaluating the event L1;
– out-of-coverage detection trigger.
NOTE: The logging configuration for event-based and periodical DL pilot strength logged measurements can be configured independently. Only one type of event can be configured to the UE.
– configuration of the logging duration. This configuration parameter defines a timer activated at the moment of configuration, that continues independent of state changes, RAT or RPLMN change. When the timer expires the logging is stopped and the configuration is cleared (except for the parameters that are required for further reporting e.g. network absolute time stamp, trace reference, trace recording session reference and TCE Id).
– network absolute time stamp to be used as a time reference to UE.
– Trace Reference parameter as indicated by the OAM configuration as specified in TS 32.422 [6].
– Trace Recording Session Reference as indicated by the OAM configuration as specified in TS 32.422 [6].
– TCE Id as indicated by the OAM configuration as specified in TS 32.422 [6].
– (optionally) MDT PLMN List, indicating the PLMNs where measurement collection and log reporting is allowed. It is either the Management Based MDT PLMN List or the Signalling Based MDT PLMN List, depending on how the Logged MDT task was initiated (see 5.1.3).
– (optionally) configuration of a logging area. A UE will log measurements as long as it is within the configured logging area. The scope of the logging area may consist of one of:
– a list of up to 32 global cell identities. If this list is configured, the UE will only log measurements when camping in any of these cells.
– a list of up to 8 TAs or 8 LAs or 8 RAs. If this list is configured, the UE will only log measurements when camping in any cell belonging to the preconfigured TA/LA/RAs.
– for NR, a list of inter-frequency neighbouring cells per frequency.
– The configured logging area can span PLMNs in the MDT PLMN List. If no area is configured, the UE will log measurements throughout the PLMNs of the MDT PLMN list.
– (optionally) for NR, configuration of a list of neighbouring frequencies and/or cells, indicating the UE to include neighbouring cell’s measurements as indicated in the list in the logged MDT report.
– (optionally) for E-UTRA, configuration of target MBSFN area(s) for MBSFN measurement logging. If target MBSFN area(s) is configured, UE applies it in addition to other restrictions such as the logging area. The UE will log measurements as long as it receives MBMS service from an indicated target MBSFN area and is within the configured logging area. The target MBSFN area(s) is defined by a list of up to 8 entries, where each entry indicates a carrier frequency and optionally indicates a specific MBSFN area on a carrier frequency.
– (optionally) configuration of the WLAN access point names, indicating the UE to attempt to obtain WLAN measurements associated to these access points.
– (optionally) configuration of the Bluetooth beacon names, indicating the UE to attempt to obtain Bluetooth measurements associated to these beacons.
– (optionally) for NR, configuration of the sensor names, indicating the UE to attempt to obtain sensor measurements.
– (optionally) for E-UTRA, configuration indicating the UE to attempt to obtain uncompensated barometric pressure measurements.
– (optionally) for NR, the network can use a flag to indicate if an early measurement/idle mode configuration has relevance for logged measurement purposes, indicating the UE is allowed to log the measurement results related to early measurement frequencies in the logged MDT report.
– (optionally) for NR, logged MDT type flag, indicating the logged measurement configuration is the signalling based MDT (see 5.1.3).
5.1.1.1.2 Configuration effectiveness
The logged measurement configuration is provided in a cell by dedicated control while UE is in CONNECTED and implies:
– logged measurement configuration for downlink pilot strength measurements (or events) logging is active
– in IDLE UE state in E-UTRAN, or
– in IDLE mode, CELL_PCH and URA_PCH states in UTRAN, or
– in CELL_FACH state when second DRX cycle is used in UTRAN, or
– in IDLE and INACTIVE states in NR
– until logging duration timer expires or stops
– logged measurement configuration for MBSFN measurement logging is active
– in IDLE and CONNECTED UE states in E-UTRAN
– until logging duration timer expires or stops
– logged measurement configuration and logs are maintained when the UE is in any state as described above, despite multiple periods interrupted by UE state transitions, e.g. for downlink pilot strength measurements when the UE is in CONNECTED state for E-UTRAN and NR and CELL_DCH, CELL_FACH state when second DRX cycle is not used in UTRAN
– logged measurement configuration and logs are maintained when the UE is in any state as described above in that RAT, despite multiple periods interrupted by UE presence in another RAT
There is only one RAT-specific logged measurement configuration for Logged MDT in the UE. When the network provides a configuration, any previously configured logged measurement configuration will be entirely replaced by the new one. Moreover, logged measurements corresponding to the previous configuration will be cleared at the same time. It is left up to the network to retrieve any relevant data before providing a new configuration.
NOTE: The network may have to do inter-RAT coordination.
When a logging area is configured, logged MDT measurements are performed as long as the UE is within this logging area. For NR, when determining whether a cell is part of the logging area, only the first entry of the plmn-IdentityList in the first entry of the PLMN-IdentityInfoList (in SIB1), and cellIdentity and TAC corresponding to the first entry of the PLMN-IdentityInfoList are considered. If no logging area is configured, logged MDT measurements are performed as long as the RPLMN is part of the MDT PLMN list. When the UE is not in the logging area or RPLMN is not part of the MDT PLMN list, the logging is suspended, i.e. the logged measurement configuration and the log are kept but measurement results are not logged. In addition, for MBSFN logged measurements, logged MDT measurements are performed in logging intervals when the UE receives MBMS service from a MBSFN area according to the target MBSFN area(s) configuration When the UE is not in the logging area or does not receive MBMS service from a MBSFN area that matches the target MBSFN area(s) configuration in the logging interval the logged measurement configuration and the log are kept but measurement results are not logged.
NOTE: The logging duration timer continues.
In case the new PLMN that does not belong to the MDT PLMN list provides a logged measurement configuration any previously configured logged measurement configuration and corresponding log are cleared and overwritten without being retrieved.
5.1.1.2 Measurement collection
In "camped normally" state, a UE shall perform logging as per the logged measurement configuration. This state includes a period between cell selection criteria not being met and UE entering "any cell selection" state, i.e. 10 s for E-UTRA (See TS 36.133 [3]) or 12 s for UTRA (See TS 25.133 [2]) or 10s for NR (See TS 38.133 [16]).
In "any cell selection" state, a UE shall perform logging of available information (i.e. at least indicator ‘anyCellSelectionDetected’, time stamp, and the available location information). In "camped on any cell" state, the periodic logging stops. However, it should be noted that the duration timer is kept running. When the UE re-enters "camped normally" state and the duration timer has not expired, the periodic logging is restarted based on new DRX and logging resumes automatically (with a leap in time stamp).
When an E-UTRA or NR UE detects an in-device coexistence problem that may affect the logged measurement results, the UE shall stop measurement logging, indicate in the log that an in-device coexistence problem has occurred, and keep the duration timer running. When the in-device coexistence problem is no longer present, and the duration timer has not expired, the logging resumes, with a leap in time stamp.
For E-UTRA MBSFN measurement logging, the UE shall perform MBSFN measurements only when receiving MBMS service, and measurement logging is performed only for logging intervals for which MBSFN measurements are available. The UE shall perform MBSFN measurements and MBSFN measurement logging in both IDLE and CONNECTED modes.
NOTE: the UE is only required to perform MBSFN measurements when receiving MBMS service of the MBSFN area(s) targeted for logging.
For WLAN measurement logging and Bluetooth measurement logging, the UE shall perform WLAN and Bluetooth measurements, respectively, only when indicated in the corresponding configuration. The measurement logging is performed only for logging intervals for which WLAN and Bluetooth measurements are available, respectively.
The measurement quantities for downlink pilot strength measurement logging are fixed and consist of both RSRP and RSRQ for EUTRA, both RSCP and Ec/No for UTRA FDD, P-CCPCH RSCP for UTRA 1.28 Mcps TDD, Rxlev for GERAN, and Pilot Pn Phase and Pilot Strength for CDMA2000 if the serving cell is EUTRAN cell, and both RSRP and RSRQ for NR.
For NR, in addition to the logged measurement quantities of the camped cell, the best beam index (SSB Index) as along with the best beam RSRP/RSRQ are logged as well as the ‘number of good beams’ (the number of SSBs that are above the configured threshold i.e., absThreshSS-BlocksConsolidation, if configured by the network) associated to the cells within the R value range (which is configured by network for cell reselection) of the highest ranked cell as part of the beam level measurements. Sensor measurements are logged if available.
For E-UTRA, uncompensated barometric pressure measurements are logged if available.
The measurement quantities for E-UTRA MBSFN measurement logging are fixed and consist of MBSFN RSRP, MBSFN RSRQ, BLER for signalling and BLER for data per MCH, in addition to the measurement quantities for downlink pilot strength measurements.
The measurement quantities for WLAN measurement logging are fixed and consist of BSSID, SSID, HESSID of WLAN APs. If configured by the network, optionally available RSSI and RTT can be included.
The measurement quantity for Bluetooth measurement logging is fixed and consists of MAC address of Bluetooth beacons. If configured by the network, optionally available RSSI can be included.
UE collects MDT measurements and continues logging according to the logged measurement configuration until UE memory reserved for MDT is full. In this case the UE stops logging, stops the log duration timer and starts the 48 hour timer.
5.1.1.3 Measurement reporting
5.1.1.3.1 Availability Indicator
A UE configured to perform Logged MDT downlink pilot strength measurements indicates the availability of Logged MDT measurements, by means of a one bit, in RRCConnectionSetupComplete or RRCSetupComplete or RRCConnectionResumeComplete or RRCResumeComplete message during connection establishment. Furthermore, the indicator (possibly updated) shall be provided within:
– E-UTRAN handover and re-establishment;
– UTRAN procedures involving the change of SRNC (SRNC relocation), CELL UPDATE, URA UPDATE messages as well as MEASUREMENT REPORT message in case of state transition to CELL_FACH without CELL UPDATE;
– NR re-establishment, reconfiguration.
The UE includes the indication in one of these messages at every transition to RRC Connected mode even though the logging period has not ended, upon connection to RAT which configured the UE to perform Logged MDT measurements and RPLMN which is equal to a PLMN in the MDT PLMN list.
A E-UTRA UE configured to perform Logged MDT MBSFN measurements indicates the availability of Logged MDT MBSFN measurements, by means of an indicator, in RRCConnectionSetupComplete message during connection establishment. The indicator (possibly updated) shall be provided within E-UTRAN also at handover and re-establishment, except when the logged measurement configuration is active in CONNECTED mode, i.e. except when the logging campaign is still ongoing.
A E-UTRA UE configured to perform Logged MDT WLAN measurements indicates the availability of Logged MDT WLAN measurements, by means of an indicator, in RRCConnectionSetupComplete message or RRCConnectionResumeComplete message during connection establishment. Furthermore, the indicator can be included in some uplink RRC messages, i.e., RRCConnectionReconfigurationComplete message, RRCConnectionReestablishmentComplete message, or UEInformationResponse message, at every transition to RRC Connected mode even though the logging period has not ended.
A E-UTRA UE configured to perform Logged MDT Bluetooth measurements indicates the availability of Logged MDT Bluetooth measurements, by means of an indicator, in RRCConnectionSetupComplete message or RRCConnectionResumeComplete message during connection establishment. Furthermore, the indicator can be included in some uplink RRC messages, i.e., RRCConnectionReconfigurationComplete message, RRCConnectionReestablishmentComplete message, or UEInformationResponse message, at every transition to RRC Connected mode even though the logging period has not ended.
A NR UE configured to perform Logged MDT WLAN measurements indicates the availability of Logged MDT WLAN measurements, by means of an indicator, in RRCSetupComplete message or RRCResumeComplete message during connection establishment. Furthermore, the indicator can be included in some uplink RRC messages, i.e., RRCReconfigurationComplete message, RRCReestablishmentComplete message, or UEInformationResponse message, at every transition to RRC Connected mode even though the logging period has not ended.
A NR UE configured to perform Logged MDT Bluetooth measurements indicates the availability of Logged MDT Bluetooth measurements, by means of an indicator, in RRCSetupComplete message or RRCResumeComplete message during connection establishment. Furthermore, the indicator can be included in some uplink RRC messages, i.e., RRCReconfigurationComplete message, RRCReestablishmentComplete message, or UEInformationResponse message, at every transition to RRC Connected mode even though the logging period has not ended.
An indicator shall be also provided in UEInformationResponse message during MDT report retrieval in case the UE has not transferred the total log in one RRC message in order to indicate the remaining data availability.
The UE will not indicate the availability of MDT measurements in another RAT or in a PLMN that is not in the MDT PLMN list.
The network may decide to retrieve the logged measurements based on this indication. In case Logged MDT measurements are retrieved before the completion of the pre-defined logging duration, the reported measurement results are deleted, but MDT measurement logging will continue according to ongoing logged measurement configuration.
In case the network does not retrieve Logged MDT measurements, UE should store non-retrieved measurements for 48 hours from the moment the duration timer for logging expired. There is no requirement to store non-retrieved data beyond 48 hours. In addition, all logged measurement configuration and the log shall be removed by the UE at switch off or detach.
5.1.1.3.2 Report retrieval
For Logged MDT the measurement reporting is triggered by an on-demand mechanism, i.e. the UE is asked by the network to send the collected measurement logs via RRC signalling. UE Information procedure defined in TS 25.331 [4] and TS 36.331 [5] and TS 38.331 [15] is used to request UE to send the collected measurement logs. The reporting may occur in different cells than which the logged measurement configuration is signalled.
Transport of Logged MDT reports in multiple RRC messages is supported. With every request, the network may receive a part of the total UE log. To indicate the reported data is a segment, the UE shall include data availability indicator in UEInformatonResponse message to convey the information that further measurement information is available, as specified in 5.1.1.3.1. In multiple RRC transmissions for segmented Logged MDT reporting, FIFO order is followed, i.e. the UE should provide oldest available measurement entries in earliest message. There is no requirement specified on the size of particular reporting parts. However, each reported part should be "self-decodable", i.e. interpretable even in case all the other parts are not available.
The UE shall send an empty report when retrieval is attempted and the RPLMN is not in the MDT PLMN list.
5.1.1.3.3 Reporting parameters
For downlink pilot strength measurements, the logged measurement report consists of measurement results for the serving cell (the measurement quantity), available UE measurements performed in idle or inactive for intra-frequency/inter-frequency/inter-RAT, time stamp and location information.
For E-UTRA MBSFN measurements logging, the logged measurement report consists of MBSFN measurement results from target MBSFN area(s), if configured, and available downlink pilot strength measurement results. Inter-RAT downlink pilot strength measurements are not required to be logged.
For WLAN and Bluetooth measurement logging, the logged measurement reports consist of WLAN and Bluetooth measurement results, respectively.
The number of neighbouring cells to be logged is limited by a fixed upper limit per frequency for each category below. The UE should log the measurement results for the neighbouring cells, if available, up to:
– 6 for intra-frequency neighbouring cells;
– 3 for inter-frequency neighbouring cells per frequency;
– 3 for GERAN neighbouring cells per frequency;
– 3 for UTRAN (if non-serving) neighbouring cells per frequency;
– 3 for E-UTRAN (if non-serving) neighbouring cells per frequency;
– 3 for NR (if non-serving) neighbouring cells per frequency;
– 3 for CDMA2000 (if serving is E-UTRA) neighbouring cells per frequency;
– 32 for WLAN APs;
– 32 for Bluetooth Beacons.
NOTE: UE in NR IDLE or INACTIVE state will not log measurements from UMTS or GSM.
The measurement reports for neighbour cells consist of:
– Physical cell identity of the logged cell;
– Carrier frequency;
– RSRP and RSRQ for EUTRA and NR;
– RSCP and Ec/No for UTRA FDD,
– P-CCPCH RSCP for UTRA 1.28 Mcps TDD;
– Rxlev for GERAN;
– Pilot Pn Phase and Pilot Strength for CDMA2000;
– RSSI and RTT for WLAN APs;
– RSSI for Bluetooth Beacons.
For any logged cell (serving or neighbour), latest available measurement result made for cell reselection purposes is included in the log only if it has not already been reported.
While logging neighbour cells measurements, the UE shall determine a fixed number of best cells based on the measurement quantity used for ranking during cell reselection per frequency or RAT.
The MBSFN measurement results consist of, per MBSFN area where MBMS service is received:
– MBSFN area identity;
– Carrier frequency;
– MBSFN RSRP;
– MBSFN RSRQ;
– MCH BLER for signalling;
– MCH BLER for data, and related MCH index.
The WLAN measurement results consist of, per wireless network served by the WLAN AP:
– BSSID, SSID and HESSID;
– RSSI for WLAN;
– RTT.
The Bluetooth measurement results consist of, per wireless network served by the Bluetooth beacon:
– MAC address;
– RSSI for Bluetooth.
Measurements are performed in accordance with requirements defined in TS 25.133 [2] and TS 36.133 [3] and TS 38.133 [16].
The measurement report is self contained, i.e. the RAN node is able to interpret the Logged MDT reporting results even if it does not have access to the logged measurement configuration. Each measurement report also contains the necessary parameters for the network to be able to route the reports to the correct TCE and for OAM to identify what is reported. The parameters are sent to the UE in the logged configuration message, see clause 5.1.1.1.1.
For each MDT measurement the UE includes a relative time stamp. The base unit for time information in the Logged MDT reports is the second. In the log associated to periodical logging configuration, the time stamp indicates the point in time when periodic logging timer expires. The time stamp is counted in seconds from the moment the logged measurement configuration is received at the UE, relative to the absolute time stamp received within the configuration. The absolute time stamp is the current network time at the point when Logged MDT is configured to the UE. The UE echoes back this absolute reference time. The time format for Logged MDT report is: YY-MM-DD HH:MM:SS.
Location information is based on available location information in the UE. Thus, the Logged MDT measurements are tagged by the UE with location data in the following manner:
– ECGI, Cell-Id or NCGI in TS 38.300 [22] of the serving cell when the measurement was taken is always included in E-UTRAN, UTRAN or NR respectively;
– Detailed location information (e.g. GNSS location information) is included if available in the UE when the measurement was taken. If detailed location information is available, the reporting shall consist of latitude and longitude. Depending on availability, altitude, uncertainty and confidence may be also additionally included. UE tags available detailed location information only once with upcoming measurement sample, and then the detailed location information is discarded, i.e. the validity of detailed location information is implicitly assumed to be one logging interval;
– Sensor information (i.e. uncompensated barometric pressure measurement (for NR and E-UTRA), UE speed and UE orientation (only in NR)) can be included, if available in the UE when the measurement was taken.
NOTE: The neighbour cell measurement information that is provided by the UE may be used to determine the UE location (RF fingerprint).
Depending on location information availability, measurement log/report consists of:
– time information, RF measurements, RF fingerprints; or
– time information, RF measurements, detailed location information (e.g. GNSS location information);
time information, RF measurements, detailed location information, sensor information.
5.1.1.4 MDT context handling
For Logged MDT in IDLE, CELL_PCH, URA_PCH states and CELL_FACH state when second DRX cycle is used and INACTIVE, no need is identified to transfer an MDT context (any related configuration information about measurement and reporting) between (e/g)NBs/RNCs if corresponding MDT configuration has already been configured to UE. In addition, MDT context is assumed to be released in the RAN nodes when the UE is in IDLE and INACTIVE if corresponding MDT configuration has already been configured to UE.
For UE in INACTIVE, the MDT context handling during cell reselection as described in 5.4.2 apply.
5.1.2 Immediate MDT procedures
5.1.2.1 Measurement configuration
For Immediate MDT, RAN measurements and UE measurements can be configured. The configuration for UE measurements is based on the existing RRC measurement procedures for configuration and reporting with some extensions for location information.
NOTE: No extensions related to time stamp are expected for Immediate MDT i.e. time stamp is expected to be provided by eNB/RNC/gNB.
If area scope is included in the MDT configuration provided to the RAN, the UE is configured with respective measurement when the UE is connected to a cell that is part of the configured area scope.
5.1.2.2 Measurement reporting
For Immediate MDT, the UE provides detailed location information (e.g. GNSS location information) if available. The UE also provides available neighbour cell measurement information that may be used to determine the UE location (RF fingerprint). ECGI, Cell-Id, or CellIdentity of the serving cell when the measurement was taken is always assumed known in E-UTRAN, UTRAN or NR respectively.
The location information which comes with UE radio measurements for MDT can be correlated with other MDT measurements, e.g. RAN measurements. For MDT measurements where UE location information is provided separately, it is assumed that the correlation of location information and MDT measurements should be done in the TCE based on time-stamps.
When the gNB becomes aware of an in-device coexistence interference problem for NR reported by the UE, this information should be forwarded to the TCE which may correlate impacted measurements (e.g. RAN measurements M4, M5, M6, M7) with the in-device coexistence interference problem.
5.1.2.3 MDT context handling during handover and UE context retrieval
The measurements configured in the UE for Immediate MDT should fully comply with the transferring and reconfiguration principles for the current measurements configured in the UE for RRM purpose during handover (including conformance with Rel-8 and Rel-9).
The target node releases the measurements configured in the UE for immediate MDT which are no longer needed based on any MDT trace configuration it receives or does not receive.
In addition, MDT configuration handling during handover and UE context retrieval depends on MDT initiation from OAM defined in clause 5.1.3:
– The MDT configuration configured by management based trace function will not propagate during handover.
– For LTE, the MDT configuration received by signalling based trace messages for a specific UE will propagate during intra-PLMN handover, and may propagate during inter-PLMN handover if the Signalling Based MDT PLMN List is available and includes the target PLMN. This behaviour applies also for MDT configuration that includes area scope, regardless of whether the source or target cell is part of the configured area scope. This behaviour applies also for Xn inter-RAT handover.
– For UMTS, the MDT configuration received by signalling based trace messages for a specific UE will continue during intra-PLMN handover, and may continue during inter-PLMN handover if the Signalling Based MDT PLMN List is available and includes the target PLMN, except for the case of SRNS relocation.
– For NR, the MDT configuration received by signalling based trace messages for a specific UE will propagate during intra-PLMN handover, intra-PLMN UE context retrieval, and may propagate during inter-PLMN handover or inter-PLMN UE context retrieval if the Signalling Based MDT PLMN List is available and includes the target PLMN. This behaviour applies also for MDT configuration that includes area scope, regardless of whether the source or target cell is part of the configured area scope. This behaviour applies also for Xn inter-RAT handover.
NOTE: In the case of SRNS relocation, MDT may be reactivated by the Core Network following a successful relocation.
5.1.3 MDT Initiation
There are two cases that RAN should initiate a MDT measurements collection task. One is that the MDT task is initiated without targeting a specific UE by the cell traffic trace, i.e. management based trace function from OAM. The other is that the MDT task is initiated towards a specific UE by the signalling trace activation messages from CN nodes, i.e. the Initial Context Setup message, the Trace Start message or the Handover request message in E-UTRAN or NR, the CN Invoke Trace message in UTRAN. The detailed procedures to transfer the MDT configurations to RAN are specified in TS 32.422 [6].
For signalling based MDT, the CN shall not initiate MDT towards a particular user unless it is allowed.
For management based MDT, the CN indicates to the RAN whether MDT is allowed to be configured by the RAN for this user considering e.g. user consent and roaming status (see TS 32.422 [6]), by providing management based MDT allowed information. For E-UTRAN/UTRAN, the MDT allowed information consists of the Management Based MDT Allowed indication and optionally the Management Based MDT PLMN List. For NR, the MDT allowed information only consists of the Management Based MDT PLMN List. The management based MDT allowed information propagates during inter-PLMN handover or inter-PLMN UE context retrieval if the Management Based MDT PLMN List is available and includes the target PLMN.
A UE is configured with an MDT PLMN List only if user consent is valid for the RPLMN.
5.1.4 UE capabilities
MDT relevant UE capabilities are component of radio access UE capabilities. Thus, the procedures used for handling UE radio capabilities over (E-)UTRAN and NR apply.
For (E-)UTRAN:
– The UE indicates one capability bit for support for Logged MDT, which indicates that the UE supports logging of downlink pilot strength measurements. The UE may also indicate capability for stand-alone GNSS positioning.
– The E-UTRA UE may indicate capability bits for support of event triggered Logged MDT.
– The E-UTRA UE may indicate a capability for RX-TX time difference measurement for E-CID positioning for MDT.
– The E-UTRA UE may indicate a capability for support of logging of MBSFN measurements.
– The E-UTRA UE may indicate a capability for support of UL PDCP delay measurement when the UE is not configured with MR-DC.
– The E-UTRA UE may indicate a capability for support of UL PDCP Packet Average Delay measurement when the UE is configured with EN-DC.
– The E-UTRA UE may indicate a capability for support of Bluetooth measurements in RRC idle mode.
– The E-UTRA UE may indicate a capability for support of WLAN measurements in RRC idle mode.
– The E-UTRA UE may indicate a capability for support of Bluetooth measurements in RRC connected mode.
– The E-UTRA UE may indicate a capability for support of WLAN measurements in RRC connected mode.
– The E-UTRA UE may indicate a capability for support of barometer measurements in RRC idle mode.
– The E-UTRA UE may indicate a capability for support of barometer measurements in RRC connected mode.
– For UMTS support of the Accessibility measurements is an optional UE feature.
For NR:
– The UE indicates one capability bit for support for Logged MDT in RRC idle and inactive mode, to indicate that the UE supports logging of downlink pilot strength measurements, periodical logging and event-triggered logging.
NOTE: Logged MDT suspension due to in-device coexistence detection is conditionally mandatory feature, i.e., it is mandatory supported if the UE supports Logged MDT in RRC idle and inactive mode.
– The NR UE may indicate a capability bit for support of signalling based Logged MDT overriding protection.
– The UE may indicate capability for stand-alone GNSS positioning.
– The NR UE may indicate a capability for support of UL PDCP packet average delay measurement.
– The NR UE may indicate a capability for support of multiple reports on accessibility measurements.
– The NR UE may indicate a capability for support of Bluetooth measurements in RRC idle and inactive mode.
– The NR UE may indicate a capability for support of WLAN measurements in RRC idle and inactive mode.
– The NR UE may indicate a capability for support of Bluetooth measurements in RRC connected state.
– The NR UE may indicate a capability for support of WLAN measurements in RRC connected state.
– The NR UE may indicate a capability for support of barometer measurements.
– The NR UE may indicate a capability for support of orientation measurements.
– The NR UE may indicate a capability for support of speed measurements.
– The NR UE may indicate a capability for support of UL PDCP excess packet delay.
– The NR UE may indicate a capability for logging and reporting on-Demand SI request information support.
– The NR UE may indicate a capability for storing and reporting PSCell Mobility History Information.
– The NR UE may indicate a capability for support of RLF report for CHO.
– The NR UE may indicate a capability for support of RLF report for DAPS.
– The NR UE may indicate a capability for support of storage and delivery of 2-step RACH related information.
5.1.5 Void
5.1.6 Accessibility measurements
The UE logs failed RRC connection establishments for LTE, UMTS and NR, i.e. a log is created when the RRC connection establishment procedure fails. For NR, UE logs any failed connection establishment attempt, i.e. a log is created when the RRC setup or resume procedure fails. The UE logs failed RRC connection establishments without the need for prior configuration by the network.
The UE stores the Selected PLMN on the RRC connection establishment failure or RRC resume procedure failure. Only if that PLMN is the same as the RPLMN, the UE may report the log.
NOTE: There is no expected performance degradation for networks using EPLMNs.
The trigger for creating a log related to a failed RRC connection establishment is for NR when timer T300 expires, for LTE when timer T300 expires and for UMTS when V300 is greater than N300. The trigger for creating log related to a failed RRC resume procedure is for NR when timer T319 expires.
The UE can store the following information related to the failed RRC connection establishment or failed RRC resume procedure:
– Time stamp, which is the elapsed time between logging and reporting the log.
– The global cell identity of the serving cell when the RRC connection establishment or resume fails, i.e. the cell which the UE attempted to access.
– The latest available radio measurements for any frequency or RAT
– The latest detailed location information, if available.
– For LTE:
– Number of Random Access Preambles transmitted;
– Indication whether the maximum transmission power was used;
– Contention detected;
– The latest WLAN measurement results, if available;
– The latest Bluetooth measurement results, if available.
– For UMTS FDD:
– Number of RRC Connection Request attempts (e.g. T300 expiry after receiving ACK and AICH)
– For UMTS 1.28 Mcps TDD:
– Number of RRC Connection Request attempts.
– Whether the FPACH is received or whether the maximum number Mmax of synchronisation attempts is reached.
– Failure indication of the E-RUCCH transmission. It is only applied when common E-DCH is supported by UE and network.
– For NR:
– SSB index of the downlink beams of serving cell;
– The latest number of consecutive connection failures in the last failed cell the UE has experienced independent of RRC state transitions;
– RACH failure report:
– Tried SSB index and number of Random Access Preambles transmitted for each tried SSB in chronological order of attempts;
– Contention detected as per RACH attempt;
– Indication whether the selected SSB is above or below the rsrp-ThresholdSSB threshold, as per RACH attempt;
– TAC of the cell in which the UE performs the RA procedure;
– For 2-step RACH, the following information can be additionally included:
– Indication that fallback from 2-step RA to 4-step RA was performed by the UE, as per RACH attempt.
– The latest WLAN measurement results, if available;
– The latest Bluetooth measurement results, if available;
– The latest sensor information, if available.
In addition, the CEF report may include additional information required for RACH Optimization solutions, as specified in TS 38.300 [22].
For NR, the UE can store multiple CEF reports to solve the problem about UL/DL coverage imbalance. For the failures happening consecutively, the UE stores one CEF report entry in the multiple CEF report list, as specified in TS 38.331 [15]. For the failures happening consecutively in the same cell, the UE replaces the last information related to the failed RRC connection establishment or failed RRC resume procedure with the new one, while the number of consecutive connection failures is increased. All the entries in the multiple CEF report list correspond to one PLMN. Upon detecting a cell with a different RPLMN, the UE clears stored CEF report entries.
5.2 E-UTRAN solutions
5.2.1 RRC_CONNECTED
UE in RRC Connected does not support Logged MDT in this release of the specification, except for the case of logged MDT for MBSFN measurements as described in clause 5.1.1. In order to support Immediate MDT where MDT measurements are executed in the UE, the existing RRC measurement configuration and reporting procedures apply. Some extensions are used to carry location information.
5.2.1.1 Measurements and reporting triggers for Immediate MDT
Measurements to be performed for Immediate MDT purposes involve reporting triggers and criteria utilized for RRM. An MDT specific UE-based measurement for UL PDCP delay is applied for QoS verification purpose. In addition, there are measurements performed in eNB.
In particular, the following measurements shall be supported for Immediate MDT performance:
Measurements:
– M1: RSRP, RSRQ and SINR measurement by UE, see TS 36.214 [9].
– M2: Power Headroom measurement by UE, see TS 36.213 [11].
– M3: Received Interference Power measurement by eNB, see TS 36.214 [9]. This is a cell measurement. One sample is logged each measurement collection period, where one sample corresponds to a measurement period as specified in TS 36.133 [3].
– M4: Data Volume measurement separately for DL and UL, per QCI per UE, by eNB, see TS 36.314 [13].
– M5: Scheduled IP Throughput for MDT measurement separately for DL and UL, per RAB per UE and per UE for the DL, per UE for the UL, by eNB, see TS 36.314 [13]. QCI values of the RABs that have contributed to a measurement value are logged with the measurement values.
– M6: Packet Delay measurement, separately for DL and UL, per QCI per UE, see UL PDCP Delay, by the UE, and Packet Delay in the DL per QCI, by the eNB, TS 36.314 [13].
NOTE 1: If the UE does not detect any UL PDCP delay based on the delay threshold and delay report interval configured by the network, the UE does not report any UL PDCP delay measurement within that period.
NOTE 2: A UE in EN-DC mode of operation can be configured with UL PDCP Packet Average Delay (ul-DelayValueConfig), if UE is capable of performing the UL average PDCP queueing delay.
– M7: Packet Loss rate measurement, separately for DL and UL per QCI per UE, by the eNB, see Packet Loss rate in the UL and Packet Uu Loss rate in the DL TS 36.314 [13].
– M8: RSSI measurement by UE, see TS 36.331 [5].
– M9: RTT measurement by UE, see TS 36.331 [5].
Measurement collection triggers:
– For M1:
– Event-triggered measurement reports according to existing RRM configuration for events A1, A2, A3, A4, A5 A6, B1 or B2
– Periodic, A2 event-triggered, or A2 event triggered periodic measurement report according to MDT specific measurement configuration.
– For M2:
– Reception of Power Headroom Report (PHR) according to existing RRM configuration.
NOTE 3: PHR is carried by MAC signalling. Thus, the existing mechanism of PHR transmission applies, see TS 36.321 [10].
– For M3:
– End of measurement collection period
– For M4:
– End of measurement collection period.
– For M5:
– End of measurement collection period.
– For M6:
– End of measurement collection period.
– For M7:
– End of measurement collection period.
– For M8:
– Associated to M1 and/or M6 related measurement reporting triggers.
– For M9:
– Associated to M1 and/or M6 related measurement reporting triggers.
5.2.1.2 Enhancement to Radio Link Failure report
The Radio Link Failure report contains information related to the latest connection failure experienced by the UE. The connection failure can be Radio Link Failure (RLF) or Handover Failure (HOF). The contents of the RLF report and the procedure for retrieving it by an eNB are described in TS 36.300 [12].
RLF reports can be collected by OAM. Upon RLF/HOF detection in the UE, rlfReport defined in TS 36.331 [5] also includes available location information on where RLF occurred, i.e. if detailed location information (e.g. GNSS location information) is available the reported location information in rlfReport consists of:
– Latitude, longitude (mandatory)
– Altitude (conditional on availability)
– Velocity (conditional on availability)
– Uncertainty (conditional on availability)
– Confidence (conditional on availability)
– Direction (conditional on availability).
As an indication of impact to MMTEL calls the UE indicates in the radio link failure report whether a radio bearer with QCI 1 was established when radio link failure was detected.
RLF reports may also include available WLAN measurement results and/or Bluetooth measurement results for calculating UE location.
If available, the UE can indicate NR neighbor cell measurements in measurements results.
5.2.1.3 Detailed Location Information
The M1 measurements are tagged by the UE with location data in the following manner:
– Detailed location information (e.g. GNSS location information) is included if available in the UE when the measurement was taken. If detailed location information is available, the reporting shall consist of latitude and longitude. Depending on availability, altitude, uncertainty and confidence may be also additionally included. The UE should include the available detailed location information only once. If the detailed location information is obtained by GNSS positioning method, GNSS time information shall be included. For both event based and periodic reporting (see 5.2.1.1), the detailed location information is included if the report is transmitted within the validity time after the detailed location information was obtained. The validity evaluation of detailed location information is left to UE implementation.
– To support UE location information in SCG failure, the location information (i.e. commonLocationInfo, see TS 38.331 [15] and WLAN and BT information, if available) is included in SCGFailureInformation message, see TS 36.331 [5].
For immediate MDT, the eNB can request the UE to attempt to make GNSS location information available. Standalone GNSS is used as the default baseline. It is desired that the UE provides fresh location information with each immediate MDT measurement report. The details how this is achieved is up to UE implementation.
The eNB may use an Enhanced Cell ID mechanism for location. The eNB forwards the raw E-CID specific measurements to the TCE. When E-CID positioning is requested, the eNB may choose to not use E-CID positioning for collected measurement for which the UE provides detailed location information.
5.2.2 RRC_IDLE
For UE in RRC_IDLE state Logged MDT procedures as described in 5.1.1 apply.
Logged MDT measurements are sent on Signalling Radio Bearer SRB2 in RRC_CONNECTED state.
5.3 UTRAN solutions
5.3.1 UTRA RRC Connected
In CELL_PCH, URA_PCH states and CELL_FACH state when second DRX cycle is used, UE supports Logged MDT as described in 5.1.1. In CELL_DCH state UE supports Immediate MDT as described in 5.1.2. In CELL_FACH state when second DRX cycle is not used, MDT is not supported in the current release.
5.3.1.1 Measurements and reporting events for Immediate MDT
The solutions for Immediate MDT in UTRAN are only applicable for UEs in CELL_DCH state. Measurements to be performed for Immediate MDT purposes involve normal UTRAN reporting triggers and criteria utilized for controlling the RRC connection. In addition, there are measurements defined that are performed in UTRAN. In particular, the following measurements shall be supported for Immediate MDT:
Measurements:
– M1: CPICH RSCP and CPICH Ec/No measurement (FDD) by UE, see TS 25.215 [7].
– M2: P-CCPCH RSCP and Timeslot ISCP for UTRA 1.28 Mcps TDD by UE, see TS 25.225 [8].
– M3: SIR and SIR error (FDD) by NodeB, see TS 25.215 [7] and TS 25.225 [8].
– M4: UE power headroom (UPH) by the UE, applicable for E-DCH transport channels, see TS 25.215 [7] and TS 25.225 [8].
– M5: Received total wideband power (RTWP) by Node B, see TS 25.215 [7] TS 25.225 [8], and TS 25.133 [2]. This is a cell measurement.
– M6: Data Volume measurement, separately for DL and UL, per QoS class per UE, by RNC.
– M7: Throughput measurement, separately for DL and UL, per RAB per UE and per UE, by RNC. Traffic class and Traffic Handling Priority for interactive RABs for the RABs that have contributed to a measurement value are logged with the measurement values.
Measurement collection triggers:
– For M1:
– Event triggered measurement reports according to existing RRM configuration, for measurement types intra-frequency measurement, inter-frequency measurement and inter-RAT measurement.
– Periodic, or 1F event-triggered measurement report, primary CPICH becomes worse than an absolute threshold, according to MDT specific measurement configuration.
– For M2:
– Event triggered measurement reports according to existing RRM configuration, for measurement types intra-frequency measurement, inter-frequency measurement and inter-RAT measurement.
– Periodic, or 1I event-triggered measurement report, timeslot ISCP above a certain threshold (TDD), according to MDT specific measurement configuration.
– For M3:
– When available
– For M4:
– Reception of UPH according to existing RRM configuration
– Provided by the UE according to RRM configuration.
– UPH samples may be collected and logged:
– always
– periodic, one sample per period.
– periodic, one sample per period, when measurement value < threshold.
– For M5:
– When available.
– End of measurement collection period.
– For M6:
– End of measurement collection period.
– For M7:
– End of measurement collection period.
5.3.1.2 Detailed Location Information
For Immediate MDT, existing procedures for UE Location information are used to obtain detailed location information.
5.3.2 UTRA Idle
For UEs in UTRA Idle mode Logged MDT procedures as described in 5.1.1 apply.
Logged MDT measurements are sent on Signalling Radio Bearer SRB4 in RRC Connected mode.
5.4 NR solutions
5.4.0 General
The management-based MDT configuration should not overwrite signalling based MDT configuration in all the single connection scenarios and EN-DC scenario.
To assist the network in preventing management based logged MDT overwriting signaling based logged MDT, if the UE is configured with logged MDT type, the UE will provide an assistance information in RRCSetupComplete / RRCConnectionSetupComplete and RRCResumeComplete / RRCConnectionResumeComplete messages. The information indicates the signaling based logged MDT configuration presence in the UE.
5.4.1 RRC_CONNECTED
In RRC_CONNECTED state UE supports Immediate MDT as described in 5.1.2. In order to support Immediate MDT, the existing RRC measurement configuration and reporting procedures apply. Some extensions are used to carry location information.
5.4.1.1 Measurements and reporting triggers for Immediate MDT
Measurements to be performed for Immediate MDT purposes involve reporting triggers and criteria utilized for RRM. In addition, there are associated network performance measurements performed in the gNB.
In particular, the following measurements shall be supported for Immediate MDT performance:
Measurements:
⁻ M1: DL signal quantities measurement results for the serving cell and for intra-frequency/Inter-frequency/inter-RAT neighbour cells, including cell/beam level measurement for NR cells only, TS 38.215 [19].
⁻ M2: Power Headroom measurement by UE, TS 38.213 [20].
⁻ M3: Void.
⁻ M4: PDCP SDU Data Volume measurement separately for DL and UL, per DRB per UE, see TS 28.552 [17].
⁻ M5: Average UE throughput measurement separately for DL and UL, per DRB per UE and per UE for the DL, per DRB per UE and per UE for the UL, by gNB, see TS 28.552 [17].
⁻ M6: Packet Delay measurement separately for DL and UL, per DRB per UE, TS 28.552 [17] and TS 38.314 [18].
NOTE 0: UL PDCP Excess Packet Delay measurement can be configured with a threshold as specified in TS 38.331 [15].
⁻ M7: Packet loss rate measurement separately for DL and UL, per DRB per UE, TS 28.552 [17] and TS 38.314 [18].
⁻ M8: RSSI measurement by UE (for WLAN/Bluetooth measurement) see TS 38.331 [15].
⁻ M9: RTT Measurement by UE (for WLAN measurement) see TS 38.331 [15].
NOTE 1: Void
NOTE 1a: M5 ~ M7 can apply to MR-DC and EN-DC SN terminated MCG/split bearers and MN terminated SCG/split bearers.
Measurement collection triggers:
– For M1:
– Event-triggered measurement reports according to existing RRM configuration for events A1, A2, A3, A4, A5, A6, B1 or B2.
– Periodic, A2 event-triggered, or A2 event triggered periodic measurement report according to MDT specific measurement configuration.
– For M2:
– Reception of Power Headroom Report (PHR) according to existing RRM configuration.
NOTE 2: PHR is carried by MAC signalling. Thus, the existing mechanism of PHR transmission applies, see TS 38.321 [21].
– For M3:
– End of measurement collection period.
– For M4:
– End of measurement collection period.
– For M5:
– End of measurement collection period.
NOTE 3: If transmission of a data burst is ongoing at the boundary of the measurement collection period, T1 and T2 in throughput evaluations are set to the end and the start of the measurement period, respectively.
– For M6:
– End of measurement collection period.
– For M7:
– End of measurement collection period.
– For M8:
– Associated to M1 and/or M6 related measurement reporting triggers.
– For M9:
– Associated to M1 and/or M6 related UE measurement reporting triggers.
5.4.1.2 Radio Link Failure report
The Radio Link Failure report contains information related to the latest connection failure experienced by the UE. The connection failure can be Radio Link Failure (RLF), or Handover Failure (HOF). The contents of the RLF report and the procedure for retrieving it by a gNB are specified in TS 38.331 [15], including failure information related to CHO, or DAPS Handover Failure (DAPS HOF). In case of consecutive connection failures associated to CHO or DAPS, the UE stores and reports both failure related information in the RLF report.
RLF report can contain latest two consecutive failures, in case one of the failures is related to CHO. In case of consecutive failures, the UE stores and reports both failure related information in the RLF report. The consecutive failure scenarios concern the following sequence of events:
a. A UE that has CHO configuration (as specified in TS 36.331 [5]) detects RLF in the source cell. The UE selects a configured candidate CHO target cell for connection re-establishment. The UE fails to re-establish to the selected CHO candidate cell.
b. A UE that has CHO configuration, executes the CHO towards the target cell upon fulfilling the configured condition and experiences a HO failure. The UE selects a configured candidate CHO target cell for connection re-establishment. The UE fails to re-establish to the selected CHO candidate cell.
c. A UE that has CHO configuration executes the normal HO towards the target cell and experiences a HO failure. The UE selects for connection re-establishment a configured candidate CHO target cell. The UE fails to re-establish to the selected CHO candidate cell using CHO procedure.
For DAPS, two consecutive failure information concern the following scenarios:
a. A UE detects a connection failure at the source (RLF) while performing access to DAPS target cell and fails to access the target (HOF).
b. A UE detects a connection failure at the target cell (HOF) and fails to perform fallback (RLF at source).
NR RLF report content required for MDT includes:
– Latest radio measurement results of the serving and neighbouring cells, including SSB/CSI-RS index and associated measurements in the serving and neighbouring cells;
NOTE: The measure quantities are sorted through the same RS type depending on the availability, according to the following priority: RSRP, RSRQ, SINR.
– For CHO, UE includes the latest radio measurement results of the candidate target cells;
– WLAN and Bluetooth measurement results, if were configured prior RLF and are available for reporting;
– "No suitable cell is found" flag when T311 expires;
– Indication per SSB/CSI-RS beams reporting whether it is configured to RLM purpose;
– Available sensor information;
– Available detailed location information;
– RACH failure report (in case, the cause for RLF is random access problem or Beam Failure Recovery failure):
– Tried SSB/CSI-RS index and number of Random Access Preambles transmitted for each tried SSB/CSI-RS in chronological order of attempts;
– Contention detected as per RACH attempt;
– Indication whether the selected SSB is above or below the rsrp-ThresholdSSB threshold, as per RACH attempt;
– TAC of the cell in which the UE performs the RA procedure;
– Frequency location related information of the RA resources used by the UE as specified in TS 38.331 [15];
– For 2-step RA, the following information can be additionally included:
– The measured RSRP of DL pathloss reference obtained just before performing RACH procedure (per RA procedure);
– Indication that fallback from 2-step RA to 4-step RA was performed by the UE, as per RACH attempt;
– Indication of RA switching point (as defined by the field msgA-TransMax in TS 38.331 [15]);
– The payload size available in the UE buffer at the time of initiating the 2-step RA procedure, without considering the padding (per RA procedure);
– MSGA PUSCH resources for 2-step RACH as specified in TS 38.331 [15] can be included in case the UE uses random access resources configured with CFRA.
If detailed location information (e.g. GNSS location information) is available the reported location information in rlf-Report consists of:
– Latitude, longitude (mandatory);
– Altitude (conditional on availability);
– Velocity (conditional on availability);
– Uncertainty (conditional on availability);
– Confidence (conditional on availability);
– Direction (conditional on availability).
If sensor information is available, the sensor information may convey uncompensated barometric pressure, UE speed, and UE orientation.
In addition, the RLF report may include additional information required for MRO solutions, as specified in TS 38.300 [22].
5.4.1.3 Immediate MDT for MR-DC
Immediate MDT is supported for (NG)EN-DC, NE-DC and NR-DC scenario.
In signalling based immediate MDT, MME provides MDT configuration for both MN and SN towards MN including multi RAT SN configuration, specifically E-UTRA and NR MDT configuration. MN then forwards the NR MDT configuration towards SN (EN-DC scenario, SN is always NR).
In management-based immediate MDT, OAM provides the MDT configuration to both MN and SN independently. For both MN and SN, Management based MDT should not overwrite signalling based MDT.
For immediate MDT configuration, MN and SN can independently configure and receive measurement from the UE.
For MN terminated SCG bearer and SN terminated MCG bearer, the terminated node, e.g., MN in case of MN terminated SCG bearer, configures the configuration to UE.
For configuring packet delay measurement D1 specified in TS 38.314 [18] in case of split bearer: only one node can configure the measurement to UE, and the UE reports the measurement result to corresponding node where the configuration was received from.
5.4.2 RRC_IDLE & RRC_INACTIVE
5.4.2.1 General
For UE in RRC_IDLE and RRC_INACTIVE states Logged MDT procedures as described in 5.1.1 apply.
For Logged MDT measurement collection for RRC INACTIVE UEs, the actual process of logging within the UE, takes place in RRC INACTIVE state and may be continued in RRC IDLE state; or vice versa.
The logged measurement stored in UE during RRC INACTIVE and RRC IDLE state are kept for a given common period before they are deleted as in LTE MDT.
If the signalling based logged or immediate MDT configuration received by the NG-RAN when UE is in RRC_INACTIVE:
– The NG-RAN stores the MDT configuration in the UE context;
– When the UE resumes the RRC connection in the last serving NG-RAN, the NG-RAN can configure the MDT configuration for the UE;
– When the UE resumes the RRC connection in one new NG-RAN, the new NG-RAN can configure the MDT configuration for the UE, only if the signalling based logged MDT was received by the new NG-RAN from the previous NG-RAN or AMF.
If the management based MDT configuration is received by the NG-RAN when UE is in RRC_INACTIVE,
– No requirement for the NG-RAN to store the MDT configuration in the UE context;
– When the UE resumes the RRC connection in the last serving NG-RAN, the NG-RAN can configure the MDT configuration for the UE;
– When the UE resumes the RRC connection in another NG-RAN, the source NG-RAN will not propagate the management based MDT configuration. The source NG-RAN should inform the target NG-RAN of UE consents.
Logged MDT measurements are sent on Signalling Radio Bearer SRB2 in RRC_CONNECTED state.
5.4.2.2 Logging of on-demand SI request related information
For NR, following on-demand SI request related information are logged for both Msg1-based and Msg3-based SI request:
– The SIB(s) that UE actually intends to request;
– The beam identifiers used to acquire the on-demand SI;
– One specific raPurpose for MSG3 based on demand SI request;
– An indication whether on-demand SI acquisition was successful or not.
Annex A (informative):
Coverage use cases
The MDT data reported from UEs and the RAN may be used to monitor and detect coverage problems in the network. Some examples of use cases of coverage problem monitoring and detection are described in the following:
– Coverage hole: A coverage hole is an area where the signal level SNR (or SINR) of both serving and allowed neighbor cells is below the level needed to maintain basic service (SRB & DL common channels), i.e. coverage of PDCCH. Coverage holes are usually caused by physical obstructions such as new buildings, hills, or by unsuitable antenna parameters, or just inadequate RF planning. UE in coverage hole will suffer from call drop and radio link failure. Multi-band and/or Multi-RAT UEs may go to other network layer instead.
– Weak coverage: Weak coverage occurs when the signal level SNR (or SINR) of serving cell is below the level needed to maintain a planned performance requirement (e.g. cell edge bit-rate).
– Pilot Pollution: In areas where coverage of different cells overlap a lot, interference levels are high, power levels are high, energy consumption is high and cell performance may be low. This problem phenomenon has been called "pilot pollution", and the problem can be addressed by reducing coverage of cells. Typically in this situation UEs may experience high SNR to more than one cell and high interference levels.
– Overshoot coverage: Overshoot occurs when coverage of a cell reaches far beyond what is planned. It can occur as an "island" of coverage in the interior of another cell, which may not be a direct neighbor. Reasons for overshoot may be reflections in buildings or across open water, lakes etc. UEs in this area may suffer call drops or high interference. Possible actions to improve the situation include changing the coverage of certain cells and mobility by exclude-listing of certain cells.
– Coverage mapping: There should be knowledge about the signal levels in the cell areas in order to get a complete view for the coverage and be able to assess the signal levels that can be provided in the network. This means that there should be measurements collected in all parts of the network, and not just in the areas where there are potential coverage issues.
– UL coverage: Poor UL coverage might impact user experience in terms of call setup failure / call drop / poor UL voice quality. Therefore, coverage should be balanced between uplink and downlink connections. Possible UL coverage optimization comprises adapting the cellular coverage by changing the site configuration (antennas) but also about adjusting the UL related parameters in the way that they allow optimized usage of UL powers in different environments.
– Cell boundary mapping: There should be knowledge about the location of (intra/inter RAT) cell boundaries in order to compare to the expected/planned network setting. Poor handover performance may be caused by changed cell boundaries due to changes in the physical condition of the surrounding area, e.g., construction of new buildings, bridge or tunnel near the handover area.
– Coverage mapping for pico cell in CA scenario: As a realization of CA scenario 4 in TS 36.300 [12], pico cell may be deployed in area where high traffic occurs. The location where a pico cell is available to be added as an SCell may show whether the deployment of pico cell is according to the needs of capacity increase.
Annex B (informative):
QoS verification use cases
The MDT data reported from UEs and the RAN may be used to verify Quality of Service, assess user experience from RAN perspective, and to assist network capacity extension. Use cases are described in the following:
– Traffic Location: MDT functionality to obtain information of where data traffic is transferred within a cell.
– User QoS Experience: MDT functionality to assess the QoS experience for a specific UE together with location information.
– Data Throughput measurements can be collected, aiming to reflect QoS for bandwidth limited traffic.
– For E-UTRA, Data Loss and Latency measurements can be collected, aiming to reflect QoS for conversational traffic.
Annex C (informative):
Measurements
This annex provides information on measurements that are used for MDT and are not specified elsewhere.
Throughput measurement for UMTS. The throughput is measured on PDCP or RLC level. A measurement value for a UE and each RAB of the UE is provided each measurement period, except if the value is zero. The measurement is performed separately for UL and DL, and is performed for PS RABs. Idle periods shall not be taken into account, when there is no data buffered or no data being transmitted.
Data Volume measurement for UMTS. Data Volume is measured on PDCP or RLC (without Layer 2 overhead). A measurement value for a QoS class for a UE is provided each measurement period, except if the value is zero, where the QoS class is one of conversational, interactive, streaming or background. The measurement is performed separately for UL and DL, and is performed for PS RABs.
Annex D (informative):
MBSFN use cases
The MDT data reported from UEs may be used to verify signal strength, signal quality and block error rates for MBSFN reception, to support network verification, re-planning of MBSFN areas, and optimization of MBSFN operation parameters.
Annex E (informative):
Change history
|
Change history |
|||||
|
Date |
WG # |
WG Doc. |
Subject/Comment |
Old |
New |
|
2010/01 |
R2#68bis |
R2-100845 |
Skeleton TS endorsed |
0.0.0 |
0.1.0 |
|
2010/01 |
R2#68bis |
R2-100846 |
Initial content provided |
0.1.0 |
0.2.0 |
|
2010/02 |
R2#69 |
R2-101800 |
Logged and Immediate MDT definitions added Requirements introduced Measurement Configuration/Reporting principles clarified |
0.2.0 |
0.2.1 |
|
2010/02 |
R2#69 |
R2-101891 |
RAN2 approved TS v0.3.0 |
0.2.1 |
0.3.0 |
|
2010/04 |
R2#69bis |
R2-102623 |
– General principles for support of Logged MDT included – Location Information principles for Logged MDT introduced – MDT Context handling for Logged MDT introduced – Report availability indicator added to 5.1.3 – Annex A |
0.3.0 |
0.3.1 |
|
2010/04 |
R2#69bis |
R2-102656 |
– Editorial changes |
0.3.1 |
0.3.2 |
|
2010/04 |
R2#69bis |
R2-102667 |
RAN2 approved TS v0.4.0 |
0.3.2 |
0.4.0 |
|
2010/05 |
R2#70 |
R2-103400 |
Logged MDT configuration and reporting principles added Periodical measurement configuration rules for Logged MDT added SRB for Logged MDT identified Measurements and triggers for Immediate MDT identified |
0.4.0 |
0.4.1 |
|
2010/05 |
R2#70 |
R2-103456 |
RAN2 approved TS v0.5.0 |
0.4.1 |
0.5.0 |
|
2010/06 |
R2#70bis |
R2-103991 |
Editorial changes: – New text organization in 5.1: split in two clauses for Logged MDT and Immediate MDT – MDT Reporting mode in 4.1 update to clarify the requirement on feature support – FFS on extension across RAT aligned to RAN#69 agreement – Retrieved data removal requirement aligned to RAN2#70 agreement |
0.5.0 |
0.5.1 |
|
2010/06 |
R2#70bis |
R2-104073 |
RAN2 approved TS v0.6.0 |
0.5.1 |
0.6.0 |
|
2010/06 |
R2#70bis |
R2-104074 |
– Logged MDT configuration message sequence added in 5.1.1.1 – Measurement area scope identified – Time stamping principles added – MDT configuration/log handling at PLMN change introduced – Validity timer for non-retrieved data defined – GNSS location information details defined – RLF enhancements on location information defined – MDT applicability for UTRA states added |
0.6.0 |
0.6.1 |
|
2010/06 |
R2#70bis |
R2-104206 |
Clarification on sending availability indicator in another RAT added |
0.6.1 |
0.6.2 |
|
2010/06 |
R2#70bis |
R2-104212 |
RAN2 approved TS v0.7.0 |
0.6.2 |
0.7.0 |
|
2010/08 |
R2#71 |
R2-104950 |
Agreed text proposal in R2-104303 on clarification on logged MDT data retrieval added MDT applicability for particular UE states clarified in corresponding clauses Time stamp details included in 5.1.1.3.3 MDT handling during handover added in 5.1.2.3 Agreed text proposal in R2-104678 to address SA5 progress added in 5.1.3 Assumptions on memory size limit capability added in 5.1.4 Further RLF enhancements listed as FFS in 5.2.1.2 |
0.7.0 |
0.7.1 |
|
2010/08 |
R2#71 |
R2-105238 |
Clarification on idle logging applicability to "camped normally" state in 5.1.1.2. added FFS on logged data clearance in shared network scenarios added Submitted to TSG RAN for information |
0.7.1 |
1.0.0 |
|
2010/10 |
R2#71b |
R2-105787 |
Editorial and formatting changes |
1.0.0 |
1.0.1 |
|
2010/10 |
R2#71b |
R2-105877 |
Logged MDT reports details on neighbours details added Accurate location information validity clarified UE memory size reserved for Logged MDT added Transport of MDT logs using multiple RRC messages defined Logging handling at PLMN change clarified |
1.0.1 |
1.0.2 |
|
2010/10 |
R2#71b |
R2-106018 |
RAN2 approved TS v1.1.0 |
1.0.2 |
1.1.0 |
|
2010/11 |
R2#72 |
R2-106682 |
Requirement on Dependency on Trace added Validity time for accurate location information in Immediate MDT added Introduction of UTRA 1.28 TDD metrics |
1.1.0 |
1.1.1 |
|
2010/11 |
R2#72 |
R2-106936 |
RAN2 approved TS v2.0.0 |
1.1.1 |
2.0.0 |
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2010-12 |
RP-50 |
RP-101162 |
– |
– |
TS 37.320 approved b RAN #50 |
10.0.0 |
|
|
2011-03 |
RP-51 |
RP-110282 |
0001 |
– |
Clarifications on MDT initiation |
10.1.0 |
|
|
RP-51 |
RP-110282 |
0002 |
– |
Clear MDT configuration and logs when the UE is not registered |
10.1.0 |
||
|
RP-51 |
RP-110282 |
0003 |
1 |
MDT stage 2 clarifications |
10.1.0 |
||
|
RP-51 |
RP-110282 |
0004 |
– |
On memory size limitation for Logged MDT |
10.1.0 |
||
|
RP-51 |
RP-110282 |
0005 |
– |
UE Capabilities for MDT |
10.1.0 |
||
|
RP-51 |
RP-110282 |
0006 |
– |
Validity time for location information in Immediate MDT |
10.1.0 |
||
|
RP-51 |
RP-110282 |
0008 |
– |
Correction to include CDMA2000 reporting for neighbouring cells |
10.1.0 |
||
|
RP-51 |
RP-110282 |
0012 |
– |
Small Clarifications and Corrections to 37.320 |
10.1.0 |
||
|
RP-51 |
RP-110282 |
0013 |
– |
Trace parameters for MDT configuration |
10.1.0 |
||
|
2011-06 |
RP-52 |
RP-110843 |
0014 |
– |
Clarification for logged MDT measurement configuration effectiveness |
10.2.0 |
|
|
RP-52 |
RP-110843 |
0015 |
– |
Correction of log availability reporting |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0016 |
– |
Immediate MDT context handling during inter-PLMN handover |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0017 |
1 |
MDT UL network measurements |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0018 |
– |
Signalling based Immediate MDT initiation with area scope configuration |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0019 |
– |
TCE ID parameter for logged MDT |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0020 |
– |
Miscellaneous corrections to 37.320 |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0025 |
1 |
MDT Stage-2 Cleanup |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0026 |
1 |
Introduction of the User consent |
10.2.0 |
||
|
RP-52 |
RP-110843 |
0027 |
– |
CR to 37.320 to clean up description of RLF Reporting |
10.2.0 |
||
|
2011-09 |
RP-53 |
RP-111285 |
0033 |
– |
Immediate MDT context handling during inter-PLMN handover |
10.3.0 |
|
|
RP-53 |
RP-111285 |
0034 |
– |
Miscellaneous corrections to 37.320 |
10.3.0 |
||
|
RP-53 |
RP-111285 |
0037 |
– |
Editorial corrections |
10.3.0 |
||
|
2011-12 |
RP-54 |
RP-111714 |
0038 |
– |
CR to 37.320 on Immediate MDT handling at handover |
10.4.0 |
|
|
RP-54 |
RP-111714 |
0039 |
– |
Small Corrections to 37.320 |
10.4.0 |
||
|
2012-06 |
RP-56 |
RP-120819 |
0045 |
1 |
Introduction of MDT enhancements |
11.0.0 |
|
|
2012-09 |
RP-57 |
RP-121370 |
0046 |
1 |
Updates for MDT enhancements |
11.1.0 |
|
|
2012-12 |
RP-58 |
RP-121946 |
0051 |
– |
MDT Open Issues Resolutions |
11.2.0 |
|
|
RP-58 |
RP-121946 |
0052 |
– |
Removing the IE Contention Detected in Accessiability Measurement(option 3) |
11.2.0 |
||
|
RP-58 |
RP-121946 |
0054 |
– |
Stage-2 update for MDT enhancements |
11.2.0 |
||
|
RP-58 |
RP-121730 |
0055 |
– |
Multi-PLMN MDT |
11.2.0 |
||
|
2013-03 |
RP-59 |
RP-130240 |
0056 |
– |
Miscellaneous MDT corrections |
11.3.0 |
|
|
RP-59 |
RP-130240 |
0057 |
– |
Correction to E-CID positioning for MDT |
11.3.0 |
||
|
RP-59 |
RP-130240 |
0058 |
– |
Corrections for multi-PLMN MDT |
11.3.0 |
||
|
2014-03 |
RP-63 |
RP-140347 |
0061 |
– |
Introduction of Cell_FACH with Second DRX to 3G Logged MDT |
12.0.0 |
|
|
2014-06 |
RP-64 |
RP-140889 |
0062 |
1 |
Introduction of MBMS operations Support for E-UTRA |
12.1.0 |
|
|
2014-09 |
RP-65 |
RP-141507 |
0066 |
– |
Minor corrections to MDT Stage-2 |
12.2.0 |
|
|
RP-65 |
RP-141496 |
0064 |
1 |
Reporting and measurement collection triggers for immediate MDT |
12.2.0 |
||
|
2015-12 |
RP-70 |
RP-152082 |
0067 |
1 |
Further Enhancements of MDT for E-UTRA |
13.0.0 |
|
|
2016-03 |
RP-71 |
RP-160470 |
0069 |
– |
Reporting of UL PDCP delay measurements for FeMDT |
13.1.0 |
|
|
2017-03 |
RP-75 |
Upgrade to Rel-14, no technical change |
14.0.0 |
||||
|
2018-06 |
RP-80 |
RP-181227 |
0071 |
2 |
B |
37.320 CR to introduce BT and WLAN in MDT |
15.0.0 |
|
RP-80 |
RP-181228 |
0072 |
– |
B |
Support for logging of ‘Any cell selection’ state |
15.0.0 |
|
|
2020-03 |
RP-87 |
RP-200354 |
0077 |
2 |
B |
CR to Introduce NR MDT |
16.0.0 |
|
2020-07 |
RP-88 |
RP-201184 |
0085 |
2 |
F |
CR to 37.320 to support NR MDT |
16.1.0 |
|
2020-09 |
RP-89 |
RP-201931 |
0090 |
– |
F |
Corrections to TS37.320 |
16.2.0 |
|
2020-12 |
RP-90 |
RP-202776 |
0098 |
1 |
F |
Merged Corrections for TS37.320 |
16.3.0 |
|
2021-03 |
RP-91 |
RP-210693 |
0103 |
– |
F |
Merged Corrections to TS 37.320 |
16.4.0 |
|
2021-06 |
RP-92 |
RP-211471 |
0107 |
2 |
F |
Merged Corrections to TS 37.320 |
16.5.0 |
|
2021-09 |
RP-93 |
RP-212443 |
0110 |
1 |
F |
On UL delay configuration in LTE |
16.6.0 |
|
2021-12 |
RP-94 |
RP-213344 |
0112 |
– |
F |
TS37.320 title update |
16.7.0 |
|
2022-03 |
RP-95 |
RP-220835 |
0116 |
– |
F |
Immediate MDT configurations for UE in inactive |
16.8.0 |
|
2022-03 |
RP-95 |
RP-220506 |
0104 |
2 |
D |
Inclusive Language Review for TS 37.320 |
17.0.0 |
|
RP-95 |
RP-220837 |
0113 |
– |
B |
Introduction of event-based trigger for LTE MDT logging [LTE-Event-MDT] |
17.0.0 |
|
|
RP-95 |
RP-220837 |
0114 |
1 |
B |
On introducing height information reporting in MDT reports [LTE-Height-MDT] |
17.0.0 |
|
|
RP-95 |
RP-220846 |
0115 |
2 |
B |
Introduction of Rel-17 MDT enhancements |
17.0.0 |
|
|
2022-06 |
RP-96 |
RP-221733 |
0119 |
– |
F |
Corrections on TS37.320 |
17.1.0 |