Method, apparatus and computer program

Abstract

An apparatus comprising: means for receiving a value for associating minimization of drive test (MDT) sessions and at least one identifier of a first MDT session associated with the value, the MDT sessions comprising the first MDT session and a second MDT session, where the value for associating the MDT sessions is associated with a user equipment; means for receiving at least one first MDT record related to the first MDT session; means for receiving a value for associating the MDT session and at least one identifier of a second MDT session associated with the value; means for receiving at least one second MDT record related to a second MDT session; and means for determining, based on the value for associating the MDT session, that both the at least one first MDT record and the at least one second MDT record originate from the same user equipment.

Description

Technical Field

[0001] This application relates to an apparatus, method, and computer program. Specifically, but not exclusively, this application relates to Minimum Drive Testing (MDT). Background Technology

[0002] A communication system can be viewed as a facility that enables a communication session between two or more entities (such as user terminals, base stations, and / or other nodes) by providing carrier waves between various entities involved in the communication path. The communication system can be provided, for example, through a communication network and one or more compatible communication devices. The communication session can include, for example, communication of data carrying communications such as voice, video, email, text messages, multimedia, and / or content data. Non-limiting examples of the services provided include two-way or multi-way calling, data communication or multimedia services, and access to data network systems such as the Internet.

[0003] Communication systems and associated equipment typically operate according to a given standard or specification that outlines what the various entities associated with the system are allowed to do and how they should be implemented. The communication protocols and / or parameters that should be used for connectivity are also usually defined. One example of a communication system is UTRAN (3G Radio). Other examples include the Long Term Evolution (LTE) of Universal Mobile Telecommunications System (UMTS) radio access technology and so-called 5G or New Radio (NR) networks. NR is being standardized by the 3rd Generation Partnership Project (3GPP). Summary of the Invention

[0004] According to a first aspect, an apparatus is provided, comprising: means for receiving a value associated with a minimized drive test MDT session and at least one identifier of a first MDT session associated with the value, the MDT session including a first MDT session and a second MDT session, wherein the value associated with the MDT session is associated with a user equipment; means for receiving at least one first MDT record associated with the first MDT session; means for receiving the value associated with the MDT session and at least one identifier of a second MDT session associated with the value; means for receiving at least one second MDT record associated with the second MDT session; and means for determining, based on the value associated with the MDT session, that both the at least one first MDT record and the at least one second MDT record originate from the user equipment.

[0005] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0006] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0007] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with the network.

[0008] According to some examples, the values ​​used to associate an MDT session are stored in the context information of the user equipment in at least one core network node.

[0009] According to some examples, at least one core network node includes AMF.

[0010] According to some examples, when a user device switches to a target node, the values ​​associated with the MDT session are forwarded to the target node.

[0011] According to some examples, the first MDT session includes a recorded MDT session, and the second MDT session includes an instantaneous MDT session.

[0012] According to a second aspect, an apparatus is provided, comprising at least one processor and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the apparatus to at least: receive a value for associating a minimized drive test MDT session and at least one identifier of a first MDT session associated with the value, the MDT session including a first MDT session and a second MDT session, wherein the value for associating the MDT session is associated with a user equipment; receive at least one first MDT record associated with the first MDT session; receive the value for associating the MDT session and at least one identifier of a second MDT session associated with the value; receive at least one second MDT record associated with the second MDT session; and determine, based on the value for associating the MDT session, that both the at least one first MDT record and the at least one second MDT record originate from the user equipment.

[0013] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0014] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0015] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with the network.

[0016] According to some examples, the values ​​used to associate an MDT session are stored in the context information of the user equipment in at least one core network node.

[0017] According to some examples, at least one core network node includes AMF.

[0018] According to some examples, when a user device switches to a target node, the values ​​associated with the MDT session are forwarded to the target node.

[0019] According to some examples, the first MDT session includes a recorded MDT session, and the second MDT session includes an instantaneous MDT session.

[0020] According to a third aspect, a method is provided, comprising: receiving a value for minimizing the association of a drive test MDT session, and at least one identifier of a first MDT session associated with the value, the MDT session including a first MDT session and a second MDT session, wherein the value for minimizing the association of the MDT session is associated with a user equipment; receiving at least one first MDT record associated with the first MDT session; receiving the value for minimizing the association of the MDT session and at least one identifier of a second MDT session associated with the value; receiving at least one second MDT record associated with the second MDT session; and determining, based on the value for minimizing the association of the MDT session, that at least one first MDT record and at least one second MDT record both originate from a user equipment.

[0021] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0022] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0023] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with the network.

[0024] According to some examples, the values ​​used to associate an MDT session are stored in the context information of the user equipment in at least one core network node.

[0025] According to some examples, at least one core network node includes AMF.

[0026] According to some examples, when a user device switches to a target node, the values ​​associated with the MDT session are forwarded to the target node.

[0027] According to some examples, the first MDT session includes a recorded MDT session, and the second MDT session includes a continuous MDT session.

[0028] According to a fourth aspect, a computer-readable medium including instructions is provided, which, when executed by an apparatus, cause the apparatus to perform at least the following: receiving a value for associating a minimized drive test MDT session and at least one identifier of a first MDT session associated with the value, the MDT session including a first MDT session and a second MDT session, wherein the value for associating the MDT session is associated with a user equipment; receiving at least one first MDT record associated with the first MDT session; receiving the value for associating the MDT session and at least one identifier of a second MDT session associated with the value; receiving at least one second MDT record associated with the second MDT session; and determining, based on the value for associating the MDT session, that at least one first MDT record and at least one second MDT record both originate from a user equipment.

[0029] According to a fifth aspect, a non-transitory computer-readable medium including program instructions, which, when executed by an apparatus, cause the apparatus to perform at least the following: receiving a value associated with a minimized drive test MDT session and at least one identifier of a first MDT session associated with the value, the MDT session including a first MDT session and a second MDT session, wherein the value associated with the MDT session is associated with a user equipment; receiving at least one first MDT record associated with the first MDT session; receiving the value associated with the MDT session and at least one identifier of a second MDT session associated with the value; receiving at least one second MDT record associated with the second MDT session; and determining, based on the value associated with the MDT session, that at least one first MDT record and at least one second MDT record both originate from a user equipment.

[0030] According to a sixth aspect, an apparatus is provided, comprising: components for generating a value for a user equipment that minimizes the association of a drive test MDT session, the MDT session including a first MDT session and a second MDT session; components for sending to a network entity the value for the user equipment that minimizes the association of the MDT session and at least one identifier of the first MDT session associated with the value; and components for sending to a network entity the value for the user equipment that minimizes the association of the MDT session and at least one identifier of the second MDT session associated with the value.

[0031] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0032] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0033] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with a network that includes the device.

[0034] According to some examples, the device includes a component for storing values ​​in the context information of the user device for associating MDT sessions.

[0035] According to some examples, the device includes components for forwarding values ​​used to associate an MDT session to the target node when the user equipment switches to the target node.

[0036] According to some examples, the first MDT session includes a recorded MDT session, and the second MDT session includes an instantaneous MDT session.

[0037] According to a seventh aspect, an apparatus is provided, comprising at least one processor and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the apparatus to at least: generate a value for a user equipment for associating a minimized drive test MDT session, the MDT session including a first MDT session and a second MDT session; send to a network entity the value for the user equipment for associating the MDT session and at least one identifier of the first MDT session associated with the value; and send to the network entity the value for the user equipment for associating the MDT session and at least one identifier of the second MDT session associated with the value.

[0038] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0039] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0040] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with a network that includes the device.

