Method and apparatus for propagating a user equipment identifier for measurement data correlation in a mobile network

Abstract

Described is a radio access network entity (501) for use in a mobile network (500), the radio access network entity being configured to: receive (601) a user equipment identifier for user equipment-level measurement data correlation from a user equipment device in the mobile network; and send (602) the user equipment identifier from a sub-entity (505, 506) of the radio access network entity to one or more other sub-entities (509, 510, 507, 508) of the radio access network entity. The user equipment identifier can be propagated across nodes (within a split gNB, as well as from one radio access network entity to another). This may allow user equipment level measurement data correlation to be easily achieved.

Description

METHOD AND APPARATUS FOR PROPAGATING A USER EQUIPMENT IDENTIFIER FOR MEASUREMENT DATA CORRELATION IN A MOBILE NETWORKTECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to the field of mobile networks, in particular to the propagation of user equipment identifiers which can be used for measurement data correlation.BACKGROUND

[0002] As part of the 3rd Generation Partnership Project (3GPP) , Release 19 Study Item “Study on enhancements for Artificial Intelligence (AI)  / Machine Learning (ML) for NG-RAN” RAN3 started the discussion concerning the correlation of measurement data for a given User Equipment (UE) .

[0003] The need to properly correlate measurement data provided by or associated to a given UE is applicable to at least the following scenarios.

[0004] Firstly, the correlation of measurement data for a specific UE in the case of a disaggregated gNB. Still in the context of the artificial intelligence  / machine learning (AI / ML) for NG-RAN, RAN3 defined a set of UE performance metrics which are useful to be reported after a mobility action (i.e., handover) inferred by an AI / ML model for, for example, load balancing or energy saving actions. This means that after the handover, the target gNB could be requested by the source gNB to provide UE performance measurements so that it may be assessed whether the handover decision determined by the AI / ML model in the source node was beneficial or not.

[0005] In one example, the UE performance defined in 3GPP Technical Specification (TS) 38.423 are Downlink / Uplink (DL / UL) UE throughput, DL / UL packet delay and DL packet loss. A particular scenario is related to the case where the target gNB is a split gNB, i.e., it is composed of logical entities termed as gNB-Central Unit (gNB-CU) and one or more gNB-Distributed Units (gNB-DUs) , for example as currently specified in 3GPP TS 38.401.

[0006] Some components of a mobile network 100 comprising a split gNB 101 is schematically illustrated in Fig. 1. The gNB is part of the 5G radio access network (NG-RAN, for example as specified in TS 38.300) of the mobile network. The mobile network also has a core network (CN) , shown in Fig. 1 as 5G core (5GC) 102.

[0007] The gNB-CU can be split into a gNB-CU-Control Plane entity (gNB-CU-CP) 103 and one or more gNB-CU-User Plane entities (gNB-CU-UPs) , one of which is shown at 104. A DU of the split gNB is shown at 105.

[0008] The 5GC 102 can communicate with the gNB over an NG interface. Specifically, the 5GC 102 can communicate with the gNB-CU-CP over an NG-C interface 106 and with the gNB-CU-UP over an NG-U interface 107. The gNB-CU-CP can communicate with the gNB-CU-UP over an E1 interface 108. The gNB-CU can communicate with the gNB-DU over an F1 interface. Specifically, the gNB-CU-CP 103 can communicate with the gNB-DU over an F1-C interface 106 and the gNB-CU-UP can communicate with the gNB-DU over an F1-U interface 110.

[0009] A UE in communication with the gNB 101 is shown at 111. The UE 111 can communicate with the gNB over a Uu interface 112.

[0010] In such a scenario, the UE performance metrics collected at the target gNB side are either measured at the gNB-DU or at both the gNB-DU and gNB-CU-UP. The latter case occurs for the measurement of the UL / DL packet delay, which results from the sum of multiple delay components some of which measured at the gNB-DU and some others at the gNB-CU-UP.

[0011] As shown in Fig. 1, D1 is the delay in the over-the-air interface, Uu 112, between the UE and the gNB (-DU) . D2 is the delay in the gNB-DU 105. D3 is the delay of the F1-U interface 110. D4 is the delay in the gNB-CU-UP 104, for example as specified in TS 28.558.

[0012] The DL packet delay measurement is determined by sum of delay components D1, …, D4. In order for the gNB-CU-CP 103 to aggregate all the delay components D1, …, D4 and derive the total DL packet delay for a UE, the gNB-CU-CP 103 needs to collect the delay components from gNB-DU 105 (D1 and D2) and gNB-CU-UP 103 (D3 and D4) associated to the same UE 111. Similar procedures and approaches are also valid for the UL packet delay, for example as specified in TS 38.314.

[0013] Currently, the definition of the measurements for each of the delay components (D1, …, D4 for the DL packet delay in Fig. 1) is available in TS 28.558 which in its latest public version v18.1.0, and for all the NG-RAN UE level measurements, lacks a UE identifier (UE ID) which could serve the purpose of measurement data correlation for measurements associated to a given UE. It is worth to note that the previous public version of the same specification, i.e., TS 28.558 v 18.0.0, made use of the 5G Temporary Mobile Subscription Identifier (5G-S-TMSI) as UE ID for the purpose of measurement data correlation for measurements associated to a given UE. However, the 5G-S-TMSI currently suffers from some limitations that prevent it to be used as UE ID for correlating measurement data from a given UE.

[0014] Secondly, the need to properly correlate measurement data provided by or associated to a given UE is applicable to allow support for Continuous Minimization of Driving Tests (MDT) . Continuous MDT is a feature currently under discussion in 3GPP RAN3 that enables the continuous collection of MDT measurement data from the same UE across UE’s Radio Resource Control (RRC) states. This means that, regardless of whether the UE is in RRC_CONNECTED, RRC_INACTIVE or RRC_IDLE state, the same UE is always able to perform and report MDT measurements without time gaps induced by RRC state changes or mobility events in RRC_CONNECTED mode.

[0015] Continuous MDT currently relies on the MDT framework that has been specified by 3GPP in Rel-10 to mainly serve the purpose of collecting data from the UE over the Uu interface and, from the network signalling perspective, two types of MDT have been introduced: signalling-based MDT and management-based MDT. The former is used to collect measurements from a certain UE which is selected in OAM based on a permanent UE identity and, if the corresponding end user has consented to contribute to MDT, the final decision to activate the data collection process for that UE is taken by the Unified Data Management (UDM) function in Core Network (CN) . In management-based MDT, instead, measurements are collected from randomly chosen UEs or a group of UEs that enter a (certain) geographical area: it is typically activated in RAN nodes of a specific area (which is identified by a list of NG-RAN cells) and UE selection is performed by RAN nodes based on parameters received by the Operations, Administration and Maintenance (OAM) system, UE radio capability and the indication about whether the MDT is allowed to be configured considering e.g. user consent and roaming status.

[0016] For both MDT types, the UE can be configured to perform immediate MDT and / or logged MDT measurements. Immediate MDT refers to the measurements performed by the UE in RRC_CONNECTED state (i.e., the UE has an active connection with the network) and such measurements are promptly reported by the UE to the network. Logged MDT, instead, occurs when the UE is either in RRC_INACTIVE or RRC_IDLE state and measurements are collected by the UE for a certain period of time, stored by the UE and then reported to the network at a later point in time when the UE transits from RRC_INACTIVE / RRC_IDLE to RRC_CONNECTED.

[0017] Continuous MDT is useful for the creation of a training dataset to be used for training AI / ML models in the OAM, as per the deployment scenarios specified for supporting the AI / ML for NG-RAN function. As defined in TS 38.300, clause 16.20.2, for the deployment of AI / ML for NG-RAN the following current exemplary scenarios may be supported: AI / ML Model Training is located in the OAM and AI / ML Model Inference is located in the NG-RAN node; AI / ML Model Training and AI / ML Model Inference are both located in the NG-RAN node.

[0018] For the case of split RAN, instead, current exemplary deployment scenarios are described in TS 38.401 clause 7.11 as follows: AI / ML model training is located in the OAM and AI / ML model inference is located in the gNB-CU; AI / ML model training and AI / ML model inference are both located in the gNB-CU.

[0019] Currently, AI / ML model training follows the definition of the "ML model training" as specified in clause 3.1 of TS 28.105, while AI / ML model inference follows the definition of the "AI / ML inference" as defined in clause 3.1 of TS 28.105.

[0020] The main requirement of a training dataset used to train an AI / ML model deployed in NG-RAN is that it shall be a consecutive (i.e., not affected by time interruptions) time series of information representing the network radio characteristics.

[0021] Since the training of AI / ML models requires a massive amount of training input data, the most useful tool to achieve this goal is to configure a group of UEs within a certain area of the network to perform management-based MDT. In management-based MDT, the OAM provides each gNB in a certain area with measurement configurations for immediate MDT and for logged MDT, such configurations are then provided via RRC signalling to the UE (s) selected by the gNB to perform management-based MDT measurement.

