Method of mobile device, method performed by access network node, mobile device and access network node

Abstract

An aspect of this disclosure includes a method performed by a mobile device. The method includes receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

Description

METHOD OF MOBILE DEVICE, METHOD PERFORMED BY ACCESS NETWORK NODE, MOBILE DEVICE AND ACCESS NETWORK NODE

[0001] The present disclosure relates to a communication system and to parts thereof.

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G / 6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to the acquisition of data by user equipments (UEs), for the purposes of training or retraining artificial intelligence (AI) and machine learning (ML) models, using minimisation of drive test (MDT) data collection based techniques.

[0003] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has started to be used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0004] Under the 3GPP standards, a NodeB (or e.g., an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node (or simply RAN), or base station to refer to any such access nodes.

[0005] For simplicity, the present application will use the term mobile device, user device, or UE, to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0006] In the current 5G architecture, the RAN architecture may be distributed with the base station structure split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for several base stations may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each base station.

[0007] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0008] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, midhaul availability and network design.

[0009] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and / or the like. The AMF generally corresponds to the mobility management entity (MME) in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0010] The coverage in many modern communication systems is often beam-based rather than cell based. There is no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell has one or more so-called synchronization signal / physical broadcast channel (PBCH) block (SSB) beams. SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH).

[0011] The UE searches for and performs measurements on the SSB beams (e.g., of the synchronization signal reference signal received power, 'SS-RSRP,' synchronization signal reference signal received quality, 'SS-RSRQ,' and / or the synchronization signal to noise and interference ratio, 'SS-SINR'). The UE maintains a set of candidate beams which may contain beams from multiple cells. A PCI and beam ID (or SSB index) thus distinguish the SSB beams from each other. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected a cell (and / or an SSB beam in the case of 5G) it may attempt to access that cell and / or SSB beam using an initial RRC connection setup procedure comprising a random-access procedure.

[0012] Some recent developments in 3GPP relate to the use of artificial intelligence (AI) and machine learning (ML), often abbreviated to AI / ML. Predictions or inferences generated using an AI / ML model can be used as part of various methods for improving the reliability or efficiency of communication in the network. For example, AI / ML models can be used to predict the path of a UE based on previous mobility of the UE, used for cell and / or beam management, or used in methods of encoding and transmitting information. An AI / ML model may be hosted at a RAN node, and the RAN node may perform control of communication resources or control related to the status of a UE (e.g., control of UE mobility, or control of a radio resource control (RRC) state of the UE) based on an inference (e.g., determination or prediction) generated using the AI / ML model. The RAN node may also transmit an inference generated using the model to another node in the network, for use at the other node.

[0013] Alternatively, an AI / ML model may be hosted at two or more nodes of the network, for example at a RAN node and at a UE. In this case, the RAN node and the UE may both make determinations or predictions using the model. For example, the UE may use the model as part of an encoding process for encoding (and / or compressing) channel state information (CSI) for transmission to the RAN node, and the RAN node may use the same model as part of a corresponding decoding (and / or decompression) process for decoding the CSI received from the UE.

[0014] It will nevertheless be appreciated that the use of AI / ML models may also be extended to other procedures and methods performed in communication system to further improve the reliability or efficiency of communication in the communication system, for example, in handover, network energy saving, network slicing, coverage and capacity optimisation, and / or beam switching procedures, to name but a few.

[0015] AI / ML models require appropriate training, and sometimes retraining, based on real data. Generally, the larger the quantity of available accurate training data, the more accurate the corresponding model once trained. To support the training of AI / ML models relating to a communication system therefore, there is a need for large quantities of accurate data relating the behaviour and performance of that communication system. Moreover, as communication systems can change over time, there is an ongoing need for large quantities of accurate data relating the behaviour and performance of that communication system to be acquired to support the retraining of such AI / ML models to reflect any such changes that may occur.

[0016] Historically, test data for a communication system would be acquired using so called 'drive tests' in which a vehicle carrying test equipment (e.g., one or more appropriately configured UEs or the like) would be driven on a route through the communication network. While travelling through the network the test equipment would gather test data associated with various communication system performance metrics. The test data might, for example, include measurement data for analysing network and / or UE performance (e.g., measurements of network parameters such as signal strength, call quality, data speed, and coverage).

[0017] NPL 1: 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https: / / www.ngmn.org / 5g-white-paper.html.

[0018] Such drive testing is, however, relatively resource intensive, inefficient, and costly. To reduce the requirements for such drive testing, therefore, mechanisms were developed to allow conventional UEs of the communication system to be configured to measure and log appropriate measurement data, in a geographic region of interest, and to report the acquired data to the core network independently, via a RAN, at an appropriate juncture. The acquired data from (potentially multiple UEs) can thus be analysed (e.g., to identify any communication system performance issues) thus reducing (or potentially eliminating) the need to dispatch appropriately qualified engineers on drive tests. These mechanisms / measurements are typically referred to minimisation of drive test / tests (MDT) mechanisms / measurements.

[0019] Two principal MDT modes have been developed for performing / reporting MDT measurements. The first MDT mode is typically referred to as 'immediate MDT' (I-MDT) and typically involves a UE performing measurements in an RRC connected (or 'active') state, and reporting those measurements to the serving RAN at a time when a configured reporting condition (or reporting trigger) has been met. Immediate MDT (I-MDT) measurements may also include measurements performed by the network itself for MDT purposes. The second MDT mode is typically referred to as 'logged MDT' (L-MDT) and typically involves a UE logging measurements made whilst in an RRC idle mode, RRC inactive state (or the like), for later reporting to the RAN.

[0020] The MDT data may be acquired by a UE using the subscriber and equipment trace functionality (known as 'Trace') that was originally developed for providing detailed information, at a call level, for one or more specific UEs. MDT data may, for example, be acquired using 'subscriber tracing' based on a specific user identity (e.g., based on an international mobile subscriber identity (IMSI)) and / or using 'equipment tracing' (e.g., based on an international mobile equipment identity (IMEI) or international mobile equipment identity with software version (IMEISV)). MDT data may, nevertheless, be acquired without targeting a specific UE using 'cell level tracing' (which is a management based trace function from an Operations, Administration and Maintenance (OAM) function) based on all active calls in a cell or multiple cells (referred to as 'cell traffic trace').

[0021] Where MDT is initiated towards a specific UE (e.g. based on IMSI, IMEI-SV, etc.), a signalling based trace procedure is used, otherwise a management based trace procedure (or cell traffic trace procedure) is used.

[0022] The MDT data may be acquired by a UE as part of one or more MDT trace recording sessions (each trace recording session forming part of a wider MDT trace session). The acquired MDT data may be reported to the RAN as a so-called MDT 'trace' or 'trace record'. Each trace session is identified by a corresponding (globally unique) trace reference which typically includes a trace identifier / trace ID and information identifying a country, and an operator.

[0023] Given the ongoing need for large quantities of data to support AI / ML model training / retraining, further development of the existing MDT framework would be beneficial. In particular, it would be beneficial if the existing MDT framework could be enhanced to allow a new mode of MDT operation - 'continuous MDT' (C-MDT) - which enables the substantially 'continuous' collection of MDT data from the same UE, even when that UE changes RRC state (RRC connected, RRC idle, RRC inactive, and / or the like). Allowing a UE to be configured to collect MDT measurement data substantially 'continuously', even as that UE changes between the various different RRC states, and to provide a substantially continuous stream (time series) of such MDT measurement data ('MDT traces') to the network would be particularly beneficial in the context of AI / ML training within an OAM part of a communication system.

[0024] The need for such development is likely to become even more pressing as communication systems are further developed to take advantage of new AI / ML capabilities. For example, a recent release of the communication standards required the following data to be collectable from a UE for AI / ML purposes: UE location information (e.g., coordinates, serving cell identifier, moving velocity); UE measurement results (e.g., RSRP, RSRQ, SINR measurements, etc) including for both cell level and beam level UE measurements; and UE mobility history information. In later releases, there will likely be even more UE measurements results and / or other data that needs to be collected by the UE for supporting AI / ML functionality.

[0025] One current proposal for supporting C-MDT data collection proposes the introduction of an indication, in a L-MDT measurement configuration, to indicate whether the UE being configured should collect continuous location information (e.g., historical cell information, latitude, longitude, altitude, velocity, etc.) across various RRC states (connected, inactive, idle).

[0026] Another current proposal for supporting C-MDT data collection proposes introduction of a "Continuous MDT" flag in a management based L-MDT measurement configuration (i.e., a configuration for cell level MDT tracing), and enabling the UE to report (e.g., to a different RAN node) that it has been configured for "Continuous MDT", as soon as the UE establishes an RRC connection from an RRC idle mode / state (e.g., with the different RAN node) - hence allowing that UE to be configured with I-MDT measurements during RRC connection establishment. This proposal also proposes introduction of the "Continuous MDT" flag in a handover request message to enable a target RAN node to configure the UE with a management-based MDT configuration.

[0027] Another current proposal for supporting C-MDT data collection proposes configuration of two signalling based MDT traces (e.g., one for I-MDT and one for L-MDT) to a UE. To support configuration of two MDT configurations, this proposal also proposes introduction of a second trace activation information element (IE) (i.e., in addition to an existing trace activation IE), to the Xn application protocol, for exchange between RAN nodes (over an Xn interface); introduction of a second trace activation information element (IE) (i.e., in addition to an existing trace activation IE), to the NG application protocol, for provision by an AMF to a RAN node (over an NG interface); or to extend an existing 'choice MDT Mode' IE (e.g., in the Xn application protocol and / or NG application protocol) to allow configuration of I-MDT and L-MDT at the same time.

[0028] However, further development of techniques and mechanisms for supporting C-MDT is still needed.

[0029] For example, existing proposals do not take account of the fact that, for management-based MDT (i.e., for cell level MDT tracing), even if a UE can be configured with both a logged MDT configuration (for use in RRC idle and RRC inactive states) and with an immediate MDT configuration for use in an RRC connected state, when that UE moves to an RRC connected state from RRC idle / inactive (during which logged MDT data has been collected) or when a UE is handed over, the network is unable to ensure that is selects the same UE for continuous MDT for subsequent immediate MDT data collection.

[0030] Accordingly, existing proposals do not ensure that the UE that collects MDT measurements whilst in the same RRC state is the same UE that collects MDT measurements across different RRC states. Moreover, existing proposals do not ensure that the TCE which eventually receives the MDT trace reports is able to associate both the received logged and immediate MDT measurements to a continuous data collection period from the same UE.

[0031] Moreover, further development is needed in respect of: the way or ways in which a UE might collect and report C-MDT data based on the C-MDT configuration; how scenarios in which the RAN node serving a UE changes (e.g., due to UE mobility) while C-MDT data collection is ongoing; how distributed RAN nodes should handle C-MDT configuration; how C-MDT configuration is handled in the context of dual connectivity; and how user consent and / or UE capability can be taken into consideration for the purposes of C-MDT configuration.

[0032] The present specification aims to disclose apparatus and methods that at least contribute to addressing one or more of the above needs and / or issues.

[0033] The disclosure has a method performed by a mobile device, the method comprising receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

[0034] The disclosure has a method performed by an access network node, the method comprising transmitting, to a mobile device, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device being used by the mobile device in performing the continuous measurements in one or more of the plurality of the RRC states; and receiving, from the mobile device, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

[0035] The disclosure has a mobile device comprising means for receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device means for performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and means for transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

[0036] The disclosure has an access network node comprising means for transmitting, to a mobile device, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device being used by the mobile device in performing the continuous measurements in one or more of the plurality of the RRC states; and means for receiving, from the mobile device, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

[0037] Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0038] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0039] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 is a simplified sequence diagram illustrating a RAN node-triggered layer-3 (L3)-type handover procedure that may be implemented in the communication system of Fig. 1;Fig. 3 is a simplified sequence diagram illustrating a RAN node-triggered layer-1 / layer-2 (L1 / L2)-type handover procedure that may be implemented in the communication system of Fig. 1;Fig. 4 illustrates a functional framework for AI / ML models, and how various entities of the framework may interact with one another, that may be implemented in the communication system of Fig. 1;Fig. 5 schematically illustrates a method of training an AI / ML model, and of monitoring the performance of the AI / ML model, which may be implemented in the communication system of Fig. 1;Fig. 6 is a simplified sequence diagram illustrating an OAM / Management centric procedure for C-MDT configuration and operation that may be implemented in the communication system illustrated in Fig. 1;Fig. 7 is simplified sequence diagram illustrating another OAM / Management centric procedure for C-MDT configuration and operation that may be implemented in the communication system illustrated in Fig. 1;Fig. 8 is a simplified sequence diagram illustrating a core network centric procedure for C-MDT configuration and operation that may be implemented in the communication system illustrated in Fig. 1;Fig. 9A is respective parts of a simplified sequence diagram illustrating another core network centric procedure for C-MDT configuration and operation that may be implemented in the communication system illustrated in Fig. 1;Fig. 9B is respective parts of a simplified sequence diagram illustrating another core network centric procedure for C-MDT configuration and operation that may be implemented in the communication system illustrated in Fig. 1;Fig. 10 is a simplified sequence diagram illustrating a UE centric procedure for handling C-MDT data collection and configuration in the context of mobility that may be implemented in the communication system illustrated in Fig. 1;Fig. 11 is a simplified sequence diagram illustrating a procedure for handling C-MDT configuration within a distributed RAN that may be implemented in the communication system illustrated in Fig. 1;Fig. 12 is a simplified sequence diagram illustrating a procedure for providing UE capability information that may be implemented in the communication system illustrated in Fig. 1;Fig. 13 is a simplified sequence diagram illustrating a procedure for handling user consent information that may be implemented in the communication system illustrated in Fig. 1;Fig. 14 is a simplified block schematic illustrating the main components of a UE for implementation in the communication system of Fig. 1;Fig. 15 is a simplified block schematic illustrating the main components of a non-distributed RAN node for implementation in the communication system of Fig. 1; andFig. 16 is a schematic block diagram illustrating the main components of a distributed RAN node for the communication system of Fig. 1;Fig. 17 is a schematic block diagram illustrating the main components of a control plane function for the communication system of Fig. 1;Fig. 18 is a schematic block diagram illustrating the main components of an OAM / Management function for the communication system of Fig. 1; andFig. 19 is a schematic block diagram illustrating the main components of a trace control entity for the communication system of Fig. 1.

[0040] <Overview> 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs 1 to 5.

[0041] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which examples of the present disclosure are applicable.

[0042] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile devices) can communicate with each other via a corresponding (radio) access network ((R)AN) node 5-1, 5-2 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN node 5 (5-1, 5-2) comprises a base station 5 that respectively operates one or more associated cells 9 (9-1, 9-2). In the illustrated communication system 1, the coverage provided by each RAN node 5 may be by means of a plurality of beams B (B1, B2… Br, Br+1… BN). It will be appreciated that while, for clarity of illustration, only a selection of possible beams B are shown for one of the RAN nodes 5, the set of beams may include any suitable number of beams and each RAN node 5 may operate a respective set of beams or may provide coverage in a non-beamformed manner.

[0043] Communication via each RAN node 5 is typically routed through a core network 7 (e.g., a 5G / 6G and / or later generations' core network or evolved packet core (EPC) network).

[0044] As those skilled in the art will appreciate, whilst three UEs 3 and two RAN nodes 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other RAN nodes 5 and UEs 3.

[0045] Each RAN node 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the RAN nodes 5 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0046] In this example one of the illustrated RAN nodes 5 is a non-distributed RAN node 5-1, while another RAN node 5 is a distributed RAN node 5-2. That distributed RAN node 5-2 forms part of a distributed RAN (which may be referred to as a 'distributed base station'). The RAN node 5-2 of a distributed RAN comprises at least one distributed unit (DU) 5-2DU(e.g., a gNB-DU or the like), and a central unit (CU) 5-2CU(e.g., a gNB-CU or the like). The CU 5-2CUemploys a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP) and a user plane function (CU-UP) which respectively communicate, with the DU 5-2DUvia a first interface (e.g., an F1-C logical interface) and a second interface (e.g., an F1-C logical interface) (the interfaces together forming a combined interface such as an F1 interface (or 'reference point')), and with one another via another interface (e.g., an E1 logical interface). It will be appreciated that while, in this example, the DU 5-2DUincludes the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the UEs 3 over the air interface, the distributed RAN node 5-2 may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer).