[0041] According to some examples, the device includes at least one processor and at least one memory storing instructions, which, when executed by the at least one processor, cause the device to at least: store values ​​in the context information of the user equipment for associating an MDT session.

[0042] According to some examples, the device includes at least one processor and at least one memory storing instructions, which, when executed by the at least one processor, cause the device to at least: forward values ​​to the target node for associating an MDT session when the user equipment switches to the target node.

[0043] According to some examples, the first MDT session includes a recorded MDT session, and the second MDT session includes an instantaneous MDT session.

[0044] According to the eighth aspect, a method is provided, comprising: generating a value for a user equipment for minimizing the association of a drive test MDT session, the MDT session including a first MDT session and a second MDT session; sending to a network entity the value for the user equipment for associating the MDT session and at least one identifier of the first MDT session associated with the value; and sending to the network entity the value for the user equipment for associating the MDT session and at least one identifier of the second MDT session associated with the value.

[0045] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0046] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0047] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with the network.

[0048] According to some examples, the method includes storing values ​​in the context information of the user device to associate MDT sessions.

[0049] According to some examples, the method includes forwarding values ​​used to associate an MDT session to the target node when the user device switches to the target node.

[0050] According to a ninth aspect, a computer-readable medium including instructions is provided, which, when executed by an apparatus, cause the apparatus to perform at least the following: generating a value for a user equipment for associating a minimized drive test MDT session, the MDT session including a first MDT session and a second MDT session; sending to a network entity the value for the user equipment for associating the MDT session and at least one identifier of the first MDT session associated with the value; and sending to the network entity the value for the user equipment for associating the MDT session and at least one identifier of the second MDT session associated with the value.

[0051] According to a tenth aspect, a non-transitory computer-readable medium is provided, comprising program instructions that, when executed by an apparatus, perform at least the following: generating a value for a user equipment for minimizing the association of a drive test MDT session, the MDT session including a first MDT session and a second MDT session; sending to a network entity the value for the user equipment for associating the MDT session and at least one identifier of the first MDT session associated with the value; and sending to the network entity the value for the user equipment for associating the MDT session and at least one identifier of the second MDT session associated with the value. Attached Figure Description

[0052] Embodiments will now be described by way of example only with reference to the accompanying drawings, in which: Figure 1 An example functional framework for artificial intelligence / machine learning (AI / ML) in radio access networks (RAN) is shown; Figure 2 An example message stream for activating MDT measurements is shown; Figure 3A An example message flow is shown for the first phase used to associate an MDT session; Figure 3B An example message flow is shown for the second phase used to associate MDT sessions; Figure 4 An example message flow for associating MDT sessions is shown; Figure 5 An example method flow is shown; Figure 6 An example method flow is shown; Figure 7 A representation of a control device according to some example embodiments is shown; Figure 8 A representation of an apparatus according to some example embodiments is shown; and Figure 9 A schematic representation of a non-volatile memory medium showing storage instructions that, when executed by a processor, allow the processor to perform one or more steps of the methods disclosed herein. Detailed Implementation

[0053] This disclosure relates to MDT configuration in a communication system.

[0054] MDT measurements can be used to determine information about a communication system. The examples in this paper provide a method for determining which MDT sessions originate from the same User Equipment (UE), such that MDT sessions from the same UE are associated.

[0055] Artificial intelligence (AI) / machine learning (ML) can be enabled in the RAN. Enhancements to data collection can be used to enable AI / ML technologies to provide predictions that are beneficial for, to name a few, network energy saving, load balancing, and / or mobility optimization.

[0056] Figure 1An example of how AI / ML can be incorporated into a functional framework within an RAN is shown. Note that this is an example, and different implementations can have different variations of the functional framework; for example, because actors and model inference can be collapsed into a single entity, the example model performance feedback can be optional or even absent. Data is collected from the RAN at point 100. This data can be used as training data for model training performed at point 106. Data collection can provide input inference data for AI / ML model inference function 102.

[0057] Data collection function 100 may include functions for providing input data to model training functions (e.g., function 106) and model inference functions (e.g., function 102). Examples of input data may include measurements from network entities, (multiple) user experiences (UEs), actor feedback, outputs from (multiple) AI / ML models, etc. Data collection 100 may provide training data for input to AI / ML model training function 106. Data collection may also provide input inference data: data for AI / ML model inference function 102.

[0058] Model training function 106 can perform AI / ML model training and / or validation. AI / ML model testing can also use model performance metrics. Data preparation of data provided by data collection function 100 can also be performed by model training function 106 (e.g., data preprocessing and cleaning, formatting and transformation). Model training function 106 can deploy / update ML models to model inference function 102. These deployed / updated models can be validated, trained and / or tested by model training function 106.

[0059] The model inference function 102 can provide AI / ML model inference output (e.g., prediction, decision, etc.). The model inference function 102 can provide model performance feedback to the model training function 106.

[0060] Actor function 104 may include the ability to receive output from model inference function 102 and trigger / execute one or more corresponding actions(s). Actor 104 may trigger actions of other entities and / or execute actions itself. Actor 104 may provide feedback information used to derive training data, inference data, or to monitor the performance of AI / ML models.

[0061] The model trained at point 106 can be deployed as an inference model at point 102. The model can be updated during subsequent training steps. Model inference at point 102 can also be used to provide model performance feedback for model training at point 106. The output from model inference at point 102 can be provided to actor 104, which in turn can provide feedback for data collection at point 100.

[0062] Minimize Drive Test (MDT) characteristics are used by operators who want to obtain feedback on coverage in a specific area of ​​their network (managed MDT) or feedback on the radio conditions experienced by a few specific UEs within a given coverage area of ​​a Public Land Mobile Network (PLMN) (signaling-based MDT). This can be used for Figure 1 Data collection from 100 locations, and for other purposes.

[0063] 3GPP defines two types of MDT: recorded MDT and instantaneous MDT. Recorded MDT is applied to the UE's idle state (e.g., RRC_IDLE) and inactive state (e.g., RRC_INACTIVE mode). For recorded MDT, when the UE is in a connected state (e.g., RRC_CONNECTED), the UE can receive the recorded MDT configuration from the network. The recorded MDT configuration can be stored in the UE. During the configured recording duration, when the UE is in the RRC_IDLE or RRC_INACTIVE state, the configured recorded MDT measurement is performed, and the measurement results are then buffered in the UE. When the UE reconnects to the network, it signals the network that the buffered measurement is available. The network can then retrieve the log and forward it to the network's Operations, Administration, and Maintenance (OAM) system (e.g., Trace Collection Entity - TCE). In connected states (e.g., RRC_connected mode), a recorded MDT configuration is maintained, but no measurements are performed; however, the network can be configured with an on-the-fly MDT configuration for use. The latter may result in the UE being configured with RRC measurements, but the UE does not know whether these RRC measurements are for Radio Resource Management (RRM) or MDT.

[0064] Continuous MDT collection is defined as MDT data collection, which enables the collection of data from the same UE across RRC states (RRC_connected, RRC_idle, RRC_inactive). Continuous MDT can be beneficial in data collection by facilitating data preparation and by avoiding errors in data collection. Continuous MDT can include recorded MDT and instantaneous MDT.

[0065] Continuous MDT can facilitate the data preparation process if measurements are taken, for example, from the “same” UE in different RRC states. This is because measurements such as Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ) can have large biases, for example, across chip vendors. To be able to compare different values ​​reported by different UEs, data preparation to normalize these values ​​needs to be performed on a per-UE implementation basis. If the MDT can correlate measurements from the same UE across RRC states, this normalization is unnecessary because the same UE will give the same error in the data measurements, and data preparation becomes much easier.

