Method, apparatus and computer program

Abstract

Correlation of Minimisation of Drive Tests (MDT) sessions from the same user equipment (UE) by means of a value which is associated with the UE, comprising: receiving a value for correlating the MDT s

Description

FIELD

[0001] The present application relates to an apparatus, method and computer program. In particular, but not exclusively, the present application relates to Minimization of Drive Tests (MDT). BACKGROUND

[0002] A communication system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, base stations and / or other nodes by providing carriers between the various entities involved in the communications path. A communication system can be provided for example by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, video, electronic mail (email), text message, multimedia and / or content data and so on. Nonlimiting examples of services provided comprise two-way or multi-way calls, data communication or multimedia services and access to a data network system, such as the Internet.

[0003] The communication system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Communication protocols and / or parameters which shall be used for the connection are also typically defined. One example of a communications system is UTRAN (3G radio). Other examples of communication systems are the long-term evolution (LTE) of the 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

[0004] According to a first aspect there is provided an apparatus comprising: means for receiving a value for correlating Minimization of Drive Tests, 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, wherein the value for correlating 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 the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value; means for receiving at least one second MDT record related to the second MDT session; means for determining, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are both originated from the user equipment.

[0005] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment

[0006] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SUPI.

[0007] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

[0008] According to some examples, the value for correlating the MDT sessions is stored in context information of the user equipment in at least one Core Network node.

[0009] According to some examples, the at least one Core Network node comprises an AMF.

[0010] According to some examples, upon a handover of the user equipment to a target node, the value for correlating the MDT sessions is forwarded to the target node.

[0011] According to some examples, the first MDT session comprises a logged MDT session and the second MDT session comprises an immediate MDT session.

[0012] According to a second aspect, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive a value for correlating Minimization of Drive Tests, 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, wherein the value for correlating MDT sessions is associated with a user equipment; receive at least one first MDT record related to the first MDT session; receive the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value; receive at least one second MDT record related to the second MDT session; determine, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are both originated from the user equipment.

[0013] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

[0014] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SUPI.

[0015] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

[0016] According to some examples, the value for correlating the MDT sessions is stored in context information of the user equipment in at least one Core Network node.

[0017] According to some examples, the at least one Core Network node comprises an AMF.

[0018] According to some examples, upon a handover of the user equipment to a target node, the value for correlating the MDT sessions is forwarded to the target node.

[0019] According to some examples, the first MDT session comprises a logged MDT session and the second MDT session comprises an immediate MDT session.

[0020] According to a third aspect there is provided a method comprising: receiving a value for correlating Minimization of Drive Tests, 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, wherein the value for correlating MDT sessions is associated with a user equipment; receiving at least one first MDT record related to the first MDT session; receiving the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value; receiving at least one second MDT record related to the second MDT session; determining, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are originated from the user equipment.

[0021] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

[0022] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SlIPI.

[0023] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

[0024] According to some examples, the value for correlating the MDT sessions is stored in context information of the user equipment in at least one Core Network node.

[0025] According to some examples, the at least one Core Network node comprises an AMF.

[0026] According to some examples, upon a handover of the user equipment to a target node, the value for correlating the MDT sessions is forwarded to the target node.

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

[0028] According to a fourth aspect there is provided a computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: receive a value for correlating Minimization of Drive Tests, 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, wherein the value for correlating MDT sessions is associated with a user equipment; receive at least one first MDT record related to the first MDT session; receive the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value; receive at least one second MDT record related to the second MDT session; determine, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are both originated from the user equipment.

[0029] According to a fifth aspect, there is provided a non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the following: receive a value for correlating Minimization of Drive Tests, 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, wherein the value for correlating MDT sessions is associated with a user equipment; receive at least one first MDT record related to the first MDT session; receive the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value; receive at least one second MDT record related to the second MDT session; determine, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are both originated from the user equipment.

[0030] According to a sixth aspect there is provided an apparatus comprising: means for generating a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment; means for sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of the first MDT session associated with the value; means for sending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of the second MDT session associated with the value.

[0031] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

[0032] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SlIPI.

[0033] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network comprising the apparatus.

[0034] According to some examples, the apparatus comprises: means for storing the value for correlating the MDT sessions in context information of the user equipment.

[0035] According to some examples, the apparatus comprises means for forwarding the value for correlating the MDT sessions to a target node upon a handover of the user equipment to the target node.

[0036] According to some examples, the first MDT session comprises a logged MDT session and the second MDT session comprises an immediate MDT session.

[0037] According to a seventh aspect there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: generate a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment; send, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of the first MDT session associated with the value; send, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of the second MDT session associated with the value.

[0038] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

[0039] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SUPI.

[0040] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network comprising the apparatus.

[0041] According to some examples, the apparatus comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: store the value for correlating the MDT sessions in context information of the user equipment.

[0042] According to some examples, the apparatus comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: forward the value for correlating the MDT sessions to a target node upon a handover of the user equipment to the target node.

[0043] According to some examples, the first MDT session comprises a logged MDT session and the second MDT session comprises an immediate MDT session.

[0044] According to an eighth aspect there is provided a method comprising: generating a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment; sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a first MDT session associated with the value; sending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a second MDT session associated with the value.

[0045] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

[0046] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SUPI.

[0047] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

[0048] According to some examples, the method comprises storing the value for correlating the MDT sessions in context information of the user equipment.

[0049] According to some examples, the method comprises forwarding the value for correlating the MDT sessions to a target node upon a handover of the user equipment to the target node.

[0050] According to a ninth aspect there is provided a computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: generating a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment; sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a first MDT session associated with the value; sending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a second MDT session associated with the value.

[0051] According to a tenth aspect there is provided a non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the following: generating a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment; sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a first MDT session associated with the value; sending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a second MDT session associated with the value. DESCRIPTION OF FIGURES

[0052] Embodiments will now be described, by way of example only, with reference to the accompanying Figures in which:

[0053] Figure 1 shows an example functional framework for Artificial Intelligence / Machine Learning (AI / ML) in Radio Access Network (RAN);

[0054] Figure 2 shows an example message flow for activating MDT measurements;

[0055] Figure 3A shows an example message flow for a first phase for correlating MDT sessions;

[0056] Figure 3B shows an example message flow for a second phase for correlating MDT sessions;

[0057] Figure 4 shows an example message flow for correlating MDT sessions;

[0058] Figure 5 shows an example method flow;

[0059] Figure 6 shows an example method flow;

[0060] Figure 7 shows a representation of a control apparatus according to some example embodiments;

[0061] Figure 8 shows a representation of an apparatus according to some example embodiments; and

[0062] Figure 9 shows a schematic representation of a non-volatile memory medium storing instructions which when executed by a processor allow a processor to perform one or more of the steps of the methods disclosed herein. DETAILED DESCRIPTION

[0063] The present disclosure relates to MDT configuration in a communications system.

[0064] MDT measurements can be used to determine information about a communications system. Examples herein provide a method for determining which MDT sessions originate from the same User Equipment (UE), such that MDT sessions from the same UE to be correlated.

[0065] Artificial Intelligence (Al) / Machine Learning (ML) can be enabled in RAN. Enhancements in data collection can be used to enable AI / ML techniques provide predictions beneficial for e.g., network energy saving, load balancing and / or mobility optimization, to give a few examples.

[0066] Figure 1 shows an example of a functional framework of how AI / ML can be incorporated in a RAN. Note that this is an example and different implementations may have different variations of the functional framework e.g., in that the Actor and the Model Inference may be collapsed in a single entity, Model Performance feedback may be optional or even non-existent, to give some examples. Data is collected at 100 from the RAN. This data can be used as training data for model training performed at 106. Data collection may provide input inference data for the AI / ML Model Inference function 102.

[0067] Data Collection function 100 may comprise a function 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, UE(s), actor feedback, output from AI / ML model(s), etc. Data collection 100 may provide training Data for input to AI / ML Model Training function 106. Data collection may provide input inference Data: Data for the AI / ML Model Inference function 102.

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

[0069] Model inference function 102 may provide AI / ML model inference output (e.g., predictions, decisions, etc.). Model inference function 102 may provide model performance feedback to model training function 106.

[0070] Actor function 104 may comprise a function that receives output from model inference function 102 and trigger / perform one or more corresponding action(s). Actor 104 may trigger actions for other entities and / or may perform actions itself. Actor 104 may feedback information for deriving training data, inference data or for monitoring AI / ML model performance.

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

[0072] The MDT (Minimization of Drive Tests) feature is used by operators who want feedback on the coverage on a particular area of their network (Management-based MDT) or feedback on the radio conditions experienced by some specific UE(s) in a given coverage area of a Public Land Mobile Network (PLMN) (signalling based MDT). This can be used for data collection at 100 of Figure 1, as well as for other purposes.

[0073] 3GPP has defined two types of MDT, Logged MDT and Immediate MDT. Logged MDT applies for idle states of a UE e.g., RRC_IDLE and inactive states of a UE e.g., RRCJNACTIVE modes. For logged MDT, the UE may receive a logged MDT configuration from the network, when it is in a connected state e.g., RRC_CONNECTED. The logged MDT configuration may be stored in the UE. The configured logged MDT measurements are performed when the UE is in an RRC_IDLE state or an RRCJNACTIVE state during the configured logging duration, and measurement results are then buffered in the UE. When the UE reconnects to a network, the availability of buffered measurements is signalled to the network. The network may then retrieve the log and forward to the Operations, Administration and Management (OAM) system of the network (e.g., Trace Collection Entity - TCE). In a connected state (e.g., RRC_CONNECTED mode) the logged MDT configuration is kept but the measurements are not performed, however the network may be configured with an Immediate MDT configuration to use. The latter may result the UE to be configured with RRC measurements, however the UE is not aware whether the purpose of these RRC measurements are Radio Resource Management (RRM) or MDT.

[0074] Continuous MDT collection is defined as MDT data collection that enables to collect data from the same UE across RRC states (RRC_Connected, RRC_ldle, RRCJnactive). Continuous MDT may have benefits in the data collection by facilitating data preparation and by avoiding errors in the data collection. Continuous MDT may comprise logged MDT and immediate MDT.

[0075] Continuous MDT can facilitate the data preparation process if for example a measurement is taken 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) measurements may have a large deviation, for example across chip vendors. To be able to compare the different values reported by different UEs, data preparation normalizing these values needs to be performed per UE implementation. If MDT can correlate measurements from the same UE across RRC states, then this normalization is not needed since the same UE will be giving the same error in the data measurements and data preparation becomes easier.

[0076] Another example where Continuous MDT could be useful is when data is collected to train an ML Model (e.g., a trajectory prediction ML model). In this case, it is easier to predict trajectories by collecting (time-series) of location data across RRC states from the same UE. This is because any two UEs cannot be assumed to be located at the same location, so it is hard to deduce if they are part of the same (identical) trajectory or they belong to two different trajectories. This determination could create errors by erroneously merging logs from different UEs. Those errors could be avoided if trajectory information is collected per UE. In addition, collecting data across RRC states is useful to build accurate data sets, not missing intermediate points or locations in the trajectory. Therefore continuous MDT tries to avoid missing data, or having long gaps in the data collection due to losing some measurements across RRC transitions of a UE.

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

[0078] Signalling-based activation, which by definition targets a specific UE, provides access to such continuous measurement series because the OAM will have the knowledge of the trace sessions activated per UE, and the Core Network (e.g., AMF) may store the signallingbased MDT configuration and apply it each time the UE connects to the network. This ensures that there will be no interruption of measurement series because the CN activates immediate MDT each time the UE connects to the network, and the UE autonomously activates logged MDT measurements each time it transits to RRC_IDLE. Also transitions between RRC_INACTIVE and RRC_CONNECTED are handled in a similar way by the UE and the NG-RAN.