[0047] Whilst one non-distributed ('integrated') RAN node 5-1 and one distributed RAN node 5-2 are shown, it will, nevertheless, be appreciated that either (or both) of the RAN nodes 5 may be provided in a distributed or non-distributed form. It will also be appreciated that whilst the term 'RAN node' is generally used herein to refer to a whole base station, the CU 5-2CUand DU 5-2DUare also both parts of a corresponding distributed RAN and are therefore each a distinct 'RAN node' albeit that they each form part of the same RAN, and that each may have only a subset of the functionality provided by a whole base station. References to a RAN node 5 as used herein should, therefore, be understood, accordingly.

[0048] The UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Neighbouring RAN nodes 5 may be connected to each other via an appropriate RAN node to RAN node interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).

[0049] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g., user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g., Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g., Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE 3 and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0050] The communication system 1 also has a management system that includes a management system / operations, administration, and maintenance (OAM) that comprises one or more management / OAM functions 14 for provisioning and managing the network and / or elements within the wider communication system 1. The one or more management / OAM functions 14 may, for example, be responsible for the storage and analysis of some radio-related measurements and may perform some data analytics functions including some RAN analytics. The one or more management / OAM functions 14 may, for example, communicate with one or more of the core network CPFs 10 and communicate with a network data analytics function (NWDAF) or the like (not shown). In the illustrated communication system 1, the management system / OAM includes one or more trace collection entities (TCEs) 16 for receiving, from a RAN node 5, trace reports carrying data acquired during trace sessions / trace recording sessions. The trace reports may include, for example, minimisation of drive test (MDT) reports including MDT measurement data acquired by one or more UEs 3.

[0051] Each RAN node 5 is respectively connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g., N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communications are routed transparently via the RAN node 5.

[0052] Each UPF 11 is connected to an external data network 20 (e.g., an IP network such as the internet) via an appropriate reference point (e.g., an N6 reference point) for communication of the user data.

[0053] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging. The AMF 10-1 receives user information sent through the network and forwards the information to the SMF 10-2.

[0054] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (e.g., N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.

[0055] Each RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0056] The DL physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting several functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. Specifically, a UE 3 may receive a Synchronization Signal / Physical Broadcast Channel (PBCH) Block (SSB) (also referred to as an 'SS / PBCH block'), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form that SSB. The RAN node 5 may transmit several SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5ms duration as an SS burst.

[0057] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0058] Similarly, the UEs 3 are configured for transmission of, and the RAN node 5-1 is configured for the reception of, control information and user data via several uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0059] When the UE 3 initially establishes a radio resource control (RRC) connection with a RAN node 5 via a cell 9 it registers with an appropriate core network node (e.g., AMF 10-1, MME). The UE 3 is in the so-called RRC connected state and an associated UE context is maintained by the network. When the UE 3 is in the so-called RRC idle state, or is in the RRC inactive state, it selects an appropriate cell for camping so that the network is aware of the approximate location of the UE 3 (although not necessarily on a cell level).

[0060] <Network Access> 　　The UEs 3 and the RAN nodes 5 of the communication system 1 are mutually configured for performing a random-access channel (RACH) procedure for the UEs 3 to access the network. Specifically, on detection and selection of a cell (and / or a beam in the case of 5G) a UE 3 is able to attempt access to that cell and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random-access procedure with a corresponding RAN node 5.