[0066] Another example where continuous MDT can be useful is when data is collected to train ML models (e.g., trajectory prediction ML models). In this case, it is easier to predict trajectories by collecting (time-series) location data from the same UE across RRC states. This is because any two UEs cannot be assumed to be in the same location, making it difficult to infer whether they are part of the same (consistent) trajectory or belong to two different trajectories. This determination can create errors by incorrectly merging records from different UEs. These errors can be avoided if trajectory information is collected per UE. Furthermore, collecting data across RRC states is useful for constructing an accurate dataset without losing intermediate points or locations in the trajectory. Therefore, continuous MDT attempts to avoid missing data, or long gaps in data collection due to the loss of some measurements due to UEs transitioning across RRC states.

[0067] Different mobility algorithms are used in idle mode and connected mode. The UE will use the cell reselection algorithm in idle mode (with some parameters provided via network configuration), while mobility in connected mode is under network control, but the network can also apply mobility policies differentiated for each UE. Therefore, merging records from different UEs can lead to errors.

[0068] Signaling-based activation (which is defined for a specific UE) provides access to this continuous measurement sequence because the OAM will know the tracking session activated for each UE, and the core network (e.g., AMF) can store the signaling-based MDT configuration and apply it each time a UE connects to the network. This ensures no interruption to the measurement sequence, as the CN activates an instantaneous MDT whenever a UE connects to the network, and the UE autonomously activates a recorded MDT measurement whenever it transitions to RRC_Idle. Furthermore, the UE and NG RAN handle the transition between RRC_Inactive and RRC_Connected in a similar manner.

[0069] OAM systems typically do not know (e.g., at the cell level) the UE's location, meaning that signaling-based activation is unsuitable for certain scenarios where the selected UE needs to be located in a specific area characterized by a cell or a set of cells. Some examples described in this paper consider UEs located in a given area (e.g., under the coverage of a given gNB or cell), or further, within a tracking area or a set of tracking areas, to obtain a continuous sequence of MDT measurements, thus using management-based MDT activation.

[0070] Some examples described in this article consider how to perform recorded MDT measurements and instantaneous MDT measurements from the same UE.

[0071] RAN nodes can receive MDT configurations (recorded MDT, instant MDT) directly from OAM. In this case, the RAN node itself selects the UE to be configured. This is called a management-based MDT. For management-based MDTs, OAM provides a TR (Tracking Reference), while the RAN node (e.g., an NG RAN node) assigns a TRSR (Tracking Record Session Reference) to each selected UE.

[0072] The RAN node can also receive MDT configurations (recorded MDT, real-time MDT) from the CN via UE-associated signaling. This is called signaling-based MDT and is specific to a particular UE.

[0073] For managed MDT data collection in a non-split architecture where there is no International Mobile Subscriber Identity (IMSI) / International Mobile Station Equipment Identity (Software Version) (IMEI(SV)) / Subscription Permanent Identifier (SUPI) standard, UE selection for the MDT can be performed at the radio point network at the base station (e.g., gNB) based on input information received from the management system and user consent information stored in the base station. For example, this can be performed for OAM input parameters that include area information.

[0074] Figure 2 An example of how to perform management-based MDT configuration is described. Then refer to... Figure 2 The approach considers examples of how to perform a combination of real-time MDT and record-based MDT for managing activation.

[0075] Figure 2 This paper summarizes how to use the cell service tracing functionality to perform MDT configuration, as described in 3GPP TS 32.422. The cell service tracing functionality can be used, for example, to activate NG RAN non-segmented architectures based on management MDT.

[0076] At point 201, the management system 220 sends a tracking session activation request to base station 214 (gNB in ​​this example), which includes parameters for configuring MDT measurements. These parameters may include an indication of the area for the managed MDT-based network. The gNB stores the parameters in a context not associated with the UE. The management system 220 can verify that the Mobile Country Code (MCC) and Mobile Network Code (MNC) specified in the TR are the same as the PLMNs supported by all cells specified in the area range where the MDT is being activated. If gNB 214 receives a request in the TR with a PLMN that does not match any PLMN in its list, it will ignore the request.

[0077] At 203, gNB 214 stores the MDT parameters sent at 201. At 205 and 207, at least one UE, including UE 212, connects to gNB 214. At 205, Access and Mobility Management Function (AMF) 218 ​​sends an Initial Context Establishment Request or Handover Request for at least one UE. A list of managed MDT PLMNs is also provided. At 207, based on this list of managed MDT PLMNs, gNB 214 stores within the UE context of UE 212: the managed MDT is permitted for use by UE 212.

[0078] At 209, gNB 214 selects one or more UEs for managed MDT. gNB 214 should select a suitable UE for MDT data collection. In some examples, this selection is based on the region received from the management system and the region where the UE is located. In some examples, user consent information received from the CN as part of the managed MDT PLMN list information element (IE) can also be used to select a suitable UE. If the user is not in the specified region, or if the managed MDT PLMN list IE does not exist in the UE context, gNB 214 does not select a UE for MDT data collection. During UE selection, gNB 214 may also consider UE capabilities (MDT capabilities) when configuring its UE selection 212 for recorded MDT. If the UE does not support recorded MDT, the UE is not selected. For managed instantaneous MDT, some measurements applicable only to RRC_connections (e.g., M4, M5) are performed directly by gNB 214, and if such measurements are requested in the MDT configuration, gNB 214 should begin the measurement according to the received configuration. The details of the measurement are defined in 3GPP TS 37.320 and 3GPP TS 38.314.

[0079] At 211, if the MDT activation in 201 is for a recorded MDT, the recorded MDT configuration is sent to the selected UE 212. In some examples, the recorded MDT tracking session is stored in UE 212 until the duration of the tracking session expires, including multiple idle or inactive periods interrupted by various RRC state transitions (such as idle-connected-idle state transitions). UE 212 collects MDT measurements and records according to its configuration until its memory reserved for the MDT is full. If this occurs, the UE stops recording, stops the log duration timer, and starts another timer. In some examples, the other timer may be a 48-hour timer.

[0080] At 211, if the MDT activation in 201 is for an immediate MDT and includes measurements performed by UE 212, the corresponding measurements are configured to UE 212 via RRC signaling as defined in TS 38.331. These measurements may correspond to DL signaling quantities further described in 3GPP TS 38.215, such as RSRP (Reference Signal Received Power), RSRQ (Reference Signal Received Quality), and SINR (Signal-to-Interference-plus-Noise Ratio). In the example, the corresponding reports may be configured to be event-triggered, threshold-defined, or periodic. When entering RRC idle mode, the RRC-configured measurements corresponding to the immediate MDT measurement configuration are deleted from UE 212 along with the RRC context. If the MDT activation in 201 is for an immediate MDT and includes measurements performed by gNB 214, gNB 214 autonomously activates these measurements without involving UE 212. Some examples are given where these measurements could be PDCP SDU data volume measurements, average UE throughput measurements, packet delay measurements, and packet loss rate measurements. It can also be noted that if these measurements correspond to an immediate MDT configuration, gNB 214 can collect only the UE measurements already provided by UE 212 without a specific configuration for UE 212. The DL semaphores listed above can be part of such measurements, and the same applies to power margin measurements as defined in 3GPP TS 38.213 reported via the MAC layer. An overview of MDT measurements is provided in 3GPP TS 37.320, which is summarized below for reference.