[0022] Fig. 2a is a communication flow illustrating continuous MDT in a mobile network 200. The OAM 201 sends a management-based MDT (m-MDT) configuration for initiating an immediate MDT session (with an associated Trace Reference, e.g., TR#1) and a logged MDT session (with an associated Trace Reference, e.g., TR#2) to the NG-RAN node, gNB 202, at 203. At 204, the UE 205 is configured by the gNB 202 with the immediate MDT and logged MDT configurations as received by the OAM.

[0023] If the UE is in RRC_CONNECTED state, as illustrated at 206, and upon being configured by the gNB 202, the UE 205 performs immediate MDT measurements and provides the associated immediate MDT measurement report to the gNB, as shown at 207. The immediate MDT report made available at the gNB by the UE is then sent by the gNB 202 to the Trace Collection Entity (TCE) 208, as shown at 209.

[0024] Conversely, if the UE is in RRC_IDLE (or RRC_INACTIVE) state, as illustrated at 210, and upon being configured by the gNB 202, the UE 205 performs logged MDT measurements, as shown at 211, and after the UE re-establishes the RRC connection with the gNB, i.e., after transition from RRC_IDLE / RRC_INACTIVE to RRC_CONNECTED, as shown at 212, the UE 205 provides a report of the associated logged MDT measurements to the gNB 202, as shown at 213. The logged MDT report made available at the gNB by the UE is then sent by the gNB 202 to the TCE 208, as shown at 214.

[0025] In order for these reports to be used for creating a training dataset for AI / ML models’ training, they should be correlated (i.e., merged together) so that a consecutive time series of information can be generated and used as training dataset to train AI / ML models in the OAM. Such a time-measurement dataset (tn, Mn) for the training (or re-training) of AI / ML models is shown in Fig. 2b.

[0026] Correlation at TCE level of immediate MDT and logged MDT reports provided by the same UE, however, requires the TCE to be able to identify, among all the possible MDT reports, which MDT reports are from the same UE: once the TCE has identified the immediate MDT and logged MDT reports provided by the same UE it can merge them together and define a unique report that fulfils the requirement of a dataset for AI / ML model’s training in OAM.

[0027] Currently the immediate MDT and logged MDT reports are provided by the gNB to the TCE after anonymization, which is mandatory if the MDT measurements have been configured by means of management-based MDT. Therefore, the TCE has no means to identify which MDT reports (immediate and logged) are provided by the same UE and, as a consequence, it cannot perform any kind of measurement data correlation.

[0028] Besides the issue of correlating the MDT reports at TCE, there is also another issue related to the need to ensure that a UE selected for Continuous MDT keeps on performing MDT measurements during connected mode mobility and RRC state transition from RRC_IDLE / RRC_INACTIVE to RRC_CONNECTED.

[0029] In connected mode mobility (i.e., handover) , a UE previously selected for Continuous MDT by a first gNB (the source gNB) and in RRC_CONNECTED under its coverage is handed over to a second gNB (the target gNB) ; in this scenario it needs to be ensured that the target gNB re-selects the UE for Continuous MDT immediately after the handover completion, so that the UE can re-start performing immediate MDT measurements under the coverage of the target gNB.

[0030] In idle / inactive mode mobility (i.e., RRC connection re-establishment / resume from RRC_IDLE / RRC_INACTIVE to RRC_CONNECTED) , a UE previously selected for Continuous MDT by a first gNB (the old serving gNB) and now in RRC_IDLE / RRC_INACTIVE performing logged MDT measurements re-establishes / resumes its RRC connection (hence transits to RRC_CONNECTED) under the coverage of second NB (the new serving gNB) ; in this scenario there is again the need for the new serving gNB to re-select the UE for Continuous MDT immediately after RRC connection re-establishment / resume, so that the UE can start performing immediate MDT measurements under the coverage of the new serving gNB.

[0031] Currently there are no means for the target gNB / new serving gNB to re-select a UE to keep on performing Continuous MDT after mobility actions.

[0032] For correlation of measurement data for a given UE, the latest version of TS 28.558 (v18.1.0) lacks a specific UE ID –refer to field g) Measured UE identifier in the template defined by 3GPP SA5 in Annex A of TS 28.558. In that version of the specification, field g) is set as “N / A” (Not Applicable) , meaning that the all NG-RAN UE level measurements are provided without any UE ID associated to these measurements. The previous version of the same specification (TS 28.558 v18.0.0) made use of the 5G-S-TMSI as UE ID. Therefore, the availability at either gNB-DU or gNB-CU-UP of the UE’s 5G-S-TMSI would allow to include in the UE level measurements performed by the gNB-DU or gNB-CU-UP the UE’s 5G-S-TMSI.

[0033] For the Continuous MDT feature, instead, multiple solutions are currently under discussion as part of the 3GPP standardization for 5G Rel-19, and no technical solution has been selected so far for normative work. Among such solutions, the one disclosed and publicly available in R3-243451 makes use of the 5G-S-TMSI as per TS 28.558 v18.0.0 to perform the correlation at TCE level of immediate MDT and logged MDT reports from the same UE (i.e., the UE identified by the 5G-S-TMSI) as well as to ensure measurement continuity during the UE mobility.

[0034] Fig. 3 schematically illustrates a possible implementation of Continuous MDT, as disclosed in R3-243451, showing the Continuous MDT in a solution in a mobile network 300 relying on the 5G-S-TMSI as an identifier for the UE. It should be noted that the solution description in R3-243451, as described below, mentions “S-TMSI” instead of “5G-S-TSMI” , but the whole concept and mechanism remain unaltered.

[0035] 1) The RAN (comprising NG-RAN1 301 and NG-RAN2 302 in Fig. 3) receives from operations and management function (OAM) 303 a management-based MDT configuration, as illustrated at 305 for NG-RAN1 301. The management-based MDT configuration is made of at least two configurations: an immediate MDT configuration and a logged MDT configuration. The two configurations have different Trace Session identifiers. This configuration contains a “Continuous MDT” flag. With this information, the NG-RAN1 knows that it has to configure selected UEs with MDT measurements in RRC_CONNECTED and in RRC_IDLE / INACTIVE.

[0036] 2) At 306, the NG-RAN1 configures the UE 304 with immediate MDT and logged MDT as per the configuration details in Step 1) above, i.e., including a “Continuous MDT” flag in the logged MDT configuration pushed to the UE.

[0037] 3) At 307, the UE 303 reports immediate MDT measurements collected while in RRC_CONNECTED and according to the immediate MDT configuration received. As part of these measurements, the UE includes the S-TMSI, for example as per definitions in TS 28.558 v18.0.0.

[0038] 3a) At 308, NG-RAN1 301 reports the immediate MDT measurements as part of a Trace Record contained in a Trace File sent to the TCE at 309. The measurements include the UE′sS-TMSI.

[0039] 4) At 310, the UE 304 moves to RRC_IDLE / INACTIVE. The UE 304 collects logged MDT measurements and stores them as per received logged MDT configuration.

[0040] 5) When the UE moves from RRC_IDLE / INACTIVE to RRC_CONNECTED under the coverage of a new serving node (NG-RAN 2) , the UE 304 indicates to the NG-RAN2 302 at 311, as part of the RRC Setup procedure, that it is configured with Continuous MDT. This allows the NG-RAN2 to immediately configure the UE with immediate MDT measurements, which can be added to the Continuous MDT trace.

[0041] 6) At 312, the NG-RAN2 302 configures the UE 304 with immediate MDT measurements.

[0042] 7) At 313, the UE 304 reports logged MDT results, which can be added as Trace Record into a Trace File. The measurements in the Trace Record can include the UE’s S-TMSI as per TS 28.558 v18.0.0.

[0043] 8) At 314, the UE 304 reports immediate MDT measurements collected while in RRC_CONNECTED and according to the immediate MDT configuration received. As part of these measurements, the UE 304 includes the S-TMSI, as per definitions in TS 28.558 v18.0.0. The NG-RAN2 302 includes the immediate MDT measurements into a Trace Record and adds them into the Trace File where the logged MDT measurements Trace Record was stored (refer to Step 7) ) . 8a) At 315, the NG-RAN2 302 reports the logged MDT measurements and the immediate MDT measurements as part of different Trace Records within a Trace File that is sent to the TCE at 316. The measurements include the UE’s S-TMSI as per TS 28.558 v18.0.0.

[0044] 9) At 317, the TCE is able to link the UE measurements received in the Trace File from NG-RAN1 301 and in the Trace File from NG-RAN2 302, thanks to the UE’s S-TMSI included in both Trace Files.

[0045] 10) At 318, to guarantee for continuous MDT measurement collection across connected mode mobility, an indication of “Continuous MDT” is included in the Handover Preparation signalling towards the target RAN. The target RAN is therefore able to appropriately configure MDT at the UE.

[0046] In traditional approaches, the 5G-S-TMSI is a UE ID assigned by the Access and Mobility Management Function (AMF) in 5GC. It identifies the UE with an AMF pool and it is used on the air interface for paging and or service request. Beside its validity only within a certain AMF pool, the 5G-S-TMSI was also specified to be a temporary UE ID for the purpose of security and privacy of the UE itself, so that the 5G-S-TMSI is re-allocated by the AMF at each periodic service request as well as at each UE paging.