[0079] UE location, e.g., at cell level, is typically not known by the OAM system, which means that signalling-based activation is not suitable for certain scenarios where the chosen UEs need to be located in a certain area, characterized by a cell or set of cells. Some of the examples described herein consider obtaining continuous series of MDT measurements for UEs located in a given area, e.g., under the coverage of a given gNB or cell, or, to give some further examples, within a tracking area or set of tracking areas, hence using managementbased MDT activation.

[0080] Some examples described herein consider how to logged MDT measurements and immediate MDT measurements from the same UE.

[0081] A RAN node may receive MDT configurations (logged MDT, immediate MDT) directly from the OAM, in which case the RAN node itself selects the UEs to be configured. This is called management-based MDT. For management-based MDT, the OAM provides the TR (Trace Reference), while the RAN node (e.g., NG-RAN node) allocates a TRSR (Trace Recording Session Reference) per selected UE.

[0082] The RAN node may also receive MDT configurations (logged MDT, immediate MDT) from the CN via UE-associated signalling. This case is called signalling-based MDT, and targets a specific UE.

[0083] For management-based MDT data collection with no International Mobile Subscriber Identity (IMSI) / lnternational Mobile station Equipment Identity (Software Version) (IMEI(SV)) / Subscription Permanent Identifier (SUPI) criteria in the case of non-split architecture, UE selection for MDT can be done in a radio network at a base station (e.g., gNB) based on the input information received from a management system and the user consent information stored in the base station. This can be performed for OAM input parameters comprising Area information, for example.

[0084] Figure 2 describes an example of how management-based MDT configuration can be performed. An example of how combined management activation of immediate and logged MDT can be performed is then considered, with respect to the method of Figure 2.

[0085] Figure 2 summarizes how MDT configuration can be performed using a cell traffic trace functionality, as described in 3GPP TS 32.422. The cell traffic trace functionality may be used, for example, for management-based MDT activation NG-RAN non-split architecture.

[0086] At 201, management system 220 sends a Trace Session activation request to a base station 214 (in this example, a gNB) including parameters for configuring MDT measurements. The parameters may include an indication of area of a network for management-based MDT. The gNB stores the parameters in a non-UE associated context. Management system 220 can validate that the Mobile Country Code (MCC) and Mobile Network Code (MNC) specified in the TR is the same as the PLMN supported by all the cells specified in an area scope in which MDT is being activated. If gNB 214 receives a request with a PLMN in the TR that does not match any PLMN in its list, it will ignore the request.

[0087] 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 setup request or a handover request for the at least one UE. A list of management-based MDT PLMNs is also provided in a list. At 207, based on the list of management-based MDT PLMNs, gNB 214 stores within a UE context of UE 212 that management-based MDT is allowed for UE 212.

[0088] At 209, gNB 214 selects one or more UEs for management-based MDT. gNB 214 shall select the suitable UEs for MDT data collection. In some examples, the selection is based on the area received from the management system and the area where UE is located. In some examples, user consent information received from the CN as part of the managementbased MDT PLMN List Information Element (IE) may also be used to select suitable UEs. If the user is not in the specified area or if the Management based MDT PLMN List IE is not present in the UE context the UE is not selected by gNB 214 for MDT data collection. During UE selection, gNB 214 can take into account also the UE capability (MDT capability) when it selects UE 212 for logged MDT configuration. If a UE does not support logged MDT, the UE is not selected. For management-based immediate MDT, some measurements (e.g. M4, M5), applicable in RRC_CONNECTED only, are performed directly by the gNB 214, and if such measurements are requested in the MDT configuration, gNB 214 should start the measurement according to the received configuration. Details of the measurements are defined in 3GPP TS 37.320 and 3GPP TS 38.314.

[0089] At 211, if MDT activation in 201 is for logged MDT, a logged MDT configuration is sent to selected UE 212. In some examples, a logged MDT trace session is preserved in UE 212 until a duration time of the trace session expires, including also multiple idle or inactive periods interrupted by various RRC state transitions such as idle-connected-idle state transitions. UE 212 collects MDT measurements and logs according to its configuration until its memory reserved for MDT is full. If this happens, UE stops logging, stops the log duration timer and starts a further timer. In some examples, the further timer may be a 48-hour timer.

[0090] At 211, if MDT activation in 201 is for immediate MDT and includes measurements performed by UE 212, the corresponding measurements are configured towards UE 212 via RRC signalling defined in TS 38.331. These measurements may correspond to DL signal quantities like RSRP (Reference Signal Received Power), RSRQ (Reference Signal Received Quality), SINR (signal-to-noise and interference ratio) further described in 3GPP TS 38.215. In an example, the corresponding reporting may be configured to be event-triggered, defined by a threshold, or periodic. RRC configured measurements corresponding to Immediate MDT measurement configuration are deleted in the UE 212 together with the RRC context when entering RRC idle mode. If MDT activation in 201 is for immediate MDT and includes measurements performed by gNB 214, the gNB 214 autonomously activates these measurements without involvement of the UE 212. These measurements may be PDCP SDU Data Volume measurement, Average UE throughput measurement, Packet Delay measurement and Packet loss rate measurement, to give some examples. It can additionally be noticed that the gNB 214 may simply collect UE measurements already provided by the UE 212 without specific configuration towards UE 212, if these measurements correspond to to the immediate MDT configuration. The DL signal quantities listed above may be part of such measurements, and the same applies for the Power Headroom measurement 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 now summarised briefly below for reference.

[0091] Immediate MDT 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. If area scope is included in the MDT configuration provided to the RAN, the UE may be configured with respective measurement when the UE is connected to a cell that is part of the configured area scope.