[0081] Real-time MDT Configuration: For real-time MDT, RAN measurements and UE measurements can be configured. Configuration for UE measurements is based on the existing RRC measurement procedures for configuration and reporting, with extensions for location information. If the area range is included in the MDT configuration provided to the RAN, the UE can be configured with corresponding measurements when it connects to a cell that is part of the configured area range.

[0082] Real-time MDT measurements may include at least one of the following: - M1: DL signal quantity measurement results for the serving cell and for neighboring cells within / between / RAT, including cell / beam level measurements for NR cells only, TS 38.215.

[0083] - M2: Power margin measurement of UE, TS 38.213.

[0084] - M4: PDCP SDU data volume measurement for DL ​​and UL for each DRB of each UE, see TS28.552.

[0085] - M5: Average UE throughput measurements by gNB for DL ​​and UL, respectively, for DL ​​per UE per DRB and per UE, and for UL per UE per DRB and per UE, see TS 28.552.

[0086] - M6: Packet delay measurements for DL ​​and UL for each DRB per UE, TS 28.552 and TS38.314 respectively.

[0087] - M7: Packet loss rate measurements for DL ​​and UL per DRB per UE, TS 28.552 and TS38.314 respectively.

[0088] - M8: RSSI measurements performed by the UE (for WLAN / Bluetooth measurements), see TS 38.331.

[0089] M9: RTT measurement performed by the UE (for WLAN measurement), see TS 38.331.

[0090] A recordable measurement MDT configuration may include at least one of the following: - Configuration for downlink pilot strength measurement recording for (E-)UTRA and NR.

[0091] - Configuration for MBSFN measurement recording for E-UTRA.

[0092] - Configuration for recording event triggering: -For (E-)UTRAN: - Supports periodic measurement triggering, with the recording interval configurable for this trigger. This parameter specifies the periodicity used to store MDT measurement results. It should be configured in seconds and as a multiple of the applied IDLE mode DRX (i.e., a multiple of 1.28 seconds, which is a factor or multiple of the idle mode DRX). UE behavior is not specified when the UE is configured with a DRX period longer than the recording interval.

[0093] -For NR: - Supports periodic measurement triggers, with the recording interval configurable for this trigger. This parameter specifies the periodicity used to store MDT measurement results.

[0094] -For E-UTRAN and NR: It supports event-based triggering, with a configurable recording interval for each trigger. This determines the periodic recording of available data (e.g., timestamps, location information), and supports the following two event types: - For event L1 based on the measurement, the event threshold, hysteresis, and trigger time are configurable. If the configured trigger time is not a multiple of the DRX cycle duration, the UE uses the next multiple of the DRX cycle duration greater than the trigger time to evaluate event L1; - Triggered by detection outside coverage area.

[0095] It should be noted that the recording configuration for both event-based and periodic DL pilot intensity recording measurements can be configured independently. One type of event can be configured for the UE.

[0096] - Configuration for recording duration. This configuration parameter defines the timer that is active at the time of configuration and continues independently of state changes, RAT, or RPLMN changes. When the timer expires, recording stops and the configuration is cleared (except for parameters required for further reporting, such as network absolute timestamp, trace reference, trace recording session reference, and TCE ID).

[0097] - The network absolute timestamp to be used as a time reference for the UE.

[0098] - TR parameters as indicated by the OAM configuration specified in TS 32.422.

[0099] - TRSR as indicated by the OAM configuration specified in TS 32.422.

[0100] - The TCE ID as indicated by the OAM configuration specified in TS 32.422.

[0101] • MDT PLMN list, indicating the PLMNs in which measurement collection and log reporting are permitted. It can be an administration-based MDT PLMN list or a signaling-based MDT PLMN list, depending on how the logging MDT task is initiated.

[0102] - Recording area configuration. The UE will record measurements as long as it is within the configured recording area. The recording area can consist of one of the following: - A list of up to 32 global cell identifiers. If this list is configured, the UE will only record measurements when camped in any of these cells.

[0103] - A list of up to 8 TAs, 8 Location Areas (LAs), or 8 RAs. If this list is configured, the UE will only record measurements when camped in any cell belonging to a pre-configured TA / LA / RA.

[0104] - For NR, a list of inter-frequency neighboring cells for each frequency.

[0105] - The configured recording area can span PLMNs in the MDT PLMN list. If no area is configured, the UE will record measurements across the entire PLMN in the MDT PLMN list.

[0106] - Configuration for the list of NR, neighboring frequencies and / or cells, which indicates to the UE the measurement of neighboring cells, as indicated in the list in the recorded MDT report.

[0107] - For E-UTRA, configuration of (multiple) target MBSFN areas for MBSFN measurement recording. If (multiple) target MBSFN areas are configured, the UE applies those target MBSFN areas in addition to other restrictions such as the recording area. The UE will record measurements as long as it receives MBMS services from the indicated target MBSFN area and within the configured recording area. The (multiple) target MBSFN areas are defined by a list of up to 8 entries, where each entry indicates a carrier frequency and optionally a specific MBSFN area on the carrier frequency.

[0108] - Configuration of WLAN access point names, which instruct the UE to attempt to obtain WLAN measurements associated with these access points.

[0109] - The configuration of Bluetooth beacon names, which instruct the UE to attempt to obtain Bluetooth measurements associated with these beacons.

[0110] - For NR, the configuration of the sensor name instructs the UE to attempt to obtain sensor measurements.

[0111] - For E-UTRA, instruct the UE to attempt to obtain an uncompensated barometric pressure measurement configuration.

[0112] - For NR, the network can use a flag to indicate whether the early measurement / idle mode configuration is relevant for recording measurement purposes, which indicates that the UE is allowed to record measurement results related to the early measurement frequency in the recording MDT report.

[0113] - For NR, the Recorded MDT Type flag indicates that the recorded measurement configuration is a signaling-based MDT.

[0114] At 213, depending on the configured anonymization level, gNB 214 can trigger a cell service tracing procedure to AMF 218 for each selected UE. If MDT anonymization requires the IME-TAC from the MDT record, gNB 214 sends the TRSR, TR, Serving Cell Global Identifier (CGI), and TCE IP address in a cell service tracing message sent to AMF 218 via UE-associated signaling at 215. This occurs when AMF 218 receives the signaling message containing the TRSR, TR, Serving Cell CGI, and privacy indicator. At 217, AMF 218 looks up the subscriber identity (IMEI (SV)) for the given cell from its database and can send the IMEI Tracking Area Code (TAC) along with the TRSR, TR, and Serving Cell CGI to TCE 216.

[0115] At 219, UE 212 can send measurement results to gNB 214 via RRC signaling. For instantaneous MDT, when gNB 214 receives measurements from UE 212 in an RRC message, gNB 214 can store the measurements along with UE 212's serving cell CGI and TR at 221. For recorded MDT, UE 212 is configured to perform recorded MDT measurements during RRC_Idle or RRC_Inactive. UE 212 can indicate the availability of MDT measurements via a one-bit indicator (e.g., the RRCSetupComplete message during connection establishment as specified in 3GPP TS 32.421). gNB 214 can decide to retrieve recorded measurements based on this indicator by sending an RRCUEInformationRequest message to UE 212. UE 212 can respond with the collected MDT logs in a UEInformationResponse message. If the registered PLMN (RPLMN) of UE 212 does not match the PLMN where the TCE used to collect MDT data resides, gNB 214 may not retrieve the MDT report from UE 212. When gNB 214 receives the MDT report from UE 212 at 219, gNB 214 can receive the TRSR, TR, and TCE Id from the report and compare the tracking PLMN (the PLMN portion of the tracking reference) with the PLMN where the TCE 216 used to collect MDT data resides. In the event of a mismatch, the MDT report may be discarded.