[0047] Moreover, when it comes to the presence of the 5G-S-TMSI as UE ID in the NG-RAN, it can be noticed that the 5G-S-TMSI as currently defined in 3GPP TSs has the following limitations (also listed in R3-243941) . The 5G-S-TMSI is not available in the gNB-DU and in the gNB-CU-UP, meaning that is it impossible for UE level measurements to be performed at either gNB-DU or gNB-CU-UP to also include the UE ID (i.e., the 5G-S-TMSI) to which these measurements refer to; and this has implication on both measurement data correlation in a split gNB and Continuous MDT. Previously described. Moreover, the 5G-S-TMSI may not always be available in the gNB-CU-CP, meaning that in case of the UE is handed over from the source gNB to the target gNB, there are no means currently to transfer the 5G-S-TMSI made available in the source gNB to the target gNB over the Xn interface connecting the source gNB with the target gNB; and this has impacts on Continuous MDT for the measurement continuity in case of UE mobility (handover in Step 10) of Fig. 3) . It is worth to recall that the usage of the 5G-S-TMSI as UE ID is specified in the v18.0.0 of TS 28.558, while in the latest version of the same specification, i.e., TS 28.558, v18.1.0, the UE ID is never associated to any of the NG-RAN UE level measurements defined in such specification. This means that correlation at TCE for the solution as disclosed in R3-243451 cannot be implemented, as the measurements lack the UE’s S-TMSI.

[0048] Based on the above, it can be concluded that it is not currently possible to either perform measurement data correlation for a given UE or to enable the Continuous MDT feature either by using the 5G-S-TMSI as the UE ID as specified in TS 28.558 v18.0.0 or in the case that the latest version of TS 28.558 (v18.1.0 or later) is used for products implementation.

[0049] The authors of the present disclosure also analysed other UE identifiers that are allocated by the NG-RAN and currently specified in 3GPP TS 38.401, for example, the RAN UE ID, and concluded that also these NG-RAN-allocated UE IDs suffer from the same limitations observed for the 5G-S-TMSI, i.e., not availability in both gNB-DU and gNB-CU-UP (depending on the type of UE ID) as well as impossibility to transfer them over the Xn interface in case of handover. This is illustrated in Table 1 showing NG-RAN-allocated UE IDs.

[0050] Table 1 –Examples of NG-RAN-allocated UE IDs SUMMARY

[0051] According to a first aspect, there is provided a radio access network entity for use in a mobile network, the radio access network entity being configured to: receive a user equipment identifier for user equipment-level measurement data correlation from a user equipment device in the mobile network; and send the user equipment identifier from a sub-entity of the radio access network entity to one or more other sub-entities of the radio access network entity.

[0052] The user equipment identifier can be propagated across nodes (within a split gNB, as well as from one radio access network entity to another) . This may allow user equipment level measurement data correlation to be easily achieved.

[0053] The radio access network entity may be a split gNodeB comprising a gNB-CU-CP sub-entity, one or more gNB-DU sub-entities and one or more gNB-CU-UP sub-entities. The radio access network entity may be configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-DU sub-entities and / or one or more of the gNB-CU-UP sub-entities of the radio access network entity. This may allow the user equipment identifier to be propagated between the gNB-CU-CP sub-entity and gNB-CU-UP sub-entities of the gNB-CU and between the gNB-CU sub-entity and gNB-DU sub-entities.

[0054] The radio access network entity may be configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-DU sub-entities and / or one or more of the gNB-CU-UP sub-entities via an F1 and / or E1 interface. This may allow the user equipment identifier to be propagated between the sub-entities of the gNB-CU and between the gNB-CU and gNB-DU sub-entities.

[0055] The radio access network entity may be configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-DU sub-entities via an F1 interface using an F1AP UE Context Setup procedure and / or F1AP UE Context Modification procedure. This may allow for the enhancement of existing procedures over the F1 interface without the need to introduce new dedicated procedures for transferring the user equipment identifier, covering both the cases of first allocation of the user equipment identifier and re-allocation of a new identifier to the same UE.

[0056] The radio access network entity may be configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-CU-UP sub-entities via an E1 interface using an E1AP Bearer Context Setup procedure and / or E1AP Bearer Context Modification procedure. This may allow for the enhancement of existing procedures over the E1 interface without the need to introduce new dedicated procedures for transferring the user equipment identifier, covering both the cases of first allocation of the user equipment identifier and re-allocation of a new identifier to the same UE.

[0057] The radio access network entity may be configured to send the user equipment identifier to one or more other network entities in the mobile network. This may allow the user equipment identifier to be propagated during Xn handover of the user equipment.

[0058] The one or more other network entities may comprise a core network entity. This may allow the user identifier to be communicated to a radio network entity via the core network entity during NG handover of the user equipment.

[0059] The core network entity may be an access and mobility management function. This may allow the access and mobility management function to propagate the user equipment identifier to other entities in the radio access network.

[0060] The radio access network entity may be configured to send the user equipment identifier to the core network entity via an NG interface. This may allow the user equipment identifier to be sent to the core network entity.

[0061] The radio access network entity may be configured to send the user equipment identifier to the core network entity in an INITIAL UE MESSAGE. This may allow the radio access network entity to conveniently communicate the user equipment identifier to the core network entity in an existing message.

[0062] The one or more other network entities may comprise one or more other radio access network entities. This may allow the user identifier to be sent between entities in the RAN. This may be advantageous for situations such as handover.

[0063] The user equipment identifier may be sent to the, or each, radio access network entity via an Xn interface. This may allow the user equipment identifier to be sent between RAN entities.

[0064] The radio access network entity may be a source node in a communication session with the user equipment device, and wherein the one or more other radio access network entities comprise a target node to which the communication session is to be handed over. This may allow the user equipment identifier to be propagated between nodes in a RAN so that it can be available at the target node.

[0065] The source node may be configured to send the user equipment identifier to the target node in a HANDOVER REQUEST message. This may allow the source node to conveniently communicate the user equipment identifier to the target node in an existing message.

[0066] The source node may be configured to send the user equipment identifier to the target radio node in an RRC container (for example, the RRC Context as specified in TS 38.423) within the HANDOVER REQUEST message. This may allow the source node to conveniently communicate the user equipment identifier to the target node in an existing RRC container within an existing message.

[0067] The source node may be configured to send the user equipment identifier to the target node via the access and mobility management function. This may allow the user equipment identifier to be propagated to the target node during NG handover.

[0068] The source node may be configured to send the user equipment identifier over the NG interface to the access and mobility management function in a HANDOVER REQUIRED message. This may allow the source node to conveniently communicate the user equipment identifier to the access and mobility management function in an existing message.

[0069] The source node may be configured to send the user equipment identifier to the core network entity in a transparent container (for example, the Source to Target Transparent Container as specified in TS 38.413) within the HANDOVER REQUIRED message. This may allow the source node to conveniently communicate the user equipment identifier to the core network entity in an existing transparent container within an existing message.

[0070] The radio access network entity may be configured to receive the user equipment identifier from the user equipment device via RRC signalling. This may be a convenient signalling method and is also compatible with the current specification (TS 38.331) .

[0071] The user equipment identifier may be a core network-allocated user identifier. This may be advantageous because it may prevent the same identifier from being allocated to another UE. For example, in a case where the identifier is allocated by the NG-RAN, it may have very limited geographical scope (i.e., it can be provided to the UE and used only within the coverage area of the gNB) and hence it may not be suitable for sending it to another gNB since it is likely that the same identifier could have been allocated to another UE.

[0072] The user equipment identifier may be a new user identifier allocated to the user equipment device for the purpose of user equipment-level measurement data correlation. In other implementations, the user equipment identifier may be a 5G-S-TMSI. This may allow for compatibility with existing identifiers that can be enhanced to be then propagated within the radio access network.

[0073] The user equipment identifier may be designated with a lifetime by its allocating entity (for example, by the core network entity, such as the access and mobility management function) . This may be advantageous for user privacy and / or security.

[0074] According to a second aspect, there is provided a radio access network entity for use in a mobile network, the radio access network entity being configured to: receive a user equipment identifier for user equipment-level measurement data correlation from a user equipment device in the mobile network; and send the user equipment identifier to one or more other network entities in the mobile network, wherein the radio access network entity is a source node in a communication session with the user equipment device, and wherein the one or more other radio access network entities comprise a target node to which the communication session is to be handed over.

[0075] The user equipment identifier can be propagated across nodes (within a split gNB, as well as from one radio access network entity to another) . This may allow user equipment level measurement data correlation to be easily achieved.

[0076] The source node may be configured to send the user equipment identifier to the target node if Xn-or NG-handover is triggered. This may allow the user equipment to be communicated to the target node when required.

[0077] The source node may be configured to send the user equipment identifier to the target node in a HANDOVER REQUEST message. This may allow the source node to conveniently communicate the user equipment identifier to the target node in an existing message.

[0078] The source node may be configured to send the user equipment identifier to the target radio node in an RRC container (for example, RRC Context as specified in TS 38.423) within the HANDOVER REQUEST message. This may allow the source node to conveniently communicate the user equipment identifier to the target node in an existing RRC container within an existing message.

[0079] The radio access network entity may be configured to send the user equipment identifier to one or more other network entities in the mobile network. This may allow the user equipment identifier to be propagated during handover of the user equipment.

[0080] The one or more other network entities may comprise a core network entity. This may allow the user identifier to be communicated to a radio network entity via the core network entity during NG handover.

[0081] The core network entity may be an access and mobility management function. This may allow the access and mobility management function to propagate the user equipment identifier to other entities in the radio access network.

[0082] The radio access network entity may be configured to send the user equipment identifier to the core network entity via an NG interface. This may allow the user equipment identifier to be sent to the core network entity.

[0083] The radio access network entity may be configured to send the user equipment identifier to the core network entity in an INITIAL UE MESSAGE. This may allow the radio access network entity to conveniently communicate the user equipment identifier to the core network entity in an existing message.