[0061] Prior to attempting initial access, the UE 3 chooses random access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends the selected preamble (e.g., in 'Msg1') to the RAN node 5 over a physical random-access channel (PRACH) for initiating the process to obtain synchronization in the uplink (UL). In response, the RAN node 5 responds with a random-access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes: a timing-alignment (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE 3 can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. The UE 3 then sends a third message ('Msg3') to the network over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE 3 in this step, and the content of the message, depends on the context in which the random-access procedure is being used. In the example of initial radio RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs 3 using the same preamble sequence. When successful, Msg4 also transfers the UE 3 to a connected state.

[0062] While a four-step contention-based RACH procedure is described it will be appreciated that a UE 3 and a RAN node 5 of the communication system 1 may also perform a non-contention based (or 'contention free') procedure in which a dedicated preamble is assigned the RAN node 5 to the UE 3. Moreover, a UE 3 and the RAN node 5 of the communication system 1 may perform a two-step RACH procedure.

[0063] Random access procedures such as that described may also be used in other contexts including, for example, handover, connection reestablishment, requesting UL scheduling where no dedicated resource for a scheduling-request has been configured for the UE 3, etc.

[0064] It will be appreciated that while the UE 3 can trigger initiation of the RACH procedure itself (e.g., when the UE 3 needs to connect to the network), initiation of the RACH procedure may be by the network. For example, a RACH procedure may be initiated via a message sent via downlink control information (DCI) with an appropriate DCI format (e.g., 1_0) in a physical downlink control channel (PDCCH) - such a message is commonly known as a PDCCH order. A RACH procedure may be also initiated by the RAN node 5 when handover is required (e.g., using a handover command message, or the like).

[0065] Different types of handover procedure that may be implemented in the communication system 1 will now be described, by way of example only, with reference to Figs. 2 and 3.

[0066] < Different Types of Handovers - Layer 3 (L3) Handover> 　　In conventional (e.g., layer-3 (L3)) handover procedures (including both RACH based and RACH-less handover procedures) handover may be triggered by a RAN node 5S, 5T. For example, a first RAN node 5S(e.g., operating as a source RAN node 5S) may initially decide to initiate a handover based on measurement reporting by the UE 3 (e.g., a measurement report triggered by a particular measurement reporting event, or periodically).

[0067] Fig. 2 is a simplified sequence diagram illustrating a RAN node triggered (L3) handover procedure that may be implemented in the communication system.

[0068] Referring to Fig. 2, the RAN node triggered handover procedure in this case concerns a handover of a UE 3 between the first RAN node 5S(e.g., operating as a source RAN node 5S) and the second RAN node 5T(e.g., operating as a target RAN node 5T).

[0069] As seen at S202, before the handover procedure starts, the first RAN node 5Sis serving and communicating user data with the UE 3 (i.e., the source base station of the handover) and will typically have a UE context for the UE 3 stored in its memory. This UE context may include, for example, information regarding roaming and access restrictions which were provided either at establishment of the connection between the UE 3 and the first RAN node 5Sor at the last (most recent) tracking area update.

[0070] At S204, the first RAN node 5Smay configure measurement procedures that are to be performed by the UE 3, and the UE 3 may transmit appropriate measurement reports to the first RAN node 5Sin accordance with the configured measurement procedures.

[0071] In the handover procedure, a handover preparation phase S206 commences when the first RAN node 5S(operating as the source RAN node 5S) decides to initiate handover. Specifically, at S208 the first RAN node 5Sdecides to handover the UE 3 to a second RAN node 5T(e.g., the target RAN node 5T) based on, for example, measurement results received in a measurement report and / or radio resource management (RRM) information.

[0072] The first RAN node 5Sissues, at S210, a handover request, to the second RAN node 5T. This message will typically pass to the second RAN node 5T, information necessary to perform the handover. The necessary information may be used for preparing the handover at the target side. The necessary information may include, for example, the target cell ID, security information, a cell radio network temporary identifier (C-RNTI) of the UE 3 at the first RAN node 5S, RRM configuration information (e.g., including UE inactive time), basic access stratum (AS) configuration information including antenna information and downlink carrier frequency, current quality of service (QoS) flow to data radio bearer (DRB) mapping rules applied to the UE 3, system information (e.g., SIB1) from the first RAN node 5S, the UE capabilities for different RATs, protocol data unit (PDU) session related information, and / or UE reported measurement information including beam-related information if available.

[0073] While not shown, it will be appreciated that, admission control may be performed by the second RAN node 5T. Slice-aware admission control may, for example, be performed if corresponding slice information is sent to the second RAN node 5Tand if protocol data unit (PDU) sessions are associated with non-supported slices the second RAN node 5Tmay reject such a PDU session.

[0074] The second RAN node 5Tprepares handover and sends an appropriate response (e.g., a handover request acknowledge message or the like) to the first RAN node 5Sat S212. The response may include an RRC message in a transparent container that is to be sent to the UE 3 as a handover command to instruct / trigger performance of the handover (e.g., an RRC reconfiguration message or the like).

[0075] The first RAN node 5Striggers the handover by sending the RRC message (e.g., the RRC reconfiguration message or the like) to the UE 3 at S214. This RRC message contains the information required to access the target cell (e.g., the target cell ID, the new C-RNTI, the second RAN node security algorithm identifiers for the selected security algorithms and / or the like).

[0076] As soon as the first RAN node 5Sreceives the response (e.g., the handover request acknowledge message or the like), or as soon as the transmission of the handover command (e.g., the RRC reconfiguration message or the like) is initiated in the downlink, data forwarding may be initiated.

[0077] A handover execution phase S216 is then initiated, and the UE 3 detaches from the first RAN node 5Sand synchronises to the second RAN node 5T(at S218).

[0078] The UE 3 synchronises to a target cell of the second RAN node 5Tand completes the handover procedure by sending an appropriate RRC message (e.g., an RRC Reconfiguration Complete message) to the second RAN node 5T(at S220).

[0079] The last phase is the handover completion phase during which the second RAN node 5Tcoordinates with the core network 7 to switch communication to the second RAN node 5T(at S222). Once communication has been switched the second RAN node 5Tinitiates a UE context release at the first RAN node 5Sto release the associated resources of the first RAN node 5S(e.g., by sending a UE context release message at S224).

[0080] It will be appreciated that mobility methods and handover procedures for the UE 3 are not restricted to the example illustrated in Fig. 2. For example, the UE 3 may be configured to perform a conditional handover (CHO) in which the UE 3 determines whether handover of the UE 3 to a candidate cell is to be performed based on one or more execution conditions previously configured by the RAN node 5.

[0081] In the handover procedure described above with reference to Fig. 2, the handover decision is based on the 'beforehand' measurement reports from the UE 3 i.e., the system decides to perform the handover sometime after it has received measurement reports from the UE 3. However, it will be appreciated that after the handover decision is made, the radio signal conditions may change either before or during handover execution (e.g., at around step S214). If such a change in conditions occurs, there may be a quality gap between the current cell that the UE 3 is operating on, and the future cell to which it is going to switch, thereby increasing the chances of a handover failure, or the occurrence of an inappropriate handover. As a result of such changes in conditions, the handover may be performed too early, too late, or may even become unnecessary. It will be appreciated that this issue is particularly pertinent when the UE 3 moves at high speeds.

[0082] Being aware of the above issues, layer-1 / layer-2 (L1 / L2) triggered mobility procedures for handover (also referred to as lower-layer triggered mobility (LTM) handovers) have been developed that make handover decisions based on more 'real time' measurement reports.

[0083] An example of such a LTM handover will now be described with reference to Fig. 3.

[0084] <Different Types of Handovers - LTM Handover> 　　Fig. 3 illustrates a simplified sequence diagram of a RAN node triggered LTM-type handover procedure that may be implemented in the communication system.

[0085] Referring to Fig. 3, the example LTM-type handover procedure in this case also concerns a handover of a UE 3 between the first RAN node 5S(e.g., operating as a source RAN node 5S) and the second RAN node 5T(e.g., operating as a target RAN node 5T).

[0086] At S301 the UE 3 may perform measurements. For example, the measurements may be measurements of one or more reference signals (RSs) and / or other signals transmitted by the first RAN node 5Sand / or second RAN node 5Tin a corresponding cell 9. In one example, the measurements may be measurements of a signal strength of a signal transmitted by the first / second RAN node 5S / 5Tto the UE 3, that can be used as part of a determination that the UE 3 is to be handed over from the first (source) RAN node 5Sto the second (target) RAN node 5T.

[0087] In another example, at S301, the UE 3 may additionally (or alternatively) perform any appropriate intra-frequency and inter-frequency measurements, which may be specified to the UE 3 via appropriate measurement objects in a configuration message sent to the UE 3 by the first RAN node 5S(not shown) that indicate frequency / time locations and SCSs of reference signals to be measured.

[0088] In another example, at step S301, the UE 3 may additionally (or alternatively) perform any appropriate inter-RAT measurements, which may be specified to the UE 3 via appropriate measurement objects in a configuration message sent to the UE 3 by the first RAN node 5S(not shown) that indicate a single carrier frequency (e.g., a E-UTRA frequency).

[0089] At S302 the UE 3 may transmit a measurement report to the first (source) RAN node 5Sthat provides an indication of the result of the measurements made by the UE 3. The measurement report may be transmitted from the UE 3 to the first RAN node 5Sin an appropriate message (e.g., an RRC message). The first RAN node 5Smay use the information provided in the measurement report to determine (not shown) that LTM needs to be configured and to initiate LTM preparation (this decision may be referred to as an LTM handover decision). Specifically, the first RAN node 5Sdecides to (pre)configure the UE 3 for handover / cell switch to each of one or more LTM candidate cells / RAN nodes forming an LTM candidate set. The LTM candidate set includes, for example, at least the cell / second RAN node 5Tthat will ultimately become the target cell / target RAN node 5T.

[0090] It will be appreciated that the UE 3 may transmit the measurement reports to the first RAN node 5-1 based on an appropriate reporting configuration previously signalled to the UE 3 by the first RAN node 5S(in a similar manner to that described with reference to Fig. 2). For example, the first RAN node 5Smay have previously provided the UE 3 with one or more reporting configurations that indicate a criterion to trigger the UE 3 to send measurement reports to the first RAN node 5S. The criterion may be a single event that triggers the UE 3 to send measurement reports to the first RAN node 5S. Alternatively the criterion may configure the UE 3 to send measurement reports to the first RAN node 5Son a periodic basis (i.e., triggered at periodic time intervals). The one or more reporting configurations may indicate to the UE 3 a type of RS that the UE 3 is to measure for beam and / or cell measurement results. For example, the one or more reporting configurations may indicate to the UE 3 that it is to measure the one or more synchronisation signals (e.g., secondary synchronisation signals) carried by SS / PBCH blocks (also referred to as 'SSBs'), CSI-RSs, or the like. By way of example only, the one or more reporting configurations may configure the UE 3 to measure and report, to the first RAN node 5S, measurement results per SS / PBCH block, measurement results per cell (or beam) based on SS / PBCH blocks, SS / PBCH block indexes, and the like. Furthermore, by way of example only, the one or more reporting configurations may configure the UE 3 to measure and report, to the first RAN node 5S, measurement results per CSI-RS resource, measurement results per cell (or per beam) based on CSI-RS resources, CSI-RS resource measurement identifiers, and the like.

[0091] The one or more reporting configurations may configure the UE 3 to measure and report, to the first RAN node 5S, SSB-based L1-RSRP measurements for beam selection. For example, the one or more reporting configurations may configure the UE 3 to measure and report, to first RAN node 5S, indexes of SSB resource sets configured for L1 mobility measurement reporting (e.g., one or more SSB resource indicators (SSBRIs)), L1 measurement quantities for each beam (e.g., RSRP), and / or differential L1 measurement quantities for each beam (e.g., differential RSRP), and / or the like.

[0092] Additionally (or alternatively) the one or more reporting configurations may indicate to the UE 3 a format in which the measurement results are to be presented to the first RAN node 5S. For example, the one or more reporting configurations may indicate to the UE 3 the quantity of measurements per cell and / or per beam to include in each measurement report sent to the first RAN node 5S. The one or more reporting configurations may also indicate to the UE 3 other appropriate associated information such as the maximum number of cells and the maximum number beams per cell to report.

[0093] At S304 the first RAN node 5Smay transmit a handover request to each candidate RAN node 5 (i.e., each RAN node 5 that may become a target of the handover / cell switch in the future). In Fig. 3 whilst a single candidate RAN node 5 (second RAN node 5Tthat ultimately becomes the target) is shown there may (but do not have to) be a plurality of candidate RAN nodes 5. The handover request may include an indication of, for example, an identity of the first RAN node 5S, a cause value for the handover, an identity of the second RAN node 5T, an identity of a target cell provided by the second RAN node 5T, UE 3 context information (e.g., a maximum bit rate of the UE 3, or security capabilities of the UE 3), UE history information, and the like. For example, the handover request may include, amongst other things, a target cell ID, security information, a C-RNTI of the UE 3 at the first RAN node 5S, RRM configuration information (e.g., including UE inactive time), basic AS configuration information including antenna information and downlink carrier frequency, current QoS flow to DRB mapping rules applied to the UE 3, the SIB1 from the first RAN node 5S, the UE capabilities for different RATs, PDU session related information, and / or UE reported measurement information including beam-related information if available.

[0094] Furthermore, it will be appreciated that if the handover has been triggered by the measurement report received by the first RAN node 5Sin S302, then the cause value included in the handover request may indicate, for example, that the handover is desirable for radio reasons.

[0095] The following procedure will be described from the perspective of the candidate (second) RAN node 5Tthat ultimately becomes the target RAN node 5T. It will, nevertheless, be appreciated that a similar procedure will be performed at each candidate RAN node 5 as part of the procedure to configure the UE 3 for LTM.

[0096] At S306, having received handover request, the second RAN node 5Tmay perform, based on that handover request, an admission control procedure. For example, the second RAN node 5Tmay perform a validation procedure that may involve performing a check that if a connection is established between the UE 3 and the second RAN node 5Tthen current resources are sufficient for the proposed connection.

[0097] At S308 having received the handover request at S304 and having performed admission control at S306, the second RAN node 5Tprepares handover with its lower layers (L1 and L2) (e.g., including reserving corresponding resources for the UE 3) and sends, to the first (source) RAN node 5S, an appropriate response (e.g., a handover request acknowledge message or the like). The handover request acknowledge message may include a transparent container comprising a message (e.g., an RRC message) to be sent to the UE 3 and that is to be used as an 'LTM candidate configuration' message to configure LTM handover / cell switch for that specific candidate (second) RAN node 5T(e.g., as a handover command to instruct performance of the handover). The message to be sent to the UE 3 may, for example, be an RRC reconfiguration message or the like. The handover request acknowledgement message may also include appropriate configuration information that enables the first RAN node 5Sto begin forwarding user plane data for the UE 3 to the second RAN node 5T.

[0098] It will be appreciated that the transmissions of at steps S304 and S308 may be performed over an appropriate interface between the first RAN node 5Sand the second RAN node 5T(e.g., an Xn or similar interface) - therefore the handover procedure in this example may be referred to as an 'Xn' (or similar interface name ) based handover procedure. Steps S301 to S308 may be referred to as a 'handover preparation phase' of the LTM-type handover procedure (which is analogous to the handover preparation phase S206 described with reference to Fig. 2). At S310, the first RAN node 5Stransmits the respective LTM candidate configuration to the UE 3 received from each candidate RAN node 5 in an appropriate (e.g. RRC) message (e.g., an RRC reconfiguration message) comprising an appropriate LTM configuration information element (IE) including the respective LTM candidate configuration for each candidate RAN node 5 (of which there may be one or more). Each LTM candidate configuration in the LTM configuration IE may, for example, be a complete candidate configuration or may be a delta configuration relative to a reference configuration.

[0099] The first RAN node 5Smay also include as part of the LTM configuration, LTM measurement configuration information for configuring L1 measurements to be reported. The measurement configuration information may, for example, be configured for configuring the UE 3 to provide an SSB based L1-RSRP measurement report for beam selection. The first RAN node 5Smay also include as part of the LTM configuration, LTM report configuration information for configuring L1 measurement reporting. The report configuration information may, for example, configure reporting to be periodic (on the PUCCH), aperiodic, semipersistent (on the PUCCH or the PUSCH), and / or the like. The report configuration information may, for example, configure the content of the report (e.g., how many cells are reported within a single L1 measurement report instance, how many reference signals per cell are reported within a single L1 measurement report instance, whether the UE 3 should include an L1 measurement report associated to the current special cell, and / or the like).

[0100] Having received those LTM candidate configurations, the UE 3 stores the LTM candidate configurations and responds to the message carrying the LTM configuration (not shown) with an appropriate response message (e.g., an RRC reconfiguration complete message or the like) to effectively indicate that the LTM configuration has been completed at the UE 3.

[0101] The UE 3 may, at this stage, perform early synchronization (not shown), in the downlink, with each candidate cell (i.e., before receiving any corresponding cell switch (or 'handover') command). The UE 3 may also, at this stage, perform early synchronization (not shown), in the uplink, with each candidate cell. Specifically, when UE-based timing advance (TA) measurement is configured, the UE 3 may acquire a respective TA value of each candidate cell by measurement. The UE 3 may perform early TA acquisition with a candidate cell in accordance with a request by the network (i.e., before receiving any corresponding cell switch (or 'handover') command). This may, for example, be done via a contention free random access (CFRA) triggered by a PDCCH order from the first RAN node 5S, following which the UE 3 sends preamble towards the indicated candidate cell. In order to minimise the data interruption of the source cell due to CFRA towards a candidate cell, the UE 3 need not receive random access response from the network for the purpose of TA value acquisition and the TA value of the candidate cell may be indicated in any cell switch command.

[0102] An LTM execution / completion phase is then initiated during which the UE 3 performs, at S312, the configured L1 measurements for the configured candidate cells (where possible) and sends, at S314, a corresponding L1 measurement report to the first RAN node 5Sin accordance with the report configuration information. L1 measurement may be performed as long as the LTM configuration (i.e., the RRC reconfiguration) provided at S310 is applicable.

[0103] When the UE 3 sends a report configured to provide SSB based L1-RSRP measurements, the L1 measurement report may include, for example, one or more SSB resource set indexes ('SSBRIs'), which are indexes of SSB resource sets configured for L1 mobility measurement reporting. This report may include, for example, a set of one or more L1-RSRP measurement results for each cell. Each reported L1-RSRP value may, for example, be an absolute (e.g., 7-bit) value, or differential reporting may be used in which one or more L1-RSRP values are reported as differential (e.g., 4-bit) values relative to another reported 'reference' absolute (e.g. 7-bit) value of L1-RSRP (e.g., the reference value may be the highest (or lowest) reported L1-RSRP).

[0104] At S316, the first RAN node 5Sdecides to execute cell switch to a target cell (i.e., a cell of the second RAN node 5-2 in this example). The first RAN node 5Smay then initiate transmission, at S318, of an LTM cell switch command (e.g., as a MAC CE for triggering a cell switch (or handover)) including a candidate configuration index corresponding to the target cell / second RAN node 5T. The UE 3 then detaches (not shown) from the source cell of the first (source) RAN node 5Sand switches to the target cell of the second (target) RAN node 5Tby applying the corresponding LTM candidate configuration indicated by candidate configuration index.

[0105] As indicated at S320, the UE 3 can then access the cell using a RACH based or RACH-less procedure. The UE 3 may, for example, perform a random-access procedure towards the target cell if the UE 3 does not have valid TA of the target cell. Nevertheless, the UE 3 may access the cell without performing a random-access procedure where the UE 3 has a valid TA. The UE 3 can complete the LTM cell switch procedure by sending an appropriate message (e.g., an RRC reconfiguration complete message) to the second RAN node 5T. If the UE 3 has performed a random-access procedure the UE 3 may consider that LTM cell switch execution has been successfully completed when the random-access procedure has successfully completed. For RACH-less LTM, on the other hand, the UE 3 may consider that the LTM cell switch execution has successfully completed when the UE 3 determines that the second RAN node 5Thas successfully received its first uplink data.

[0106] It will be appreciated that mobility methods and handover procedures for the UE 3 are not restricted to the example illustrated in Fig. 3. For example, the UE 3 may be configured to perform a CHO in which the UE 3 determines whether handover of the UE 3 to a candidate cell is to be performed based on one or more execution conditions.

[0107] <Carrier Aggregation (CA)> 　　In the communication system 1, increases in bandwidth, and thereby bitrate can be achieved through carrier aggregation (CA), whereby multiple frequency blocks, i.e., component carriers (CCs), are assigned to the same UE 3 for use. Each CC in turn serves a cell which provides a particular bandwidth and set of services to the UE 3. For example, in CA each UE 3 has a first CC that provides a primary cell (PCell) that carries traffic and RRC signalling messages and may additionally any number of other CCs that each provide their own corresponding secondary cell (SCell) which carry traffic alone. The SCells are optional, and are added, removed, and / or reconfigured are required by the UE 3 and the network.

[0108] In CA, when initially scanning for a cell to camp on each UE 3 scans for a PCell. The PCell is serves as the main point of communication between the UE 3 and the RAN node 5 and is responsible for all control information signalling (e.g., RRC Configuration signalling), non-access stratum (NAS) signalling, and the like, between the UE 3 and the network, as well as initial data transmissions. The PCell typically offers a high bandwidth for low latency data transmission. It will be appreciated that when initially scanning for a PCell to camp on each UE 3 searches for SSB as described previously to enable efficient cell searching for, and initial access to the PCell.

[0109] As and when required, the UE 3 may be triggered to search for, and camp on one or more secondary cells (SCells) to provide additional capacity and adaptability in the network. For example, the UE 3 may be triggered to search for, and camp on one or more SCells to provide extra bandwidth when the network is experiencing high data traffic or congestion. Additionally, or alternatively, SCells may be camped on to provide specific specialist services, for example, the UE 3 may camp onto a SCell that caters for Internet-of-Things (IoT) devices, high-definition data streaming, or the like.

[0110] <Dual Connectivity (DC)> 　　The UEs 3 and RAN nodes 5 of the communication system are also mutually configured for dual connectivity in which the UE 3 can be configured to connect and communicate via (at least) two different RAN nodes 5 known as a master RAN node 5 and a secondary RAN node 5 that are themselves interconnected via an appropriate RAN node to RAN node interface (e.g., Xn or X2). It will be appreciated that, in dual connectivity, the master RAN node and the secondary RAN node may be configured to use the same, or a different, radio access technology (e.g., the RAN nodes 5 may each use a different one of a 4G, 5G, 6G (or other) radio access technology).

[0111] CA can also be used by a UE 3, in the context of dual connectivity. For example, a UE 3 may be configured to communicate via one, or multiple (carrier aggregated) cells of the master RAN node and via one, or multiple (carrier aggregated) cells of the secondary RAN node.

[0112] A group of serving cells associated with the master RAN node may be referred to as a master cell group (MCG). The MCG typically comprises a so called special cell (SpCell) which is the PCell (Primary Cell), and one or more SCells. A group of serving cells associated with the secondary RAN Node may be referred to as a secondary cell group (SCG). The SCG typically comprises an SpCell, which is known as a primary SCell (PSCell) in this case, and one or more SCells.

[0113] It will be appreciated that whilst CA and DC are conceptually similar, there are a number of differences. For example, in CA the user traffic is typically split between different carriers at the MAC layer, whereas in DC user traffic is typically split at the PDCP layer.

[0114] <AI / ML> 　　The communication system 1 supports the use of artificial intelligence (AI) and machine learning (ML), often abbreviated to AI / ML in accordance with recent developments in cellular communication technology (e.g., as part of the work of the 3GPP) that those skilled in the art will be familiar with. These AI / ML features make use of trained AI / ML models to make one or more predictions or inferences, from a set of one or more input vectors, which can be used in the network (e.g., for improving the reliability or efficiency of communication in the network).

[0115] In respect of the communication system 1, for example, AI / ML models could potentially be trained and used for predicting the path of a UE 3 based on previous mobility of the UE 3, used for beam management, or used in methods of encoding and transmitting information. An AI / ML model may be hosted at a RAN node 5 (or any other suitable network node), and the RAN node 5 may perform control of communication resources for UEs 3 it serves, and / or perform control related to the status of a UE 3 (e.g. control of UE mobility, or control of a radio resource control, RRC, state of the UE 3) based on an inference (e.g. determination or prediction) generated using the AI / ML model. The RAN node 5 may also transmit an inference generated using the model to another node in the network, for use at the other node. An AI / ML model may also be hosted the UE 3, or at a plurality of locations within the network, for example at both the RAN node 5 and at the UE 3. For example, the RAN node 5 and the UE 3 may both make determinations and / or predictions using the same model or different models.

[0116] The support for such AI / ML features may involve different levels of collaboration between the network (RAN node 5 and / or core network 7) and a UE 3 served by the network when deploying and using such AI / ML features. For example, three possible 'network-UE collaboration levels' that may be supported are: Level x: Involving no collaboration between the network and the UE 3. Specifically, level x is an implementation-based AI / ML operation without any dedicated AI / ML-specific enhancement. Level y: Signalling-based collaboration without AI / ML model transfer. For example, this level is applicable when model training is performed offline, and models are registered to both a RAN node 5 and the UE 3. Here, the RAN node 5 and the UE 3 are aware of available models (before operation), and the RAN node 5 is only required to activate / deactivate the models residing at the UE 3 when needed. Level z: Signalling-based collaboration with AI / ML model transfer (e.g., where an AI / ML model is transferred to the UE 3 when needed).

[0117] The AI / ML model types that are supported in the communication system 1 may include, for example: Single-sided model: A single-sided AI / ML model is an AI / ML model that is deployed (hosted) only at the UE side or at the network side. For example, an AI / ML model may be hosted (stored, for generating inferences) at a UE 3, RAN node 5, or a central entity of the communication system 1, or an operations, administration, and maintenance (OAM) / over-the-top (OTT) server. When the AI / ML model is used at a UE 3, a RAN node 5, a central entity of the communication system 1, or an OAM / OTT server only, the AI / ML model may be referred to as a 'single-sided' model. An example of this type of 'single-sided' model is an AI / ML model for beam prediction in time, which can be deployed at the UE side. However, even when the model is a single-sided model, it will be appreciated that the model need not necessarily be trained at the node at which it is deployed (e.g., a UE 3 or a RAN node 5). For example, the model could be trained at the RAN node 5 (or at another node in the network such as a core network node / function - e.g., a central entity of the communication system 1, or an OAM / OTT server - and then transferred to the UE 3 for use at the UE 3. Two-sided model: A 'two-sided' model is an AI / ML model (or model pair) that has one AI / ML model hosted at one node (e.g., the UE 3), and a corresponding AI / ML model hosted at another node (e.g., a RAN node 5) - it will be appreciated that any pair of network nodes may be used. Such a two-sided model may also be referred to as a 'paired' AI / ML model. An inference using a two-sided model is performed jointly across the nodes at which the AI / ML models of the two-sided model are deployed. The joint inference may comprise, for example, a first part of the inference being performed at one node (e.g., the UE 3 or RAN node 5), and then the remaining part may be performed by the other (e.g., the RAN node 5 or UE 3). It will be appreciated that whilst the AI / ML model hosted at the different nodes may be the same AI / ML model, they need not necessarily be the same model. One example of this type of model is, for example only, channel state information (CSI) compression, where the UE performs CSI compression and network performs CSI decompression. As with the single-sided model case, the two-sided model (or models) may be trained at any suitable network node, and then transmitted to the UE 3 and the RAN node 5 (or other respective node or nodes).

[0118] A general discussion of how AI / ML may be implemented in the communication system 1 will now be provided, by way of example only, with reference to Figs. 4 and 5.

[0119] Fig. 4 illustrates a functional framework for AI / ML models, and how various entities of the framework may interact with one another, that may be implemented in the communication system 1.

[0120] The entities include a data collection entity 441, a model training function 443, a model inference function 445, an actor 447, a management function 449, and a model storage entity 451.

[0121] The model storage entity 451 may be a reference point for protocol terminations for model transfer and delivery. The AI / ML models could be stored at any suitable node in the network.

[0122] The data collection entity 441 provides training data to the model training function 443, inference data to the model inference function 445, and monitoring data to the management function 449. The collected data may be, for example, data regarding mobility (e.g., handover of a UE 3, or a location of the UE 3). The data may be obtained, for example, by a UE 3 or a RAN node 5 (e.g., by receiving a measurement report from the UE 3, or by receiving data from another RAN node 5 or a core network node / function) and transmitted to another RAN node 5 or core network node that generates the AI / ML model inference output (or alternatively, the same RAN node 5 that obtains the data may generate the AI / ML model output).

[0123] The model training function 443 performs the AI / ML model training, validation, and testing, and may generate model performance metrics as part of a model testing procedure. The model training function 443 may output a trained AI / ML model to the model storage entity 451 (though it will be appreciated that the output model may be stored at locations other than model storage entity 451).

[0124] The model inference function 445 provides AI / ML model inference output (e.g., predictions or decisions), and the actor 447 is a function or node that receives the output from the model inference function 445 and triggers or performs corresponding actions (e.g., the RAN node 5 that increases / reduces its transmit power or initiates a handover procedure for the UE 3). The AI / ML model inference output may be, for example, a prediction of mobility (e.g., expected path, route or trajectory, inter-cell, or inter-beam mobility, or expected handover) of the UE 3, or one or more parameters for use in encoding or decoding transmissions between the RAN node 5 and the UE 3. The model inference function 445 may receive an AI / ML model from the model storage entity 451, and inference data from the data collection entity 441 for use with the AI / ML model. The model inference function 445 may also output monitoring data for use at the management function 449 and receive information indicating an AI / ML to activate or deactivate from the management function 449.

[0125] The management function 449 receives monitoring data from the data collection entity 441 and may also receive monitoring data from the model inference function 445. The management function 449 may transmit to the model storage entity 451, an indication of an AI / ML model to be transmitted for use at the model inference function 445. The management function 449 may also transmit to the model training function 443, performance feedback or a retraining request for the AI / ML model.

[0126] The functions illustrated in Fig. 4 may be co-located at a single node of the communication system 1 (e.g., at the RAN node 5 or core network node / function) or may be distributed amongst a plurality of network nodes (e.g., a plurality of the RAN nodes 5).

[0127] By way of example only, terms referred to by 3GPP in the context of this framework include: AI / ML model training: A process to train an AI / ML Model [by learning the input / output relationship] in a data driven manner and obtain the trained AI / ML Model for inference. Model training can be performed offline or online or combination of both. AI / ML model validation: A subprocess of training, to evaluate the quality of an AI / ML model using a dataset different from one used for model training, which helps selecting model parameters that generalize beyond the dataset used for model training. AI / ML model testing: A subprocess of training, to evaluate the performance of a final AI / ML model using a dataset different from one used for model training and validation. Differently from AI / ML model validation, testing does not assume subsequent tuning of the model. AI / ML model Inference: A process of using a trained AI / ML model to produce a set of outputs based on a set of inputs. Data collection: A process of collecting data by the network nodes, management entity, or UE for the purpose of AI / ML model training, data analytics and inference. Model monitoring: A procedure that monitors the inference performance of the AI / ML model. Model activation: Enable an AI / ML model for a specific function. Model deactivation: Disable an AI / ML model for a specific function. Model switching: Deactivating a currently active AI / ML model and activating a different AI / ML model for a specific function. Supervised learning: A process of training a model from input and its corresponding labels. Unsupervised leaning: A process of training a model without labelled data. Semi-supervised learning: A process of training a model with a mix of labelled data and unlabelled data. Reinforcement Learning (RL): A process of training an AI / ML model from input (also referred to as 'state') and a feedback signal (also referred to as 'reward') resulting from the model's output (also referred to as 'action') in an environment the model is interacting with.

[0128] The data collection by the data collection entity 441 may be performed at various nodes of the communication system 1 (e.g., at one or more RAN nodes 5 or UEs 3). Particularly advantageous methods of obtaining, at the UE 3, data for an AI / ML model, and transmitting the AI / ML data from the UE 3 to the RAN node 5, will be described in more detail later.

[0129] Fig. 5 schematically illustrates of a method of training an AI / ML model, and of monitoring the performance of the AI / ML model. As illustrated in Fig. 5, stored data / features may first be extracted in a data extraction step. In the data validation step, a determination of whether to proceed with training or retraining the AI / ML model is made (e.g., based on the extracted data). In the data preparation stage, the data is prepared for use in training the AI / ML model. For example, the data may be cleaned (e.g., filtered), subject to a transformation, or modified in any other suitable manner. The data may also be divided in training data, validation data and test data sets in the data preparation stage.

[0130] In the model training step, the AI / ML model is trained (or retrained) using training data prepared in the data preparation step. It will be appreciated that any suitable training method can be used to train the AI / ML model (e.g., a method that comprises supervised learning or unsupervised learning). In the model evaluation step, the AI / ML model is evaluated (e.g., a prediction accuracy of the AI / ML model is evaluated) using a test data set (which may be generated in the data preparation step). In the model validation step, a determination of whether the AI / ML model is suitable for deployment in the communication system 1 is made (e.g., based on the results of the model evaluation step).

[0131] In the model serving step, the AI / ML model is deployed for use in the communication system 1. AI / ML model deployment may comprise compiling a trained AI / ML model, packaging the model into an executable format, and delivering the AI / ML model to a target device. For example, the AI / ML model may be transmitted to the RAN node 5 and / or the UE 3, for use at the RAN node 5 and / or the UE 3 to generate predictions or determinations using the AI / ML model as part of a prediction service step, as illustrated in Fig. 4. In the performance monitoring step, the performance of the deployed AI / ML model is monitored. The predictive performance of the AI / ML model may be monitored by comparing predictions generated using the model with one or more measurements. For example, when the AI / ML model is used to predict a location of a UE 3, the prediction accuracy of the AI / ML model may be assessed using a measurement of an actual location of the UE 3. If the AI / ML model is used for predicting future measurement results (e.g., the measured Reference Signal Received Power (RSRP) of reference signals) at some point in time, the prediction accuracy of the AI / ML model may be assessed using actual measurement results acquired by the UE 3 when that point in time is reached. If the AI / ML model is used for determining parameters for use in encoding and decoding data transmitted between a RAN node 5 and a UE 3, the model may be assessed based on the performance of the encoding and / or decoding processes. In the retraining trigger step, retraining of the AI / ML model is triggered (e.g., because the prediction accuracy of the AI / ML model has fallen below an acceptable threshold accuracy, or because a performance of a method that uses inferences from the AI / ML model has fallen below an acceptable threshold performance), and the method returns to the data extraction step.

[0132] Each step of the method of Fig. 5 may be executed at a single node of the communication system 1 (including at the RAN node 5), or alternatively steps of the method may be distributed between a plurality of different nodes (or indeed one or more of these steps may be performed online or offline).

[0133] As discussed above with reference to Figs. 4 and 5, information collected by nodes / functions in the communication system 1 (e.g., at the UE 3 and / or RAN nodes 5) can be used as training data for an AI / ML model and used as inference data for use in generating one or more model inferences using the AI / ML model. The information used as training data, monitoring data, and / or to generate the one or more model inferences may be referred to as 'AI / ML information' or 'AI / ML data.'

[0134] <Configuration information for AI / ML> 　　Configuration information for an AI / ML model (which may be referred to as "AI / ML configuration information") may be exchanged between nodes in the communication system. For example, a core network node may transmit AI / ML configuration information to a RAN node 5 (or any other entity of the network that supports an AI / ML-based prediction functionality) that hosts an AI / ML model. The AI / ML configuration information may include a list of supported use cases for the AI / ML model (the AI / ML model need not necessarily be for predicting UE mobility). The supported use cases may be, for example: energy saving; traffic steering; anomaly detection; quality of experience (QoE) optimisation; mobility robustness optimisation (MRO); RAN slice service level agreement (SLA) assurance; massive multiple-input multiple-output (MIMO) beamforming optimisation; network slice subnet instance (NSSI) resource allocation; optimisation coverage and capacity optimisation (CCO); mobility load balancing (MLB); RACH optimisation; or UE transmission power optimisation. The AI / ML configuration information may include an indication of a particular AI / ML model to use for a particular use case. The AI / ML configuration information may also include an indication of whether feedback is required (e.g., from another network node). The feedback may include, for example, communication performance feedback (e.g., indicating a communication performance for communication between a UE 3 and a RAN node 5).

[0135] < Minimisation of Drive Test (MDT) Functionality> 　　The UEs 3, RAN nodes 5, CPFs 10, management / OAM functions 14, and TCE 16 of the communication system 1 are also mutually configured, where appropriate, to support the collection, reporting, and analysis minimisation of drive test / tests (MDT) data. The supported functionality includes, for example, the configuration of a UE 3, by a RAN node 5, to perform MDT measurement and reporting, including immediate MDT (I-MDT) type measurement and reporting and logged MDT (L-MDT) measurement and reporting. In particular, the UEs 3, RAN nodes 5, CPFs 10, management / OAM functions 14, and TCE 16 of the communication system 1 are also mutually configured, where appropriate, to support performance of signalling based MDT trace procedures in which the configuration of MDT is towards a specific UE (e.g. based on IMSI, IMEI-SV, etc.), and performance of management based MDT trace procedure (or cell traffic trace procedure).

[0136] <Support for Continuous MDT (C-MDT) Functionality> 　　Beneficially, as described in more detail later, the UEs 3, RAN nodes 5, CPFs 10, management / OAM functions 14, and / or TCE 16 of the communication system 1 are also mutually configured, where appropriate, for implementing one or more mechanisms / techniques for supporting continuous MDT (C-MDT) data collection.

[0137] A number of these possible mechanisms / techniques that may be implemented in the communication system 1 will now be briefly introduced, by way of example only, before a more detailed description of the various mechanisms / techniques is provided.

[0138] It will be appreciated that the communication system 1 need not support all the possible mechanisms / techniques to achieve a technical benefit. For example, the communication system 1 may only support a single one of the mechanisms / techniques described. Nevertheless, the various mechanisms / techniques described are not mutually exclusive and so the communication system 1 may support all, or a subset of the various mechanisms / techniques described to provide a commensurate benefit. For example, some of the mechanisms / techniques may supported as different options that may be used at different times in the communication system 1 depending on circumstance.

[0139] For example, as described in more detail later, the various nodes / equipment / functions of the communication system 1 may, beneficially, be configured (where appropriate) to support one or more OAM / Management centric procedures for efficient C-MDT configuration and associated operation. For example, an OAM / management function 14 may provide a C-MDT configuration (e.g., for a management based C-MDT trace procedure) to a RAN node 5, which can then perform appropriate UE selection for C-MDT collection.

[0140] Alternatively (or additionally) the various nodes / equipment / functions of the communication system 1 may, beneficially, be configured (where appropriate) to support one or more core network centric procedures for efficient C-MDT configuration and associated operation. For example, an OAM / management function 14 may provide the C-MDT configuration to a CPF 10 (such as an AMF 10-1 or similarly functioning CPF 10), and that CPF 10 (e.g., AMF 10-1) may then decide when to provide the C-MDT configuration to the RAN node 5 (e.g., for a signalling based C-MDT trace procedure). In this case the CPF 10 (e.g., AMF 10-1) and / or RAN node 5 can perform appropriate UE selection for C-MDT collection.

[0141] As described in more detail later, beneficially, the UEs 3 and RAN nodes 5 may be mutually configured to support one or more different mechanisms for UE C-MDT data collection and / or reporting. For example, data collection may be configured to occur until the amount of data collected reaches a threshold, until timer has expired, during a specific time window, and / or when a specific data collection event is triggered. In the case of an RRC connected UE 3 the collected data may be reported on data collection completion, or the collected data may be stored until requested. In the case of an RRC idle / inactive UE 3 a RACH procedure may be initiated to report the collected data on data collection completion, or the collected data may be stored until requested.

[0142] As described in more detail later, beneficially, the UEs 3 and RAN nodes 5 may be mutually configured to support one or more different mechanisms for handling mobility scenarios in which the RAN node 5 serving a UE 3 changes (e.g., due to UE mobility) while C-MDT data collection is ongoing (e.g., when a UE 3 in an RRC idle / inactive state (re)selects to a new cell or a UE 3 in an RRC connected state is handed over).

[0143] As described in more detail later, beneficially, the various parts of the distributed RAN node 5-2 may be mutually configured to implement a mechanism for handling C-MDT configuration and UE selection for C-MDT.

[0144] As described in more detail later, beneficially, the RAN nodes 5 may be configured to implement a mechanism for handling C-MDT configuration for a UE 3 in the event that the RAN nodes 5 are configured as a master RAN node and a secondary RAN node for providing dual connectivity to that UE 3.

[0145] As described in more detail later, beneficially, each UE 3 and RAN node 5 may be mutually configured to support a mechanism for informing a RAN node 5 of a capability, of a given UE 3, to perform C-MDT data collection and / or reporting.

[0146] As described in more detail later, the various nodes / equipment / functions of the communication system 1 may, beneficially, be configured (where appropriate) to allow user consent for C-MDT operation of a UE 3 to be taken into proper account for the purposes of C-MDT configuration.

[0147] <OAM / Management Based C-MDT Configuration> 　　As mentioned above, the various nodes / equipment / functions of the communication system 1 may, be configured (where appropriate) to support one or more OAM / Management based procedures for efficient C-MDT configuration and associated operation. Two such procedures will now be described in more detail, by way of example only, with reference to Figs. 6 and 7.

[0148] <Combined C-MDT Configuration> 　　Fig. 6 is a simplified sequence diagram illustrating a first OAM / Management centric procedure for C-MDT configuration and operation that may be implemented in the communication system 1.

[0149] In the example illustrated in Fig. 6 initially, at S602, a management / OAM function 14 sends, to a RAN node 5, a message for configuring C-MDT (e.g., a dedicated C-MDT configuration message, dedicated C-MDT activation message, or the like) that includes a C-MDT configuration. The C-MDT configuration included in the message may, for example, comprise an I-MDT configuration (for use by UEs 3 when in RRC connected) and an L-MDT configuration (for use by UEs 3 when in RRC idle / inactive). The C-MDT configuration may also include configuration information indicating one or more of the following: -　　a 'job type' for indicating the type of MDT that is to be performed - this may, for example, be set to "I-MDT & L-MDT" or "C-MDT" to indicate that continuous MDT measurements are to be performed by the UE 3 across all RRC states; -　　one or more 'trace references' each including a corresponding 'trace ID' (possibly in conjunction with and information identifying a country, and an operator) - for example a single trace reference / trace ID specifically for C-MDT, or separate trace reference / trace IDs for I-MDT and for L-MDT; -　　an area scope - for example information indicating a tracking area (TA), information indicating a cell list, and / or information indicating one or more UEs 3. The information indicating one or more UEs 3 may, for example be in the form of a UE ID list (e.g., of IMSIs / IMEIs), an identifier of specific group of one or more UEs 3 (e.g., a UE group ID), information indicating a UE type, and / or a list of C-MDT specific UE IDs (e.g., a C-MDT UE ID list) (in a case where such C-MDT specific UE IDs are allocated by the management / OAM function 14). A C-MDT specific UE ID may, for example, be a unified UE ID for a specific operator. A C-MDT specific UE ID may, for example, be allocated by the management / OAM function 14, or by an AMF 10-1 (or a differently named core network entity having a similar function to the AMF 10-1) during a UE attach procedure or a C-MDT configuration procedure. Any UE IDs included (whether C-MDT specific or not) may be used by a RAN node 5 for identifying the same UE for C-MDT performed across different RRC states (and potentially under a different RAN node 5) and hance perform associated MDT report correlation; and / or -　　a C-MDT specific reporting trigger, report interval, and / or logging interval.

[0150] At S604, the management / OAM function 14 may send a C-MDT activation message to the RAN node 5. The C-MDT activation message may, for example, include a C-MDT data collection indication to activate C-MDT data collection at the RAN.

[0151] At S606, the RAN node 5 selects one or more specific UEs 3 for performing C-MDT data collection based on, for example, that UE's capability, associated user consent information, area scope, received UE ID list / UE type / UE group ID, and / or the like. More details on how UE capability and user consent may be handled are discussed in more detail later.

[0152] At S608, the RAN node 5 may send the C-MDT configuration (e.g., as received at S602) together with a list of the selected UEs 3 (e.g., as a selected UE ID list) to, in this example, an AMF 10-1. It will be appreciated that whilst an AMF 10-1 is described a differently named core network entity having a similar function to the AMF 10-1 could be used. In a case where the C-MDT UE lDs are allocated by the AMF 10-1, the AMF 10-1 may then map each received UE ID in the list to a corresponding C-MDT UE lD, and send a corresponding C-MDT UE lD list to the RAN node 5 at S610. It will be appreciated that steps S608 and S610 may not be necessary in a case where the management / OAM function 14 allocates the C-MDT UE lDs and sends them to the RAN node 5 at S602.

[0153] At S612, the RAN node 5 respectively configures C-MDT to each selected UE 3 using an appropriate message (that may include the C-MDT UE ID associated with that UE 3 e.g., if the UE 3 is not yet aware of the C-MDT UE ID because it was allocated earlier in the procedure rather than during, for example, an initial attach procedure or the like). The message may, for example, comprise an existing RRC message, such as an RRC (connection) reconfiguration message, which has been extended to allow inclusion of the C-MDT configuration (or at least the L-MDT configuration part of the C-MDT configuration where the RRC message already allows inclusion of an I-MDT configuration). Nevertheless, the message may be a new dedicated (RRC) C-MDT message (e.g., a 'Continuous Measurement Configuration' message or the like) that includes the C-MDT configuration.

[0154] At S614, each configured UE 3 in an RRC connected mode / state may respectively perform I-MDT data collection. At S616, when a given data collection session is completed and / or reporting is triggered at a UE 3 then that UE 3 sends, to the RAN node 5, an associated I-MDT report carrying the collected I-MDT data. The I-MDT report may be a specific 'I-MDT' report or may be a more generic 'C-MDT' report carrying the collected I-MDT data with an accompanying indication that the report is for I-MDT data (e.g., 'I-MDT indication' or the like). The sending of the I-MDT report may, for example, be based on a C-MDT reporting trigger and / or C-MDT reporting interval provided in the C-MDT configuration. A UE 3 that sends such an I-MDT report includes, in that I-MDT report, the corresponding C-MDT UE ID allocated to that UE 3 (thereby beneficially supporting traceability and subsequent MDT report correlation). It will be appreciated that whilst the C-MDT UE ID included in the I-MDT report may be a new ID allocated by a management / OAM function 14 or AMF 10-1, an existing temporary identifier, such as serving temporary mobile subscriber identity (S-TMSI) or the like, may be used (e.g., effectively as the C-MDT UE ID).

[0155] At S618, the RAN node 5 forwards the I-MDT report together with the associated C-MDT UE ID to a TCE 16.

[0156] At S620, each configured UE 3 that will enter an RRC idle / inactive mode / state respectively performs L-MDT data collection during the transition into that RRC inactive / idle mode / state, and after that UE 3 has moved to the RRC idle / inactive mode / state. Then, when a configured UE 3 that has entered the RRC idle / inactive mode / state returns to an RRC connected mode / state at S622 that UE 3 sends, to the RAN node 5 at S624, an associated L-MDT report carrying the collected L-MDT data. The L-MDT report may be a specific 'L-MDT' report or may be a more generic 'C-MDT' report carrying the collected L-MDT data with an accompanying indication that the report is for L-MDT data (e.g., 'L-MDT indication' or the like). The L-MDT report may be configured to include MDT reporting of L-MDT data collected during RRC state transition, and of L-MDT data collected during RRC inactive / idle mode / state, separately. A UE 3 that sends such an L-MDT report includes, in that L-MDT report, the corresponding C-MDT UE ID (possibly S-TMSI) allocated to that UE 3 (thereby beneficially supporting traceability and subsequent MDT report correlation).

[0157] At S626, the RAN node 5 forwards the L-MDT report together with the associated C-MDT UE ID to the TCE 16.

[0158] It will be appreciated that steps S612 through S624 may apply to all UEs 3 selected by the RAN node 5 for C-MDT at S606.

[0159] <Separate Intermediate and Logged MDT Configurations> 　　Fig. 7 is simplified sequence diagram illustrating another OAM / Management centric procedure for C-MDT configuration and operation that may be implemented in the communication system 1.

[0160] In the example illustrated in Fig. 7, unlike the procedure of Fig. 6, the management / OAM function 14 does not send, to a RAN node 5, a single combined message for configuring C-MDT (e.g., a dedicated C-MDT configuration message, dedicated C-MDT activation message, or the like).

[0161] Instead, the management / OAM function 14 sends separate MDT configuration messages for configuring I-MDT data collection (by UEs 3 when in RRC connected) and L-MDT data collection (by UEs 3 when in RRC idle / inactive) respectively (at S702-1, and S702-2). It will be appreciated that these may be sent at any suitable timings and need not be sent in a particular sequence.

[0162] It will be appreciated that these separate I-MDT and L-MDT configurations, in effect, represent a corresponding C-MDT configuration.

[0163] The respective I-MDT and L-MDT configuration messages may, for example, comprise an I-MDT configuration and an L-MDT configuration.

[0164] At S706, the RAN node 5 selects one or more specific UEs 3 for performing C-MDT data collection based on, for example, that UE's capability, associated user consent information, I-MDT area scope, L-MDT area scope, (or combined 'C-MDT' area scope), received UE ID list / UE type / UE group ID, and / or the like. More details on how UE capability and user consent may be handled are discussed in more detail later.

[0165] At S708, the RAN node 5 sends the MDT configurations (e.g., both the I-MDT configuration as received at S702-1 and the L-MDT configuration S702-2), together with a list of the selected UEs (e.g., as a selected UE ID list) to, in this example, an AMF 10-1. It will be appreciated that whilst an AMF 10-1 is described a differently named core network entity having a similar function to the AMF 10-1 could be used. In a case where the C-MDT UE lDs are allocated by the AMF 10-1, the AMF 10-1 may then map each received UE ID in the list to a corresponding C-MDT UE lD, and send a corresponding C-MDT UE lD list to the RAN node 5 at S710. It will be appreciated that steps S708 and S710 may not be necessary in a case where the C-MDT UE lDs are allocated elsewhere (e.g., by the management / OAM function 14).

[0166] At S712, the RAN node 5 respectively sends an appropriate message to each selected UE 3 (that may include the C-MDT UE ID associated with that UE 3) to provide (at least) the I-MDT configuration to that selected UE 3, together with an indication (e.g., a 'C-MDT indication' or the like) that C-MDT data collection is applicable (i.e., that the I-MDT configuration is to be used for C-MDT data collection in the RRC connected state). The message may, for example, comprise an RRC message, such as an RRC (connection) reconfiguration message.

[0167] At S714, each configured UE 3 in an RRC connected mode / state may respectively perform I-MDT data collection. At S716, when a given data collection session is completed and / or reporting is triggered at a UE 3 then that UE 3 sends, to the RAN node 5, an associated I-MDT report carrying the collected I-MDT data. The sending of the I-MDT report may, for example, be based on an associated reporting trigger and / or reporting interval provided in the I-MDT configuration. A UE 3 that sends such an I-MDT report includes, in that I-MDT report, the corresponding C-MDT UE ID (possibly S-TMSI) allocated to that UE 3 (thereby beneficially supporting traceability and subsequent MDT report correlation).

[0168] At S717 the RAN node 5 sends, to the same UE 3 from which it received the I-MDT report sent at S716, an appropriate message (that may include the C-MDT UE ID associated with that UE 3) to provide the L-MDT configuration to that UE 3, together with an indication (e.g., a 'C-MDT indication' or the like) that C-MDT data collection is applicable (i.e., that the L-MDT configuration is to be used for C-MDT data collection in the RRC idle / inactive state). The message may, for example, comprise an RRC message, such as a logged measurement configuration message or the like. It will be appreciated that this message may be sent anytime while a UE 3 is in an RRC connected mode / state and need not be sent at the specific timing shown (e.g., it may be sent before an I-MDT report is received or after an I-MDT report is forwarded to a TCE 16).

[0169] At S718, the RAN node 5 forwards the I-MDT report together with the associated C-MDT UE ID to the TCE 16.

[0170] At S720, each configured UE 3 that will enter an RRC idle / inactive mode / state respectively performs L-MDT data collection during the transition into that RRC inactive / idle mode / state, and after that UE has moved to the RRC idle / inactive mode / state. Then, when a configured UE 3 that has entered the RRC idle / inactive mode / state returns to an RRC connected mode / state at S722, that UE 3 sends, to the RAN node 5 at S724, an associated L-MDT report carrying the collected L-MDT data. The L-MDT report may be configured to include MDT reporting of L-MDT data collected during RRC state transition, and of L-MDT data collected during RRC inactive / idle mode / state, separately. A UE 3 that sends such an L-MDT report includes, in that L-MDT report, the corresponding C-MDT UE ID (possibly S-TMSI) allocated to that UE 3 thereby beneficially supporting traceability and subsequent MDT report correlation.

[0171] At S726, the RAN node 5 forwards the L-MDT report together with the associated C-MDT UE ID to the TCE 16.

[0172] It will be appreciated that steps S712 through S724 may apply to all UEs 3 selected by the RAN node 5 for C-MDT at S706.

[0173] <Core Network / Signalling Based C-MDT Configuration> 　　As mentioned above, t the various nodes / equipment / functions of the communication system 1 may, beneficially, be configured (where appropriate) to support one or more core network centric procedures for efficient C-MDT configuration and associated operation. Two such procedures will now be described in more detail, by way of example only, with reference to Figs. 8, 9A and 9B.

[0174] < Combined C-MDT Configuration> 　　Fig. 8 is a simplified sequence diagram illustrating a core network centric procedure for C-MDT configuration and operation that may be implemented in the communication system 1.

[0175] In the example illustrated in Fig. 8 initially, at S802, a management / OAM function 14 sends, to an AMF 10-1 (or differently named core network entity having a similar function), a message for configuring C-MDT (e.g., a dedicated C-MDT configuration message, dedicated C-MDT activation message, or the like) that includes a C-MDT configuration. The C-MDT configuration included in the message may, for example, comprise an I-MDT configuration (for use by UEs 3 when in RRC connected) and an L-MDT configuration (for use by UEs 3 when in RRC idle / inactive). The C-MDT configuration may also include configuration information indicating one or more of the following: -　　a 'job type' for indicating the type of MDT that is to be performed - this may, for example, be set to "I-MDT & L-MDT" or "C-MDT" to indicate that continuous MDT measurements are to be performed by the UE across all RRC states; -　　one or more 'trace references' each including a corresponding 'trace ID' (possibly in conjunction with and information identifying a country, and an operator) - for example a single trace reference / trace ID specifically for C-MDT, or separate trace reference / trace IDs for I-MDT and for L-MDT; -　　an area scope - for example information indicating a tracking area (TA), information indicating a cell list, and / or information indicating one or more UEs 3. The information indicating one or more UEs 3 may, for example be in the form of a UE ID list (e.g., of IMSIs / IMEIs), an identifier of specific group of one or more UEs 3 (e.g., a UE group ID), and / or information indicating a UE type; and / or -　　a C-MDT specific reporting trigger, report interval, and / or logging interval.

[0176] At S803,the AMF 10-1 may select one or more specific UEs 3 for performing C-MDT data collection based on, for example, that UE's capability, associated user consent information, area scope, received UE ID list / UE type / UE group ID, and / or the like. More details on how UE capability and user consent may be handled are discussed in more detail later.

[0177] At S804, the AMF 10-1 maps each UE ID to in the list to a corresponding C-MDT UE lD. It will be appreciated that the UE IDs that are mapped may be for all the UEs 3 indicated in the C-MDT configuration, or may be for a subset of those UEs 3 (e.g., the UEs 3 selected by the AMF 10-1 at S803 if such a selection is made). It will also be appreciated that the　　AMF 10-1 may generate a C-MDT UE ID after receiving the C-MDT configuration from the management / OAM function 14 at S802, or during a respective UE attach procedure for each UE 3 (the C-MDT UE ID may be stored in a UE context for each UE 3).

[0178] At S805, the AMF 10-1 sends a message (e.g., a 'C-MDT configuration message') to the RAN node 5 including the C-MDT configuration provided by the management / OAM function 14 at S802. The AMF 10-1 may include in that C-MDT configuration message, a list of UE IDs (e.g., for UEs 3 indicated by the management / OAM function 14 at S802, or selected by the AMF 10-1 at S803) and a list of associated assigned C-MDT UE IDs. It will be appreciated that the C-MDT configuration message may be sent to each RAN node 5 in a tracking area (or RAN-based notification area (RNA)) of the (indicated or selected) UEs 3.

[0179] At S806, the RAN node 5 may select one or more specific UEs 3 for performing C-MDT data collection based on, for example, that UE's capability, associated user consent information, area scope, received UE ID list / UE type / UE group ID, and / or the like. More details on how UE capability and user consent may be handled are discussed in more detail later. It will be appreciated that this selection may not happen if the AMF 10-1 has made the selection at S803. Nevertheless, the RAN node 5 may select a subset of one or more specific UEs 3 for performing C-MDT data collection that were selected by the AMF 10-1 at S803.

[0180] At S812, the RAN node 5 respectively configures C-MDT to each selected UE 3 using an appropriate message (that may include the C-MDT UE ID associated with that UE 3). The message may, for example, comprise an existing RRC message, such as an RRC (connection) reconfiguration message, which has been extended to allow inclusion of the C-MDT configuration (or at least the L-MDT configuration part of the C-MDT configuration where the RRC message already allows inclusion of an I-MDT configuration). Nevertheless, the message may be a new dedicated (RRC) C-MDT message (e.g., a 'Continuous Measurement Configuration' message or the like) that includes the C-MDT configuration.

[0181] At S814, each configured UE 3 in an RRC connected mode / state may respectively perform I-MDT data collection. At S816, when a given data collection session is completed and / or reporting is triggered at a UE 3 then that UE 3 sends, to the RAN node 5, an associated I-MDT report carrying the collected I-MDT data. The I-MDT report may be a specific 'I-MDT' report or may be a more generic 'C-MDT' report carrying the collected I-MDT data with an accompanying indication that the report is for I-MDT data (e.g., 'I-MDT indication' or the like). The sending of the I-MDT report may, for example, be based on a C-MDT reporting trigger and / or C-MDT reporting interval provided in the C-MDT configuration. A UE 3 that sends such an I-MDT report includes, in that I-MDT report, the corresponding C-MDT UE ID (possibly S-TMSI) allocated to that UE 3 (thereby beneficially supporting traceability and subsequent MDT report correlation).

[0182] At S818, the RAN node 5 forwards the I-MDT report together with the associated C-MDT UE ID to a TCE 16.

[0183] At S820, each configured UE 3 that will enter an RRC idle / inactive mode / state respectively performs L-MDT data collection during the transition into that RRC inactive / idle mode / state, and after that UE 3 has moved to the RRC idle / inactive mode / state. Then, when a configured UE 3 that has entered the RRC idle / inactive mode / state returns to an RRC connected mode / state at S822 that UE 3 sends, to the RAN node 5 at S824, an associated L-MDT report carrying the collected L-MDT data. The L-MDT report may be a specific 'L-MDT' report or may be a more generic 'C-MDT' report carrying the collected L-MDT data with an accompanying indication that the report is for L-MDT data (e.g., 'L-MDT indication' or the like). The L-MDT report may be configured to include MDT reporting of L-MDT data collected during RRC state transition, and of L-MDT data collected during RRC inactive / idle mode / state, separately. A UE 3 that sends such an L-MDT report includes, in that L-MDT report, the corresponding C-MDT UE ID (possibly S-TMSI) allocated to that UE 3 (thereby beneficially supporting traceability and subsequent MDT report correlation).

[0184] At S826, the RAN node 5 forwards the L-MDT report together with the associated C-MDT UE ID to the TCE 16.

[0185] It will be appreciated that steps S812 through S824 may apply to all UEs 3 selected by the AMF 10-1 and / or the RAN node 5 for C-MDT.

[0186] <Separate Intermediate and Logged MDT Configurations> 　　Figs. 9A and 9B are respective parts of a simplified sequence diagram illustrating another core network centric procedure for C-MDT configuration and operation that may be implemented in the communication system 1.

[0187] Referring firstly to Fig. 9A, in this example, unlike the procedure of Fig. 8, the management / OAM function 14 does not send, to an AMF 10-1 (or differently named core network entity having a similar function), a single combined message for configuring C-MDT (e.g., a dedicated C-MDT configuration message, dedicated C-MDT activation message, or the like).

[0188] Instead, the management / OAM function 14 sends separate MDT configuration messages for configuring I-MDT data collection (by UEs 3 when in RRC connected) and L-MDT data collection (by UEs 3 when in RRC idle / inactive) respectively (at S802-1, and S802-2)

[0189] It will be appreciated that these separate I-MDT and L-MDT configurations, in effect, represent a corresponding C-MDT configuration.

[0190] The respective I-MDT and L-MDT configuration messages may, for example, comprise an I-MDT configuration and an L-MDT configuration.

[0191] At S903,the AMF 10-1 may select one or more specific UEs 3 for performing C-MDT data collection based on, for example, that UE's capability, associated user consent information, area scope, received UE ID list / UE type / UE group ID, and / or the like. More details on how UE capability and user consent may be handled are discussed in more detail later.

[0192] At S904, the AMF 10-1 maps each UE ID to in the list to a corresponding C-MDT UE lD. It will be appreciated that the UE IDs that are mapped may be for all the UEs 3 indicated in the I-MDT and / or L-MDT configurations, or may be for a subset of those UEs 3 (e.g., the UEs 3 selected by the AMF 10-1 at S903 if such a selection is made). It will also be appreciated that the AMF 10-1 may generate a C-MDT UE ID after receiving the I-MDT / L-MDT configuration from the management / OAM function 14 at S902-1 / S902-2, or during a respective UE attach procedure for each UE (the C-MDT UE ID may be stored in a UE context for each UE 3).

[0193] The AMF 10-1 may then send one or more messages to the RAN node 5 for configuring C-MDT data collection.

[0194] For example, the AMF 10-1 may send separate MDT configuration messages for providing an I-MDT configuration (and associated UE ID list) as indicated at S905-1, and for providing an I-MDT configuration (and associated UE ID list) as indicated at S905-2. The AMF 10-1 may also send, at S905-3, a further message (e.g., a 'C-MDT configuration message') to the RAN node 5 including a list of UE IDs (e.g., for UEs indicated by the management / OAM function 14 at S902-1 / S902-2, or selected by the AMF 10-1 at S903) and a list of associated assigned C-MDT UE IDs.

[0195] Nevertheless, rather than send separate configuration messages, the AMF 10-1 may send a single message (e.g., a 'C-MDT configuration message') to the RAN node 5 (as seen at S905-4) including both the I-MDT and the L-MDT configurations provided by the management / OAM function 14 at S902-1 / S902-2. The AMF 10-1 may include in that C-MDT configuration message, a list of UE IDs (e.g., for UEs 3 indicated by the management / OAM function 14 at S902-1 / S902-2, or selected by the AMF 10-1 at S903) and a list of associated assigned C-MDT UE IDs.

[0196] It will be appreciated that regardless of whether separate configuration messages are sent, or a single configuration message is sent, each configuration message may be respectively sent to every RAN node 5 in a tracking area (or RAN-based notification area (RNA)) of the (indicated or selected) UEs 3.

[0197] At S906, the RAN node 5 may select one or more specific UEs 3 for performing C-MDT data collection based on, for example, that UE's capability, associated user consent information, area scope, received UE ID list / UE type / UE group ID, and / or the like. More details on how UE capability and user consent may be handled are discussed in more detail later. It will be appreciated that this selection may not happen if the AMF 10-1 has made the selection at S903. Nevertheless, the RAN node 5 may select a subset of one or more specific UEs 3 for performing C-MDT data collection that were selected by the AMF 10-1 at S903.

[0198] Turning to Fig. 9B, at S912, the RAN node 5 respectively sends an appropriate message to each selected UE 3 (that may include the C-MDT UE ID associated with that UE 3) to provide (at least) the I-MDT configuration to that selected UE 3, together with an indication (e.g., a 'C-MDT indication' or the like) that C-MDT data collection is applicable (i.e., that the I-MDT configuration is to be used for C-MDT data collection in the RRC connected state). The message may, for example, comprise an existing RRC message, such as an RRC (connection) reconfiguration message.

[0199] At S914, each configured UE 3 in an RRC connected mode / state may respectively perform I-MDT data collection. At S916, when a given data collection session is completed and / or reporting is triggered at a UE 3 then that UE 3 sends, to the RAN node 5, an associated I-MDT report carrying the collected I-MDT data. The sending of the I-MDT report may, for example, be based on an associated reporting trigger and / or reporting interval provided in the I-MDT configuration. A UE 3 that sends such an I-MDT report includes, in that I-MDT report, the corresponding C-MDT UE ID (possibly S-TMSI) allocated to that UE (thereby beneficially supporting traceability and subsequent MDT report correlation).

[0200] At S917 the RAN node 5 sends, to the same UE 3 from which it received the I-MDT report sent at S916, an appropriate message (that may include the C-MDT UE ID associated with that UE 3) to provide the L-MDT configuration to that UE 3, together with an indication (e.g., a 'C-MDT indication' or the like) that C-MDT data collection is applicable (i.e., that the L-MDT configuration is to be used for C-MDT data collection in the RRC idle / inactive state). The message may, for example, comprise an RRC message, such as a logged measurement configuration message or the like. It will be appreciated that this message may be sent anytime while a UE is in an RRC connected mode / state and need not be sent at the specific timing shown (e.g., it may be sent before an I-MDT report is received or after an I-MDT report is forwarded to a TCE 16).

[0201] At S918, the RAN node 5 forwards the I-MDT report together with the associated C-MDT UE ID to the TCE 16.

[0202] At S920, each configured UE 3 that will enter an RRC idle / inactive mode / state respectively performs L-MDT data collection during the transition into that RRC inactive / idle mode / state, and after that UE has moved to the RRC idle / inactive mode / state. Then, when a configured UE 3 that has entered the RRC idle / inactive mode / state returns to an RRC connected mode / state at S922, that UE 3 sends, to the RAN node 5 at S924, an associated L-MDT report carrying the collected L-MDT data. The L-MDT report may be configured to include MDT reporting of L-MDT data collected during RRC state transition, and of L-MDT data collected during RRC inactive / idle mode / state, separately. A UE 3 that sends such an L-MDT report includes, in that L-MDT report, the corresponding C-MDT UE ID allocated to that UE (possibly S-TMSI) thereby beneficially supporting traceability and subsequent MDT report correlation.

[0203] At S926, the RAN node 5 forwards the L-MDT report together with the associated C-MDT UE ID to the TCE 16.

[0204] It will be appreciated that steps S912 through S924 may apply to all UEs 3 selected by the RAN node 5 for C-MDT at S906.

[0205] <UE Continuous MDT data collection and reporting> 　　As mentioned above, the UEs 3 and RAN nodes 5 may be mutually configured to support one or more different mechanisms for UE C-MDT data collection and / or reporting.

[0206] A number of different ways in which a UE 3 may be configured for C-MDT data collection and / or reporting will now be described in more detail by way of example only.

[0207] For example, a UE C-MDT configuration may provide the UE 3 with one or more data size / memory thresholds for corresponding storage of the MDT data collected by that UE 3 during an RRC connected mode / state, and / or an RRC idle / inactive mode / state. For example, a memory size threshold and / or a threshold representing a number of measurement entries may be configured.

[0208] Alternatively (or additionally) the UE C-MDT configuration may provide the UE 3 with information defining a C-MDT data collection time window and / or or a C-MDT data collection timer.

[0209] Alternatively (or additionally) the UE C-MDT configuration may provide the UE 3 with information defining a specific event the occurrence of which may trigger data collection (e.g. an event indicative of the UE 3 experiencing poor wireless signal quality, or an event indicative of the UE 3 experiencing a radio link failure).

[0210] In a case where a configured C-MDT data collection timer or C-MDT data collection time window is configured and / or in a case where the data collected during the configured C-MDT logging is greater than (or possibly equal to) a configured data size / memory threshold (e.g. in terms of a memory size used, and / or a number of measurement entries collected), then: -　　A UE 3 in an RRC connected mode / state may report the C-MDT data collected to the RAN node 5 as soon as (just after) the data collection has completed (e.g., as indicated by a configured time window completing, a configured timer expiring, and / or a configured threshold being reached / exceeded). Alternatively, the UE 3 may simply store the C-MDT data collected until the data is requested by the RAN node 5 (e.g., using an on-demand data report request or the like). -　　A UE 3 in an RRC idle / inactive mode / state may initiate a random access (RACH) procedure to connect to the RAN node 5 for the purpose of providing a C-MDT data report including the collected data as soon as (just after) the data collection has completed (e.g., as indicated by a configured time window completing, a configured timer expiring, and / or a configured threshold being reached / exceeded). Alternatively, the UE 3 may simply store the C-MDT data collected until an appropriate paging message is received from the RAN node 5 (e.g., with a paging cause value (or the like) being set to indicate that the paging is for the purposes of requesting an on-demand report of collected C-MDT data).

[0211] It will be appreciated that collected C-MDT data may be reported by a UE 3 in a number of different reporting methods. It will be appreciated that different UEs 3 may be capable of reporting C-MDT data in accordance with one or more of these reporting methods. For example, a UE 3 may report C-MDT data in accordance a different one of these methods at different times.

[0212] A UE 3 may, for example, be configured to be able to send a full report of collected C-MDT data that is stored in the memory of that UE 3.

[0213] A UE 3 may alternatively (or additionally) be configured to be able to send only part of the collected C-MDT data stored in the memory of that UE 3. In this case, the UE 3 may also be configured to send an indication indicating that there is still C-MDT data remaining. Such an indication of remaining MDT data may comprise (or may be sent with a separate) indication of the amount / volume of the remaining C-MDT data.

[0214] A UE 3 may alternatively (or additionally) be configured to be able to send an indication of the availability of a full C-MDT data report and / or a data volume for the full C-MDT data report. Based on receipt of such an indication a RAN node 5 may allocate / schedule appropriate resources for the UE 3 to send that C-MDT data report.

[0215] <C-MDT - Mobility Considerations> 　　As mentioned above, the UEs 3 and RAN nodes 5 may be mutually configured to support one or more different mechanisms for handling mobility scenarios in which the RAN node serving a UE changes (e.g., due to UE mobility) while C-MDT data collection is ongoing (e.g., when a UE 3 in an RRC idle / inactive state (re)selects to a new cell or a UE 3 in an RRC connected state is handed over). A number of different ways for handling mobility will now be described in more detail by way of example only.

[0216] <C-MDT Handling in Idle / Inactive Mode Mobility Scenarios> 　　Fig. 10 is a simplified sequence diagram illustrating a UE centric procedure for handling C-MDT data collection and configuration in the context of mobility that may be implemented in the communication system 1.

[0217] It will be appreciated that this procedure may be used when a RAN node 5 that provides a C-MDT configuration to the UE 3 before the UE 3 enters an RRC idle / inactive mode / state is different to a RAN node 5 that the UE 3 later connects to when it exits that RRC idle / inactive mode / state.

[0218] As seen in Fig. 10, at S1017 a first RAN node 5Sconfigures the UE 3 with a C-MDT configuration including at least an L-MDT configuration (e.g., together with a C-MDT indication) and a C-MDT UE ID (e.g., as assigned by an AMF 10-1 during one of the procedures described with reference to Figs. 6 to 9). The message may, for example, comprise an RRC message, such as an RRC (connection) reconfiguration message. The message may, for example, correspond to the message sent at S612, S717, S812, or S917 in Figs. 6, 7, 8, or 9b respectively.

[0219] At S1020 the UE 3 may begin to transition to an RRC idle / inactive mode / state and performs L-MDT data collection during the transition into that RRC inactive / idle mode / state, and after that UE has moved to the RRC idle / inactive mode / state.

[0220] Then, if the UE 3 returns to an RRC connected mode / state at S1022 with a second RAN node 5T(rather than the first RAN node 5S), the UE 3 sends to the second RAN node 5T, at S1023, in indication of C-MDT availability in an appropriate (RRC) message (e.g., in an RRC setup complete message or the like).

[0221] The second RAN node 5Tretrieves, at S1024, the L-MDT data collected by the UE 3, together with the associated C-MDT UE ID. The retrieved L-MDT report may include L-MDT data collected during RRC state transition, and L-MDT data collected during RRC inactive / idle mode / state, separately. The second RAN node 5Tcan then send the retrieved L-MDT report (for C-MDT), together with the C-MDT UE ID, to a TCE 16 (as seen at S1026). Thus the TCE 16 can correlate the C-MDT (I-MDT / L-MDT) data collected by the UE 3 when being served by different RAN nodes 5.

[0222] The second RAN node 5Tcan also provide, at S1028, the same UE 3 with an I-MDT configuration for continued C-MDT data collection in the RRC connected mode / state.

[0223] <C-MDT Handling in Handover Mobility Scenarios> 　　It will be appreciated that the scenario covered by the procedure described with reference to Fig. 10 is not the only mobility scenario that may occur. Another mobility scenario that may occur is a handover scenario (e.g., a handover as described with reference to Fig. 2 or Fig. 3).

[0224] <RAN Centric C-MDT Handling in Handover Scenario> 　　To cater for such a handover scenario, a C-MDT indication may be sent from source RAN node 5Sto the target RAN node 5T(shown in Fig. 2 or Fig. 3) to inform the target RAN node 5T(or candidate RAN node 5T) that the UE 3 has been selected for C-MDT collection. This indication may, for example, be included in a handover request (e.g., a handover request as sent at S210 in Fig. 2, or a handover request as sent at S304 in Fig. 3).

[0225] Accordingly, the target RAN node 5T(or candidate RAN node 5T) is able to know to configure I-MDT / C-MDT to that UE 3 after that UE 3 has completed the handover to the target RAN node 5T(or candidate RAN node 5T).

[0226] < UE Centric C-MDT Handling in Handover Scenario> 　　It will also be appreciated that whilst the UE centric procedure of Fig. 10 is described in the context of a change of serving RAN node 5Sthat occurs while a UE 3 is in an RRC idle / inactive mode / state, a UE centric procedure may also be used in a handover scenario. For example, during a handover procedure, when or after the UE 3 connects to the target RAN node 5T, the UE 3 may send an appropriate message (e.g., the RRC reconfiguration complete message or a new C-MDT indication message) including a C-MDT indication, to the target RAN node 5T.

[0227] <C-MDT configuration Handling by Distributed RAN> 　　As mentioned above, the various parts of the distributed RAN node 5-2 may be mutually configured to implement a mechanism for handling C-MDT configuration and UE selection for C-MDT.

[0228] A method of handling C-MDT configuration and UE selection for C-MDT in a distributed RAN 5-2 will now be described in more detail by way of example only with reference to Fig. 11. Fig. 11 is a simplified sequence diagram illustrating a procedure for handling C-MDT configuration within the distributed RAN node 5-2 that may be implemented in the communication system 1.

[0229] In the procedure of Fig. 11 the distributed RAN node 5-2 comprises a CU 5-2CUand a DU 5-2DU. The CU 5-2CUemploys a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP 5-2CU-CP) and a user plane function (CU-UP 5-2CU-UP) which respectively communicate, with the DU 5-2DUvia a first interface (e.g., an F1-C logical interface) and a second interface (e.g., an F1-C logical interface) which, collectively, form a combined interface (e.g., an F1 logical interface).

[0230] Referring to Fig. 11, when one or more messages defining a C-MDT configuration are provided to the distributed RAN node 5-2 that C-MDT configuration is received by the control plane function 5-2CU-CP, of the CU 5-2CU, of the distributed RAN node 5-2. The one or more messages defining a C-MDT configuration may, for example, be received from the management / OAM function 14 (e.g., as seen at S602 in Fig. 6 or at S702-1 and S702-2 in Fig. 7) or from the AMF 10-1 (e.g., as seen at S805 in Fig. 8 or at S905-1 to S905-3, or S905-4 in Fig. 9).

[0231] The control plane function 5-2CU-CPthen sends the C-MDT configuration to the user plane function 5-2CU-UP, of the CU 5-2CU, of the distributed RAN node 5-2 (at S1102), and to the DU 5-2DU, of the distributed RAN node 5-2 (at S1104), for the purposes of supporting C-MDT data collection. The C-MDT configuration may, for example, be forwarded as a single message including the I-MDT and L-MDT configurations together with the associated UE ID list. It will be appreciated that this forwarding to the user plane function 5-2CU-UPand the DU 5-2DUmay occur at substantially the same time, or at different times, and may occur in any appropriate sequence.

[0232] As seen at S1106, the control plane function 5-2CU-CPis responsible for performing any selection, at the distributed RAN node 5-2, of UEs for C-MDT (e.g., UE selection as shown at S606, S706, S806, or S906 in Figs. 6, 7, 8, and 9a respectively). As seen at S1112, the control plane function 5-2CU-CPis also responsible for providing the associated C-MDT configuration (e.g., the I-MDT and L-MDT data collection configurations for C-MDT) to each selected UE 3. I will be appreciated that this provision of the associated C-MDT configuration by the distributed RAN node 5-2 may occur at S612, S712, S812, or S912 in Figs. 6, 7, 8, and 9b respectively.

[0233] <C-MDT configuration Handling in Dual Connectivity Scenarios> 　　As mentioned above, the RAN nodes 5 may be configured to implement a mechanism for handling C-MDT configuration for a UE 3 in the event that the RAN nodes 5 are configured as a master RAN node and a secondary RAN node for providing dual connectivity to that UE 3.

[0234] Specifically, when one or more messages defining a C-MDT configuration, that is applicable to both a master node and a secondary node for dual connectivity purposes, are provided to a RAN node 5 that is configured as a master node for a dual connectivity scenario, that RAN node 5 may forward the C-MDT configuration to a RAN node 5 that is configured as a secondary node for that dual connectivity scenario. The one or more messages defining a C-MDT configuration may, for example, be received from the AMF 10-1 (e.g., as seen at S805 in Fig. 8 or at S905-1 to S905-3, or S905-4 in Fig. 9).

[0235] < UE Capability Considerations > 　　As mentioned above, each UE 3 and RAN node 5 may be mutually configured to support a mechanism for informing a RAN node 5 of a capability, of a given UE 3, to perform C-MDT data collection and / or reporting. Specifically, it may be optional for a UE 3 to have a capability to support C-MDT and so it would be beneficial for a RAN node 5 to be able to ascertain whether a given UE 3 has the capability to support C-MDT.

[0236] A method for informing a RAN node 5 of a capability, of a given UE 3, to perform C-MDT data collection and / or reporting will now be described in more detail by way of example only with reference to Fig. 12. Fig. 12 is a simplified sequence diagram illustrating a procedure for providing UE capability information that may be implemented in the communication system 1.

[0237] As seen at S1202, the RAN node 5 may send a UE capability enquiry to the UE 3 including a UE capability request (this may be a request for the capabilities of the UE in general or a specific request in relation to the capability of the UE 3 to support C-MDT).

[0238] At S1204, the UE 3 responds with UE capability information including UE C-MDT capability information. The UE capability information may, for example, include an indication of whether the UE supports C-MDT. The UE capability information may also include (where C-MDT is supported) include an indication of a UE memory size (e.g., of the memory available for C-MDT data) and / or (if applicable) any applicable energy saving (ES) requirement.

[0239] An Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element that may be used for C-MDT capability in UE capability information is provided below (by way of example only): UE-CMDT-Capability ::= SEQUENCE { 　　cmdt-support　　　　　　Cmdt-support 　 ue-memory-size　　　　　　Ue-memroy-size　　　　OPTIONAL 　　Es-requirement　　　　　　 es-requirement　　　　OPTIONAL

[0240] It will be appreciated that a RAN node 5 may use the C-MDT capability information provided by multiple UEs 3 for performing UE selection for C-MDT based on UE capability (e.g., UE selection as shown at S606, S706, S806, or S906 in Figs. 6, 7, 8, and 9a respectively).

[0241] <User Consent Considerations> 　　As mentioned above, the various nodes / equipment / functions of the communication system 1 may be configured to allow user consent for C-MDT operation of a UE 3 to be taken into account for the purposes of C-MDT configuration.

[0242] There are a number of different ways in which user consent may be used in respect of C-MDT (and / or related) operation. For example user consent may be applicable for specific use cases or for specific UE measurements for C-MDT collection. A few of the different ways in which user consent may be applied are as follows: -　　A single C-MDT user consent may be supported that may be used by a user to consent for C-MDT data collection; -　　A plurality of different user consents may be supported, for example a different respective user consent for each of a plurality of different levels / amounts of data collection volume to which a user may consent. Similarly, a different user consent may be applicable for different data collection purposes, a different user consent may be applicable for AI / ML model training, a different user consent may be applicable for performance monitoring for an AI / ML model, etc. -　　Explicit user consent for C-MDT data collection or the like may not be needed when configuring C-MDT or selecting UEs 3 for C-MDT. Instead, it may be assumed that a user can provide user consent for C-MDT data collection as part of an associated subscription to a given mobile operator. The AMF 10-1 may then obtain this user consent in respect of a given UE 3 from a user subscription database, and use this information to determine and select the suitable UE(s) 3 for C-MDT based data collection. -　　An implicit user consent may be used for C-MDT data collection. For example, user consent may be assumed based on user consent associated with other use cases e.g., user consent associated with another MDT data collection method.

[0243] One way in which a RAN node 5 may manage user consent considerations will now be described by way of example only with reference to Fig. 13. Fig. 13 is a simplified sequence diagram illustrating a procedure for handling user consent information that may be implemented in the communication system 1.

[0244] As seen in Fig. 13, in this example, the AMF 10-1 obtains user consent status for each UE 3 from a unified data management function (UDM) 10-3 and then stores this user consent status for each UE 3 in local subscriber database (at S1302). For example, when a UE 3 attaches to the network, the UDM 10-3 may forward the user consent information, stored in a UDM database, to a corresponding AMF 10-1. When the AMF 10-1 receives the user consent information it may store that information in a subscriber database of the AMF 10-1.

[0245] Then, as seen at S1304, during a UE context setup procedure (e.g. in an initial context setup request message for that UE 3) the AMF 10-1 may send, to the RAN node 5, a C-MDT allowed indication based on the user consent to indicate whether C-MDT is allowed to be configured, by the RAN node 5, for that UE. Optionally the message may include a C-MDT public land mobile network (PLMN) list. The RAN node 5 may respond appropriately (e.g., with an initial context setup response message) as seen at S1306.

[0246] The RAN node 5 and / or AMF 10-1 may thus take account of the user consent (e.g., based on C-MDT allowed indication or user consent information stored at the AMF 10-1) when selecting UEs for C-MDT.

[0247] During a handover procedure for a given UE 3 (e.g., a handover procedure as described with reference to Fig. 2 or Fig. 3), a source RAN node 5Smay inform a target (or candidate) RAN node 5Tof the C-MDT allowed indication (and optional C-MDT PLMN list) for that UE 3.

[0248] <Devices of the Communication System> <User Equipment> 　　Fig. 14 is a schematic block diagram illustrating the main components of a UE 3 that may be used in the communication system 1.

[0249] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0250] The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communications control module 43.

[0251] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5-1 (and other communication devices connected to the RAN node 5-1, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communications via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communications via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

[0252] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0253] The communication control module 43 is configured, in particular, to control the UE's communications, where applicable, in accordance with any of the methods described herein.

[0254] <RAN node (non-distributed)> 　　Fig. 15 is a schematic block diagram illustrating the main components of a (non-distributed) RAN node 5-1 that may be used in the communication system 1.

[0255] As shown, the RAN node 5-1 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g., a single or multi-panel antenna array / massive antenna), and for transmitting signals to and for receiving signals from network nodes in the core network 7 via a core network interface 55 (e.g., comprising the N2, N3 and other reference points / interfaces).