[0092] Immediate MDT measurements may comprise at least one of the following: M1: DL signal quantities measurement results for the serving cell and for intra-frequency / lnter-frequency / inter-RAT neighbour cells, including cell / beam level measurement for NR cells only, TS 38.215. M2: Power Headroom measurement by UE, TS 38.213. M4: PDCP SDU Data Volume measurement separately for DL and UL, per DRB per UE, see TS 28.552. 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 . M6: Packet Delay measurement separately for DL and UL, per DRB per UE, TS 28.552 and TS 38.314. M7: Packet loss rate measurement separately for DL and UL, per DRB per UE, TS 28.552 and TS 38.314. M8: RSSI measurement by UE (for WLAN / Bluetooth measurement) see TS 38.331 . M9: RTT Measurement by UE (for WLAN measurement) see TS 38.331.

[0093] A logged measurement MDT configuration may comprise at least one 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. It should be noted that The logging configuration for event-based and periodical DL pilot strength logged measurements can be configured independently. 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. TR parameter as indicated by the OAM configuration as specified in TS 32.422. TRSR as indicated by the OAM configuration as specified in TS 32.422. TCE Id as indicated by the OAM configuration as specified in TS 32.422. 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. 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 Location Areas (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. 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. 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. configuration of the WLAN access point names, indicating the UE to attempt to obtain WLAN measurements associated to these access points. configuration of the Bluetooth beacon names, indicating the UE to attempt to obtain Bluetooth measurements associated to these beacons. for NR, configuration of the sensor names, indicating the UE to attempt to obtain sensor measurements. for E-UTRA, configuration indicating the UE to attempt to obtain uncompensated barometric pressure measurements. 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. for NR, logged MDT type flag, indicating the logged measurement configuration is the signalling based MDT.

[0094] At 213, depending on the configured anonymization level, gNB 214 may trigger Cell Traffic Trace procedure per selected UE towards AMF 218. IftheMDT anonymization requires the IMEI-TAC in the MDT record, gNB 214 sends the TRSR, TR, serving Cell Global Identity (CGI), and TCE IP Address in a CELL TRAFFIC TRACE message sent, at 215, by gNB 214 to AMF 218 via UE-associated signalling. When AMF 218 receives this signalling message containing the TRSR, TR, serving cell CGI, and the Privacy Indicator, at 217, AMF 218 looks up the subscriber identities (IMEI(SV)) of the given cell from its database, and may send the IMEI-Tracking Area Code (TAC) together with the TRSR, TR and the serving cell CGI to the TCE 216.

[0095] At 219, UE 212 may send measurement results via RRC signalling to gNB 214. For immediate MDT, when gNB 214 receives the measurements from UE 212 in an RRC message, gNB 214 may store the measurements at 221 together with the UE 212’s serving cell CGI and the TR. For logged MDT, UE 212 is configured to perform logged MDT measurements in RRC_IDLE or RRCJNACTIVE. UE 212 may indicate the availability of MDT measurements, by means of a one-bit indicator, in e.g., the RRCSetupComplete message during connection establishment as specified in 3GPP TS 32.421. gNB 214 can decide to retrieve the logged measurements based on this indication by sending a RRC UElnformationRequest message to UE 212. UE 212 can answer with the collected MDT logs in UElnformationResponse message. gNB 214 may not retrieve MDT report from UE 212 if UE 212’s Registered PLMN (RPLMN) does not match the PLMN where TCE used to collect MDT data resides. When gNB 214 receives the MDT report from UE 212 at 219, gNB 214 may receive theTRSR, TR and TCE Id from the report, and compares the Trace PLMN (PLMN portion of Trace Reference) with the PLMN where TCE 216 used to collect MDT data resides. The MDT report maybe be discarded in the case of a mismatch in the comparison.

[0096] It should be noted that logged measurement configurations and logs may be maintained when UE 212 is in any state of a Radio Access Technology (RAT) even if there exist multiple periods of interruptions when UE 212 is in a different RAT. There exists a single logged measurement configuration for Logged MDT in UE 212 for a RAT. When network provides a configuration, previously configured logged measurement configurations will be replaced by the new one. Logged measurements corresponding to previous configuration will be cleared also. Network should be able to retrieve data before it is deleted (e.g., when a new configuration is given to the UE).

[0097] At 223, MDT records can be reported from gNB 214 to TCE 216. For logged MDT, the TCE Id is indicated in the MDT report is translated to the actual IP address of the TCE by the gNB before it forwards the measurement records. The address translation is based on mapping configured in the gNB. For immediate MDT, the IP address of the TCE is indicated for the gNB in the trace configuration.

[0098] At 225, correlation of MDT measurements obtained via MDT can be performed.

[0099] According to some examples, combined management-based activation of logged and immediate MDT may be performed to assist continuous MDT collection. A possible method for performing combined management-based activation of logged and immediate MDT is outlined below. The method is outlined with respect to the steps and entities of Figure 2 above, however it should be noted that the method is an example only, and that other alternative methods are envisaged.

[0100] Initially, the management system 220 sends a management-based logged MDT configuration to gNB 214. In this example, the management-based logged MDT configuration comprises a first TR, TR A. The management system 220 sends a management-based immediate MDT configuration to gNB 214. In this example, the management-based immediate MDT configuration comprises a second TR, TR B.

[0101] Base station node (gNB 214) then selects one or more of its served UEs (in this example, UE 212) for logged MDT and immediate MDT as per 209 in Figure 2. In this example, the logged MDT is given a first TRSR, TRSR a, and the immediate MDT is given a second TRSR, TRSR b, such that the logged MDT session for UE 212 has TR A, TRSR a and the immediate MDT for MDT session has TR B, TRSR b. The logged MDT configuration is sent to UE 212 as per 211 and the immediate MDT configuration is activated as per 211 by e.g., RRC measurements. IMEI TAC can be provided to TCE as per 213 to 217 of Figure 2.

[0102] Considering an example where UE 212 is initially in a connected state (e.g., RRC_CONNECTED), measurement results from immediate MDT (TR B) may be received by gNB 212 and stored in gNB 212, as per 219 and 221. If UE 212 were then to go to an idle mode (e.g., RRCJDLE), gNB 214 may send stored MDT measurements (TR B) to TCE 216 (as per 223). In the idle state, as per 211, UE 212 collects measurements according to the logged MDT configuration (TR A) and stores the measurements. When UE 212 connects again to the network (i.e., changes from the idle state to a connected state), UE 212 indicates availability of logged MDT measurements (TR A) and gNB 214 retrieves them as per 219, and forwards the log to the TCE 216 (as per 223). At this step the network may also reactivate the immediate MDT configuration for UE 212. In some examples, immediate MDT records and logged MDT records may be correlated to (as per 225).

[0103] According to examples described herein, when triggered by the Cell Traffic Trace procedure, an AMF sends specific information to the TCE, which allows the TCE to distinguish the UE without identifying it. This specific information may be sent along with a TR / TRSR as at 223. Using the specific information and the TR / TRSR, the records may be combined at 225 to correlate different logs pertaining to the same UE.

[0104] The specific information may be one of: • a random number generated as follows: when the UE registers (UE context created in the CN), or at least before the first time it sends information to the TCE (Figure 2 217), the AMF generates the random number for the UE and stores it for the duration of the UE context in the CN; or • a hash value of one or more of the UE’s permanent IDs (full International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI). • the TR / TRSR of the logged MDT configuration.

[0105] By generating the specific information for the UE and providing the specific information (e.g., a value for correlating MDT logs) to the TCE, the TCE can correlate MDT logs (with different TR / TRSR) pertaining to the same UE, and then by post-processing constitute a continuous log independent of RRC states. In an earlier standardized approach, before mandatory anonymization of MDT, the use of permanent UE ID, e.g. IMSI (or SUPI in 5G) allowed to correlate different MDT logs. Using a permanent ID causes security concerns, as it allows a UE to be identified.

[0106] The first two options may be considered to comprise generating a value for correlating MDT sessions for a user equipment. The value may be associated with a specific UE. According to the first option, using the random number enables correlation of MDT logs, but the UE can’t be identified. According to the second option, a hash value in principle serves the same purpose a random number. In addition, if one or more permanent UE IDs are known by an entity that also can regenerate the hash value, it can be possible to retrieve logs for specific UEs if needed (e.g., in the case of data loss, etc.).

[0107] The third option of using a logged MDT measurement configuration requires the network to upload the logged measurement report stored in the UE before the network can send immediate MDT measurement data to the TCE. The immediate MDT measurement data can then be correlated at the TCE.

[0108] Figure 3A shows a first phase of an example method flow for the first and second options discussed above. In the first phase shown in Figure 3A, an initial configuration of a UE is performed, and immediate MDT measurements are performed and reported to TCE 316. At the end of phase 1, UE 312 enters an idle mode and then starts to collect logged MDT measurements. In the second phase shown in Figure 3B, UE 312 reconnects to the network with available logged MDT measurements. Further MDT measurements may also be collected. The immediate and logged MDT measurements are reported to TCE 316. TCE 316 can then determine that the different MDT records come from the same UE 312 (in 351 of Figure 3B).

[0109] At 301a / b, one or more MDT measurement configurations comprising at least one trace reference (TR) may be sent to base station 314 (in this example, base station 314 comprises a gNB, but it will be understood that in other example other base station types can be used). According to some examples, the one or more MDT measurement configurations sent at 301 a / b may comprise an area indication in which the MDT measurement configurations are to be used. At 301a, a network entity 320 (which in this example comprises a management system 320) sends a logged MDT measurement configuration to gNB 314. In other examples, network entity may comprise a Network Data and Analytics Function (NWDAF), for example. In this example, the logged MDT measurement configuration comprises TR A. At 301b, management system 320 sends the immediate MDT configuration with at least one TR (in this example, TR B). Using the logged / immediate combination info provided by OAM, gNB 314 can select the same UE 312 for logged MDT and immediate MDT (at 309 - discussed below). This can be performed by including the TR of logged MDT (TR A) together with the immediate MDT configuration (TR B).

[0110] At 303, MDT parameters are stored at gNB 314. This may be performed as in 203 of Figure 2.

[0111] At 305a, the UE 312 may register with the network. At 305b, a network entity (in this example, AMF 318) may allocate a random number (RN) for UE 313. AMF 318 may store the RN in a UE context for UE 312 in the CN (e.g., at AMF 318 or at any other CN entity).

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

[0113] At 305c, an initial context setup request or handover request is sent to gNB 314. The request may comprise a list of PLMNs for management-based MDT.

[0114] At 307, gNB 314 stores within UE context for UE 312 that management-based MDT is allowed. This could be performed similarly to 207, for example.

[0115] At 309, gNB 314 selects one or more UEs for management-based MDT based on received MDT parameters at 301a / b. In this example, gNB 314 selects UE 312. The selection may also be based on area scope indicated by management system 320 and / or the management-based MDT PLMN IE received at 305c. Each UE may be allocated a logged MDT TRSR and immediate MDT TRSR. In this example, UE 312 is assigned TRSR a for logged MDT and TRSR b for immediate MDT.

[0116] At 311a, gNB 314 sends a logged MDT measurement configuration to UE 312, along with TR A and TRSR a. gNB 314 may use the logged MDT measurement configuration for performing logged MDT measurements at UE 312.

[0117] At 311b, gNB 314 may send RRC measurements corresponding to an immediate MDT measurement configuration to UE 312. gNB 314 may also, or alternatively, use the immediate MDT measurement configuration for performing immediate MDT measurements relative to UE 312 without involving the UE 312.

[0118] At 315a, gNB 314 sends, to AMF 318, TR A and TRSR a for a logged MDT session for UE 312. According to some examples, TR A and TRSR a are sent in an NGAP CELL TRAFFIC TRACE message.

[0119] At 315b, gNB 314 sends, to AMF 318, TR B and TRSR b for an immediate MDT session for UE 312. According to some examples, TR B and TRSR b are sent in an NGAP CELL TRAFFIC TRACE message.

[0120] At 317a, for the logged MDT session at UE 312, TR A, TRSR a and the RN for UE 312 is sent to TCE 316. IMEI-Type Allocation Code (IMEI-TAC) for the logged MDT session may also be included.

[0121] At 317b, for the immediate MDT session at UE 312, TR B, TRSR b and the RN for UE 312 is sent to TCE 316. IMEI-Type Allocation Code (IMEI-TAC) for the immediate MDT session may also be included.

[0122] At 319, UE 312 may perform immediate MDT measurements which are then sent from UE 312 to gNB 314. At 321, gNB saves the measurements received at 319 to MDT records at gNB 314. At 323, gNB 314 reports the MDT records along with TR B and TRSR b to TCE 316.

[0123] At 325, UE 312 enters an idle mode (e.g., RRC_IDLE) and starts collecting logged MDT measurements, using the configuration received at 311a.

[0124] A second phase is described in the example of Figure 3B, following on from the first phase of Figure 3A.

[0125] At 327a, 327b and 327c, UE 312 reconnects to the network of gNB 314. At 327a, UE 312 sends an RRC setup request to gNB 314. At 327b, gNB 314 sends a message for setting up an RRC connection with UE 312. At 327c, UE 312 indicates to gNB 314 that RRC setup is complete. At 327c, UE 312 may also indicate to gNB 314 that logged MDT measurements are available from 325 of Figure 3A.

[0126] At 327d, AMF 318 may send an initial context setup request or a handover request to gNB 314. The request may comprise a list of PLMNs for management-based MDT.

[0127] At 329, gNB 314 may store within the UE context for UE 312 that management-based MDT is allowed for UE 312.

[0128] At 331, gNB 314 selects UE 312 for management-based immediate MDT using TR B received at 301b and allocates TRSR cto the immediate MDT session.

[0129] At 333, gNB 314 sends a measurement configuration for immediate MDT. This may be performed using RRC signalling.

[0130] At 335, gNB 314 sends AMF 318, TR B and TRSR c for an immediate MDT session for UE 312. According to some examples, TR B and TRSR c are sent in an NGAP CELL TRAFFIC TRACE message.

[0131] At 337, for the immediate MDT session at UE 312, TR B, TRSR c and the RN for UE 312 is sent to TCE 316. IMEI-Type Allocation Code (IMEI-TAC) for the immediate MDT session may also be included.

[0132] At 339, UE 312 may perform immediate MDT measurements which are then sent from UE 312 to gNB 314. At 341, gNB saves the measurements received at 319 to MDT records at gNB 314. At 343, gNB 314 reports the MDT records along with TR B and TRSR c to TCE 316.

[0133] At 345a gNB 314 sends a request (e.g., UE information request) to UE to obtain one or more logged MDT measurements report (that were indicated as available at 327c). At 345b UE 312 sends a response (e.g., UE information response) including at least one logged MDT measurement report with TR A and TRSR a to gNB 314. At 347, gNB 314 saves the logged MDT records to MDT records. At 349, the logged MDT records are sent to TCE 316, along with TR A and TRSR a.

[0134] At 351, TCE 316 can use the received RN associated with UE 312 along with the MDT session references (in this example, ({TR B, TRSR b}, {TR B, TRSR c}, {TR A, TRSR a}) to determine that the two immediate MDT sessions and the logged MDT session of Figures 3A and 3B originate from the same UE.

[0135] It should be noted that while there are two immediate MDT sessions and one logged MDT session shown in the example of Figure 3A, in other examples there may be X immediate MDT session(s) and Y logged MDT session(s), where X and Y are positive integers or zero, and X+Y is more than or equal to 2.

[0136] Instead of generating a RN according to the first option discussed above, the second option can be used in Figures 3A and 3B by instead generating a hash value of one or more of the UE 312’s permanent IDs (full International Mobile Equipment Identity (IMEI), International Mobile Subscriber Identity (IMSI), Subscription Permanent Identifier (SUPI) at 305b, and then sending the hash value instead of the RN in Figures 3A and 3B.

[0137] Figure 4 shows an example method according to the third option discussed above, where MDT sessions from a UE can be correlated using a TR and TRSR of a previous logged MDT session. At 450, we assume that UE 412 has been involved in a previous logged MDT session with TR A and TRSR a.

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

[0139] At 403, MDT parameters are stored at gNB 414. This may be performed as in 203 of Figure 2.

[0140] At 405a, UE 412 indicates to gNB 414 that RRC setup is complete. At 405a, UE 412 may also indicate to gNB 414 that logged MDT measurements are available.

[0141] At 405b, AMF 418 may send an initial context setup request or a handover request to gNB 414. The request may comprise a list of PLMNs for management-based MDT.

[0142] At 407, gNB 414 may store within the UE context for UE 412 that management-based MDT is allowed for UE 412.

[0143] At 409, gNB 414 selects UE 412 for management-based immediate MDT using TR B received at 401b, and allocates TRSR b to the immediate MDT session.

[0144] 411 to 419 may be performed similarly to 211 to 219 of Figure 2.

[0145] At 421, gNB 414 may store UE measurements for the immediate MDT session from UE 412 to MDT records, including TR B and TRSR b used for the immediate MDT session.

[0146] At 423a, TR A and TRSR a are requested from UE 412 by gNB 414. This may be requested by requesting a logged measurement report from UE 412. TR A and TRSR a for UE 412 may be sent from UE 412 to gNB 414. Before 423b, TRSR a is not known by gNB 414. TR A TRSR a may then be stored in the UE context for UE 412 for use in case further reporting of immediate MDT measurements to TCE 416 is needed while the UE is in RRC_CONNECTED.

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

[0148] At 423e, together with the stored immediate MDT measurements, the logged MDT reference (TR A, TRSR a) is reported in order to allow correlation in TCE 416 (together with immediate MDT reference (TR B, TRSR b)).

[0149] At 424, logged MDT and Immediate MDT logs are correlated in TCE 416 based on the logged MDT session reference (TR A, TRSR a). Any future MDT sessions from UE 412 can be similarly reported to TCE 416 by including TR A and TRSR a, which allows TCE to correlate MDT sessions to determine which MDT sessions originate from the same UE 412.

[0150] Figure 5 shows an example method flow. The method may be performed, for example, by a TCE such as TCE 216, 316, 416.

[0151] At 500, the method comprises receiving a value for correlating 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, wherein the value for correlating MDT sessions is associated with a user equipment.

[0152] At 502, the method comprises receiving at least one first MDT record related to the first MDT session.

[0153] At 504, the method comprises receiving the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value.

[0154] At 506, the method comprises receiving at least one second MDT record related to the second MDT session,

[0155] At 508, the method comprises determining, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are originated from the user equipment.

[0156] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

[0157] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SUPI.

[0158] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

[0159] According to some examples, the value for correlating the MDT sessions is stored in context information of the user equipment in at least one Core Network node.

[0160] According to some examples, the at least one Core Network node comprises an AMF.

[0161] According to some examples, upon a handover of the user equipment to a target node, the value for correlating the MDT sessions is forwarded to the target node.

[0162] According to some examples, the first MDT session comprises a logged MDT session and the second MDT session comprises a continuous MDT session.

[0163] Figure 6 shows an example method flow. The method may be performed, by an AMF such as AMF 218, AMF 318, AMF 418, for example.

[0164] At 600, the method comprises generating a value for correlating MDT sessions, the MDT sessions comprising a first MDT session for a user equipment and a second MDT session for the user equipment.

[0165] At 602, the method comprises sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a first MDT session associated with the value.

[0166] At 604, the method comprises sending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a second MDT session associated with the value.

[0167] According to some examples, the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

[0168] According to some examples, the permanent identifier of the user equipment comprises a full IMEI, an IMSI or SUPI.

[0169] According to some examples, the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

[0170] According to some examples, the method comprises storing the value for correlating the MDT sessions in context information of the user equipment.

[0171] According to some examples, the method comprises forwarding the value for correlating the MDT sessions to a target node upon a handover of the user equipment to the target node.

[0172] FIG. 7 illustrates an example of a control apparatus 760 for controlling a network. The control apparatus may comprise at least one random access memory (RAM) 711a, at least on read only memory (ROM) 711b, at least one processor 712, 713 and an input / output interface 714. The at least one processor 712, 713 may be coupled to the RAM 711a and the ROM 711b. The at least one processor 712, 713 may be configured to execute an appropriate software code 715. The software code 715 may, for example, allow the 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 apparatus 700 may be interconnected with another control apparatus 700 controlling another function of the RAN or the core network.

[0173] FIG. 8 illustrates an example of a terminal 800, such as a UE. The terminal 800 may be provided by any device capable of sending and receiving radio signals. In some examples, the terminal may comprise a user equipment, a mobile station (MS) or mobile device, such as a mobile phone or what is known as a ’smart phone’, a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), a personal data assistant (PDA) or a tablet provided with wireless communication capabilities, a machine-type communications (MTC) device, an Internet of things (loT) type communication device or any combinations of these or the like. The terminal 800 may provide, for example, communication of data for carrying communications. The communications may be one or more of voice, electronic mail (email), text message, multimedia, data, machine data and so on.

[0174] The terminal 800 may be configured to receive signals over an air or radio interface 807 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In FIG. 8, transceiver apparatus is designated schematically by block 806. The transceiver apparatus 806 may be provided, for example, by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the mobile device.

[0175] The 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 software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The at least one processor 801 is coupled to the RAM 802b and the ROM 802a. The at least one processor 801 may be configured to execute an appropriate software code 808. The software code 808 may for example allow to perform one or more of steps of any method flow described herein. The software code 808 may be stored in the ROM 802a.

[0176] The processor, storage and other relevant control apparatus can be provided on an appropriate circuit board and / or in chipsets. This example is denoted by reference 802. The device may optionally have a user interface, such as key pad 805, touch sensitive screen or pad, combinations thereof or the like. Optionally, one or more of a display, a speaker and a microphone may be provided depending on the type of the device.

[0177] UEs, such as UE 312 in Figures 3A and 3B, UE 212 in Figure 2 or UE 412 in Figure 4 may take the form of a terminal device 400 as schematically shown in Figure 8.

[0178] FIG. 9 shows a schematic representation of non-volatile memory media 900a (e.g. computer disc (CD) or digital versatile disc (DVD)) and 900b (e.g. universal serial bus (USB) memory stick) storing instructions and / or parameters 902 which when executed by a processor allow the processor to perform one or more of the steps of any method flow described herein.

[0179] It should be understood that the apparatuses may comprise or be coupled to other units or modules etc., such as radio parts or radio heads, used in or for transmission and / or reception. Although the apparatuses have been described, in some examples as one entity, different modules and memory may be implemented in one or more physical or logical entities.

[0180] It is noted that whilst some examples have been described in relation to 5G networks, similar techniques and / or mechanisms can be applied in relation to other networks and communication systems (e.g., 6G and beyond). Therefore, although certain examples were described above, by way of illustration with reference to certain example architectures for wireless networks, technologies and standards, other examples may be applied to any other suitable forms of communication systems than those illustrated and described herein.

[0181] It is also noted herein that while the above details various examples, there are several variations and modifications which may be made to any of the aforementioned example solutions without departing from the scope of the examples described herein.

[0182] s used herein, “at least one of the following: ” and “at least one of <a list of two or more elements*” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0183] In general, the various examples may be implemented in hardware or special purpose circuitry, software, logic or any combination thereof. Some examples detailed in the subject disclosure may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the subject disclosure is not limited thereto. While various aspects of the subject disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0184] As used herein, the term “circuitry” may refer to one or more or all of the following examples:

[0185] (a) hardware-only circuit implementations (such as, implementations in only analog and / or digital circuitry) and

[0186] (b) combinations of hardware circuits and software, such as (as applicable):

[0187] (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and

[0188] (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

[0189] (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0190] This definition of circuitry applies to all uses of this term herein, including in any claims. As a further example, as used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0191] The various examples detailed in the subject disclosure may be implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware. Computer software or program, also called program product, including software routines, applets and / or macros, may be stored in any apparatus-readable data storage medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computer-executable components which, when the program is run, are configured to carry out one or more steps of any method flow described herein. The one or more computer-executable components may be at least one software code or portions of it.

[0192] Further in this regard it should be noted that any blocks of the logic flow as in the Figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as DVD and the data variants thereof, CD. The physical media may be implemented as a non-transitory media.

[0193] The term “non-transitory,” as used herein, is a limitation of the medium itself (e.g., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0194] The memory may be of any type suitable to the local technical environment and may 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 processors may be of any type suitable to the local technical environment, and may comprise one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), FPGA, gate level circuits and processors based on multi core processor architecture, as non-limiting examples.

[0195] Examples of the subject disclosure may be practiced in various components, such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0196] The scope of protection sought for the various examples described herein is set out by the independent claims. The examples, if any, described herein that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various facets of the subject disclosure.