[0116] It should be noted that when UE 212 is in any Radio Access Technology (RAT) state, even if there are multiple outage periods when UE 212 is in different RATs, the recorded measurement configuration and records can be maintained. A single recorded measurement configuration exists for the recorded MDT in UE 212 for RAT purposes. When the network provides a configuration, the previously configured recorded measurement configuration will be replaced by the new measurement configuration. The recorded measurements corresponding to the previous configuration will also be cleared. The network should be able to retrieve the data before it is deleted (e.g., when a new configuration is provided to the UE).

[0117] At 223, MDT records can be reported from gNB 214 to TCE 216. For record-based MDT, the TCE ID indicated in the MDT report is translated by gNB to the TCE's actual IP address before the measurement record is forwarded. Address translation is based on the mapping configured in gNB. For instantaneous MDT, the TCE's IP address is indicated to gNB in ​​the tracking configuration.

[0118] At position 225, the correlation of the MDT measurement obtained via MDT can be performed.

[0119] Based on some examples, a management-based activation of a combination of recorded MDT and immediate MDT can be performed to assist in continuous MDT collection. Possible methods for performing management-based activation of a combination of recorded MDT and immediate MDT are outlined below. Regarding the above... Figure 2 The steps and entities outlined in this paper provide an overview of the method; however, it should be noted that this method is merely an example, and other alternative methods are envisioned.

[0120] Initially, the management system 220 sends a management-based, record-based MDT configuration to the gNB 214. In this example, the management-based, record-based MDT configuration includes a first TR, TR A. The management system 220 then sends a management-based, real-time MDT configuration to the gNB 214. In this example, the management-based, real-time MDT configuration includes a second TR, TR B.

[0121] The base station node (gNB 214) then according to Figure 2 209 selects one or more of the UEs it serves (UE 212 in this example) for recorded MDT and instant MDT. In this example, recorded MDT is given a first TRSR, TRSR a, and instant MDT is given a second TRSR, TRSR b, such that the recorded MDT session for UE 212 has TRSR a, TRSR a, and the instant MDT for the MDT session has TRSR b, TRSR b. The recorded MDT configuration is sent to UE 212 according to 211, and the instant MDT configuration is activated according to 211 by, for example, RRC measurement. It can be configured according to... Figure 2 IMEI TAC is provided to TCE from 213 to 217.

[0122] Considering the example where UE 212 is initially in a connected state (e.g., RRC_connected), measurement results from the instantaneous MDT (TR B) can be received by and stored in gNB 212, as per 219 and 221. If UE 212 subsequently enters an idle mode (e.g., RRC_idle), gNB 214 can send the stored MDT measurements (TR B) to TCE 216 (as per 223). In the idle state, as per 211, UE 212 collects and stores measurements according to the recorded MDT configuration (TR A). When UE 212 reconnects to the network (i.e., changes from the idle state to the connected state), UE 212 indicates the availability of the recorded MDT measurements (TR A), and gNB 214 retrieves them as per 219 and forwards the logs to TCE 216 (as per 223). In this step, the network can also reactivate the instantaneous MDT configuration for UE 212. In some examples, immediate MDT records and record-based MDT records can be associated (according to 225).

[0123] As described in the example, when triggered by a cell traffic tracing procedure, the AMF sends specific information to the TCE, allowing the TCE to distinguish the UE without identifying it. This specific information can be sent along with a TR / TRSR, as shown at 223. Using the specific information and the TR / TRSR, records can be combined at 225 to associate different logs related to the same UE.

[0124] Specific information can be one of the following: The random numbers generated are as follows: when the UE registers (when a UE context is created in the CN), or at least before the UE first sends information to the TCE. Figure 2 (217), the AMF generates a random number for the UE and stores the random number in the UE context in the CN for the duration of the random number; or • Hash value of one or more permanent identifiers of the UE (complete International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI)).

[0125] • TR / TRSR for recorded MDT configuration.

[0126] By generating specific information for the UE and providing that information (e.g., values ​​used to associate MDT logs) to the TCE, the TCE can associate MDT logs related to the same UE (with different TR / TRSRs), and then, through post-processing, construct a continuous log independent of the RRC state. In earlier standardized approaches, a permanent UEID (e.g., IMSI (or SUPI in 5G)) was used to allow the association of different MDT logs before mandatory anonymization of the MDT. Using a permanent ID raises security concerns because it allows the UE to be identified.

[0127] The first two options can be considered to involve generating a value used to associate an MDT session for a user equipment. This value can be associated with a specific UE. According to the first option, using a random number enables association of MDT logs but does not identify the UE. According to the second option, a hash value is used in principle for the same purpose as the random number. Furthermore, if an entity knows one or more permanent UE IDs and is also able to regenerate the hash value, it can retrieve logs for a specific UE when needed (e.g., in the event of data loss).

[0128] The third option for using the recorded MDT measurement configuration requires the network to upload the recorded measurement report stored in the UE before the network can send the real-time MDT measurement data to the TCE. The real-time MDT measurement data can then be associated at the TCE.