[0256] Although not shown, the RAN node 5-1 may also be coupled to other RAN nodes via an appropriate interface (e.g., the so-called 'Xn' interface in NR). The RAN node 5-1 has a controller 57 to control the operation of the RAN node 5-1. The controller 57 is configured to control the overall operation of the RAN node 5-1 by, in this example, program instructions or software instructions stored within memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0257] As shown, these software instructions include, among other things, an operating system 61, and a communications control module 63.

[0258] The communications control module 63 is operable to control the communication between the RAN node 5-1 and UEs 3 and other network entities that are connected to the RAN node 5-1. The communications control module 63 is configured for the overall control of the reception and decoding of uplink communications, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 63 is also configured for the overall handling the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communications control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0259] It will be appreciated that the communications control module 63 may include a number of sub-modules (or 'layers') to support specific functionalities. For example, the communications control module 63 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc.

[0260] The communication control module 63 is configured, in particular, to control the RAN Node's communications, where applicable, in accordance with any of the methods described herein.

[0261] <RAN node (distributed)> 　　Fig. 16 is a simplified block schematic illustrating the main components of a distributed RAN node 5-2 comprising a distributed type of base station that may be used in the communication system 1.

[0262] As shown, the RAN node 5-2 includes a central unit (RAN node CU) 5-2CUand a distributed unit (RAN node DU) 5-2DU(although it may include other RAN node DUs 5-2DUas described above). Each unit 5-2CU, 5-2DUincludes respective transceiver circuitry 51c, 51d.