[0197] The foregoing description has provided by way of non-limiting examples to provide a full and informative description the subject disclosure. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the claims. 5 However, all such and similar modifications of the teachings of this disclosure will still fall within the scope of the examples described herein. Indeed, there is a further example comprising a combination of one or more examples with any of the other examples previously described herein.

Claims

1. An apparatus comprising:means for receiving a value for correlating Minimization of Drive Tests, 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, wherein the value for correlating 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 the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value;means for receiving at least one second MDT record related to the second MDT session; andmeans for determining, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are both originated from the user equipment.

2. The apparatus according to claim 1, wherein the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

3. The apparatus according to claim or claim 2, wherein the value for correlating the MDT sessions is generated upon the user equipment registering with a network4. The apparatus according to any of claims 1 to 3, wherein the value for correlating the MDT sessions is stored in context information of the user equipment in at least one Core Network node.

5. The apparatus according to any of claims 1 to 4, wherein upon a handover of the user equipment to a target node, the value for correlating the MDT sessions is forwarded to the target node.

6. The apparatus according to any preceding claim, wherein the first MDT session comprises a logged MDT session and the second MDT session comprises an immediate MDT session.

7. A method comprising:receiving a value for correlating Minimization of Drive Tests, 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, wherein the value for correlating MDT sessions is associated with a user equipment;receiving at least one first MDT record related to the first MDT session;receiving the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value;receiving at least one second MDT record related to the second MDT session; anddetermining, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are originated from the user equipment.