[0129] Figure 3A The first stage of an example method flow for the first and second options described above is shown. Figure 3A In the first phase shown, the UE undergoes initial configuration, and real-time MDT measurements are performed and reported to TCE 316. At the end of phase 1, the UE 312 enters idle mode and then begins collecting recorded MDT measurements. Figure 3B In the second phase shown, UE 312 reconnects to the network using available recorded MDT measurements. Further MDT measurements can also be collected. Both instantaneous and recorded MDT measurements are reported to TCE 316. TCE 316 can then determine that different MDT records originate from the same UE 312 (in... Figure 3B (of the 351).

[0130] At 301a / b, one or more MDT measurement configurations, including at least one tracking reference (TR), can be sent to base station 314 (in this example, base station 314 includes a gNB, but it should be understood that other base station types may be used in other examples). According to some examples, the one or more MDT measurement configurations sent at 301a / b may include an area indication in which the MDT measurement configuration will be used. At 301a, network entity 320 (in this example, management system 320) sends a recorded MDT measurement configuration to gNB 314. In other examples, the network entity may include, for example, a Network Data and Analytics Function (NWDAF). In this example, the recorded MDT measurement configuration includes TR A. At 301b, management system 320 sends an instantaneous MDT configuration with at least one TR (in this example, TR B). Using the recorded / instantaneous combination information provided by OAM, gNB 314 can select the same UE 312 for both recorded and instantaneous MDTs (discussed below at 309). This can be done by including the TR of the recorded MDT (TR A) along with the immediate MDT configuration (TR B).

[0131] At position 303, the MDT parameters are stored at position 314 of gNB. This can be done as follows: Figure 2 It should be executed as described in section 203.

[0132] At 305a, UE 312 can register with the network. At 305b, a network entity (AMF 318 in this example) can assign a random number (RN) to UE 313. AMF 318 can store the RN in the UE context of UE 312 in the CN (e.g., at AMF 318 or at any other CN entity).

[0133] In the example of inter-CN mobility, the RN assigned to UE 312 at 305b can be forwarded to the target CN as part of the UE context (e.g., in the case of inter-CN handover).

[0134] In 305c, an initial context establishment request or switchover request is sent to gNB 314. This request may include a list of PLMNs for a managed MDT.

[0135] At 307, gNB 314 stores within the UE context for UE 312: allowing managed MDT. For example, this can be performed similarly to 207.

[0136] At 309, gNB 314 selects one or more UEs for the managed MDT based on the MDT parameters received at 301a / b. In this example, gNB 314 selects UE 312. This selection can also be based on the area range indicated by management system 320 and / or the managed MDT PLMN IE received at 305c. Each UE can be assigned a recorded MDT TRSR and an instantaneous MDT TRSR. In this example, UE 312 is assigned TRSR a for recorded MDT and TRSR b for instantaneous MDT.

[0137] At 311a, gNB 314 sends the recorded MDT measurement configuration, TR A, and TRSR a to UE 312. gNB 314 can use the recorded MDT measurement configuration to perform recorded MDT measurements at UE 312.

[0138] At 311b, gNB 314 can send RRC measurements corresponding to the instant MDT measurement configuration to UE 312. gNB 314 can also, or alternatively, use the instant MDT measurement configuration to perform instant MDT measurements relative to UE 312 without involving UE 312.

[0139] At 315a, gNB 314 sends TR A and TRSR a for the recorded MDT session of UE 312 to AMF 318. According to some examples, TR A and TRSR a are sent in the NGAP cell traffic trace message.

[0140] At 315b, gNB 314 sends TR B and TRSR b for the instant MDT session of UE 312 to AMF 318. According to some examples, TR B and TRSR b are sent in the NGAP cell traffic trace message.

[0141] At 317a, for a recorded MDT session at UE 312, TR A, TRSR a, and RN for UE 312 are sent to TCE 316. An IMEI type assignment code (IMEI-TAC) for the recorded MDT session may also be included.

[0142] At 317b, for an immediate MDT session at UE 312, TR B, TRSR b, and RN for UE 312 are sent to TCE 316. An IMEI type assignment code (IMEI-TAC) for the immediate MDT session may also be included.

[0143] At 319, UE 312 can perform an immediate MDT measurement and then send it from UE 312 to gNB 314. At 321, gNB saves the measurement received at 319 to the MDT record at gNB 314. At 323, gNB 314 reports the MDT record, along with TR B and TRSR b, to TCE 316.

[0144] At 325, UE 312 enters idle mode (e.g., RRC_idle) and begins collecting recorded MDT measurements using the configuration received at 311a.

[0145] exist Figure 3B The example describes the second phase, which follows in Figure 3A The first stage.

[0146] At points 327a, 327b, and 327c, UE 312 reconnects to the network of gNB 314. At point 327a, UE 312 sends an RRC establishment request to gNB 314. At point 327b, gNB 314 sends a message to establish an RRC connection with UE 312. At point 327c, UE 312 indicates to gNB 314 that the RRC establishment is complete. At point 327c, UE 312 can also indicate to gNB 314 that the recorded MDT measurement was performed from... Figure 3A It can be obtained from 325 locations.

[0147] At 327d, AMF 318 can send an initial context establishment request or a switchover request to gNB 314. This request may include a list of PLMNs for a managed MDT.

[0148] At 329, gNB 314 can be stored within the UE context for UE 312: for UE 312, management-based MDT is allowed.

[0149] At 331, gNB 314 uses TR B received at 301b to select UE 312 for managed instant MDT and assigns TRSR c to the instant MDT session.

[0150] At 333, gNB 314 sends the measurement configuration for real-time MDT. This can be performed using RRC signaling.

[0151] At 335, gNB 314 sends TR B and TRSR c for the instant MDT session of UE 312 to AMF 318. According to some examples, TR B and TRSR c are sent in the NGAP cell traffic trace message.

[0152] At 337, for the instant MDT session at UE 312, TR B, TRSR c, and RN for UE 312 are sent to TCE 316. An IMEI type assignment code (IMEI-TAC) for the instant MDT session may also be included.

[0153] At 339, UE 312 can perform an instantaneous MDT measurement and then send it from UE 312 to gNB 314. At 341, gNB saves the measurement received at 319 to the MDT record at gNB 314. At 343, gNB 314 reports the MDT record, along with TR B and TRSR c, to TCE 316.

[0154] At 345, gNB 314 sends a request (e.g., UE information request) to the UE to obtain one or more recorded MDT measurement reports (indicated as available at 327c). At 345b, UE 312 sends a response (e.g., UE information response) to gNB 314, which includes at least one recorded MDT measurement report with TR A and TRSR a. At 347, gNB 314 saves the recorded MDT record to an MDT record. At 349, the recorded MDT record, along with TR A and TRSR a, is sent to TCE 316.

[0155] At 351, TCE 316 can use the received RN associated with UE 312 and the MDT session reference (in this example, {TR B, TRSR b}, {TR B, TRSR c}, {TR A, TRSR a}) to determine Figure 3A and 3B The two real-time MDT sessions and the recorded MDT sessions originated from the same UE.

[0156] It should be noted that, although in Figure 3A The example shows two immediate MDT sessions and one recorded MDT session, but in other examples, there may be X (more) immediate MDT sessions and Y (more) recorded MDT sessions, where X and Y are positive integers or zero, and X+Y is greater than or equal to 2.

[0157] As an alternative to generating RN based on the first option mentioned above, one can... Figure 3A and 3B The second option is used, which involves generating a hash of one or more of the UE 312's permanent IDs (Complete International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI)) at 305b instead of sending the hash value. Figure 3A and3B RN in.

[0158] Figure 4 An example method according to the third option above is shown, where the TR and TRSR of a previous recorded MDT session can be used to associate an MDT session from the UE. In 450, we assume that UE 412 has already participated in a previous recorded MDT session with TR A and TRSRa.

[0159] At 401b, the management system 420 sends an instantaneous MDT configuration with at least one TR (TR B in this example) to the base station 414. In this example, the base station 414 includes a gNB.

[0160] At position 403, the MDT parameters are stored at position 414 of gNB. This can be done as follows: Figure 2 It should be executed as described in section 203.

[0161] At 405a, UE 412 indicates to gNB 414 that RRC establishment has been completed. At 405a, UE 412 can also indicate to gNB 414 that recorded MDT measurements are available.

[0162] At 405b, AMF 418 can send an initial context establishment request or a switchover request to gNB 414. This request may include a list of PLMNs for a managed MDT.

[0163] At 407, gNB 414 can be stored within the UE context for UE 412: for UE 412, a managed MDT is allowed.

[0164] At 409, gNB 414 uses TR B received at 401b to select UE 412 for managed instant MDT and assigns TRSR b to the instant MDT session.

[0165] It can be similar to Figure 2 211 to 219 are used to execute 411 to 419.

[0166] At 421, gNB 414 can store UE measurements for an instant MDT session from UE 412 into an MDT record, including TR B and TRSR b for the instant MDT session.

[0167] At 423a, gNB 414 requests TR A and TRSR a from UE 412. This can be requested by requesting a recorded measurement report from UE 412. TR A and TRSR a for UE 412 can be sent from UE 412 to gNB 414. Prior to 423b, gNB 414 is unaware of TRSR a. TR A and TRSR a can then be stored in the UE context for UE 412 for use in cases where further reporting of immediate MDT measurements to TCE 416 is required when the UE is in an RRC connection.

[0168] At 423d, gNB 414 can send TR A and TRSR a to TCE 416 for UE 412.

[0169] At 423e, along with the stored instantaneous MDT measurements, the recorded MDT references (TR A, TRSR a) are reported to allow for association in TCE 416 (along with the instantaneous MDT references (TR B, TRSR b)).

[0170] At 424, the recorded MDT log and the real-time MDT log are correlated in TCE 416 based on the recorded MDT session references (TR A, TRSR a). By including TR A and TRSR a, any future MDT sessions from UE 412 can be similarly reported to TCE 416, which allows TCE to correlate MDT sessions to determine which MDT sessions originated from the same UE 412.

[0171] Figure 5 An example method flow is shown. This method can be executed, for example, by a TCE (such as TCE 216, 316, 416).

[0172] At 500, the method includes receiving a value for associating an MDT session, and at least one identifier of a first MDT session associated with the value, the MDT session including a first MDT session and a second MDT session, wherein the value for associating the MDT session is associated with a user equipment.

[0173] At 502, the method includes receiving at least one first MDT record associated with the first MDT session.

[0174] At 504, the method includes receiving a value for associating an MDT session and at least one identifier for a second MDT session associated with the value.

[0175] At 506, the method includes receiving at least one second MDT record associated with the second MDT session.

[0176] At 508, the method includes: determining, based on values ​​used to associate MDT sessions, that at least one first MDT record and at least one second MDT record both originate from the user equipment.

[0177] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0178] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0179] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with the network.