[0263] The transceiver circuitry 51d of the distributed unit 5-2DUis operable to transmit signals to and to receive signals from UEs 3 via an air interface 53d and one or more antennas and is also operable to transmit signals to and to receive signals from the central unit 5-2CUvia an interface, for example the distributed unit side of an F1 interface (which may be provided over a satellite radio interface).

[0264] The transceiver circuitry 51c of the central unit 5-2CUis operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RAN nodes via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network and a RAN node to RAN node (e.g., Xn) interface for communicating with other RAN nodes 5. The transceiver circuitry 51c of the central unit 5-2CUis also operable to transmit signals to and to receive signals from one or more distributed units 5-2DU, for example the central unit side of the F1 interface provided.

[0265] Each unit 5-2CU, 5-2DUincludes a respective controller 57c, 57d which controls the operation of the corresponding transceiver circuitry 51c, 51d in accordance with software stored in the respective memories 59c and 59d of the central unit 5-2CUand the distributed unit 5-2CU. The software of each unit may be pre-installed in the memory 59c, 59d and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software of each unit includes, among other things, a respective operating system 61c, 61d, and a respective communications control module 63c, 63d.

[0266] Each communications control module 63c, 63d is operable to control the communication of its corresponding unit 5-2CU, 5-2DUincluding the communication from one unit to the other. The communications control module 63d of the distributed unit 5-2DUcontrols communication between the distributed unit 5-2DUand the UEs 3, and the communications control module 63c of the central unit 5-2CUcontrols communication between the central unit 5-2CUand other network entities that are connected to the distributed RAN node 5-2.