8. A method according to claim 7, wherein the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

9. The method according to claim 7 or claim 8, wherein the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

10. The method according to any of claims 7 to 9, wherein the value for correlating the MDT sessions is stored in context information of the user equipment in at least one Core Network node.

11. The method according to any of claims 7 to 10, wherein upon a handover of the user equipment to a target node, the value for correlating the MDT sessions is forwarded to the target node.

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

13. A computer program comprising instructions stored thereon for performing at least the following:receiving a value for correlating Minimization of Drive Tests, MDT, sessions, and at least one identifier of a first MDT session associated with the value, the MDT sessionscomprising the first MDT session and a second MDT session, wherein the value for correlating MDT sessions is associated with a user equipment;receiving at least one first MDT record related to the first MDT session;receiving the value for correlating MDT sessions and at least one identifier of the second MDT session associated with the value;receiving at least one second MDT record related to the second MDT session; anddetermining, based on the value for correlating MDT sessions, that the at least one first MDT record and the at least one second MDT record are originated from the user equipment.

14. An apparatus comprising:means for generating a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment;means for sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of the first MDT session associated with the value; andmeans for sending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of the second MDT session associated with the value.

15. The apparatus according to claim 14, wherein the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

16. The apparatus according to any of claims 14 to 15, wherein the value for correlating the MDT sessions is generated upon the user equipment registering with a network comprising the apparatus.