[0180] According to some examples, the values ​​used to associate an MDT session are stored in the context information of the user equipment in at least one core network node.

[0181] According to some examples, at least one core network node includes AMF.

[0182] According to some examples, when a user device switches to a target node, the values ​​associated with the MDT session are forwarded to the target node.

[0183] According to some examples, the first MDT session includes a recorded MDT session, and the second MDT session includes a continuous MDT session.

[0184] Figure 6 An example method flow is shown. This method can be executed by an AMF (such as AMF 218, AMF 318, AMF 418).

[0185] At 600, the method includes generating values ​​for a user device to associate an MDT session, the MDT session including a first MDT session and a second MDT session for the user device.

[0186] At 602, the method includes sending to a network entity a value for a user equipment used to associate an MDT session and at least one identifier of a first MDT session associated with the value.

[0187] At 604, the method includes sending to a network entity at least one identifier for a user equipment, used to associate an MDT session and a second MDT session associated with the value.

[0188] According to some examples, the values ​​used to associate an MDT session include a random number or a hash of a user device's permanent identifier.

[0189] According to some examples, the permanent identifier of a user device includes the complete IMEI, IMSI, or SUPI.

[0190] According to some examples, the values ​​used to associate an MDT session are generated when the user equipment registers with the network.

[0191] According to some examples, the method includes storing values ​​in the context information of the user device to associate MDT sessions.

[0192] According to some examples, the method includes forwarding values ​​used to associate an MDT session to the target node when the user device switches to the target node.

[0193] Figure 7 An example of a control device 760 for controlling a network is shown. The control device may include at least one random access memory (RAM) 711a, at least one read-only memory (ROM) 711b, at least one processor 712, 713, and an input / output interface 714. At least one processor 712, 713 may be coupled to the RAM 711a and ROM 711b. At least one processor 712, 713 may be configured to execute appropriate software code 715. The software code 715 may, for example, allow at least one processor 712, 713 to perform one or more steps of any method flow described herein. The software code 715 may be stored in the ROM 711b. The control device 700 may be interconnected with another control device 700 that controls another function of the RAN or core network.

[0194] Figure 8 An example of a terminal 800, such as a UE, is shown. Terminal 800 can be provided by any device capable of transmitting and receiving radio signals. In some examples, the terminal may include a user equipment, a mobile station (MS) or mobile device (such as a mobile phone or a device called a "smartphone"), a computer provided with a wireless interface card or other wireless interface facilities (e.g., a USB dongle), a personal data assistant (PDA) or tablet computer provided with wireless communication capabilities, a machine-type communication (MTC) device, an Internet of Things (IoT) type communication device, or any combination thereof. Terminal 800 can provide, for example, communication for carrying data. Communication can be one or more of voice, email, text messages, multimedia, data, machine data, etc.

[0195] Terminal 800 can be configured to receive signals via appropriate means for receiving, through an air interface or radio interface 807, and can transmit signals via appropriate means for transmitting radio signals. Figure 8 In this diagram, the transceiver device is schematically designated by block 806. The transceiver device 806 may be provided, for example, by means of a radio section and an associated antenna arrangement. The antenna arrangement may be located inside or outside the mobile device.

[0196] Terminal 800 may be provided with at least one processor 801, at least one memory ROM 802a, at least one RAM 802b, and other possible components 803 and 804 for use in the software and hardware-assisted execution of tasks designed to be performed, including control of access to and communication with access systems and other communication devices. At least one processor 801 is coupled to RAM 802b and ROM 802a. At least one processor 801 may be configured to execute appropriate software code 808. Software code 808 may, for example, allow the execution of one or more steps of any method flow described herein. Software code 808 may be stored in ROM 802a.

[0197] Processors, storage devices, and other related control devices may be provided on a suitable circuit board and / or chipset. This example is indicated by reference numeral 802. The device may optionally have a user interface, such as a keypad 805, a touch-sensitive screen or keypad, combinations thereof, etc. Optionally, depending on the type of device, one or more of a display, speaker, and microphone may be provided.