[0267] The communications control modules 63c, 63d also respectively control the part played by the central unit 5-2CUand distributed unit 5-2DUin the flow of uplink and downlink user traffic and control data to be received from and transmitted to the communications devices served by the RAN node 5-2 including, for example, control data for managing operation of the UEs 3. Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin the reception and decoding of uplink communications, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin the overall handling the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0268] It will be appreciated that each communication control module 63c, 63d may include a number of sub-modules (or 'layers') to support specific functionalities supported by the by the central unit 5-2CUand distributed unit 5-2DU. For example, a communications PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc may be distributed between the central unit 5-2CUand distributed unit 5-2DUappropriately depending on where the functional split is configured between the central unit 5-2CUand distributed unit 5-2DU.

[0269] Each communication control module 63c, 63d is configured, in particular, to control the respective communications of the central unit 5-2CUand distributed unit 5-2DU, where applicable, in accordance with any of the methods described herein.

[0270] <Core Network Function> 　　Fig.17 is a schematic block diagram illustrating the main components of a core network control plane node / function 10 that may be used in the communication system 1.

[0271] As shown, the control plane node / function 10 has a transceiver circuit 71 for transmitting signals to and for receiving signals from nodes of the communication system 1 (such as OAM / management functions 14, other nodes / functions of the core network 7, and / or RAN nodes 5) via one or more network interfaces 72.