[0084] The source node may be configured to send the user equipment identifier to the target node via the core network entity. This may allow the user identifier to be communicated to the target node via the core network entity during NG handover.

[0085] The source node may be configured to send the user equipment identifier over the NG interface to the core network entity in a HANDOVER REQUIRED message. This may allow the source node to conveniently communicate the user equipment identifier to the core network entity in an existing message.

[0086] The source node may be configured to send the user equipment identifier to the core network entity in a transparent container (for example, Source to Target Transparent Container as specified in TS 38.413) within the HANDOVER REQUEST message. This may allow the source node to conveniently communicate the user equipment identifier to the core network entity in an existing transparent container of an existing message.

[0087] The one or more other network entities may comprise one or more other radio access network entities. The user equipment identifier may be sent to the, or each, radio access network entity via an Xn interface. This may allow the user equipment identifier to be sent between RAN entities.

[0088] The user equipment identifier may be a core network-allocated user identifier. This may be advantageous because it may prevent the same identifier from being allocated to another UE. For example, in a case where the identifier is allocated by the NG-RAN, it may have very limited geographical scope (i.e., it can be provided to the UE and used only within the coverage area of the gNB) and hence it may not be suitable for sending it to another gNB since it is likely that the same identifier could have been allocated to another UE.

[0089] The user equipment identifier may be a new user identifier allocated to the user equipment device for the purpose of user equipment-level measurement data correlation. In other implementations, the user equipment identifier may be a 5G-S-TMSI. This may allow for compatibility with existing identifiers that can be enhanced to be then propagated within the radio access network.

[0090] The user equipment identifier may be designated with a lifetime by its allocating entity (for example, by the core network entity, such as the access and mobility management function) . This may be advantageous for user privacy and / or security.

[0091] The radio access network entity may be configured to receive the user equipment identifier from the user equipment device via RRC signalling. This may be a convenient signalling method and is also compatible with the current specification (TS 38.331) .

[0092] The radio access network entity may be a gNodeB. This may allow the present approach to be used in common mobile networks.

[0093] According to another aspect, there is provided a core network entity for use in a mobile network, the core network entity being configured to allocate a user equipment identifier for the purpose of user equipment-level measurement data correlation to a user equipment device in the mobile network.

[0094] This may be advantageous because it may prevent the same identifier from being allocated to another UE. For example, in a case where the identifier is allocated by the NG-RAN, it may have very limited geographical scope (i.e., it can be provided to the UE and used only within the coverage area of the gNB) and hence it may not be suitable for sending it to another gNB since it is likely that the same identifier could have been allocated to another UE.

[0095] The core network entity may be configured to send the user equipment identifier to a serving radio access network entity in a communication session with the user equipment device via NG signalling. This may allow the user equipment identifier to be conveniently communicated to the serving node.

[0096] The core network entity may be configured to send the user equipment identifier to the serving radio access network entity in response to a request from the serving radio access network entity to retrieve the user equipment identifier. This may allow the serving RAN entity to retrieve the user equipment identifier when it is needed.

[0097] The serving radio access network entity may be a target node in an Xn-or NG-handover procedure for the user equipment device. The target node may be configured to retrieve the user equipment identifier from the core network entity by triggering an NGAP Path Switch Request procedure with the core network entity. This may allow the target node to be made aware of the allocated user equipment identifier if, after either Xn-or NG-handover, the target node has not been provided with such information by the source node.

[0098] The core network entity may be configured to send the user equipment identifier to the serving radio access network entity via a UE Context Modification procedure or a Downlink NAS Transport procedure. This may allow the serving node to be made aware of the re-allocated user equipment identifier by the AMF by exploiting existing procedures, for example as specified in TS 38.413.

[0099] The core network entity may be an access and mobility management function. This may allow the access and mobility management function to propagate the user equipment identifier to other entities in the radio access network.

[0100] According to a further aspect, there is provided a user equipment device for use in a mobile network, the user equipment device being configured to: receive a user equipment identifier from a core network entity of the mobile network, the user equipment identifier being allocated to the user equipment device for the purpose of user equipment-level measurement data correlation; and signal the user equipment identifier to a radio access network entity of the mobile network. This may allow the user equipment device to be provided with an identifier that can be propagated to different components in the RAN of the mobile network.

[0101] The radio access network entity may be a gNodeB. This may allow the present approach to be used in common mobile networks.

[0102] The core network entity may be an access and mobility management function. This may allow the access and mobility management function to propagate the user equipment identifier to other entities in the radio access network.

[0103] The user equipment identifier may be a re-allocated user equipment identifier. This may allow the core network to reallocate the user identifier from an originally allocated user identifier.

[0104] The user equipment device may signal the user equipment identifier to the radio access network entity with one or more user equipment-level measurements made by the user equipment device. The radio access network entity may signal the user identifier and the associated one or more user equipment-level measurements to a trace collection entity of the mobile network for performing correlation of the measurements made by the user equipment device. The one or more user equipment-level measurements may include user equipment performance measurements (for example, packet delay measurements and / or other metrics, such as packet loss and throughput) . The one or more user equipment level measurements may include MDT measurements.

[0105] The user equipment identifier can be used to uniquely identify the UE (within at least the AMF pool) and is designed for the purpose of being propagated across NG-RAN nodes (within a split gNB, as well as from one RAN entity (e.g. gNB) to another) . The new UE ID is by design available in all RAN entities so that UE level measurement data correlation can be easily achieved. Since it is a CN-allocated UE ID, the same principles adopted for the 5G-S-TMSI in terms of temporary validity can be re-used, hence limiting the specification impact (from at least a security perspective) .

[0106] When using an existing UE ID, such as the 5G-S-TMSI, the identifier can uniquely identify the UE (within the AMF pool) and it is enhanced so that it can be propagated across NG-RAN nodes (within the split gNB as well as from one gNB to another) . The 5G-S-TMSI usage is extended with respect to its original meaning (UE paging, periodic service request) in order to correctly reflect the enhanced usage. There are no impacts to network domains other than the RAN, as an existing UE ID (such as 5G-S-TMSI) is used.

[0107] The user equipment identifier may be used within one or more of the entities in the mobile network (for example, one or more of the RAN entities or CN entities) for UE level measurement correlation and / or to allow datasets to be collected during MDT.

[0108] According to another aspect, there is provided a method for implementation at a radio access network entity in a mobile network, the method comprising: receiving a user equipment identifier for user equipment-level measurement data correlation from  a user equipment device in the mobile network; and sending the user equipment identifier from a sub-entity of the radio access network entity to one or more other sub-entities of the radio access network entity.

[0109] According to a further aspect, there is provided a method for implementation at a radio access network entity in a mobile network, the method comprising: receiving a user equipment identifier for user equipment-level measurement data correlation from a user equipment device in the mobile network; and sending the user equipment identifier to one or more other network entities in the mobile network, wherein the radio access network entity is a source node in a communication session with the user equipment device, and wherein the one or more other radio access network entities comprise a target node to which the communication session is to be handed over.

[0110] According to another aspect, there is provided a method for implementation at a core network entity in a mobile network, the method comprising allocating a user equipment identifier for the purpose of user equipment-level measurement data correlation to a user equipment device in the mobile network.

[0111] According to a further aspect there is provided a method for implementation at a user equipment device in a mobile network, the method comprising: receiving a user equipment identifier from a core network entity of the mobile network, the user equipment identifier being allocated to the user equipment device for the purpose of user equipment-level measurement data correlation; and signalling the user equipment identifier to a radio access network entity of the mobile network.

[0112] According to a further aspect, there is provided a mobile network comprising the radio access network entity and / or core network entity and / or user equipment device described above.

[0113] According to a further aspect, there is provided one or more computer programs for instructing a computer comprising one or more processors to implement the methods above.

[0114] According to a further aspect there is provided a data carrier storing in non-transitory form the one or more computer programs above.

[0115] BRIEF DESCRIPTION OF THE FIGURES

[0116] Fig. 1 schematically illustrates components of a mobile network that are involved in the packet delay measurement.

[0117] Fig. 2 (a) is a communication flow illustrating signalling for Continuous Minimization of Driving Tests.

[0118] Fig. 2 (b) illustrates a dataset for the training of AI / ML models using Minimization of Driving Tests measurements.

[0119] Fig. 3 schematically illustrates a further example of Continuous Minimization of Driving Tests.

[0120] Fig. 4 schematically illustrates an exemplary 3GPP system in which embodiments of the present disclosure may be implemented.

[0121] Fig. 5 schematically illustrates an NG-RAN architecture, where a gNB (gNB1) is a split node and another gNB (gNB2) is a non-split node.

[0122] Fig. 6 schematically illustrates the steps of an exemplary method for implementation at a radio access network entity in a mobile network.

[0123] Fig. 7 schematically illustrates the steps of another exemplary method for implementation at a radio access network entity in a mobile network.

[0124] Fig. 8 schematically illustrates an exemplary method for implementation at a core network entity in a mobile network.

[0125] Fig. 9 schematically illustrates the steps of an exemplary method for implementation at a user equipment device in a mobile network.DETAILED DESCRIPTION