17. The apparatus according to any of claims 14 to 16, comprising:means for storing the value for correlating the MDT sessions in context information of the user equipment.

18. The apparatus according to any of claims 14 to 17, comprising:means for forwarding the value for correlating the MDT sessions to a target node upon a handover of the user equipment to the target node.

19. The apparatus according to any of claims 14 to 18, wherein the first MDT session comprises a logged MDT session and the second MDT session comprises an immediate MDT session.

20. A method comprising:generating a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment;sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a first MDT session associated with the value; andsending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a second MDT session associated with the value.

21. The method according to claim 20, wherein the value for correlating the MDT sessions comprises a random number or a hash value of a permanent identifier of the user equipment.

22. The method according to claim 20 or claim 21, wherein the value for correlating the MDT sessions is generated upon the user equipment registering with a network.

23. The method according to any of claims 20 to 22, comprising:storing the value for correlating the MDT sessions in context information of the user equipment.

24. The method according to any of claims 20 to 23, comprising:forwarding the value for correlating the MDT sessions to a target node upon a handover of the user equipment to the target node.

25. A computer program comprising instructions stored thereon for performing at least the following:generating a value for correlating Minimization of Drive Tests, MDT, sessions comprising a first MDT session and a second MDT session for a user equipment;sending, to a network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a first MDT session associated with the value; andsending, to the network entity, the value for correlating MDT sessions for the user equipment and at least one identifier of a second MDT session associated with the value.

Images