[0272] The control plane node / function 10 has a controller 73 to control the operation of the control plane node / function 10 in accordance with the specific functions that that control plane node / function 10 is required to provide (e.g., when operating as an AMF 10-1, SMF 10-2, UDM 11, AUSF, PCF, AF, SEAF, ARPF, and / or the like). The controller 73 is configured to control the overall operation of the control plane node / function 10 by, in this example, program instructions or software instructions stored within memory 74. Software may, for example, be pre-installed in the memory 74 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD). As shown, these software instructions include, among other things, an operating system 75, and a communications control module 76.

[0273] The communications control module 76 is operable to control the communication between the control plane node / function 10 and other network entities. The communication control module 76 is configured, in particular, to control the communication of the control plane node / function 10, where applicable, in accordance with any of the methods described herein.

[0274] <Management / OAM Function> 　　Fig. 18 is a schematic block diagram illustrating the main components of a management / OAM function 14 that may be used in the communication system 1.

[0275] As shown, the management / OAM function 14 has a transceiver circuit 81 for transmitting signals to and for receiving signals from nodes of the communication system 1 (such as nodes / functions of the core network 7, and / or RAN nodes 5) via one or more network interfaces 82.

[0276] The management / OAM function 14 has a controller 83 to control the operation of the management / OAM function 14. The controller 83 is configured to control the overall operation of the management / OAM function 14 by, in this example, program instructions or software instructions stored within memory 84. Software may, for example, be pre-installed in the memory 84 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD). As shown, these software instructions include, among other things, an operating system 85, and a communications control module 86.

[0277] The communications control module 86 is operable to control the communication between the management / OAM function 14 and other network entities. The communication control module 86 is configured, in particular, to control the communication of the management / OAM function 14, where applicable, in accordance with any of the methods described herein.

[0278] <Trace Collection Entity> 　　Fig. 19 is a schematic block diagram illustrating the main components of a TCE 16 that may be used in the communication system 1.

[0279] As shown, the TCE 16 has a transceiver circuit 91 for transmitting signals to and for receiving signals from nodes of the communication system 1 (such as RAN nodes 5) via one or more network interfaces 92.

[0280] The TCE 16 has a controller 93 to control the operation of the TCE 16. The controller 93 is configured to control the overall operation of the TCE 16 by, in this example, program instructions or software instructions stored within memory 94. Software may, for example, be pre-installed in the memory 94 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD). As shown, these software instructions include, among other things, an operating system 95, and a communications control module 96.

[0281] The communications control module 96 is operable to control the communication between the TCE 16 and other network entities. The communication control module 96 is configured, in particular, to control the communication of the TCE 16, where applicable, in accordance with any of the methods described herein.

[0282] <Modifications and Alternatives> 　　Detailed examples been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the concepts embodied therein.

[0283] It will be appreciated that description of features of and actions performed by a RAN node (base station), apply equally to distributed type base stations as to non-distributed type base stations.

[0284] It will also be appreciated that whilst information elements having specific names have been described differently named information elements but having a similar purpose may be used.

[0285] In the above description the UE and the base station are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosed enhancements, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0286] In the above examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE or base station as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all, of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE or the base station in order to update their functionalities.

[0287] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0288] The User Equipment (or "UE," "mobile station," "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0289] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0290] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for an extended period of time.

[0291] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; moulds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0292] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