[0126] Fig. 4 schematically illustrates an exemplary deployment of a 3GPP 5G network 400 in which one or more embodiments of the present disclosure may be implemented. Although the examples described herein refer to a 5G network, the described examples may also be implemented in different communication networks that are currently available or developed in the future. The network comprises a plurality of network entities (NEs) . The NEs may be network function (NFs) , which may be software-based. The NEs may alternatively be network apparatus (hardware-based) .

[0127] A mobile network comprises a Radio Access Network (RAN) and a Core Network (CN) . The RAN handles the wireless aspects, while the CN handles the management and control aspects. Both the RAN and CN have a User Plane (UP) to transmit traffic. A Control Plane (CP) can carry signalling traffic.

[0128] The exemplary network 400 shown in Fig. 4 comprises a network slice selection function (NSSF) 401, network exposure function (NEF) 402, network repository function (NRF) 403, policy control function (PCF) 404, unified data management (UDM) 405, application function (AF) 406, network slice-specific authentication and authorization function (NSSAAF) 407 and authentication server function (AUSF) 408. The network comprises an access and mobility management function (AMF) 409. The network comprises a session management function (SMF) 410. The network also comprises a service communication proxy (SCP) 411, a user equipment (UE) 412, an access network (AN) 413 (here a radio access network (RAN) ) , user plane function (UPF) 414 and data network (DN) 415.

[0129] A gNB is a RAN node providing NR user plane and control plane protocol terminations towards the UE. A gNB is connected via the NG interface to the 5GC. The gNB may in some implementations operate as defined in 3GPP TS 38.300. Other implementations are possible, for example according to future specifications.

[0130] Some technical problems that embodiments of the present disclosure aim to resolve are the limitations preventing the currently available UE IDs (for example, 5G-S-TMSI, etc. ) to be used to perform the correlation of measurement data for a given UE, which is important in scenarios such as UE measurement correlation in the case of disaggregated gNB or Continuous MDT. For example, embodiments of the present disclosure may address a problem of ensuring that the UE ID associated to UE level measurements and used for correlation of such measurements for a given UE is available in the gNB (including in the gNB-CU-UP / gNB-DU in the case of a split gNB) , and how to ensure that the UE ID associated to UE level measurements and used for correlation of such measurements for a given UE is made available in a target gNB after the UE is handed over from the source gNB to the target gNB.

[0131] To overcome such exemplary technical problems described above concerning the currently available UE IDs which may prevent such UE IDs to be suitable enablers for the correlation of measurement data for a given UE, two exemplary solutions are described herein. In the following, the terms UE identifier and UE ID are used interchangeably.

[0132] In a first solution, a new CN-allocated unique UE identifier is introduced that can be propagated across NG-RAN nodes and hence be made available in gNBs (or in gNB-CU-UP / gNB-DU in the case of a split gNB) , and also in the target gNB in case of handover. The UE ID may be designed with a “lifetime” in order to fulfil security and / or privacy of the user.

[0133] In a second solution, an existing identifier such as the 5G-S-TMSI can be enhanced so that it can be made available in the gNB-DU and gNB-CU-UP, as well as be transferred to another gNB over the Xn or NG interface during handover. This can allow the UE ID to be propagated across NG-RAN nodes and hence be made available in gNB / gNB-CU-UP / gNB-DU, and also in the target gNB in the case of handover.

[0134] To illustrate these exemplary solutions, Fig. 5 schematically illustrates a mobile network 500 having an NG-RAN architecture. In this example, the RAN entities (nodes) are gNBs. In this example, first gNB (gNB1) 501 is a split node and a second gNB (gNB2) 502 is a non-split node. In other implementations, both gNBs may be non-split or split, or gNB 501 may be non-split and gNB 502 may be split. The gNBs 501 and 502 can communicate via an Xn interface 520. The gNBs are part of the RAN of the mobile network. The gNBs are RAN entities. The mobile network also has a CN, which may be a 5G core (5GC) . The CN in this example comprises an AMF 503. The 5GC comprising AMF 503 can communicate with the gNB 501 via an NG interface 504. The AMF may communicate with the gNB-CU-CP over an NG-C interface and with the gNB-CU-UP over an NG-U interface (not shown in Fig. 5) . The AMF 503 may also communicate with gNB 502 via an NG interface (not shown in Fig. 5) .

[0135] A split gNB is composed of logical sub-entities comprising one gNB-CU sub-entity and one or more gNB-DU sub-entities (examples of which are described in 3GPP TS 38.401) . The gNB-CU 505 can be split into a gNB-CU-CP 506 and one or more gNB-CU-UP entities, two of which are shown at 507 and 508. Two gNB-DU sub-entities of the split gNB are shown at 509 and 510.

[0136] The gNB-CU-CP 506 can communicate with the gNB-CU-UPs over an E1 interface, 511, 512. The gNB-CU 505 can communicate with the gNB-DUs over an F1 interface, 513, 514. The gNB-CU-CP may communicate with the gNB-DU over an F1-C interface and the gNB-CU-UP may communicate with the gNB-DU over an F1-U interface (not shown in Fig. 5) .

[0137] A UE 530 may communicate with either of gNBs 501, 502 over a Uu interface, illustrated at 531 for the communication link between gNB 501 and UE 530 where gNB 501 is the serving node.

[0138] In Fig. 5, the UE ID sent from the core network entity (AMF 503 in this example) to the UE 530 is shown at 540.

[0139] As mentioned above, a first solution comprises introducing a new CN-allocated unique UE identifier that can be propagated across NG-RAN nodes and hence be made available in gNB / gNB-CU-UP / gNB-DU, and also in the target gNB in case of handover. The UE ID can be designed with a proper “lifetime” in order to fulfil security and privacy of the user.

[0140] The new CN-allocated UE ID (referred to as nUEID below) can be used for data measurement correlation. In this example, the AMF allocates the new UE identifier (nUEID) to the UE for the purpose of UE level measurement data correlation.

[0141] When the gNB 501 (or the gNB-CU 505 or the gNB-CU-CP 507 in the case of a split gNB) has received the nEUID from the UE over a radio interface via RRC signalling, the gNB 501 can include the nUEID in the INITIAL UE MESSAGE sent from the gNB 501 to the AMF 503 over the NG interface 504. In the case of a split gNB, the nUEID can be included in the INITIAL UE MESSAGE sent from the gNB-CU 505 (or from the gNB-CU-CP1 506) to the AMF 503.

[0142] If gNB1 501 is a split NG-RAN node, the gNB-CU-CP 506 can transfer the nUEID to the gNB-CU-UPs 507, 508 that it controls over the E1 interfaces 511, 512 respectively.

[0143] If gNB1 501 is a split NG-RAN node, the gNB-CU 505 can transfer the nUEID to the gNB-DUs 509, 510 that it controls over the F1 interfaces 513, 514 respectively.

[0144] Two exemplary options for performing this step will now be described.

[0145] In a first implementation, the allocated nUEID can be immediately transferred from gNB-CU 505 to the one or more gNB-DU sub-entities (in this example, there are two gNB-DU sub-entities 509, 510) via the F1 interface (513 and 514) . The F1AP UE Context Setup procedure in TS 38.473 may be used. The allocated nUEID can be immediately transferred from gNB-CU-CP 506 to the one or more gNB-CU-UP sub-entities (in this example, there are two gNB-CU-UP sub-entities 507, 508) via the E1 interface (511, 512) . The E1AP Bearer Context Setup procedure in TS 37.483 may be used.

[0146] In a second implementation, the nUEID can be kept (for example, stored at a memory of the gNB) only in gNB1 501. The nUEID can be kept (for example, stored in memory) at the gNB-CU 505 and can be propagated to the one or more gNB-DU sub-entities (509, 510) only when it is needed. The nUEID can be kept (for example, stored in memory) at the gNB-CU-CP 506, and can be propagated to the one or more gNB-CU-UP sub-entities (507, 508) only when it is needed.

[0147] In this case, since it can be assumed that the UE context in the one or more gNB-DU sub-entities 509, 510 (and / or the bearer context in the one or more gNB-CU-UP sub-entities 507, 508) has already been established, the F1AP UE Context Modification procedure in TS 38.473 (or the E1AP Bearer Context Modification procedure in TS 37.483) could be used.

[0148] In the case of Xn-handover (and if the nUEID has not been reallocated due to e.g. associated validity timer expiration) the nUEID can be transferred over the Xn interface from the source gNB1 501 to the target gNB2 502 in the HANDOVER REQUEST message or, alternatively, in the RRC container (for example, RRC Context as specified in TS 38.423) within the HANDOVER REQUEST message.

[0149] In case of NG-handover, via the AMF 503 (and if the nUEID has not been reallocated due to e.g. associated validity timer expiration) , the nUEID is transferred over the NG interface to the target gNB2 502 in the HANDOVER REQUEST (AMF to gNB2) message or, alternatively, in the “Source to Target Transparent Container” within the HANDOVER REQUEST message.

[0150] For the case where, after either Xn-or NG-handover, the target gNB2 502 requires the nUEID for the purpose of correlation of measurement data for the concerned UE (for example, the target gNB2 502 decides to configure the UE to perform Continuous MDT after the handover completion) but the target gNB2 502 does not have any nUEID for the UE because such information has not been sent from the source gNB1 501 over the Xn 520 or NG 504 interface, then, for example, the NGAP Path Switch Request procedure in TS 38.413 could be triggered by the target gNB2 502 towards the AMF 503 to retrieve the nUEID allocated by the AMF 503 to that UE 530.