[0198] UE (such as Figure 3A and 3B UE 312 in Figure 2 UE 212 or Figure 4 UE412 in the middle can take the following measures: Figure 8 The terminal device 400 is shown schematically in the diagram.

[0199] Figure 9 A schematic diagram is shown of non-volatile memory media 900a (e.g., computer disk (CD) or digital universal disk (DVD)) and 900b (e.g., Universal Serial Bus (USB) Memory Stick) that store instructions and / or parameters 902, which, when executed by a processor, allow the processor to perform one or more steps of any method flow described herein.

[0200] It should be understood that the device may include or be coupled to other units or modules, such as radio sections or radio heads used for transmitting and / or receiving. Although the device has been described as a single entity in some examples, different modules and memories may be implemented in one or more physical or logical entities.

[0201] Note that while some examples are described with respect to 5G networks, similar technologies and / or mechanisms can be applied to other networks and communication systems, such as 6G and beyond. Therefore, although some examples have been described above by reference to certain example architectures used in wireless networks, technologies, and standards, other examples can be applied to any other suitable form of communication system besides those shown and described herein.

[0202] It should also be noted that while various examples have been detailed above, some variations and modifications can be made to any of the aforementioned example solutions without departing from the scope of the examples described herein.

[0203] As used herein, “at least one of the following: a list of two or more elements” and “at least one of the lists of two or more elements” and similar wording, wherein the list of two or more elements is connected by “and” or “or”, means at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.

[0204] Generally, various examples can be implemented in hardware or special-purpose circuit systems, software, logic, or any combination thereof. Some examples detailed in this subject matter disclosure can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, but this subject matter disclosure is not limited thereto. Although various aspects of this subject matter disclosure may be illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, special-purpose circuits or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof, as non-limiting examples.

[0205] As used herein, the term "circuit system" may refer to one or more, or all of the following: (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuits only) and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and (ii) Any part of the (multiple) hardware processors (including (multiple) digital signal processors), software, and (multiple) memories, which work together to enable a device (such as a mobile phone or server) to perform various functions and (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g. firmware) to operate, but may not exist when the software is not required to operate.

[0206] The definition of circuit system applies to all uses of the term herein, including any claim. As yet another example, as used herein, the term circuit system also covers implementations of hardware circuitry or processors (or processors) or hardware circuitry or processors and their accompanying software and / or firmware. The term circuit system also covers, for example (and if applicable to a particular claim element), baseband integrated circuits or processor integrated circuits for mobile devices or similar integrated circuits in servers, cellular network devices or other computing or networking devices.

[0207] The various examples detailed in this disclosure can be implemented by computer software executable by a mobile device's data processor (e.g., a processor entity), by hardware, or by a combination of software and hardware. Computer software or programs (also known as program products), including software routines, applets, and / or macros, can be stored in any device-readable data storage medium and include program instructions for performing a specific task. A computer program product can include one or more computer-executable components configured, when the program is run, to perform one or more steps of any of the method flows described herein. The one or more computer-executable components can be at least one piece of software code or a portion thereof.

[0208] Furthermore, it should be noted that any box in the logical flow diagram can represent a program step, or an interconnected logic circuit, a box and function, or a combination of program steps and logic circuits, boxes and functions. Software can be stored on physical media such as memory chips, memory blocks implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs, etc. The physical media can be implemented as non-transitory media.

[0209] As used herein, the term “non-transient” refers to the limitations of the medium itself (e.g., tangible rather than signaling), rather than limitations on the persistence of data storage (e.g., RAM versus ROM).

[0210] The memory can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. The data processor can be of any type suitable for the local technical environment and, by way of non-limiting example, can include one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an FPGA, gate-level circuits, and processors based on multi-core processor architectures.

[0211] The examples disclosed in this topic can be practiced in various components such as integrated circuit modules. Integrated circuit design is a highly automated process. Complex and powerful software tools can be used to transform logic-level designs into semiconductor circuit designs ready to be etched and formed on semiconductor substrates.

[0212] The scope of protection sought by the various examples described herein is set forth in the independent claims. Examples described herein that do not fall within the scope of the independent claims (if any) shall be interpreted as examples that aid in understanding the various aspects disclosed herein.

[0213] The foregoing description is provided by way of non-limiting example to provide a complete and informative description of the subject matter disclosure. However, various modifications and adaptations will be apparent to those skilled in the art when read in conjunction with the accompanying drawings and claims, given the foregoing description. Nevertheless, all such and similar modifications to the teachings of this disclosure will still fall within the scope of the examples described herein. In fact, there are other examples that include combinations of one or more examples with any other examples previously described herein.

Claims

1. An apparatus comprising: A component for receiving a value associated with a minimizing drive test MDT session and at least one identifier of a first MDT session associated with the value, the MDT session including the first MDT session and a second MDT session, wherein the value associated with the MDT session is associated with a user equipment. A component for receiving at least one first MDT record associated with the first MDT session; A component for receiving the value used to associate an MDT session and at least one identifier of the second MDT session associated with the value; A component for receiving at least one second MDT record associated with the second MDT session; as well as The component used to determine, based on the value used to associate the MDT session, that both the at least one first MDT record and the at least one second MDT record originate from the user equipment.

2. The apparatus of claim 1, wherein the value used to associate the MDT session includes a random number or a hash value of a permanent identifier of the user equipment.

3. The apparatus of claim 2 or 3, wherein the value used to associate the MDT session is generated when the user equipment registers with the network.

4. The apparatus according to any one of claims 1 to 3, wherein the value for associating the MDT session is stored in the context information of the user equipment in at least one core network node.

5. The apparatus according to any one of claims 1 to 4, wherein when the user equipment switches to the target node, the value associated with the MDT session is forwarded to the target node.

6. The apparatus according to any one of the preceding claims, wherein the first MDT session comprises a recorded MDT session, and the second MDT session comprises an instantaneous MDT session.

7. A method comprising: Receive a value for minimizing the association of a drive test MDT session, and at least one identifier of a first MDT session associated with the value, the MDT session including the first MDT session and a second MDT session, wherein the value for minimizing the association of the MDT session is associated with a user equipment. Receive at least one first MDT record associated with the first MDT session; Receive the value used to associate the MDT session and at least one identifier of the second MDT session associated with the value; Receive at least one second MDT record associated with the second MDT session; as well as Based on the value used to associate the MDT session, it is determined that both the at least one first MDT record and the at least one second MDT record originate from the user equipment.

8. The method of claim 7, wherein the value used to associate the MDT session includes a random number or a hash of a permanent identifier of the user equipment.

9. The method of claim 7 or 8, wherein the value used to associate the MDT session is generated when the user equipment registers with the network.

10. The method according to any one of claims 7 to 9, wherein the value used to associate the MDT session is stored in the context information of the user equipment in at least one core network node.

11. The method according to any one of claims 7 to 10, wherein when the user equipment switches to the target node, the value associated with the MDT session is forwarded to the target node.

12. The method according to any one of claims 7 to 11, wherein the first MDT session comprises a recorded MDT session, and the second MDT session comprises a continuous MDT session.

13. A computer program comprising instructions stored thereon, the instructions being configured to perform at least the following: Receive a value for minimizing the association of a drive test MDT session, and at least one identifier of a first MDT session associated with the value, the MDT session including the first MDT session and a second MDT session, wherein the value for minimizing the association of the MDT session is associated with a user equipment. Receive at least one first MDT record associated with the first MDT session; Receive the value used to associate the MDT session and at least one identifier of the second MDT session associated with the value; Receive at least one second MDT record associated with the second MDT session; as well as Based on the value used to associate the MDT session, it is determined that both the at least one first MDT record and the at least one second MDT record originate from the user equipment.

14. An apparatus comprising: A component for generating values ​​for user equipment that minimize the association of drive test MDT sessions, the MDT sessions including a first MDT session and a second MDT session; A component for sending to a network entity the value associated with the user equipment for which an MDT session is associated, and at least one identifier of the first MDT session associated with the value. as well as A component for sending to the network entity the value for the user equipment used to associate an MDT session and at least one identifier of the second MDT session associated with the value.

15. The apparatus of claim 14, wherein the value used to associate the MDT session includes a random number or a hash of a permanent identifier of the user equipment.

16. The apparatus of any one of claims 14 to 15, wherein the value for associating the MDT session is generated when the user equipment registers with a network including the apparatus.

17. The apparatus according to any one of claims 14 to 16, comprising: A component for storing the values ​​used to associate the MDT session in the context information of the user equipment.

18. The apparatus according to any one of claims 14 to 17, comprising: A component for forwarding the value used to associate the MDT session to the target node when the user equipment switches to the target node.

19. The apparatus of any one of claims 14 to 18, wherein the first MDT session comprises a recorded MDT session, and the second MDT session comprises an instantaneous MDT session.

20. A method comprising: Generate values ​​for user equipment to minimize the association of drive test MDT sessions, wherein the MDT sessions include a first MDT session and a second MDT session; Send to the network entity the value for the user equipment used to associate an MDT session and at least one identifier of the first MDT session associated with the value; as well as Send to the network entity the value for the user equipment used to associate an MDT session and at least one identifier of a second MDT session associated with the value.

21. The method of claim 20, wherein the value used to associate the MDT session includes a random number or a hash of a permanent identifier of the user equipment.

22. The method of claim 20 or 21, wherein the value used to associate the MDT session is generated when the user equipment registers with the network.

23. The method according to any one of claims 20 to 22, comprising: The value used to associate the MDT session is stored in the context information of the user equipment.

24. The method according to any one of claims 20 to 23, comprising: When the user equipment switches to the target node, the value used to associate the MDT session is forwarded to the target node.

25. A computer program comprising instructions stored thereon, the instructions being configured to perform at least the following: Generate values ​​for user equipment to minimize the association of drive test MDT sessions, wherein the MDT sessions include a first MDT session and a second MDT session; Send to the network entity the value for the user equipment used to associate an MDT session and at least one identifier of the first MDT session associated with the value; as well as Send to the network entity the value for the user equipment used to associate an MDT session and at least one identifier of a second MDT session associated with the value.

Images