[0293] A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0294] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0295] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0296] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0297] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0298] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)," using a variety of wired and / or wireless communication technologies.

[0299] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for an extended period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g., vehicles) or attached to animals or persons to be monitored / tracked.

[0300] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0301] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0302] Further, the above-described UE categories are merely examples of applications of the technical ideas and exemplary examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

[0303] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0304] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device; 　　performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and 　　transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is allocated by a core network. 　　(Supplementary note 3) 　　The method according to supplementary note 2, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is allocated during a registration procedure or a configuration procedure for the continuous measurements. 　　(Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes: 　　　　information for configuring measurements in one of the plurality of the RRC states of the mobile device; and 　　　　information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device. 　　(Supplementary note 5) 　　The method according to supplementary note 4, wherein 　　the transmitting the respective measurement reports including the information for tracing the process of the continuous measurements across the plurality of the RRC states is performed in a case where the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes the information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is transmitted from an operations, administration, and maintenance function node to the access network node, and 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted from a core network node for an access and mobility management function. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is transmitted from a core network node for an access and mobility management function, and 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted from the core network node for the access and mobility management function. 　　(Supplementary note 8) 　　The method according to supplementary note 6 or 7, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted based on a user consent corresponding to the mobile device, stored in the core network node for the access and mobility management function. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is transmitted from a further access network node to the access network node upon a handover for the mobile device from the further access network node to the access network node. 　　(Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 8, further comprising: 　　in a case where the mobile device moves to a further access network node upon transiting from a RRC inactive / idle state to a RRC connected state, transmitting respective measurement reports corresponding to the RRC inactive / idle state, the respective measurement reports including information for tracing the process of the continuous measurements across the plurality of the RRC states. 　　(Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, wherein 　　the receiving the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by receiving from a central unit - control plane of the access network node. 　　(Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 11, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes at least one of: 　　　　information for indicating a threshold for storing measurement data of the continuous measurements across the plurality of the RRC states, 　　　　information for indicating at least one time window for performing the continuous measurements, 　　　　information for indicating at least one timer value for performing the continuous measurements, or 　　　　information for indicating at least one event for triggering the continuous measurements. 　　(Supplementary note 13) 　　The method according to supplementary note 12, wherein 　　the transmitting the respective measurement reports corresponding to the one or more of the plurality of the RRC states is performed based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device. 　　(Supplementary note 14) 　　The method according to any one of supplementary notes 1 to 13, wherein 　　the respective measurement reports includes at least one of: 　　　　a full report of measured data on the continuous measurements, or 　　　　a part of a report of measured data on the continuous measurements and information for indicating that the mobile device has remaining data on the continuous measurements. 　　(Supplementary note 15) 　　The method according to any one of supplementary notes 1 to 14, further comprising: 　　transmitting, to the access network node, information indicating at least one of: 　　　　availability of measured data on the continuous measurements, or 　　　　data volume of the measured data on the continuous measurements, 　　before transmitting the respective measurement reports corresponding to the one or more of the plurality of the RRC states. 　　(Supplementary note 16) 　　The method according to any one of supplementary notes 1 to 15, further comprising: 　　transmitting, to the access network node, capability information of the mobile device indicating available data size for the continuous measurements. 　　(Supplementary note 17) 　　The method according to any one of supplementary notes 1 to 16, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states includes information for indicating the mobile device which reports a respective measurement report across the plurality of the RRC states. 　　(Supplementary note 18) 　　A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device being used by the mobile device in performing the continuous measurements in one or more of the plurality of the RRC states; and 　　receiving, from the mobile device, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states. 　　(Supplementary note 19) 　　The method according to supplementary note 18, further comprising: 　　receiving, from a core network or an operations, administration, and maintenance function node, the information for tracing the process of the continuous measurements across the plurality of the RRC states. 　　(Supplementary note 20) 　　The method according to supplementary note 19, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is received during a registration procedure or a configuration procedure for the continuous measurements. 　　(Supplementary note 21) 　　The method according to any one of supplementary notes 18 to 20, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes: 　　　　information for configuring measurements in one of the plurality of the RRC states of the mobile device; and 　　　　information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device. 　　(Supplementary note 22) 　　The method according to supplementary note 21, wherein 　　the receiving the respective measurement reports including the information for tracing the process of the continuous measurements across the plurality of the RRC states is performed in a case where the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes the information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device. 　　(Supplementary note 23) 　　The method according to supplementary note 19, wherein 　　the receiving the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by receiving from an operations, administration, and maintenance function node . 　　(Supplementary note 24) 　　The method according to supplementary note 19, wherein 　　the receiving the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by receiving from a core network node for an access and mobility management function, and the method comprises: 　　receiving, from the core network node for the access and mobility management function, the information for tracing the process of the continuous measurements across the plurality of the RRC states. 　　(Supplementary note 25) 　　The method according to supplementary note 23 or 24, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted based on a user consent corresponding to the mobile device, stored in the core network node for the access and mobility management function. 　　(Supplementary note 26) 　　The method according to any one of supplementary notes 18 to 24 , further comprising: 　　receiving, from a further access network node, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device upon a handover for the mobile device from the further access network node to the access network node. 　　(Supplementary note 27) 　　The method according to any one of supplementary notes 18 to 24, wherein 　　in a case where the mobile device moves to a further access network node upon transiting from a RRC inactive / idle state to a RRC connected state, respective measurement reports corresponding to the RRC inactive / idle state is transmitted from the mobile device to the further access network node, the respective measurement reports including information for tracing the process of the continuous measurements across the plurality of the RRC states. 　　(Supplementary note 28) 　　The method according to any one of supplementary notes 18 to 24 , wherein 　　the transmitting the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by transmitting from a central unit - control plane of the access network node. 　　(Supplementary note 29) 　　The method according to any one of supplementary notes 18 to 24, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes at least one of: 　　　　information for indicating a threshold for storing measurement data of the continuous measurements across the plurality of the RRC states, 　　　　information for indicating at least one time window for performing the continuous measurements, 　　　　information for indicating at least one timer value for performing the continuous measurements, or 　　　　information for indicating at least one event for triggering the continuous measurements. 　　(Supplementary note 30) 　　The method according to supplementary note 29, wherein 　　the receiving the respective measurement reports corresponding to the one or more of the plurality of the RRC states is performed based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device. 　　(Supplementary note 31) 　　The method according to any one of supplementary notes 18 to 30, wherein 　　the respective measurement reports includes at least one of: 　　　　a full report of measured data on the continuous measurements, or 　　　　a part of a report of measured data on the continuous measurements and information for indicating that the mobile device has remaining data on the continuous measurements. 　　(Supplementary note 32) 　　The method according to any one of supplementary notes 18 to 31, further comprising: 　　receiving, from the mobile device, information indicating at least one of: 　　　　availability of measured data on the continuous measurements, or 　　　　data volume of the measured data on the continuous measurements, 　　　　before receiving the respective measurement reports corresponding to the one or more of the plurality of the RRC states. 　　(Supplementary note 33) 　　The method according to any one of supplementary notes 18 to 32, further comprising: 　　receiving, from the mobile device, capability information of the mobile device indicating available data size for the continuous measurements. 　　(Supplementary note 34) 　　The method according to any one of supplementary notes 18 to 33, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states includes information for indicating the mobile device which reports a respective measurement report across the plurality of the RRC states. 　　(Supplementary note 35) 　　A mobile device comprising: 　　means for receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device; 　　means for performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and 　　means for transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states. 　　(Supplementary note 36) 　　An access network node comprising: 　　means for transmitting, to a mobile device, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device being used by the mobile device in performing the continuous measurements in one or more of the plurality of the RRC states; and 　　means for receiving, from the mobile device, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

[0305] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2414442.0, filed on October 1, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0306] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 51 TRANSCEIVER CIRCUIT 51c TRANSCEIVER CIRCUIT(CU) 51d TRANSCEIVER CIRCUIT(DU) 53 ANTENNA 53d AIR INTERFACE 55 CORE NETWORK INTERFACE 55c NETWORK INTERFACE 57 CONTROLLER 57c CU CONTROLLER 57d DU CONTROLLER 59 MEMORY 59c CU MEMORY 59d DU MEMORY 61 OPERATING SYSTEM 61c CU OPERATING SYSTEM 61d DU OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE 63c CU COMMUNICATIONS CONTROL MODULE 63d DU COMMUNICATIONS CONTROL MODULE 71 TRANSCEIVER CIRCUIT 72 NETWORK INTERFACE 73 CONTROLLER 74 MEMORY 75 OPERATING SYSTEM 76 COMMUNICATIONS CONTROL MODULE 81 TRANSCEIVER CIRCUIT 82 NETWORK INTERFACE 83 CONTROLLER 84 MEMORY 85 OPERATING SYSTEM 86 COMMUNICATIONS CONTROL MODULE 91 TRANSCEIVER CIRCUIT 92 NETWORK INTERFACE 93 CONTROLLER 94 MEMORY 95 OPERATING SYSTEM 96 COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by a mobile device, the method comprising: 　　receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device; 　　performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and 　　transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

2. The method according to claim 1, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is allocated by a core network.

3. The method according to claim 2, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is allocated during a registration procedure or a configuration procedure for the continuous measurements.

4. The method according to any one of claims 1 to 3, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes: 　　　　information for configuring measurements in one of the plurality of the RRC states of the mobile device; and 　　　　information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device.

5. The method according to claim 4, wherein 　　the transmitting the respective measurement reports including the information for tracing the process of the continuous measurements across the plurality of the RRC states is performed in a case where the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes the information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device.

6. The method according to any one of claims 1 to 5, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is transmitted from an operations, administration, and maintenance function node to the access network node, and 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted from a core network node for an access and mobility management function.

7. The method according to any one of claims 1 to 5, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is transmitted from a core network node for an access and mobility management function, and 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted from the core network node for the access and mobility management function.

8. The method according to claim 6 or 7, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted based on a user consent corresponding to the mobile device, stored in the core network node for the access and mobility management function.

9. The method according to any one of claims 1 to 8, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is transmitted from a further access network node to the access network node upon a handover for the mobile device from the further access network node to the access network node.

10. The method according to any one of claims 1 to 8, further comprising: 　　in a case where the mobile device moves to a further access network node upon transiting from a RRC inactive / idle state to a RRC connected state, transmitting respective measurement reports corresponding to the RRC inactive / idle state, the respective measurement reports including information for tracing the process of the continuous measurements across the plurality of the RRC states.

11. The method according to any one of claims 1 to 10, wherein 　　the receiving the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by receiving from a central unit - control plane of the access network node.

12. The method according to any one of claims 1 to 11, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes at least one of: 　　　　information for indicating a threshold for storing measurement data of the continuous measurements across the plurality of the RRC states, 　　　　information for indicating at least one time window for performing the continuous measurements, 　　　　information for indicating at least one timer value for performing the continuous measurements, or 　　　　information for indicating at least one event for triggering the continuous measurements.

13. The method according to claim 12, wherein 　　the transmitting the respective measurement reports corresponding to the one or more of the plurality of the RRC states is performed based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device.

14. The method according to any one of claims 1 to 13, wherein 　　the respective measurement reports includes at least one of: 　　　　a full report of measured data on the continuous measurements, or 　　　　a part of a report of measured data on the continuous measurements and information for indicating that the mobile device has remaining data on the continuous measurements.

15. The method according to any one of claims 1 to 14, further comprising: 　　transmitting, to the access network node, information indicating at least one of: 　　　　availability of measured data on the continuous measurements, or 　　　　data volume of the measured data on the continuous measurements, 　　before transmitting the respective measurement reports corresponding to the one or more of the plurality of the RRC states.

16. The method according to any one of claims 1 to 15, further comprising: 　　transmitting, to the access network node, capability information of the mobile device indicating available data size for the continuous measurements.

17. The method according to any one of claims 1 to 16, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states includes information for indicating the mobile device which reports a respective measurement report across the plurality of the RRC states.

18. A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device being used by the mobile device in performing the continuous measurements in one or more of the plurality of the RRC states; and 　　receiving, from the mobile device, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

19. The method according to claim 18, further comprising: 　　receiving, from a core network or an operations, administration, and maintenance function node, the information for tracing the process of the continuous measurements across the plurality of the RRC states.

20. The method according to claim 19, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is received during a registration procedure or a configuration procedure for the continuous measurements.

21. The method according to any one of claims 18 to 20, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes: 　　　　information for configuring measurements in one of the plurality of the RRC states of the mobile device; and 　　　　information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device.

22. The method according to claim 21, wherein 　　the receiving the respective measurement reports including the information for tracing the process of the continuous measurements across the plurality of the RRC states is performed in a case where the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes the information indicating that the measurements correspond to the continuous measurements across the plurality of the RRC states of the mobile device.

23. The method according to claim 19, wherein 　　the receiving the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by receiving from an operations, administration, and maintenance function node .

24. The method according to claim 19, wherein 　　the receiving the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by receiving from a core network node for an access and mobility management function, and the method comprises: 　　receiving, from the core network node for the access and mobility management function, the information for tracing the process of the continuous measurements across the plurality of the RRC states.

25. The method according to claim 23 or 24, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states is transmitted based on a user consent corresponding to the mobile device, stored in the core network node for the access and mobility management function.

26. The method according to any one of claims 18 to 24 , further comprising: 　　receiving, from a further access network node, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device upon a handover for the mobile device from the further access network node to the access network node.

27. The method according to any one of claims 18 to 24, wherein 　　in a case where the mobile device moves to a further access network node upon transiting from a RRC inactive / idle state to a RRC connected state, respective measurement reports corresponding to the RRC inactive / idle state is transmitted from the mobile device to the further access network node, the respective measurement reports including information for tracing the process of the continuous measurements across the plurality of the RRC states.

28. The method according to any one of claims 18 to 24 , wherein 　　the transmitting the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device is performed by transmitting from a central unit - control plane of the access network node.

29. The method according to any one of claims 18 to 24, wherein 　　the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device includes at least one of: 　　　　information for indicating a threshold for storing measurement data of the continuous measurements across the plurality of the RRC states, 　　　　information for indicating at least one time window for performing the continuous measurements, 　　　　information for indicating at least one timer value for performing the continuous measurements, or 　　　　information for indicating at least one event for triggering the continuous measurements.

30. The method according to claim 29, wherein 　　the receiving the respective measurement reports corresponding to the one or more of the plurality of the RRC states is performed based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device.

31. The method according to any one of claims 18 to 30, wherein 　　the respective measurement reports includes at least one of: 　　　　a full report of measured data on the continuous measurements, or 　　　　a part of a report of measured data on the continuous measurements and information for indicating that the mobile device has remaining data on the continuous measurements.

32. The method according to any one of claims 18 to 31, further comprising: 　　receiving, from the mobile device, information indicating at least one of: 　　　　availability of measured data on the continuous measurements, or 　　　　data volume of the measured data on the continuous measurements, 　　　　before receiving the respective measurement reports corresponding to the one or more of the plurality of the RRC states.

33. The method according to any one of claims 18 to 32, further comprising: 　　receiving, from the mobile device, capability information of the mobile device indicating available data size for the continuous measurements.

34. The method according to any one of claims 18 to 33, wherein 　　the information for tracing the process of the continuous measurements across the plurality of the RRC states includes information for indicating the mobile device which reports a respective measurement report across the plurality of the RRC states.

35. A mobile device comprising: 　　means for receiving, from an access network node, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device; 　　means for performing the continuous measurements in one or more of the plurality of the RRC states, based on the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device; and 　　means for transmitting, to the access network node, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

36. An access network node comprising: 　　means for transmitting, to a mobile device, information for configuring continuous measurements across a plurality of a Radio Resource Control (RRC) states of the mobile device, the information for configuring the continuous measurements across the plurality of the RRC states of the mobile device being used by the mobile device in performing the continuous measurements in one or more of the plurality of the RRC states; and 　　means for receiving, from the mobile device, respective measurement reports corresponding to the one or more of the plurality of the RRC states, the respective measurement reports including information for tracing a process of the continuous measurements across the plurality of the RRC states.

Images