[0151] When the AMF 503 re-allocates the nUEID, the AMF 503 can send it to the UE 530 via NAS signalling, and the serving gNB1 501 is made aware of such nUEID re-allocation via either one of the following options:

[0152] In a first implementation, the UE 530 can inform the gNB1 501 (or the gNB-CU 505  / gNB-CU-CP 506 in the case of a split gNB) about the nUEID re-allocation, for example via RRC signalling.

[0153] In a second implementation, the AMF 503 can send the newly allocated nUEID for the UE to the serving gNB1 501 (or the gNB-CU 505  / gNB-CU-CP 506 in the case of a split gNB) , for example via NG signalling. The UE Context Modification procedure in TS 38.413 or, alternatively, the Downlink NAS Transport procedure in TS 38.413 could be used.

[0154] In a third implementation, the serving gNB1 501 (or the gNB-CU 505  / gNB-CU-CP 506 in the case of a split gNB) can retrieve the latest nUEID from AMF 503, for example whenever needed, via NG signalling.

[0155] The third implementation can also be useful when, in the case of Xn-handover, the source gNB1 501 does not provide the nUEID in the HANDOVER REQUEST message (or, alternatively, in the RRC container (such as RRC Context as specified in TS 38.423) within the HANDOVER REQUEST message) over the Xn interface.

[0156] The third implementation can also be useful for the case where, after either Xn-or NG-handover, the target gNB2 502 requires the nUEID for the purpose of correlation of measurement data for the concerned UE (for example, the target gNB2 502 decides to configure the UE 530 to perform Continuous MDT after the handover completion) but the target gNB2 502 does not have the nUEID because such information has not been sent from the source gNB1 501 over Xn / NG interface (520 / 504) . The Path Switch Request procedure in TS 38.413 could be triggered by the target gNB2 502 towards the AMF 503 to retrieve the nUEID allocated by the AMF 503 to that UE 530.

[0157] Once the gNB1 501 (or the gNB-CU 505  / gNB-CU-CP 506 in the case of a split gNB) has stored the newly allocated nUEID, it can be propagated if Xn- / NG-handover is triggered or, in case of split gNB, by using one of the above-described approaches to transfer the newly allocated nUEID to the one or more gNB-DU 509, 510 and gNB-CU-UP 507, 508 sub-entities. The UE Context Modification procedure in TS 38.473 and the Bearer Context Modification procedure in TS 37.483 could be used for informing the gNB-DU 509, 510 and gNB-CU-UP 508 sub-entities respectively, about the newly allocated nUEID.

[0158] To overcome technical problems such as those described above concerning the currently available UE IDs (for example, 5G-S-TMSI etc. ) which prevent such UE IDs to be suitable enablers for the correlation of measurement data for a given UE, an alternative solution is to enhance the existing 5G-S-TMSI so that it can be propagated across NG-RAN nodes and hence be made available in gNB / gNB-CU-UP / gNB-DU, and also in the target gNB in the case of handover.

[0159] To enhance the existing 5G-S-TMSI, one or more of the following steps may be applied. The arrangement shown in Fig. 5 also applies to this situation.

[0160] The AMF 503 allocates the 5G-S-TMSI to the UE 530. The AMF may allocate the 5G-S-TMSI to the UE for the first time (i.e. as a first identifier) . The 5G-S-TSMI may be intended to be used also for the purpose of UE level measurement data correlation (other than for the other purposes as currently specified by 3GPP, e.g., CN-based UE paging) .

[0161] When gNB1 501 (gNB-CU 505 / gNB-CU-CP 506 if gNB1 is a split node) has received from the radio interface via RRC signalling the 5G-S-TMSI, it can include the 5G-S-TMSI in the INITIAL UE MESSAGE over the NG interface (from gNB1 to AMF, or from gNB-CU  / gNB-CU-CP to AMF in the case of a split gNB) .

[0162] If gNB1 501 is a split NG-RAN node, as in Fig. 5, the gNB-CU 505 can transfer the 5G-S-TMSI as the UE ID to the one or more gNB-DU sub-entities (509 and 510 in this example) that it controls over the F1 interface (513, 514) .

[0163] The gNB-CU-CP 506 can transfer the 5G-S-TMSI to the one or more gNB-CU-UP sub-entities (507 and 508 in this example) that it controls over the E1 interface (511 and 512) .

[0164] Two exemplary options for performing this step will now be described.

[0165] In a first implementation, the allocated 5G-S-TSMI can be immediately transferred from gNB-CU 505 to the one or more gNB-DU sub-entities (in this example, there are two gNB-DU sub-entities 509, 510) via the F1 interface (513 and 514) . The F1AP UE Context Setup procedure in TS 38.473 may be used. The allocated 5G-S-TSMI can be immediately transferred from gNB-CU-CP 506 to the one or more gNB-CU-UP sub-entities (in this example, there are two gNB-CU-UP sub-entities 507, 508) via the E1 interface (511, 512) . The E1AP Bearer Context Setup procedure in TS 37.483 may be used.

[0166] In a second implementation, the 5G-S-TMSI can be kept (for example, stored at a memory of the gNB) only in gNB1 501. The 5G-S-TMSI can be kept (for example, stored in memory) at the gNB-CU 505 and can be propagated to the one or more gNB-DU sub-entities (509, 510) only when it is needed. The 5G-S-TMSI can be kept (for example, stored in memory) at the gNB-CU-CP 506, and can be propagated to the one or more gNB-CU-UP sub-entities (507, 508) only when it is needed.

[0167] In this case, since it can be assumed that the UE context in the one or more gNB-DU sub-entities 509, 510 (and / or the bearer context in the one or more gNB-CU-UP sub-entities 507, 508) has already been established, the F1AP UE Context Modification procedure in TS 38.473 (or the E1AP Bearer Context Modification procedure in TS 37.483) could be used.

[0168] In the case of Xn-handover (and if the 5G-S-TMSI has not been reallocated due to e.g. associated validity timer expiration) the 5G-S-TMSI is transferred over the Xn interface 520 to the target gNB2 502 in the HANDOVER REQUEST message or, alternatively, in the RRC container (for example, RRC Context as specified in TS 38.423) within the HANDOVER REQUEST message.

[0169] In case of NG-handover (and if the 5G-S-TMSI has not been reallocated due to e.g. associated validity timer expiration) the 5G-S-TMSI is transferred over the NG interface 504 to the target gNB2 502 in the HANDOVER REQUEST (AMF 503 to gNB2 502) message or, alternatively, in the “Source to Target Transparent Container” within the HANDOVER REQUEST message.

[0170] For the case where, after either Xn-or NG-handover, the target gNB2 requires the 5G-S-TMSI for the purpose of correlation of measurement data for the concerned UE (e.g., target gNB2 502 decides to configure the UE 530 to perform Continuous MDT after the handover completion) but the target gNB2 502 does not have any 5G-S-TMSI for the UE because such information has not been sent from the source gNB1 502 over Xn / NG interface 520 / 504, then the NGAP Path Switch Request procedure in TS 38.413 could be triggered by the target gNB2 502 towards the AMF 503 to retrieve the 5G-S-TMSI allocated by the AMF 503 to that UE 530.

[0171] When the AMF 503 re-allocates the 5G-S-TMSI, the AMF 503 can send it to the UE530 via NAS signalling, and the serving gNB1 501 can be made aware of such 5G-S-TMSI re-allocation via one of the following options:

[0172] In a first implementation, the UE 530 can inform the gNB1 501 (or the gNB-CU  / gNB-CU-CP in the case of a split gNB) about the 5G-S-TMSI re-allocation via RRC signalling.

[0173] In a second implementation, the AMF 503 can send the newly allocated 5G-S-TMSI for the UE to the serving gNB1 501 (or the gNB-CU  / gNB-CU-CP in the case of a split gNB) via NG signalling. The UE Context Modification procedure in TS 38.413 or, alternatively, the Downlink NAS Transport procedure in TS 38.413 could be used.

[0174] In a third implementation, the serving gNB1 501 (or the gNB-CU 505  / gNB-CU-CP 506 in the case of a split gNB) can retrieve the latest 5G-S-TMSI from AMF, for example whenever needed, via NG signalling.

[0175] The third implementation can also be useful when, in the case of Xn-handover, the source gNB1 does not provide the 5G-S-TMSI in the HANDOVER REQUEST message (or, alternatively, in the RRC container (for example RRC Context as specified in TS 38.423) within the HANDOVER REQUEST message) over the Xn interface.

[0176] The third implementation can also be useful for the case where, after either Xn-or NG-handover, the target gNB2 502 requires the 5G-S-TMSI for the purpose of correlation of measurement data for the concerned UE 530 (for example, the target gNB2 502 decides to configure the UE 530 to perform Continuous MDT after the handover completion) but the target gNB2 502 does not have the 5G-S-TMSI because such information has not been sent from the source gNB1 501 over the Xn / NG interface 520 / 504. The Path Switch Request procedure in TS 38.413 could be triggered by the target gNB2 502 towards the AMF 503 to retrieve the 5G-S-TMSI allocated by the AMF 503 to that UE 530.

[0177] Once the gNB1 501 (or the gNB-CU 505  / gNB-CU-CP 506 in the case of a split gNB) has stored the newly allocated 5G-S-TMSI, it can be propagated if Xn- / NG-handover is triggered or, in case of split gNB, by using one of the above-described approaches to transfer the newly allocated 5G-S-TMSI to the one or more gNB-DU 509, 510 and gNB-CU-UP 507, 508 sub-entities. The UE Context Modification procedure in TS 38.473 and the Bearer Context Modification procedure in TS 37.483 could be used for informing the gNB-DU 509, 510 and gNB-CU-UP 507, 508 sub-entities respectively, about the newly allocated 5G-S-TMSI.

[0178] In general, for all of the exemplary options described above, the following aspects are related to the validity time of the UE identifier.

[0179] i. When and how to transfer the allocated UE identifier within the NG-RAN

[0180] ii. How to deal with UE identifier re-allocation by the AMF

[0181] Concerning aspect i., consider the scenario where the UE has been allocated with a UE identifier for the first time.

[0182] If gNB1 is a non-split gNB: once the gNB1 receives the allocated UE identifier from the UE (via RRC signalling) , the gNB1 (source node) can transfer the UE identifier to a target node, gNB2, if Xn- / NG-handover is triggered.

[0183] For the case where, after the handover, the target gNB2 decides to configure the UE to perform, for example, Continuous MDT but the target gNB2 does not have any identifier for the UE because such information has not been sent from the source gNB1 over the Xn or NG interface as appropriate) , a NGAP Path Switch Request procedure, for example as described in 3GPP TS 38.413, can be triggered by the target gNB2 towards the AMF to retrieve the UE identifier allocated by the AMF to that UE.

[0184] If gNB1 is a split gNB, as shown in Fig. 5, in addition to the node behaviour for the handover as described above, the allocated UE identifier may be made available in the gNB-DU 509, 510 and gNB-CU-UP 507, 508 sub-entities via F1 513, 514 and E1 511, 512 interfaces, respectively.

[0185] Below are two exemplary options for achieving this.

[0186] In one implementation, the allocated UE ID can be immediately transferred from gNB-CU 505 to the one or more gNB-DU sub-entities (in this example, there are two gNB-DU sub-entities 509, 510) via the F1 interface (513 and 514) . The F1AP UE Context Setup procedure in TS 38.473 may be used. The allocated UE ID can be immediately transferred from gNB-CU-CP 506 to the one or more gNB-CU-UP sub-entities (in this example, there are two gNB-CU-UP sub-entities 507, 508) via the E1 interface (511, 512) . The E1AP Bearer Context Setup procedure in TS 37.483 may be used.

[0187] In another implementation, the UE ID can be kept (for example, stored at a memory of the gNB) only in gNB1 501. The UE ID can be kept (for example, stored in memory) at the gNB-CU 505 and can be propagated to the one or more gNB-DU sub-entities (509, 510) only when it is needed. The UE ID can be kept (for example, stored in memory) at the gNB-CU-CP 506, and can be propagated to the one or more gNB-CU-UP sub-entities (507, 508) only when it is needed. For example, UE ID may be needed if the UE is selected to perform Continuous MDT by the gNB-CU  / gNB-CU-CP.

[0188] In this case, since it can be assumed that the UE context in the one or more gNB-DU sub-entities 509, 510 (and / or the bearer context in the one or more gNB-CU-UP sub-entities 507, 508) has already been established, the F1AP UE Context Modification procedure in TS 38.473 (or the E1AP Bearer Context Modification procedure in TS 37.483) could be used.

[0189] Concerning aspect ii., instead, consider the scenario where the UE has been allocated with a new UE identifier, i.e., there is a re-allocation of the UE identifier by the AMF 503.

[0190] When the AMF 503 re-allocates the UE identifier, the AMF 503 can send the UE identifier to the UE via Non Access Stratum (NAS) signalling, but the serving gNB should be made aware of such UE identifier re-allocation. This can be achieved by multiple options, some of which will be described below.

[0191] In a first exemplary option, the UE can inform the gNB (or the gNB-CU / gNB-CU-CP in the case of a split gNB) about the UE identifier re-allocation via RRC signalling.

[0192] In a second exemplary option, the AMF 503 can send the newly allocated UE identifier for the UE 530 to the serving gNB (or the gNB-CU / gNB-CU-CP in the case of a split gNB) via NG signalling. The UE Context Modification procedure, for example as described in TS 38.413 or, alternatively, the Downlink NAS Transport procedure, for example as described in 3GPP TS 38.413, could be used.

[0193] In a third exemplary option, the serving gNB (or gNB-CU / gNB-CU-CP in the case of a split node) can retrieve the latest UE identifier from the AMF, for example whenever needed, via NG signalling. This option may be useful when, in case of Xn-handover, the source gNB does not provide the UE identifier in the HANDOVER REQUEST message (or, alternatively, in the RRC container (for example, RRC Context as specified in TS 38.423) within the HANDOVER REQUEST message) over the Xn interface. This option may also be useful for the case where, after the handover, the target gNB decides to configure the UE to perform Continuous MDT but the target gNB does not have the UE identifier (for example, because this information has not been sent from the source gNB over the Xn / NG interface) . In this case, the Path Switch Request procedure, for example as described in 3GPP TS 38.413, could be triggered by the target gNB towards the AMF to retrieve the UE ID allocated by the AMF to that UE.

[0194] Once the gNB (or the gNB-CU / gNB-CU-CP in the case of a split gNB) has stored the newly allocated UE ID, it can be propagated if Xn- / NG-handover is triggered or, in case of split gNB, by following one of the above-described options to transfer the newly allocated UE ID to the gNB-DU and gNB-CU-UP. The UE Context Modification procedure described in TS 38.473 and the Bearer Context Modification procedure described in TS 37.483 could be used for informing the gNB-DU and the gNB-CU-UP, respectively, about the newly allocated UE ID.

[0195] Fig. 6 illustrates the steps of an exemplary method for implementation at a radio access network entity in a mobile network. At step 601, the method comprises receiving a user equipment identifier for user equipment-level measurement data correlation  from a user equipment device in the mobile network. At step 602, the method comprises sending the user equipment identifier from a sub-entity of the radio access network entity to one or more other sub-entities of the radio access network entity.

[0196] Fig. 7 illustrates the steps of an exemplary method for implementation at a radio access network entity in a mobile network. At step 701, the method comprises receiving a user equipment identifier for user equipment-level measurement data correlation from a user equipment device in the mobile network. At step 702, the method comprises sending the user equipment identifier to one or more other network entities in the mobile network, wherein the radio access network entity is a source node in a communication session with the user equipment device, and wherein the one or more other radio access network entities comprise a target node to which the communication session is to be handed over.

[0197] Fig. 8 illustrates the steps of an exemplary method for implementation at a core network entity in a mobile network. At step 801, the method comprises allocating a user equipment identifier for the purpose of user equipment-level measurement data correlation to a user equipment device in the mobile network.

[0198] Fig. 9 illustrates the steps of an exemplary method for implementation at a user equipment device in a mobile network. At step 901, the method comprises receiving a user equipment identifier from a core network entity of the mobile network, the user equipment identifier being allocated to the user equipment device for the purpose of user equipment-level measurement data correlation. At step 902, the method comprises signalling the user equipment identifier to a radio access network entity of the mobile network.

[0199] Embodiments of the present disclosure may provide at least the following advantages.

[0200] A new CN-allocated UE ID can uniquely identify the UE (within at least the AMF pool) and may be designed for the purpose of being propagated across NG-RAN nodes (within a split gNB, as well as from one RAN entity (e.g. gNB) to another) . The new UE ID is by design available in all RAN entities so that UE level measurement data correlation can be easily achieved. Since it is a CN-allocated UE ID, the same principles adopted for the 5G-S-TMSI in terms of temporary validity can be re-used, hence limiting the specification impact (from at least a security perspective) .

[0201] When using an existing UE ID, such as the 5G-S-TMSI, the identifier can uniquely identify the UE (within the AMF pool) and it is enhanced so that it can be propagated across NG-RAN nodes (within the split gNB as well as from one gNB to another) . The 5G-S-TMSI usage is extended with respect to its original meaning (UE paging, periodic service request) in order to correctly reflect the enhanced usage. There are no impacts to network domains other than the RAN, as an existing UE ID (such as 5G-S-TMSI) is used.

[0202] The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein. The applicant indicates that aspects of the present disclosure may consist of any such individual feature or combination of features. In view of the foregoing description, it will be evident to a person skilled in the art that various modifications may be made within the scope of the disclosure.

Claims

1.A radio access network entity (501) for use in a mobile network (500) , the radio access network entity being configured to:receive (601) a user equipment identifier (540) for user equipment-level measurement data correlation from a user equipment device (530) in the mobile network; andsend (602) the user equipment identifier from a sub-entity (505, 506) of the radio access network entity to one or more other sub-entities (509, 510, 507, 508) of the radio access network entity.2.The radio access network entity (501) as claimed in claim 1, wherein the radio access network entity is a split gNodeB comprising a gNB-CU-CP sub-entity, one or more gNB-DU sub-entities and one or more gNB-CU-UP sub-entities, wherein the radio access network entity is configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-DU sub-entities and / or one or more of the gNB-CU-UP sub-entities of the radio access network entity.3.The radio access network entity (501) as claimed in claim 2, wherein the radio access network entity is configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-DU sub-entities and / or one or more of the gNB-CU-UP sub-entities via an F1 and / or E1 interface.4.The radio access network entity (501) as claimed in claim 3, wherein the radio access network entity is configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-DU sub-entities via an F1 interface using an F1AP UE Context Setup procedure and / or F1AP UE Context Modification procedure.5.The radio access network entity (501) as claimed in claim 3, wherein the radio access network entity is configured to transfer the user equipment identifier from the gNB-CU-CP sub-entity to one or more of the gNB-CU-UP sub-entities via an E1 interface using an E1AP Bearer Context Setup procedure and / or E1AP Bearer Context Modification procedure.6.The radio access network entity (501) as claimed in any preceding claim, wherein the radio access network entity is configured to send the user equipment identifier to one or more other network entities in the mobile network.7.The radio access network entity (501) as claimed in claim 6, wherein the one or more other network entities comprises a core network entity.8.The radio access network entity (501) as claimed in claim 7, wherein the core network entity is an access and mobility management function.9.The radio access network entity (501) as claimed in claim 7 or claim 8, wherein the radio access network entity is configured to send the user equipment identifier to the core network entity via an NG interface.10.The radio access network entity (501) as claimed in claim 9, wherein the radio access network entity is configured to send the user equipment identifier to the core network entity in an INITIAL UE MESSAGE.11.The radio access network entity (501) as claimed in any of claims 6 to 10, wherein the one or more other network entities comprise one or more other radio access network entities.12.The radio access network entity (501) as claimed in claim 11, wherein the user equipment identifier is sent to the, or each, radio access network entity via an Xn interface.13.The radio access network entity (501) as claimed in claim 11 or claim 12, wherein the radio access network entity is a source node in a communication session with the user equipment device, and wherein the one or more other radio access network entities comprise a target node to which the communication session is to be handed over.14.The radio access network entity (501) as claimed in claim 13, wherein the source node is configured to send the user equipment identifier to the target node in a HANDOVER REQUEST message.15.The radio access network entity (501) as claimed in claim 14, wherein the source node is configured to send the user equipment identifier to the target radio node in an RRC container within the HANDOVER REQUEST message.16.The radio access network entity (501) as claimed in claim 13 as dependent on claim 11 as further dependent on claim 8, wherein the source node is configured to send the user equipment identifier to the target node via the access and mobility management function.17.The radio access network entity (501) as claimed in claim 16, wherein the source node is configured to send the user equipment identifier over the NG interface to the access and mobility management function in a HANDOVER REQUIRED message.18.The radio access network entity (501) as claimed in claim 17, wherein the source node is configured to send the user equipment identifier to the core network entity in a transparent container within the HANDOVER REQUIRED message.19.The radio access network entity (501) as claimed in any preceding claim, wherein the radio access network entity is configured to receive the user equipment identifier from the user equipment device via RRC signalling.20.The radio access network entity (501) as claimed in any preceding claim, wherein the user equipment identifier is a core network-allocated user identifier.21.The radio access network entity (501) as claimed in claim 20, wherein the user equipment identifier is a new user identifier allocated to the user equipment device for the purpose of user equipment-level measurement data correlation, or a 5G-S-TMSI.22.The radio access network entity (501) as claimed in any preceding claim, wherein the user equipment identifier is designated with a lifetime by its allocating entity.23.A radio access network entity (501) for use in a mobile network (500) , the radio access network entity being configured to:receive (701) a user equipment identifier (540) for user equipment-level measurement data correlation from a user equipment device (530) in the mobile network; andsend (702) the user equipment identifier to one or more other network entities (502) in the mobile network, wherein the radio access network entity (501) is a source node in a communication session with the user equipment device (530) , and wherein the one or more other radio access network entities comprise a target node (502) to which the communication session is to be handed over.24.The radio access network entity (501) as claimed in claim 23, wherein the source node is configured to send the user equipment identifier to the target node if Xn-or NG-handover is triggered.25.The radio access network entity (501) as claimed in claim 23 or claim 24, wherein the source node is configured to send the user equipment identifier to the target node in a HANDOVER REQUEST message.26.The radio access network entity (501) as claimed in claim 25, wherein the source node is configured to send the user equipment identifier to the target radio node in an RRC container within the HANDOVER REQUEST message.27.The radio access network entity (501) as claimed in any of claims 23 to 26, wherein the radio access network entity is configured to send the user equipment identifier to one or more other network entities in the mobile network.28.The radio access network entity (501) as claimed in claim 27, wherein the one or more other network entities comprises a core network entity.29.The radio access network entity (501) as claimed in claim 28, wherein the core network entity is an access and mobility management function.30.The radio access network entity (501) as claimed in claim 28 or claim 29, wherein the radio access network entity is configured to send the user equipment identifier to the core network entity via an NG interface.31.The radio access network entity (501) as claimed in any of claims 28 to 30, wherein the radio access network entity is configured to send the user equipment identifier to the core network entity in an INITIAL UE MESSAGE.32.The radio access network entity (501) as claimed in any of claims 28 to 31, wherein the source node is configured to send the user equipment identifier to the target node via the core network entity.33.The radio access network entity (501) as claimed in claim 32 as dependent on claim 30, wherein the source node is configured to send the user equipment identifier over the NG interface to the core network entity in a HANDOVER REQUIRED message.34.The radio access network entity (501) as claimed in claim 33, wherein the source node is configured to send the user equipment identifier to the core network entity in a transparent container within the HANDOVER REQUIRED message.35.The radio access network entity (501) as claimed in claim 27, wherein the one or more other network entities comprise one or more other radio access network entities, wherein the user equipment identifier is sent to the, or each, radio access network entity via an Xn interface.36.The radio access network entity (501) as claimed in any of claims 23 to 35, wherein the user equipment identifier is a core network-allocated user identifier.37.The radio access network entity (501) as claimed in claim 36, wherein the user equipment identifier is a new user identifier allocated to the user equipment device for the purpose of user equipment-level measurement data correlation, or a 5G-S-TMSI.38.The radio access network entity (501) as claimed in any of claims 23 to 37, wherein the user equipment identifier is designated with a lifetime by its allocating entity.39.The radio access network entity (501) as claimed in any of claims 23 to 38, wherein the radio access network entity is configured to receive the user equipment identifier from the user equipment device via RRC signalling.40.The radio access network entity (501) as claimed in any of claims 23 to 39, wherein the radio access network entity is a gNodeB.41.A core network entity (503) for use in a mobile network, the core network entity being configured to allocate a user equipment identifier for the purpose of user equipment-level measurement data correlation to a user equipment device in the mobile network.42.The core network entity (503) as claimed in claim 41, wherein the core network entity is configured to send the user equipment identifier to a serving radio access network entity in a communication session with the user equipment device via NG signalling.43.The core network entity (503) as claimed in claim 42, wherein the core network entity is configured to send the user equipment identifier to the serving radio access network entity in response to a request from the serving radio access network entity to retrieve the user equipment identifier.44.The core network entity (503) as claimed in claim 43, wherein the serving radio access network entity is a target node in an Xn-or NG-handover procedure for the user equipment device and wherein the target node is configured to retrieve the user equipment identifier from the core network entity by triggering an NGAP Path Switch Request procedure with the core network entity.45.The core network entity (503) as claimed in claim 42, wherein the core network entity is configured to send the user equipment identifier to the serving radio access network entity via a UE Context Modification procedure or a Downlink NAS Transport procedure.46.The core network entity (503) of any of claims 41 to 45, wherein the core network entity is an access and mobility management function.47.A user equipment device (530) for use in a mobile network, the user equipment device being configured to:receive a user equipment identifier from a core network entity of the mobile network, the user equipment identifier being allocated to the user equipment device for the purpose of user equipment-level measurement data correlation; andsignal the user equipment identifier to a radio access network entity of the mobile network.48.The user equipment device (530) as claimed in claim 47, wherein the radio access network entity is a gNodeB.49.The user equipment device (530) as claimed in claim 47 or claim 48, wherein the core network entity is an access and mobility management function.50.The user equipment device (530) as claimed in any of claims 47 to 49, wherein the user equipment identifier is a re-allocated user equipment identifier.51.A method (600) for implementation at a radio access network entity (501) in a mobile network (500) , the method comprising:receiving (601) a user equipment identifier (540) for user equipment-level measurement data correlation from a user equipment device (530) in the mobile network; andsending (602) the user equipment identifier from a sub-entity (505, 506) of the radio access network entity to one or more other sub-entities (509, 510, 507, 508) of the radio access network entity.52.A method (700) for implementation at a radio access network entity (501) in a mobile network, the method comprising:receiving (701) a user equipment identifier (540) for user equipment-level measurement data correlation from a user equipment device (530) in the mobile network; andsending (702) the user equipment identifier to one or more other network entities (502) in the mobile network, wherein the radio access network entity (501) is a source node in a communication session with the user equipment device (530) , and wherein the one or more other radio access network entities comprise a target node (502) to which the communication session is to be handed over.53.A method (800) for implementation at a core network entity (503) in a mobile network, the method comprising allocating (801) a user equipment identifier (540) for the purpose of user equipment-level measurement data correlation to a user equipment device (530) in the mobile network.54.A method (900) for implementation at a user equipment device (530) in a mobile network, the method comprising:receiving (901) a user equipment identifier (540) from a core network entity of the mobile network, the user equipment identifier being allocated to the user equipment device for the purpose of user equipment-level measurement data correlation; andsignalling (902) the user equipment identifier to a radio access network entity (501) of the mobile network.

Images