Method and apparatus to enable data collection for ai / ML assisted positioning of served and non-served equipment

Abstract

According to an aspect, there is provided a method for execution by a first network node (e.g. RAN node). The method involves sending, to another network node (e.g. AMF node or LMF node), a request for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit) or a served UE. The method also involves receiving a response including either (i) the ground truth information for the at least one equipment or (ii) an indication that the ground truth information cannot be provided. The solution enables the first network node to trigger a request specific to the equipment or specific to radio conditions or to reference signal configuration for data collection for the purpose of achieving training or monitoring data for an AI / ML assisted model.

Description

[0001] METHOD AND APPARATUS TO ENABLE DATA COLLECTION

[0002] FOR AI / ML ASSISTED POSITIONING OF SERVED AND NON-SERVED EQUIPMENT

[0003] Related Application

[0004] [1] This application claims priority from US provisional application no.

[0005] 63 / 740441 filed on December 31, 2024 and entitled “Method and Apparatus to Enable Data Collection for AI / ML Assisted Positioning of Non-Served Equipment” and US provisional application no. 63 / 740432 filed on December 31, 2024 and entitled “Method and Apparatus to Enable Data Collection for AI / ML Assisted Positioning of Served Data”, which are both incorporated by reference in their entirety.

[0006] Field of the Disclosure

[0007] [2] This disclosure relates to mobile communication systems, and more particularly to data collection for an Artificial Intelligence I Machine Learning (AI / ML) model for predicting positioning of equipment in a defined area.

[0008] Background

[0009] [3] None of the material in the background section should be interpreted to be Applicant’s admitted prior art.

[0010] AI / ML Modeling and Associated Principles

[0011] [4] An Artificial Intelligence (Al) or Machine Learning (ML) technique includes one or more algorithms which use a set of data as input for training one or more AI / ML models. In the context of a wireless communication system such as, for example, a 3rdGeneration Partnership Project (3GPP) 5thGeneration System (5GS), the output of an AI / ML model can be used by a network entity (e.g. user equipment (UE), base station (BS), or another node) for performing certain operations or taking certain decisions (e.g. handover, etc.) fully or partially based on a prediction (i.e., the output of the AI / ML model), which in turn depends on the trained AI / ML model. The AI / ML model can betrained in the network entity online (or on-the-fly while processing data) or offline in the background. More specifically:

[0012] • Online training is an AI / ML training process where the AI / ML model being used for inference is (typically continuously) trained in (near) real-time with the arrival of new training samples or data; and

[0013] • Offline training is an AI / ML training process where the AI / ML model is trained based on collected samples or data, and where the trained AI / ML model is later used or delivered for inference.

[0014] [5] AI / ML model inference refers to a process of using a trained AI / ML model to produce a set of outputs based on a set of inputs.

[0015] [6] The AI / ML models can be trained in a network entity or device, which can be a UE, a network node, or another node.

[0016] • Case I: UE-side (AI / ML) model. A UE-side AI / ML model is an AI / ML model whose inference is performed entirely at the UE.

[0017] • Case II: Network-side (AI / ML) model. A network-side AI / ML model is an AI / ML model whose inference is performed entirely at the network.

[0018] • Case III: One-sided (AI / ML) model. A one-sided AI / ML model is a UE-side (AI / ML) model or a network-side (AI / ML) model.

[0019] • Case IV: Two-sided (AI / ML) model. A two-sided AI / ML model is a paired AI / ML model(s) over which joint inference is performed, where joint inference comprises AI / ML Inference whose inference is performed jointly across the UE and the network, i.e., the first part of inference is firstly performed by UE and then the remaining part is performed by a base station (e.g., a gNodeB (gNB) in the case of New Radio (NR)), or vice versa.

[0020] [7] An AI / ML model can be transferred or delivered over the air interface either in terms of one or more parameters of a model structure known at the receiving end or a new model with parameters. The model delivery may contain a full model or a partial model.[8] The term “lifecycle management (LCM)” of an AI / ML model refers to the process of developing, deploying, and maintaining the AI / ML model. An example of the AI / ML model training pipeline illustrating different stages is shown in Figure 1. An AI / ML model training pipeline includes several processing stages including gathering unprocessed input data from data repositories (data ingestion) 101, finding high-quality input features (data pre-processing) 102, finding the optimal mapping of the model input features to a desired model output target in a sense determined by a loss function (model training) 103, and evaluating model performance on unseen data from a functional level as well as from a system level when relevant (model evaluation) 104. The training pipeline typically ends with a model registration stage 105, which may include operations to make the AI / ML model runnable via compilation to a specific hardware and steps like versioning and packaging of the AI / ML model so that it can be executed.

[0021] AI / ML Model Based Positioning

[0022] [9] A new use case addressed by 3GPP is that an AI / ML model can be used for UE positioning. A UE or a gNB, depending on capability, can have a trained AI / ML model stored inside the device, or have an untrained AI / ML model that can be trained on-the-fly to either produce measurements to localize a UE within a Radio Access Network (RAN) coverage area or directly predict or determine the UE location by exploiting measurements performed by the UE or gNB on reference signals such as Positioning Reference Signal (PRS), Sounding Reference Signal (SRS), etc. within the RAN coverage area.

[0023]

[0010] Measurements predicted / determined by the gNB by exploiting an AI / ML model can include, but are not limited to:

[0024] • gNB Rx-Tx time difference: The gNB Rx-Tx time difference is defined as T9NB-RX - TgNB-Tx where:

[0025] o TgNB-Rx is the positioning node received timing of uplink subframe #i containing Sounding Reference Signal (SRS) associated with UE, defined by the first detected path in time. It is measured on SRS signals received from the UE.o TgNB-Tx is the positioning node transmit timing of downlink subframe #j that is closest in time to the subframe #i received from the UE.

[0026] • Uplink (UL) Relative Time of Arrival (UL RTOA): UL RTOA is defined as the beginning of subframe i containing SRS received in positioning node j, relative to a configurable reference time. For example, nodel (e.g., base station, etc.) measures the reception time of signals transmitted by the UE with respect to a reference time.

[0027] AI / ML Assisted Network Positioning

[0028]

[0011] In this mode, the positioning measurements are performed by the gNB by using the AI / ML model. After completion, the positioning measurements are then reported to the location server. The location server, upon receiving measurements, determines the location of the UE within the RAN coverage area. The location server, depending on the need, may forward the UE location to another node within the network to facilitate provisioning of UE location information to the application layer or a third party that is interested or has requested the positioning of the UE within the RAN coverage area for further action to be taken.

[0029] Representative Use Cases for AI / ML

[0030]

[0012] The following are selected as representative sub-use cases:

[0031] • Direct AI / ML positioning:

[0032] o AI / ML model output: UE location

[0033] o e.g., fingerprinting based on channel observation as the input of AI / ML model

[0034] • AI / ML assisted positioning:

[0035] o AI / ML model output: new measurement and / or enhancement of existing measurement

[0036] o e.g., Line-Of-Sight (LOS) / Non-LOS (NLOS) identification, timing and / or angle of measurement, likelihood of measurement

[0013] More specifically, the following Cases are considered for study:

[0037] • Case 1: UE-based positioning with UE-side model, direct AI / ML or AI / ML assisted positioning

[0038] • Case 2a: UE-assisted / Location Management Function (LMF)-based positioning with UE-side model, AI / ML assisted positioning

[0039] • Case 2b: UE-assisted / LMF-based positioning with LMF-side model, direct AI / ML positioning

[0040] • Case 3a: Next Generation RAN (NG-RAN) node assisted positioning with gN 13- side model, AI / ML assisted positioning

[0041] • Case 3b: NG-RAN node assisted positioning with LMF-side model, direct AI / ML positioning

[0042]

[0014] One-sided model whose inference is performed entirely at the UE or at the network is prioritized in the 3GPP Rel-18 Study Item.

[0043]

[0015] For all five positioning cases (Case 1 / 2a / 2b / 3a / 3b), RAN1 has not considered prioritization.

[0044]

[0016] For positioning enhancement use case:

[0045] • For AI / ML model training, training data can be generated by UE / Positioning Reference Unit (PRU) / gNB / LMF.

[0046] • For LMF-side model inference (Case 2b, Case 3b), input data can be generated by UE / gNB and terminated at LMF.

[0047] • For gNB-side model inference (Case 3a), input data is internally available at gNB.

[0048] • For UE-side model inference (Case 1, Case 2a), input data is internally available at UE.

[0049] • For performance monitoring at the LMF side, calculated performance metrics (if needed) or data needed for performance metric calculation (if needed) can be generated by UE / gNB and terminated at LMF.• For performance monitoring at the gNB side, calculated performance metrics (if needed) or data needed for performance metric calculation (if needed) can be generated by at least gNB.

[0050] Related Aspects in Release 19 WID for AI / ML Positioning

[0051]

[0017] 3GPP Work Item Description (WID) RP-242399 entitled “Revised WID on Artificial Intelligence (Al) / Machine Learning (ML) for NR Air Interface” dated September 2024 has the following Information:

[0052] • Positioning accuracy enhancements, encompassing [RAN1 / RAN2 / RAN3]: o Direct AI / ML positioning:

[0053] ■ (1stpriority) Case 1: UE-based positioning with UE-side model, direct AI / ML positioning.

[0054] ■ (2ndpriority) Case 2b: UE-assisted / LMF-based positioning with LMF-side model, direct AI / ML positioning.

[0055] ■ (1stpriority) Case 3b: NG-RAN node assisted positioning with LMF- side model, direct AI / ML positioning.

[0056] • AI / ML assisted positioning:

[0057] o (2ndpriority) Case 2a: UE-assisted / LMF-based positioning with UE-side model, AI / ML assisted positioning.

[0058] o (1stpriority) Case 3a: NG-RAN node assisted positioning with gNB-side model, AI / ML assisted positioning.

[0059] • Specify necessary measurements, signalling / mechanism(s) to facilitate LCM operations specific to the Positioning accuracy enhancements use cases, if any.

[0060] • Investigate and specify the necessary signalling of necessary measurement enhancements (if any).

[0061] • Enabling method(s) to ensure consistency between training and inference regarding NW-side additional conditions (if identified) for inference at UE for relevant positioning sub use cases.• Note: RAN1 will not discuss any proposals targeting 2ndpriority issues in Q4 of 2024.

[0062] NG-RAN Architecture

[0063]

[0018] Referring now to Figure 2, shown is a block diagram of an example NG-RAN 201. This Figure is a reproduction of Figure 6.1-1 of 3GPP Technical Specification (TS) 38.401 entitled “NG-RAN; Architecture description” Version 18.2.0 dated 2024-07-03 (hereinafter “3GPP TS 38.401”), which illustrates the overall architecture of the NG-RAN 201. The NG-RAN 201 has a set of gNBs 202,203 connected to a 5thGeneration Core 204 (5GC) through an NG interface. 3GPP TS 38.401 describes the overall NG-RAN architecture.

[0064]

[0019] A disaggregated gNB may have a gNB-Central Unit 205 (CU) and one or more gNB-Distributed Unit(s) 206a-b (DU(s)). The gNB-CU 205 and each gNB-DU 206a-b is connected via an F1 interface. As shown in Figure 2, this F1 interface is responsible for possible information and control signaling from a Packet Data Convergence Protocol (PDCP) entity located in the CU and Radio Link Control (RLC) entity located in the DU.

[0065] Positioning Architecture

[0066]

[0020] Before Release 16, Long Term Evolution (LTE) based positioning was the prevalent Radio Access Technology (RAT) based positioning solutions available. Starting from Release 16 specification, positioning is also supported in New Radio (NR). Referring now to Figure 3, shown is a block diagram of an example positioning architecture with NG-RAN 301. The interactions between a gNB of the NG-RAN 301 and a UE 302 is supported via the Radio Resource Control (RRC) protocol, while the location node interfaces with the UE 302 via the LTE positioning protocol (LPP). LPP is a common protocol to both NR and LTE. LMF 304 is the location node in NR which is coupled to the NG-RAN 301 via AMF 303. There are also interactions between the location node 304 and the gNB via the NR Positioning Protocol a (NRPPa) protocol.

[0067]

[0021] The positioning architecture in Figure 3 will also be used to support AI / ML based positioning. Release 19 work on introducing AI / ML based positioning will notonly exploit the legacy protocol but will also rely on already defined / existing reference signals that are used for positioning.

[0068]

[0069]

[0022] A Positioning Reference Unit (PRU) at a known location can perform positioning measurements (e.g., RSTD, RSRP, UE Rx-Tx Time Difference measurements, DL-RSCPD, DL-RSCP, etc.) and report these measurements to a location server. In addition, the PRU can transmit SRS to enable TRPs to measure and report UL positioning measurements (e.g., RTOA, UL-AoA, gNB Rx-Tx Time Difference, UL-RSCP, etc.) from PRU at a known location. The PRU measurements can be compared by a location server with the measurements expected at the known PRU location to determine correction terms for other nearby target devices. The DL- and / or UL location measurements for other target devices can then be corrected based on the previously determined correction terms.

[0070]

[0023] PRU measurements may also be provided to the target device in the assistance data,

[0071]

[0024] From a location server perspective, the PRU functionality is realized by a UE with known location. From the RAN perspective, the PRU is a UE under direct network control, that is to say, owned and deployed by the network’s operator.

[0072]

[0025] Much like a UE, a PRU can be served by a RAN node (i.e. served PRU) or not served by a RAN node (i.e. non-served PRU).

[0073] Progress in 3GPP RAN3

[0074]

[0026] 3GPP RAN3 has discussed the case of AI / ML assisted positioning and the following agreements were taken:

[0075] The LMF starts a NRPPa transaction. The gNB determines that data collection is needed.

[0076] The above agreement implies that an NRPPa transaction is always initiated by the LMF. However, a RAN node should be able to determine that data collection is needed and therefore trigger a process that leads to data collection from the LMF.

[0027] The details of how a solution to the data collection problem could be defined were not discussed, but the following high level solutions were listed in RAN3:

[0077] • Solution 1a: gNB-triggered Data Collection Request via a new NGAP message • Solution 1b: gNB-triggered Data Collection Request via a new NRPPa message • Solutionlc: gNB-triggered Data Collection Request via the existing NRPPa message

[0078] • Solution 2: “Xn-like Data Collection” over NRPPa

[0079]

[0028] Additionally, the following open points were captured as part of RAN3's discussions:

[0080] • For further study (FFS how the gNB requests the LMF and whether this request triggers positioning for the UE being requested for part B information (as defined by RAN1).

[0081] • FFS on the protocol used (NRPPa or NGAP) for the data collection request. FFS how the UE is identified.

[0082]

[0029] During discussions in RAN3 the following terminology was used to identify different types of information needed in support of use case 3a:

[0083] • The term “Part A” was used to identify the following measured metrics used as inputs to an AI / ML inference process:

[0084] o channel measurement

[0085] o quality indicator of channel measurement

[0086] o time stamp of channel measurement

[0087] • The term “Part B” was used to identify the ground truth or labels for an AI / ML based inference process. Some or all of the following parameters are included in “Part B”:

[0088] o ground truth label (or its approximation)

[0089] o quality indicator of label

[0090] o time stamp of labelSummary of the Disclosure

[0091]

[0030] The problem of data collection for training and / or monitoring purposes for the case of AI / ML assisted positioning, namely for the case where an AI / ML model is hosted at the RAN to infer positioning measurements is still unresolved in 3GPP. In particular, there are different cases for which a solution to such problem has not been described in known literature. Such cases correspond to scenarios where data collection is needed from UEs that are not being positioned.

[0092]

[0031] As a first example, data collection may be needed in the case of UEs that are not served by the RAN, but for which the RAN can detect their UL SRS transmissions. If these UEs are in specific radio conditions (e.g. specific radio environment, using specific UL SRS configurations) for which the RAN has not trained its AI / ML assisted positioning models, the RAN might need to collect labels (i.e. information leading or associated to the UE position) for such UEs for the purpose of forming training data sets to be used to train AI / ML models.

[0093]

[0032] As a second example, data collection may be needed in the case of UEs that are served by the RAN and that are under particular radio conditions. For these UEs the RAN might find it beneficial to collect label or ground truth information to be used to form training data for AI / ML assisted positioning models, which can help other purposes such as beam steering. Such labels or ground truth could include the UE position or any metric that could conduct to it, with the objective of combining, at the RAN, such labels with measurements taken for the same UE (e.g. UL SRS measurements) to form a set of training data (made by a set of inputs - measurements - and a label - the UE position).

[0094]

[0033] In US Provisional Application No. 63 / 700,202 filed 2024-09-27, a solution was described where the LMF triggers an initial procedure to inform the RAN about the UEs that are available in a given area for data collection. However, this solution family is not suitable for cases where the UE for which data collection is needed is not being positioned. Namely, the procedure is not suitable for cases where the LMF has no knowledge of the UE for which data collection is needed. In other words, the requested UE for ground truth has no known location computed yet at LMF.

[0034] In EP Provisional Application No. 24383041.1 filed 2024-09-27, a solution was described where the RAN is able to indicate that data collection is needed for UEs in a given area. However, in this disclosure, the problem of how the RAN can specify for which UE identity data collection is needed was not addressed.

[0095]

[0035] Therefore, a problem addressed in this disclosure is how to enable the RAN to identify equipment for which data collection for training / monitoring of AI / ML assisted positioning models is needed. Such equipment can be UEs that are not-served by the RAN (i.e. non-served UE or a PRU). In the case of non-served UEs, a problem is how to identify the UEs for which data collection is needed. Alternatively, such equipment can be a served UE. Another problem is how to trigger a request for positioning and data collection for such UEs, with a purpose of receiving label / ground truth information on these UE positions, that can be used by RAN to form training / monitoring data sets.

[0096]

[0036] According to an aspect, there is provided a method for execution by a first network node (e.g. RAN node). The method involves sending, to another network node (e.g. AMF node or LMF node), a request for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit) or a served UE. The method also involves receiving a response including either (i) the ground truth information for the at least one equipment or (ii) an indication that the ground truth information cannot be provided.

[0097]

[0037] In some implementations, the request concerns at least one non-served UE, and wherein the request identifies the at least one non-served UE using an SRS (Sounding Reference Signal) configuration of the at least one non-served UE. Additionally, or alternatively, the request identifies the at least one non-served UE using an NRPPa (New Radio Positioning Protocol A) transaction ID (Identifier), an LMF (Location Management Function) measurement ID, and / or a RAN measurement ID. In this way, it is possible to identify the at least one UE even though it is non-served. Such IDs can be included both in the request at steps 501 & 503, and the response at steps 506a & 506b.

[0038] The solution enables the RAN to trigger a request specific to one or more non-served UE or specific to radio conditions or to reference signal configuration for data collection for the purpose of achieving training or monitoring data for an AI / ML assisted model. The solution can be applied to collection of training / monitoring data for non-served UEs. The RAN can therefore acquire data concerning conditions for which models were not sufficiently trained or for which model performance was not sufficiently monitored. This enables the RAN to train and tune its models in a more accurate way, which could ensure that models can perform well under all types of radio conditions, reference signal configuration conditions, and for all types of UEs.

[0098]

[0039] In other implementations, the request concerns at least one PRU, and wherein the request identifies the at least one PRU using an area of interest and / or operating conditions.

[0099]

[0040] In some implementations, the request for ground truth information is a first request for data collection sent to a second network node (e.g. AMF) to trigger positioning request with a third network node (e.g. LMF). Furthermore, the method involves sending, to the third network node, a second request for data collection.

[0100]

[0041] An advantage of enabling the RAN to request for Part B for PRUs is that the location of a PRU is known, hence not subject to errors. Enabling the RAN to request for Part B for PRUs can be particularly useful if the model has not been trained with accurate data and it needs to be trained with such data to achieve sufficient accuracy. Also, a PRU location may not be subject to privacy constraints, e.g. user consent. This may ensure that, if a PRU is available in the area where data is needed at the RAN, data collection for such PRU can be invoked.

[0101]

[0042] In some implementations, the request concerns at least one served UE. In some implementations, the response is received from a second network node which is same as the another network node to which the request is sent. In other implementations, the response is received from a third network node which is different from the another network node to which the request is sent. For example, the method can involve receiving, from the third network node, an acknowledgement message that the ground truth information is available and can be retrieved from the third networknode. Furthermore, the method can involve sending, to the third network node, a request message for the ground truth information.

[0102]

[0043] In some implementations, the request for ground truth information indicates a time window within the ground truth information is to be received.

[0103]

[0044] In some implementations, the response includes the ground truth information. In some implementations, the method involves obtaining SRS measurements for the at least one equipment, and combining the SRS measurements with the ground truth information to form training data set.

[0104]

[0045] In some implementations, the response includes the indication that the ground truth information cannot be provided. In some implementations, the indication includes a cause code indicating failure due to user consent not being available and / or a cause code indicating failure due to positioning could not be performed.

[0105]

[0046] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a first network node (e.g. RAN node), configure the first network node to implement a method as summarized above.

[0106]

[0047] According to another aspect, there is provided a first network node (e.g. RAN node). The first network node has a network interface configured to communicate with other network nodes, and control circuitry coupled to the network interface. The control circuitry is configured to send, to another network node (e.g. AMF or LMF), a request for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit) or a served UE. The control circuitry is also configured to receive a response including either (i) the ground truth information for the at least one equipment or (ii) an indication that the ground truth information cannot be provided.

[0107]

[0048] In some implementations, the control circuitry is also configured to implement a method as summarized above.

[0108]

[0049] According to another aspect, there is provided a method for execution by a second network node (e.g. AMF node). The method involves receiving, from a firstnetwork node (e.g. RAN node), a request (e.g. first NGAP message) for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a served UE (User Equipment) or a PRU (Positioning Reference Unit). The method also involves facilitating transfer, to the first network node, the ground truth information or an indication that the ground truth information cannot be provided.

[0109]

[0050] In some implementations, the request concerns at least one PRU, and the request identifies the at least one PRU using an area of interest and / or operating conditions.

[0110]

[0051] In some implementations, the request concerns at least one served UE, and the method involves receiving an UL RS (Uplink Reference Signal) configuration for which data collection is performed.

[0111]

[0052] In some implementations, the method involves checking if data collection for the at least one equipment is possible (e.g. availability of PRU in area on interest). Furthermore, if data collection for the at least one equipment is possible, the method involves selecting a third network node (e.g. LMF) for the at least one equipment, triggering a service request to the third network node for the at least one equipment, and facilitating transfer of the ground truth information.

[0112]

[0053] In some implementations, if data collection for the at least one equipment is not possible, the method involves facilitating transfer of the indication that the ground truth information cannot be provided. In some implementations, the indication includes a cause code indicating failure due to user consent not being available and / or a cause code indicating failure due to positioning could not be performed.

[0113]

[0054] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a second network node (e.g. AMF node), configure the second network node to implement a method as summarized above.

[0114]

[0055] According to another aspect, there is provided a second network node (e.g. AMF node). The second network node has a network interface configured to communicate with other network nodes, and control circuitry coupled to the network interface. The control circuitry is configured to receive, from a first network node (e.g.RAN node), a request (e.g. first NGAP message) for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a served UE (User Equipment) or a PRU (Positioning Reference Unit). The control circuitry is also configured to facilitate transfer, to the first network node, the ground truth information or an indication that the ground truth information cannot be provided.

[0115]

[0056] In some implementations, the control circuitry is further configured to implement a method as summarized above.

[0116]

[0057] According to another aspect, there is provided a method for execution by a third network node (e.g. LMF node). The method involves receiving, from another network node (e.g. RAN node or AMF node), a request (e.g. data collection request) for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit) or a served UE. The method also involves sending the ground truth information or an indication that the ground truth information cannot be provided.

[0117]

[0058] In some implementations, the request concerns at least one non-served UE, and wherein the request identifies the at least one non-served UE using an SRS (Sounding Reference Signal) configuration of the at least one non-served UE. Additionally, or alternatively, the request identifies the at least one non-served UE using an NRPPa (New Radio Positioning Protocol A) transaction ID (Identifier), an LMF measurement ID, and / or a RAN (Radio Access Network) measurement ID. In this way, it is possible to identify the at least one UE even though it is non-served.

[0118]

[0059] In some implementations, the request concerns at least one PRU, and wherein the request identifies the at least one PRU using an area of interest and / or operating conditions.

[0119]

[0060] In some implementations, the request for ground truth information is a first request for data collection from a second network node (e.g. AMF). Furthermore, the method involves receiving, from the first network node, a second request for data collection.

[0061] In some implementations, the request concerns at least one served UE, and the method involves receiving an UL RS (Uplink Reference Signal) configuration for which data collection is performed.

[0120]

[0062] In some implementations, the method involves checking if data collection for the at least one equipment is possible (e.g. availability of PRU in area on interest). Furthermore, if data collection for the at least one equipment is possible, the method involves sending the ground truth information. In some implementations, the ground truth information is sent to the first network node.

[0121]

[0063] In some implementations, if data collection for the at least one equipment is not possible, the method involves sending the indication that the ground truth information cannot be provided. In some implementations, the indication includes a cause code indicating failure due to user consent not being available and / or a cause code indicating failure due to positioning could not be performed.

[0122]

[0064] According to another aspect, there is provided a non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a third network node (e.g. LMF node), configure the third network node to implement a method as summarized above.

[0123]

[0065] According to another aspect, there is provided a third network node (e.g. LMF node). The third network node has a network interface configured to communicate with other network nodes, and control circuitry coupled to the network interface. The control circuitry is configured to receive, from another network node (e.g. RAN node or AMF node), a request (e.g. data collection request) for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a nonserved UE (User Equipment) or a PRU (Positioning Reference Unit). The control circuitry is also configured to send the ground truth information or an indication that the ground truth information cannot be provided.

[0124]

[0066] In some implementations, the control circuitry is further configured to implement a method as summarized above.

[0067] Other aspects and features of the present disclosure will become apparent, to those ordinarily skilled in the art, upon review of the following description of the various embodiments of the disclosure.

[0125] Brief Description of the Drawings

[0126]

[0068] Embodiments will now be described with reference to the attached drawings in which:

[0127] Figure 1 is a flowchart of an example training pipeline for an AI / ML model; Figure 2 is a block diagram of an example NG-RAN;

[0128] Figure 3 is a block diagram of an example positioning architecture with NG-RAN;

[0129] Figure 4 is a block diagram of a communication system, in accordance with an embodiment of the disclosure;

[0130] Figure 5 is a sequence drawing of an example method enabling data collection for AI / ML assisted positioning of equipment;

[0131] Figure 6 is a flowchart of an example method having gNB-triggered request for ground truth information for training;

[0132] Figure 7 is a sequence drawing of an example method having coordination solution for aligning SRS configuration used for measurement inferences by other gNBs;

[0133] Figure 8 is a flowchart of an example method having gNB-triggered request for ground truth information for training;

[0134] Figure 9 is a sequence drawing of an example method for data request for non-served UEs;

[0135] Figure 10 is a sequence drawing of an example method for data request for PRUs;

[0136] Figures 11 and 12 are sequence drawings of example methods for coordination between nodes for SRS configuration alignment;

[0137] Figure 13 is a sequence drawing of an example method for measurement procedure and unsuccessful operation;Figure 14 is a flowchart of an example method with RAN triggered request and UE location generation using UL SRS based positioning;

[0138] Figure 15 is a flowchart of an example method with RAN triggered request and UE location generation in a positioning method agnostic way;

[0139] Figure 16 is a sequence drawing of an example process with reception of data from the LMF combined with LMF triggered UL positioning techniques;

[0140] Figure 17 is a sequence drawing of an example process with positioning-technique-agnostic reception of data from the LMF; and

[0141] Figure 18 is a sequence drawing of an example process with provisioning of UE data via an AMF node to a RAN node.

[0142] Detailed Description of Embodiments

[0143]

[0069] It should be understood at the outset that although illustrative implementations of one or more embodiments of the present disclosure are provided below, the disclosed systems and / or methods may be implemented using any number of techniques. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended embodiment along with their full scope of equivalents.

[0144] Introduction

[0145]

[0070] Referring now to Figure 4, shown is a block diagram of a communication system 100, in accordance with an embodiment of the disclosure. The communication system 100 has UEs 130a-c capable of accessing a network 102, which might for example be a 5G network or some other network. The UEs 130a-c can include nonserved UEs 130a which are not served by the RAN node 110, and served UEs 130b-c which are served by the RAN node 110. The communication system 100 may also have one or more PRUs 140a-c. The network 102 has several network nodes including a first network node 110, a second network node 210, a third network node 310, and may have other network nodes 150 as well, but these are not shown for simplicity. These network nodes are shown to be separate entities with separate components, but in other implementations some network nodes could be combined or otherwise haveshared components. Also, although only a few UEs 130a-c and PRUs 140a-c are shown, it is understood that there may be numerous UEs and PRUs.

[0146]

[0071] The first network node 110 has a network interface 115 configured to communicate with other nodes of the communication system 100, a CRM 119, and control circuitry 116 coupled to the network interface 115 and the CRM 119. In some implementations, the control circuitry 116 includes a processor 117 that executes software, which can stem from a memory 118. However, other implementations are possible and are within the scope of this disclosure. The first network node 110 can have additional components, but these are not shown for simplicity. In some implementations, the first network node 110 is a RAN node 110, such as the gNB as depicted in Figure 3. Other implementations are possible as described below.

[0147]

[0072] The second network node 210 has a network interface 215 configured to communicate with other nodes of the communication system 100, a CRM 219, and control circuitry 216 coupled to the network interface 215 and the CRM 219. In some implementations, the control circuitry 216 includes a processor 217 that executes software, which can stem from a memory 218. However, other implementations are possible and are within the scope of this disclosure. The first network node 210 can have additional components, but these are not shown for simplicity. In some implementations, the second network node 210 is an AMF node 210, such as the AMF 303 as depicted in Figure 3. Other implementations are possible as described below.

[0148]

[0073] The third network node 310 has a network interface 215 configured to communicate with other nodes of the communication system 100, a CRM 319, and control circuitry 316 coupled to the network interface 315 and the CRM 319. In some implementations, the control circuitry 316 includes a processor 317 that executes software, which can stem from a memory 318. However, other implementations are possible and are within the scope of this disclosure. The first network node 310 can have additional components, but these are not shown for simplicity. In some implementations, the third network node 310 is an LMF node 310, such as the LMF 304 as depicted in Figure 3. Other implementations are possible as described below.

[0074] A problem addressed in this disclosure is how to enable the first network node 110 (e.g. RAN node) to identify equipment (e.g. UEs 130a-130cor PRUs 140a-c) for which data collection for training / monitoring of AI / ML assisted positioning models is needed. Such equipment can be non-served UEs 130a that are not-served by the first network node 110, or the PRUs 140a-c. In the case of a non-served UE 130a, a problem is how to identify the UE 130a for which data collection is needed. Alternatively, such equipment can be a served UE 130b-c. Another problem is how to trigger a request for positioning and data collection for such UEs, with a purpose of receiving label / ground truth information on these UE positions, that can be used by RAN to form training / monitoring data sets.

[0149]

[0075] The control circuitry 116 of the first network node 110, the control circuitry 216 of the second network node 210, and the control circuitry 316 of the third network node 310 implement a method of enabling data collection for AI / ML assisted positioning of equipment 130a-c or 140a-b. Such operation by the control circuitries 116, 216, and 316 will be described below with reference to Figure s. Although the method of Figure 5 is described below with reference to the communication system 100 shown in Figure 4, it is to be understood that the method of Figure 5 is applicable to other communication systems. In general, the method of Figure 5 is applicable to any appropriately configured communication system.

[0150]

[0076] At step 501, the first network node 110 (e.g. RAN node) sends a request for ground truth information (e.g. location information and time stamp) for at least one equipment which can be a non-served UE 130a or PRU 140a-b or a served UE 103b-c. In some implementations, the request is provided to the second network node 210 (e.g. AMF node) as shown. In other implementations, the request is provided to the third network node 310 (e.g. LMF node).

[0151]

[0077] In some implementations, at step 502, the second network node 210 checks if data collection is possible for the at least one equipment (e.g. if user consent for UEs is in place, or availability of PRU in area on interest, etc.). If data collection is possible, the second network node 210 selects the third network node (e.g. LMF) for the at least one equipment, triggering a service request to the third network node 310 for the at least one equipment, and facilitates transfer of the ground truth information.Specifically, the second network node 210 sends, to the third network node 310 at step 503, a request for ground truth information.

[0152]

[0078] In some implementations, at step 504, the third network node 310 also checks if data collection is possible for the at least equipment (e.g. if user consent for UEs is in place, or availability of PRU in area on interest, etc.). If data collection is possible, then at step 505 a positioning procedure is executed. Example details of the positioning procedure are provided later.

[0153]

[0079] At steps 506a and 506b, the ground truth information is provided from the third network node 310 to the first network node 110. In some implementations, the second network node 210 is involved in delivering the ground truth information as shown. In other implementations, the ground truth information is provided from the third network node 310 to the first network node 110. In some implementations, upon the first network node 110 receiving the ground truth information, there is further processing at step 507. For example, the first network node 110 can combine SRS measurements with the ground truth information to form training data set. The SRS measurements can be previously obtained for the at least one equipment.

[0154]

[0080] In some implementations, the request at step 501 concerns at least one non-served UE 130a, and wherein the request identifies the at least one non-served UE 130a using an SRS configuration of the at least one non-served UE 130a. Additionally, or alternatively, the request identifies the at least one non-served UE 130a using an NRPPa transaction ID, an LMF measurement ID, and / or a RAN measurement ID. In this way, it is possible to identify the at least one UE 130a even though it is nonserved.

[0155]

[0081] In other implementations, the request at step 501 concerns at least one PRU 140a-b, and wherein the request identifies the at least one PRU 140a-b using an area of interest and / or operating conditions.

[0156]

[0082] In other implementations, the request at step 501 concerns at least one served UE 130b-c. The response can be received from the second network node 210 as shown. Alternatively, response can be received from the third network node 310. In some implementations, the first network node 110 receives, from the third networknode 310, an acknowledgement message that the ground truth information is available and can be retrieved from the third network node 310. The first network node 110 can subsequently send, to the third network node 310, a request message for the ground truth information.

[0157]

[0083] In the illustrated example, the checks performed at step 502 and 504 results in the data collection proceeding. However, if data collection is not possible (e.g. user consent not being available, or positioning could not be performed), a reply can instead be sent as shown at steps 508a and 508b with an indication that the ground truth information cannot be provided. In some implementations, the indication includes a cause code indicating failure due to user consent not being available and / or a cause code indicating failure due to positioning could not be performed.

[0158]

[0084] In some implementations, the request for ground truth information indicates a time window within the ground truth information is to be received. Such time window can be indicated as a specific time unit, e.g. in seconds. Alternatively, or additionally, such time window can be specified starting from a specific point in time, e.g. related to the SFN time. Alternatively, or additionally, such time window can be specified starting from reception of a specific message, e.g. the request for data collection message.

[0159]

[0085] According to another embodiment of the disclosure, there is provided a non-transitory CRM having recorded thereon statements and instructions that, when executed by the processor 117 of the first network node 110, implement a method as described herein. The non-transitory computer readable medium can be the memory 118 and / or the CRM 119 of the first network node 110 shown in Figure 4, or some other non-transitory CRM.

[0160]

[0086] According to another embodiment of the disclosure, there is provided a non-transitory CRM having recorded thereon statements and instructions that, when executed by the processor 217 of the second network node 210, implement a method as described herein. The non-transitory computer readable medium can be the memory 218 and / or the CRM 219 of the second network node 210 shown in Figure 4, or some other non-transitory CRM.

[0087] According to another embodiment of the disclosure, there is provided a non-transitory CRM having recorded thereon statements and instructions that, when executed by the processor 317 of the third network node 310, implement a method as described herein. The non-transitory computer readable medium can be the memory 318 and / or the CRM 319 of the first network node 310 shown in Figure 4, or some other non-transitory CRM.

[0161]

[0088] Examples of a non-transitory CRM include memory, an SSD (Solid State Drive), a hard disk drive, a CD (Compact Disc), a DVD (Digital Video Disc), a BD (Blu-ray Disc), a memory stick, etc. Other non-transitory CRMs are also possible.

[0162]

[0089] The illustrated examples described herein focus on software implementations. However, other implementations are possible and are within the scope of this disclosure. Other implementations can include additional or alternative hardware components, such as any appropriately configured FPGA (Field-Programmable Gate Array), ASIC (Application-Specific Integrated Circuit), and / or microcontroller, for example. Thus, the control circuitry 116 of the first network node 114 can instead be implemented with any suitable combination of hardware, software and / or firmware.

[0163]

[0090] The embodiments described herein can be applicable but not limited to 3GPP NR. Hence, the first network node 110 can be any suitable RAN node such as a base station (e.g. a NR gNB, or 6G-RAT base station) or any other device with similar function. The second network node 210 can be a 5G AMF, a 6G AMF, or any other core network function involved with communication for positioning. The third network node 310 can be a 5G LMF, a 6G LMF, or any other suitable Location Management Service that is in charge of UE positioning.

[0164]

[0091] Embodiment disclosed herein focus on communication between a positioning function (LMF) and a RAN node. However, the methods described herein apply equally to the associated communication between a gNB-CU and a gNB-DU within the same gNB as first network node and second network node, respectively. Therefore, embodiment disclosed herein are not necessarily limited to the first network node being a RAN node, the second network node 210 being an AMF node, and the third network node 310 being an LMF node.

[0092] Further example details are provided in the following sections. It is to be understood that the following sections are very specific and are provided merely for exemplary purposes, such that other implementations are possible and within the scope of the disclosure. By way of overview, the following sections are split into two main parts: Part 1 relating to embodiments with non-served UEs 130a and for PRUs 140a-c, and Part 2 relating to embodiments with served UEs 130b-c.

[0165] Part 1: Overview of Embodiments with Non-Served UEs and for PRUs

[0166]

[0093] This section presents new methods to enable the RAN to trigger data collection in coverage areas where specific radio conditions occur, e.g. particularly radio cluttered areas, for non-served UEs 130a and for PRUs 140a-c.

[0167]

[0094] This section presents new methods to create alignment between serving and non-serving gNB on the SRS configuration to use for training. This can be done either via:

[0168] • From a non-serving gNB triggering a new data collection request with specific SRS configuration to use for model training.

[0169] • A handshake between gNBs and LMF to coordinate over NRPPa on the nonserving cells getting aligned on the SRS configuration for training. Or between gNBs themselves over Xn.

[0170] • By gNB requesting for PRU location information in case of no available UE data is available.

[0171] • Via OAM pre-configuration.

[0172]

[0095] One solution described in this section is that the RAN proceeds to trigger a request for data collection for AI / ML assisted positioning model training and monitoring as shown in Figure 6, which is a flowchart of an example method having gNB-triggered request for ground truth information for training. The method involves triggering data collection and receiving data for non-served UEs. Especially, how part B including ground truths / labels, as described in the section entitled “Progress in RAN3”, used for training / monitoring purposes, can be obtained on-demand.

[0096] Step 601: The RAN node 110 receives a request from the LMF node 310 (over NRPPa) for AI / ML assisted positioning measurements for a non-served UE 130a, e.g. based on inputs derived from detection of a non-served UE SRS signalling. Optionally, the RAN node 110 rejects such request, e.g. on the basis of not having a trained model for the radio conditions and / or SRS configuration of the non-served UE 130a. The the RAN node 110 may indicate to the LMF node 310 the cause of the rejection, e.g. lack of training for a specific radio condition. In this case, the LMF node 310 may expect a request for Part B for the non-served UE 130a.

[0173]

[0097] Step 602: The RAN node 110 determines that data collection for AI / ML assisted positioning model training / monitoring is needed for the radio conditions and SRS configuration corresponding to the non-served UE 130a.

[0174]

[0098] Step 603: The RAN node 110 signals to the LMF node 310 (over NRPPa that data collection is needed for the non-served UE 130a associated to the previous measurement request. The RAN node 110 may include the NRPPa Transaction ID, LMF Measurement ID and RAN Measurement ID included in the previously received NRPPa measurement request. These parameters may serve to identify the UE for which data collection is needed at the LMF node 310.

[0175]

[0099] Step 604: The LMF node 310 checks that data requested can be provided, e.g. the location of the UE or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. The latter may imply user consent checks.

[0176]

[0100] Step 605: If possible, the LMF node 310 reports to the RAN node 110 the requested data.

[0177]

[0101] Step 606: The RAN node 110 uses the received data to form training data, e.g. by combining SRS measurements for the non-served UE 130a and the UE-location received from the LMF node 310, or to monitor the model performance, e.g. by comparing the UE location received and the inferred positioning measurements (leading to a UE location).

[0178]

[0102] The following general steps in Figure 6 are foreseen for this family of methods. The method includes a solution for a non-serving gNB requesting by itselfground truth from the LMF node 310 fortraining purpose when it checks the lack of data for performing inference. This focuses on a gNB initiated triggered request for training. Other methods are described below.

[0179]

[0103] Another alternative is where the LMF node 310 coordinates over NRPPa with each measuring gNB in advance by retrieving first their SRS capabilities from previous positioning sessions, understanding their patterns, and “pruning” (i.e., communalizing) them in a common SRS configuration that can be used for AI / ML positioning for all involved gNB-models. Thereby signalling the SRS configuration to other gNB models involved in positioning measurements inference. This coordination can also happen overXn between gNBs instead of NRPPa via the LMF node 310. See for example Figure 7, which is a sequence drawing of an example method having coordination solution based (over NRPPa) for aligning SRS configuration used for measurement inferences by other gNBs. Figure 7 has steps 701, 702, 703, 704, 705 and 706, which are self-explanatory.

[0180]

[0104] A third solution described in this section is based on cases where the nonserving gNB requests for ground truth from a PRU 140a-c. See for example Figure 8, which is a flowchart of an example method having gNB-triggered request for ground truth information for training.

[0181]

[0105] Step 801: The RAN node 110 determines that data collection for a nonserved PRU 140a-c is needed. This could be due to lack of training I monitoring data in a given coverage area.

[0182]

[0106] Step 802: The RAN node 110 signals to the CN (e.g. AMF node 210) a request for positioning data for a non-served PRU 140a-c within a specified area. The RAN node 110 may specify the number of PRUs 140a-c for which Part B is needed and the area within which the PRUs 140a-c need to be located.

[0183]

[0107] Step 803: The AMF node 210 optionally performs checks on whether data collection is possible for any PRUs 140a-c located in the area of interest described by the RAN node 110. The AMF node 210 triggers a positioning request towards the LMF node 310 one or more PRU 140a-c. Optionally, the AMF node 210 can indicate to the LMF node 310 that the request is for RAN triggered data collection purposes.

[0108] Step 804: The LMF node 310 checks that data requested can be provided, e.g. the location of the PRU 140a-c or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. The latter may imply user consent checks.

[0184]

[0109] Step 805: If possible, the LMF node 310 reports to the RAN node 110 the requested data.

[0185]

[0110] Step 806: The RAN node 110 uses the received data to form training data, e.g. by combining SRS measurements for the non-served PRU 140a-c and the PRU location received from the LMF node 310, or to monitor the model performance, e.g. by comparing the PRU location received and the inferred positioning measurements (leading to a PRU location)

[0186]

[0111] Finally it is not precluded, that the LMF node 310 knows in advance gNBs capabilities for AI / ML inference via OAM, and selects the gNBs that should be involved in measurement from the subset of available RAN nodes based on the level of training and capabilities of their AI / ML model. Such selection can be configured in advance, or based on past positioning sessions.

[0187] Part 1: Data Collection for Non-Served UEs

[0188]

[0112] Referring now to Figure 9, shown is a sequence drawing of an example method for data request for non-served UEs 130a. The steps shown in this sequence drawing are described below. It is to be understood that these steps are very specific and are provided for exemplary purposes. Other implementations are possible.

[0189]

[0113] Step 901: The LMF node 310 triggers a measurement request towards the RAN for UE not served by the RAN node 110. The LMF node 310 requests the RAN node 110 to provide UL measurements for a specific UL RS configuration where UL RS, e.g. SRS, is signalled by a UE not served by the RAN node 110. Optionally, the LMF node 310 may request the RAN node 110 that such UL measurements are derived by means of AI / ML inference, i.e. that the RAN node 110 performs AI / ML assisted positioning.

[0114] The RAN node 110 determines that it is not able to provide AI / ML based measurements or it does not have similar Relative Time of Arrival (RTOA) or Angle of Arrival (AoA) in its training data set (i.e. the RAN node 110 has extrapolated the value). The RAN node 110 may either fail the measurement request from the LMF node 310, e.g. if explicit AI / ML based measurements were requested by the LMF node 310, or it may respond successfully and provide measurements not inferred via AI / ML or extrapolated value and requesting training data for the UE (part B).

[0190]

[0115] Step 902: The RAN node 110 determines that it needs to trigger data collection for the UL RS configuration for the non-served UE 130a, for which the LMF node 310 has requested measurements. Reasons for the RAN node 110 to request data for such non-served UEs 130a can be:

[0191] • The UE is in specific radio conditions for which the RAN node 110 did not sufficiently train its models.

[0192] • The UE is in specific radio conditions for which the RAN node 110 did not sufficiently monitor its models' performance.

[0193] • The UE uses specific reference signals configurations (e.g. SRS configurations) for which the RAN node 110 did not sufficiently train its models.

[0194] • The UE uses specific reference signals configurations (e.g. SRS configurations) for which the RAN node 110 did not monitor its models sufficiently.

[0195] • The UE has advance capability such as multiple antenna i.e UE is configured to transmit SRS using Timing error group (TEG, as defined in TS 38.305).

[0196]

[0116] Step 903: The RAN node 110 requests to the LMF node 310 for positioning labels for the UE, where the UE is identified by means of its SRS configuration, as the RAN node 110 does not serve the UE and cannot identify it directly. Namely the RAN node 110 requests to the LMF node 310 the data including location information or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. Such request may occur over the RAN node 110 to LMF node 310 communication protocol, such as NRPPa. The LMF node 310 checks whether such data collection for the UE identified by its SRS configuration is possible, e.g. the LMF node 310 checks if user consent has been given for the UE and for data collection. TheRAN node 110 may further add the RAN / LMF measurement ID and transaction ID used over the NRPPa procedure to help identify the UE.

[0197]

[0117] In one embodiment, the RAN node 110 indicates a time window within which it is to receive the ground truth information. Such time window can be indicated as:

[0198] • a specific time unit, e.g. in seconds,

[0199] • starting from a specific point in time, e.g. related to the SFN time, and / or

[0200] • starting from reception of a specific message, e.g. the request for data collection message.

[0201]

[0118] If data collection is possible, the LMF node 310 responds with labels for the concerned UEs identified by its SRS configuration.

[0202]

[0119] Step 904: The RAN node 110 may therefore measure the UL RS, e.g. SRS, signalled by the non-served UE 130a at specific points in time. By associating the UL RS measurements at a given time with the UE position or in general the UE “data” received from the LMF node 310 for the same or a close enough point in time, the RAN node 110 can construct a set of training data. Similarly, the RAN node 110 can check the model performance by inferring the AI / ML assisted positioning measurements from the UL RS measurements taken for the non-served UE 130a and compares such inferred measurements with the same measurements derived from the UE position or UE data signalled by the LMF node 310.

[0203] Part 1: Data collection for PRUs

[0204]

[0120] Referring now to Figure 10, shown is a sequence drawing of an example method for data request for PRUs 140a-c. The steps shown in this sequence drawing are described below. It is to be understood that these steps are very specific and are provided for exemplary purposes. Other implementations are possible.

[0205]

[0121] Step 1001: The RAN node 110 determines that it needs to trigger data collection for one or more PRUs 140a-c, optionally determining the coverage area where such PRUs 140a-c need to be located. Reasons for the RAN node 110 to request data for such PRUs 140a-c can be:• The area of interest presents specific radio conditions for which the RAN node 110 did not sufficiently train its models.

[0206] • The area of interest presents specific radio conditions for which the RAN node 110 did not sufficiently monitor its models' performance.

[0207] • The model has not been trained with training data made by accurate UE location information.

[0208] • The model has not been monitored with training data made by accurate UE location information.

[0209] • A specific reference signals configurations (e.g. SRS configurations) needs to be used for collection of Part A, for which the RAN node 110 did not sufficiently train its models.

[0210] • A specific reference signals configurations (e.g. SRS configurations) needs to be used for collection of Part A, for which the RAN node 110 did not monitor its models sufficiently.

[0211]

[0122] Step 1002: The RAN node 110 triggers towards the CN (Core Network), e.g. the AMF node 210, a request over the RAN-CN interface, e.g. the NGAP. In such request, the RAN node 110 requests for data collection from one or more PRUs 140a-c.

[0212]

[0123] In one embodiment, the RAN node 110 indicates a time window within which it is to receive the ground truth information. Such time window can be indicated as:

[0213] • a specific time unit, e.g. in seconds,

[0214] • starting from a specific point in time, e.g. related to the SFN time, and / or

[0215] • starting from reception of a specific message, e.g. the request for data collection message.

[0216]

[0124] In one embodiment of this method, the RAN node 110 specifies an area of interest within which the PRUs 140a-c should be selected. This area could be identifier by, for example, one or more of:

[0217] • Beam Identifiers,• Cell identifiers,

[0218] • Tracking Area Identifiers,

[0219] • Geographical coordinates limiting an area, and / or

[0220] • Geographical coordinates included in an area.

[0221]

[0125] In another embodiment of this method, the RAN node 110 specifies the operating conditions for which a PRU 140a-c should be selected:

[0222] • Associated channel condition, e.g. link power in the form of uplink or downlink RSRP condition,

[0223] • PRU speed, and / or

[0224] • PRU bandwidth.

[0225]

[0126] In another embodiment of this method, the request is carried out in a non-UE associated manner.

[0226]

[0127] In one dependent embodiment, the RAN node 110 indicates to the AMF node 210 that the data collection request is for the purpose of AI / ML model training, or AI / ML model performance monitoring.

[0227]

[0128] Step 1003: Upon reception of the request for data collection from the RAN node 110, the AMF node 210 carries out the following:

[0228] • It checks whether any PRU 140a-c is available for data collection and if an area of interest is specified by the RAN node 110, if any PRU 140a-c is available for data collection within such area.

[0229] • It optionally performs user consent checks for the one or more PRU 140a-c for which data collection is requested. Note that this step could also be performed by the LMF node 310 in following steps, before sending positioning information to the RAN node 110.

[0230] • If data collection for the lists of PRUs 140a-c is possible, the AMF node 210 triggers a positioning request towards the LMF node 310 for such PRUs 140a-c. A number of options are available:o The AMF node 210 triggers concurrent positioning requests for a list of PRUs 140a-c in one message over the NL1 interface. Specifically, the Nlmf_Location service message sent over NL1 is enhanced to enable location determination request for a number of PRUs 140a-c. o Or, the AMF node 210 triggers one positioning request for one PRU 140a- c at a time, via one Nlmf_Location service message, after selecting an appropriate LMF node 310 for each PRU 140a-c positioning session. If the PRU 140a-c is in CM IDLE state, the AMF node 210 initiates a network triggered Service Request procedure to establish a signalling connection with the PRU 140a-c.

[0231] o The LMF selection by AMF node 210 takes into account the computational load of each LMF node 310, the PRU positioning capabilities, and historical positioning information from previous PRU positioning sessions (which PRU 140a-c has been positioning by which the LMF node 310) when sending the NL1 Nlmf_Location service message to the selected LMF node 310.

[0232] o The LMF node 310 may use the procedures defined in TS 23.273 clause 6.11 to obtain location information from one or more PRUs 140a-c. For example, the location information may include location information for the PRU(s) 140a-c or for the NG-RAN or both.

[0233] • Optionally, the AMF node 210 specifies to the LMF node 310 that such positioning process is for the purpose of data collection at the RAN node 110. Such information could include that data collection is for the purpose of gathering labels to be used for training / monitoring of AI / ML assisted positioning models. The latter may let the LMF node 310 understand that the SRS configuration should be triggered towards each PRU 140a-c and that UL SRS measurement need to be collected by the RAN node 110.

[0234] o Specifically, the AMF node 210 triggers the network initiated location requested as specified in TS 23.273 with an indication that the positioning request is for data collection as below:

[0235] Network Induced Location Request (NI-LR). With a Network Induced Location Request (NI-LR), a serving AMF for a UE initiates localization ofthe UE for a regulatory service (e.g. an emergency call from the UE) or for verification of a UE location (country or international area) for NR satellite access or for data collection request from NG-RAN.

[0236]

[0129] Step 1004: The LMF node 310 may carry out user consent checks for the PRU 140a-c for which data collection is requested and based on that determines whether a positioning process to derive the requested data can be triggered / reused to signal data to the RAN node 110. Alternatively or additionally, user consent check can be carried out by the AMF node 210. If data collection for the PRU 140a-c is allowed, the LMF node 310 achieves the requested data for the concerned PRU 140a-c by any means possible. Namely, the LMF node 310 may trigger any positioning technique to derive the UE positions, such as GNSS based positioning. It should be noted that the position of a PRU 140a-c may be known at the LMF node 310 in advance, hence the LMF node 310 may not need to trigger a process by which such position is calculated, but simply retrieve the PRU position previously stored.

[0237]

[0130] Step 1005: The RAN node 110 requests to the LMF node 310 for positioning labels for each PRU 140a-c. Namely the RAN node 110 requests to the LMF node 310 the data including location information for the PRUs 140a-cor any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. Such request may occur over a RAN to LMF communication protocol, such as NRPPa. The LMF node 310 responds with labels for the concerned UEs.

[0238]

[0131] As an alternative, the PRU positioning information may be reported by the AMF node 210 to the RAN node 110, as part of message 4 in the figure below. In this case, the message would be signalled to the RAN node 110 only after the LMF node 310 derives the PRU position and sends it to the AMF node 210, assuming that either the AMF node 210 or the LMF node 310 have checked that data collection for the PRUs 140a-c of concern is allowed.

[0239]

[0132] Step 1006: In order to derive the measurement parts that would need to be associated to the label provided by the LMF node 310 to form training data, the RAN node 110 may configure the UE with UL reference signals transmission, e.g. the RAN node 110 may configure the UE with an SRS configuration. Alternatively, the RANnode 110 may receive from the LMF node 310 a request to configure the PRU 140a-c with a specific UL RS configuration, e.g. an SRS configuration. As part of this process, the RAN node 110 may indicate to the LMF node 310 a specific SRS configuration for which the RAN node 110 wants the PRU 140a-c to be configured, and the PRU 140a-c may be configured by the RAN node 110 with such SRS configuration. Such configuration may be used by the RAN node 110 to measure UL RS form the UE and derive “Part A”.

[0240]

[0133] Step 1007: The RAN node 110 may therefore measure the SRS signalled by the PRU 140a-c at specific points in time. By associating the SRS measurements at a given time with the PRU position or in general the PRU “data” received from the LMF node 310 for the same or a close enough point in time, the RAN node 110 can construct a set of training data. Similarly, the RAN node 110 can check the model performance by inferring the AI / ML assisted positioning measurements from the SRS measurements taken for the PRU 140a-c and compare such inferred measurements with the same measurements derived from the PRU position or UE data signalled by the LMF node 310. In other words, the RAN node 110 may correlate the PRU SRS measurements with the received PRU location from LMF node 310 based on the time stamp associated with each of these information.

[0241] Part 1: Coordination based method for non-serving gNBs via NRPPa orXn on the SRS configuration

[0242]

[0134] For positioning, the AI / ML model generated results (inference) is from at least 3 TRPs and hence it would be appropriate if the group of TRPs perform training at the same time. It is possible to have some coordination either facilitated by LMF over NRPPa or via Xn. Either the LMF node 310 can send the message that the training session should be started or gNBs may decide to trigger the training session by sending a request to other neighbor gNBs via Xn.

[0243] Part 1: Coordination between nodes for SRS configuration alignment

[0244]

[0135] Referring now to Figures 11 and 12, shown are sequence drawings of example methods for coordination between nodes for SRS configuration alignment. The steps shown in these sequence drawings are described below. It is to beunderstood that these steps are very specific and are provided for exemplary purposes. Other implementations are possible.

[0245]

[0136] Figure 11 shows how a first gNB1 can request a second gNB2 to start data collection at step 1101, and a reply can be sent at step 1102. The reply can accept the request or reject the request. Further details are provided with reference to Figure 12.

[0246]

[0137] At step 1201 , a serving gNB1 may receive user consent from a certain UE for data collection. Once the serving gNB1 determines that criteria for data collection from the certain UE has been met, it informs a neighbor gNB2 at steo 1202 if it wants to participate in the training session. The neighbor gNB2 can reply at step 1203. At step1204, the serving gNB1 configures SRS for positioning towards the UE which has given user consent for data collection for positioning. If the neighbor gNB2 accepts to take part to the training data session, then at step 1205 the serving gNB1 provides the SRS configuration to the other gNBs2. At steps 1206 & 1207, the serving gNB1 asks to LMF for part B via AMF with a time stamp overlapping SRS transmission. At step 1028, the LMF provides the part B to the serving gNB1 which then is forwarded to other gNBs participating in training session at step 1209.

[0247]

[0138] In one embodiment, the LMF requests via NRPPa message from each participating gNB the previous SRS configuration it has used to infer UL SRS measurements, and stores them into an LMF SRS context.

[0248]

[0139] The LMF aligns each SRS configuration into a common SRS configuration parameters that can be used for training and inference by each gNB and signals it via NRPPa to all non-serving gNBs.

[0249] Part 1: Technical

[0250]

[0251]

[0140] Below are potential spec impacts to 3GPP TS 38.455 entitled “NG-RAN; NR Positioning Protocol A (NRPPa)” version 18.3.0 dated 2024-09-21:

[0252] Unsuccessful Operation

[0253]

[0141] Referring now to Figure 13, shown is a sequence drawing of an example method for measurement procedure and unsuccessful operation.

[0142] If the NG-RAN node cannot configure any of the requested measurements for any of the TRPs in the TRP Measurement Request List IE of the MEASUREMENT REQUEST message at step 1301, it shall respond with a MEASUREMENT FAILURE message with an appropriate cause value at step 1302.

[0254]

[0143] The NG-RAN node may send a failure message with cause “T raining data set unavailable or inference not possible” and initiate a new message at step 1303 to request training data from LMF. The gNB may optionally use the same measurement Identifiers as used by LMF in Measurement request.

[0255]

[0144] The LMF upon receiving such request for training data message initiates a new procedures to provide the gNB with training data over non-UE associated procedure at step 1304.

[0256] Cause

[0257]

[0145] The purpose of the cause information element is to indicate the reason for a particular event for the whole protocol.

[0258] >

[0259] >

[0260]

[0261] >

[0262]

[0263]

[0264] Part 2: Overview of Embodiments with Served UEs

[0265]

[0146] This section presents new methods for RAN triggering data collection and receiving data for served UEs 130b-c. Especially, this section presents solutions on how part B, including ground truths / labels as described herein, can be obtained on-demand (i.e. triggered by gNB whenever gNB determines that part B from a certain UE is beneficial for training purpose).

[0266]

[0147] Referring first to Figure 14, shown is a flowchart of an example method with RAN triggered request and UE location generation using UL SRS based positioning.

[0267]

[0148] Step 1401 : The RAN node 110 determines that data collection for AI / ML assisted positioning model training / monitoring is needed for one or more specific UE.

[0149] Step 1402: The RAN node 110 signals to the CN (e.g. the AMF node 210) a request for positioning data, identifying the one or more UE for which data is needed by means of the UE identifiers used on the RAN-CN interface, e.g. UE NGAP IDs. If the RAN node 110 has received user consent information for data collection, the RAN node 110 selects UEs on the basis of such information.

[0268]

[0150] Step 1403: The AMF node 210 optionally performs checks on whether data collection is possible for the one or more UEs, e.g. user consent check. Alternatively, the LMF node 310 can perform user consent check at a later stage and before triggering the positioning process. Alternatively, the RAN node 110 can receive information per UE on whether user consent for data collection is in place.

[0269]

[0151] The AMF node 210 triggers a positioning request towards the LMF node 310 for the specific UEs. Optionally, the AMF node 210 can indicate to the LMF node 310 that the request is for RAN triggered data collection purposes

[0270]

[0152] Step 1404: If the LMF node 310 carries out user consent check, the LMF node 310 will trigger a positioning process based on whether user consent is in place. Tge LMF node 310 triggers a positioning process over NRPPA for the specific one or more UEs, the process is based on UL positioning measurements. The RAN node 110 optionally indicates to the LMF node 310 the SRS configuration to use. The RAN node 110 collects measurements and it may or may not report them to the LMF node 310.

[0271]

[0153] Step 1405: The RAN node 110 requests from the LMF node 310 the location of the one or more UEs or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. The LMF node 310 reports to the RAN node 110 such data.

[0272]

[0154] Step 1406: The RAN node 110 uses the received data to form training data, e.g. by combining SRS measurements for a UE and the UE location received from the LMF node 310, or to monitor the model performance, e.g. by comparing the UE location received and the inferred positioning measurements (leading to a UE location).

[0155] Referring now to Figure 15, shown is a flowchart of an example method with RAN triggered request and UE location generation in a positioning method agnostic way.

[0273]

[0156] Step 1501: The RAN node 110 determines that data collection for AI / ML assisted positioning model training / monitoring is needed for one or more specific UE.

[0274]

[0157] Step 1502: The RAN node 110 signals to the CN (e.g. the AMF node 210) a request for positioning data, identifying the one or more UE for which data is needed by means of the UE identifiers used on the RAN-CN interface, e.g. UE NGAP IDs. If the RAN node 110 has received user consent information for data collection, the RAN node 110 selects UEs on the basis of such information.

[0275]

[0158] Step 1503: The AMF node 210 optionally performs checks on whether data collection is possible for the one or more UEs, e.g. user consent check. Alternatively, the LMF node 310 can perform user consent check at a later stage and before triggering the positioning process. Alternatively, the RAN node 110 can receive information per UE on whether user consent for data collection is in place.

[0276]

[0159] The AMF node 210 triggers a positioning request towards the LMF node 310 for the specific UEs. Optionally, the AMF node 210 can indicate to the LMF node 310 that the request is for RAN triggered data collection purposes.

[0277]

[0160] Step 1504: If the LMF node 310 carries out user consent check, the LMF node 310 will trigger a positioning process based on whether user consent is in place. The LMF node 310 achieve the UE location information by any means possible, e.g. via GNSS positioning information from the UE.

[0278]

[0161] Step 1505: The RAN node 110 requests from the LMF node 310 the location of the one or more UEs or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. The LMF node 310 reports to the RAN node 110 such data.

[0279]

[0162] Step 1506: The RAN node 110 configures the UE with UL reference signal transmission and collects measurements from the UE, which are used as inputs to form training data. The RAN node 110 uses the received data from the LMFnode 310 to form training data by combining UL measurements for a UE and the UE location received from the LMF node 310, or to monitor the model performance, e.g. by comparing the UE location received and the inferred positioning measurements {leading to a UE location}

[0280]

[0163] The following general steps are foreseen for this family of methods and can be separated into two different ways:

[0281] • The steps when Part B (i.e., UE location) is generated using UL positioning methods based on UL SRS configuration triggered by the LMF node 310. See for example step 1404 of Figure 14.

[0282] • An alternative method to the one above is described below where Positioning of the UE is generated independent of UL SRS transmission. See for example step 1504 of Figure 15. The LMF node 310 decides to trigger any positioning method to generate UE location information.

[0283]

[0164] This section presents a new RAN-CN interaction for data collection request to support NG-RAN assisted positioning with gNB-sided model based on the embodiments listed below.

[0284] Part 2: Reception of Data from the LMF Combined with LMF Triggered UL Positioning

[0285]

[0165] Referring now to Figure 16, shown is a sequence drawing of an example process with reception of data from the LMF node 310 combined with LMF triggered UL positioning techniques. The steps shown in this sequence drawing are described below. It is to be understood that these steps are very specific and are provided for exemplary purposes. Other implementations are possible.

[0286]

[0166] Step 1601: the RAN node 110 determines that it needs to collect data for one or more of its served UEs 130b-c. Reasons for such request could be that the RAN node 110 needs to collect data for one or more specific UL RS configurations, e.g. SRS configurations, for which e.g. the RAN node 110 does not have sufficient amounts of data.

[0167] The needed data may be for the purpose of generating training data or monitoring data to be used for management of AI / ML assisted positioning models, e.g. for training or upgrading or tuning such models. For a UE, “Data” here is described as part B information in section 2.2.8. Generally, it is location information for the UE or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning.

[0287]

[0168] Reasons for the RAN node 110 to request data for specific UEs can be:

[0288] • The UE has specific capabilities or characteristics for which the RAN node 110 did not sufficiently train its models.

[0289] • The UE has specific capabilities or characteristics for which the RAN node 110 did not sufficiently monitor its models' performance.

[0290] • The UE has specific capabilities or characteristics (e.g. multiple antennas and supports advance communication / positioning features like carrier aggregation) which makes it a good candidate as part B can be deduced more precisely. • The UE is in specific radio conditions for which the RAN node 110 did not sufficiently train its models.

[0291] • The UE is in specific radio conditions for which the RAN node 110 did not sufficiently monitor its models' performance.

[0292] • The UE uses or is selected to use specific reference signals configurations (e.g.

[0293] SRS configurations) for which the RAN node 110 did not sufficiently train its models.

[0294] • The UE uses or is selected to use specific reference signals configurations (e.g.

[0295] SRS configurations) for which the RAN node 110 did not sufficiently monitor its models' performance.

[0296] The gNB may also receive user consent for data collection information from the core network (CN), e.g. as part of the RAN-CN messages such as the Initial Context Setup message from the AMF node 210 to the RAN node 110. Based on the information received, the RAN node 110 may determine whether data collection for AI / ML assisted positioning is possible or not for a given UE. If user consent is not received from the CN, the AMF node 210 or the LMF node 310may perform the user consent check before processing with the data collection as described on subsequent steps below.

[0297] In an embodiment, the RAN node 110 determines the candidate UE for training based upon UE conditions (multi-path, coverage status), capabilities and user consent.

[0298]

[0169] Step 1602: The RAN node 110 triggers towards the CN, e.g. the AMF node 210, a request over the RAN-CN interface, e.g. the NGAP. In such request, the RAN node 110 requests for data collection from one or more UEs.

[0299]

[0170] In one embodiment of this method, the request is carried out in a UE associated manner. Namely, the request is specific to a single UE. The request triggered by the RAN node 110 will therefore contain UE specific application protocol identifiers, identifying the UE over the concerned interface. Such identifiers could be UE NGAP IDs, e.g. AMF UE NGAP ID or RAN UE NGAP ID or both.

[0300]

[0171] In another embodiment of this method, the request is carried out in a non-UE associated manner. Namely, the request is not specific to a single UE, but it is for a group of UEs. The request triggered by the RAN node 110 will therefore contain a list of UE specific application protocol identifiers, identifying one or more UE over the concerned interface. Such identifiers could be UE NGAP IDs of each of the UEs for which data collection is needed, e.g. per UE AMF UE NGAP ID or RAN UE NGAP ID or both.

[0301]

[0172] In one dependent embodiment, the RAN node 110 indicates to the AMF node 210 that the data collection request is for the purpose of AI / ML model training, or AI / ML model performance monitoring.

[0302]

[0173] In one embodiment, the RAN node 110 indicates a time window within which it is to receive the ground truth information. Such time window can be indicated as:

[0303] • a specific time unit, e.g. in seconds,

[0304] • starting from a specific point in time, e.g. related to the SFN time, and / or• starting from reception of a specific message, e.g. the request for data collection message.

[0305]

[0174] Step 1603: Upon reception of the request for data collection from the RAN node 110, the AMF node 210 carries out the following:

[0306] • It optionally performs user consent checks (if not indicated before by the AMF node 210 to the RAN node 110 during the context setup procedures) for the one or more UEs for which data collection is requested. Note that this step could also be performed by the LMF node 310 in following steps, before sending positioning information to the RAN node 110.

[0307] • If data collection for the lists of UEs indicated by the RAN node 110 is possible, the AMF node 210 triggers a positioning request towards the LMF node 310 for such UEs. Examples of how this can be done are below:

[0308] o The AMF node 210 triggers concurrent positioning requests for a list of UEs in one message over the NL1 interface. Specifically, the Nlmf_Location service message sent over NL1 is enhanced to enable location determination request for a number of UEs.

[0309] o Or, the AMF node 210 triggers one positioning request for one UE at a time, via one Nlmf_Location service message, after selecting an appropriate LMF node 310 for each UE positioning session. The LMF selection by AMF node 210 takes into account the computational load of each LMF node 310, the UEs positioning capabilities, and historical positioning information from previous UE positioning sessions (which UE has been positioning by which the LMF node 310) when sending the NL1 Nlmf_Location service message to the selected LMF node 310.

[0310] • Optionally, the AMF node 210 specifies to the LMF node 310 that such positioning process is for the purpose of data collection at the RAN node 110. Such information could include that data collection is for the purpose of gathering labels to be used for training / monitoring of AI / ML assisted positioning models. The latter may let the LMF node 310 understand that the positioning process to be triggered should be UL measurement based and it may use configuration of SRS transmission for the UEs to be positioned and for which labels are used.o In one example, the AMF node 210 triggers the network initiated location requested as specified in TS 23.273 with an indication that the positioning request is for data collection as shown below:

[0311] Network Induced Location Request (NI-LR)

[0312] With a Network Induced Location Request (NI-LR), a serving AMF for a UE initiates localization of the UE for a regulatory service (e.g. an emergency call from the UE) or for verification of a UE location (country or international area) for NR satellite access or for data collection request from NG-RAN.

[0313]

[0175] Step 1604: The LMF node 310 may carry out user consent checks for the UE for which data collection is requested and, based on that, determine whether a positioning process to derive the requested data can be triggered / reused to signal data to the RAN node 110. Alternatively or additionally, user consent check can be carried out by the AMF node 210 or the RAN node 110. If data collection for the UE is allowed, the LMF node 310 triggers a positioning process for the one or more UEs for which the AMF node 210 requested. Such process may be carried out over a RAN-LMF communication protocol such as NRPPa. New or legacy procedures for the configuration of the positioning process could be adopted. The LMF node 310 may trigger a positioning process for the concerned UEs that is based on UL measurements of UE signalled reference signals, e.g. SRS based on the request from the AMF node 210. For such purpose, and during the signalling exchange between the LMF node 310 and the RAN node 110 to configure the positioning transmission at the UE, the RAN node 110 may indicate to the LMF node 310 that a specific UL reference signal configuration (e.g. SRS configuration) will be used, as part of legacy positioning information exchange procedures. Alternatively, the RAN node 110 can indicate during the first NGAP message the SRS configuration for each of the UE requested for UL RS (e.g. SRS) configuration, so that the LMF node 310 uses it during measurement request.

[0176] Step 1605: Once positioning is configured and triggered for the one or more concerned UEs, the RAN node 110 retrieve the UE ground truth, this can be as following:

[0314] o The AMF node 210 provides the UE location in the first NGAP response message that triggered the positioning process, once UE location has been computed.

[0315] o The AMF node 210 indicates that data collection is possible, and optionally that the requested data is available, and user consent check verified, therefore the RAN node 110 can start requesting for UE location. In this case the RAN node 110 requests to the LMF node 310 for positioning labels for each UE. Namely the RAN node 110 requests to the LMF node 310 the data including location information for the UE or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. Such request may occur over a RAN to LMF communication protocol, such as NRPPa. The LMF node 310 responds with labels for the concerned UEs.

[0316] o The RAN node 110 can request for one UE at a time over NRPPa interface in a new NRPPa message transported over NGAP UE associated UL NRPPa TRANSPORT message.

[0317] o The RAN node 110 request for multiple UEs over the NRPPa interface in new NRPPa message transported over NGAP non-U E associated UL NRPPa TRANSPORT message.

[0318]

[0177] Step 1606: By receiving the data from the LMF node 310, the RAN node 110 can construct training / monitoring data for each UE. This may occur by associating the labels for each UE with the UL RS signal measurements from the same UE, where the label (e.g. the UE location) and the RS measurements are associated to the same or to sufficiently close points in time.

[0319] Part 2:

[0320]

[0321] of Data from the LMF

[0322]

[0178] Referring now to Figure 17, shown is a sequence drawing of an example process with positioning-technique-agnostic reception of data from the LMF node 310.The steps shown in this sequence drawing are described below. It is to be understood that these steps are very specific and are provided for exemplary purposes. Other implementations are possible.

[0323]

[0179] Step 1701: the RAN node 110 determines that it needs to collect data for one or more of its served UEs 130b-c for the purpose of generating training data or monitoring data to be used for management of AI / ML assisted positioning models, e.g. for training or upgrading or tuning such models. For a UE, “Data” here is intended as location information for the UE or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning.

[0324]

[0180] Reasons for the RAN node 110 to request data for specific UEs can be:

[0325] • The UE has specific capabilities or characteristics for which the RAN node 110 did not sufficiently train its models.

[0326] • The UE has specific capabilities or characteristics for which the RAN node 110 did not sufficiently monitor its models' performance.

[0327] • The UE has specific capabilities or characteristics (e.g. multiple antennas and supports advance communication / positioning features like carrier aggregation) which makes it a good candidate as part B can be deduced more precisely. • The UE is in specific radio conditions for which the RAN node 110 did not sufficiently train its models.

[0328] • The UE is in specific radio conditions for which the RAN node 110 did not sufficiently monitor its models' performance.

[0329] • The UE uses or is selected to use specific reference signals configurations (e.g.

[0330] SRS configurations) for which the RAN node 110 did not sufficiently train its models.

[0331] • The UE uses or is selected to use specific reference signals configurations (e.g.

[0332] SRS configurations) for which the RAN node 110 did not sufficiently monitor its models' performance.

[0181] The gNB may also receive user consent for data collection information from the core network (CN), e.g. as part of the RAN-CN messages such as the Initial Context Setup message from the AMF node 210 to the RAN node 110. Based on the information received, the RAN node 110 may determine whether data collection for AI / ML assisted positioning is possible or not for a given UE. If user consent is not received from the CN, the AMF node 210 or the LMF node 310 may perform the user consent check before processing with the data collection as described on subsequent steps below.

[0333]

[0182] Step 1702: The RAN node 110 triggers towards the CN, e.g. the AMF node 210, a request over the RAN-CN interface, e.g. the NGAP. In such request, the RAN node 110 requests for data collection from one or more UEs.

[0334]

[0183] In one embodiment of this method, the request is carried out in a UE associated manner. Namely, the request is specific to a single UE. The request triggered by the RAN node 110 will therefore contain UE specific application protocol identifiers, identifying the UE over the concerned interface. Such identifiers could be UE NGAP IDs, e.g. AMF UE NGAP ID or RAN UE NGAP ID or both.

[0335]

[0184] In another embodiment of this method, the request is carried out in a non-UE associated manner. Namely, the request is not specific to a single UE, but it is for a group of UEs. The request triggered by the RAN node 110 will therefore contain a list of UE specific application protocol identifiers, identifying one or more UE over the concerned interface. Such identifiers could be UE NGAP IDs of each of the UEs for which data collection is needed, e.g. per UE AMF UE NGAP ID or RAN UE NGAP ID or both.

[0336]

[0185] In one dependent embodiment, the RAN node 110 indicates to the AMF node 210 that the data collection request is for the purpose of AI / ML model training, or AI / ML model performance monitoring.

[0337]

[0186] In one embodiment, the RAN node 110 indicates a time window within which it is to receive the ground truth information. Such time window can be indicated as:

[0338] in a specific time unit, e.g. in seconds,• starting from a specific point in time, e.g. related to the or in terms of SFN time, and / or

[0339] • starting from reception of a specific message, e.g. the request for data collection message.

[0340]

[0187] Step 1703: Upon reception of the request for data collection from the RAN node 110, the AMF node 210 carries out the following:

[0341] • It optionally performs user consent checks (if not indicated before by the AMF node 210 to the RAN node 110 during the context setup procedures) for the one or more UEs for which data collection is requested. Note that this step could also be performed by the LMF node 310 in following steps, before sending positioning information to the RAN node 110.

[0342] • If data collection for the list of UEs within those described by the RNA is possible, the AMF node 210 triggers a positioning request towards the LMF node 310 for such UEs.

[0343] • Optionally, the AMF node 210 specifies to the LMF node 310 that such positioning process is for the purpose of data collection at the RAN node 110.

[0344]

[0188] Step 1704: The LMF node 310 may carry out user consent checks for the UE for which data collection is requested and based on that determine whether a positioning process to derive the requested data can be triggered / reused to signal data to the RAN node 110. Alternatively or additionally, user consent check can be carried out by the AMF node 210 or the RAN node 110. If data collection for the UE is allowed, the LMF node 310 achieves the requested data for the concerned UEs by any means possible. Namely, the LMF node 310 may trigger any positioning technique to derive the UE positions, such as GNSS based positioning.

[0345]

[0189] Step 1705: The RAN node 110 requests to the LMF node 310 for positioning labels for each UE. Namely the RAN node 110 requests to the LMF node 310 the data including location information for the UE or any metric that can be used as ground truth for the inferred positioning measurements the RAN node 110 has to provide for AI / ML assisted positioning. Such request may occur over a RAN to LMFcommunication protocol, such as NRPPa. The LMF node 310 responds with labels for the concerned UEs.

[0346]

[0190] Step 1706: In order to derive the measurement parts that would need to be associated to the label provided by the LMF node 310 to form training data, the RAN node 110 may configure the UE with UL reference signals transmission, e.g. the RAN node 110 may configure the UE with an SRS configuration. Alternatively, the RAN node 110 may receive from the LMF node 310 a request to configure the UE with a specific UL RS configuration, e.g. an SRS configuration. Such configuration may be used by the RAN node 110 to measure UL RS form the UE and derive “Part A”.

[0347]

[0191] Step 1707: The RAN node 110 may therefore measure the SRS signalled by the UE at specific points in time. By associating the RS measurements at a given time with the UE position or in general the UE “data” received from the LMF node 310 for the same or a close enough point in time, the RAN node 110 can construct a set of training data. Similarly, the RAN node 110 can check the model performance by inferring the AI / ML assisted positioning measurements from the SRS measurements taken for the UE and compare such inferred measurements with the same measurements derived from the UE position or UE data signalled by the LMF node 310. In other words, the RAN node 110 may correlate the UL measurements collected by the UE for the RS configuration with the received UE location from the LMF node 310 based on the time stamp associated with each of these information.

[0348] Part 2: Reception of Data from the AMF

[0349]

[0192] Referring now to Figure 18, shown is a sequence drawing of an example process with provisioning of UE data via the AMF node 210 to the RAN node 110. The steps shown in this sequence drawing are described below. It is to be understood that these steps are very specific and are provided for exemplary purposes. Other implementations are possible.

[0350]

[0193] This embodiment includes both options based on UL measurement positioning techniques described in the first embodiment, to positioning techniques agnostic approaches described in the second embodiment. Step 1801, 1802, 1803,1804 and 1806 of Figure 18 are similar to steps step 1601, 1602, 1603, 1604 and 1606 of Figure 16, and thus their descriptions are not repeated here.

[0351]

[0194] The difference in the embodiment of Figure 18 is that at step 1805 the RAN node 110 does not request the data to the LMF node 310 and the LMF node 310 does not signal data to the RAN node 110, such as, for example, in step 1605 of Figure 16. Instead, at step 1805 the LMF node 310 will signal the UE position to the AMF node 210, which triggered a positioning process for the one or more UEs, as requested by the RAN node 110. The AMF node 210 can therefore signal to the RAN node 110 the requested data, namely the labels in the form of e.g. the UE position. The RAN node 110 can derive e.g. training data by either combining the UE label with the RS measurements derived from the UL positioning process triggered by the LMF node 310 (as in the first embodiment) or by combining the UE label with UL RS measurements derived by UL RS configuration at the UE, where the UL RS is for example an SRS.

[0352]

[0195] In one embodiment, the AMF node 210 sends the response message to the data collection together with the UE data in one message after arrow 8 in step 1805. In case of failure, due to e.g., no UE consent, or failure to UE positioning, a failure message is sent. A new cause value can be defined, e.g., “UE positioning failed”.

[0353] Part 2: Technical Specification Impact

[0354]

[0196] Below are potential spec impacts to 3GPP TS 38.413 entitled “NG-RAN; NG Application Protocol (NGAP)” version 18.3.0 dated 2024-09-21:

[0355] DATA COLLECTION REQUEST

[0356]

[0197] This message is sent by the NG-RAN node to request data collection from the AMF node 210 over the NG interface for one UE.

[0357] Direction: NG-RAN node AMF

[0358]

[0359]

[0360] DATA COLLECTION RESPONSE

[0361]

[0198] This message is sent by the AMF to provide ground truth information to the NG-RAN over the NG interface.

[0362] Direction:

[0363]

[0364] node

[0365] >

[0366] >

[0367]

[0368] DATA COLLECTION FAILURE

[0369]

[0199] This message is sent by the AMF to indicate failure of providing ground truth to the NG-RAN over the NG interface.

[0370] Direction:

[0371]

[0372] node

[0373]

[0374]

[0375] Example List of Embodiments

[0376]

[0200] RAN embodiments:

[0377] • The RAN node 110 requests via a first NGAP message to the AMF node 210 for ground truth (i.e. , location information and time stamp) for a single UE, or for a list of UEs. A UE is identified by its NGAP UE ID in the NGAP message.

[0378] • Optionally, indicating to the LMF node 310 a specific UL Rs configuration for which data collection is performed and configuring the UE with it.

[0379] • Receiving the location information of the requested UE(s) in a second message, which can be either a response message to the first NGAP message described in step 1 or that can be the response to a data collection request from the RAN node 110 to the LMF node 310 signalled after Step 1.

[0380] • Receiving, in case of failure, an indication that the ground truth information of the requested UE(s) cannot be provided in a second message, which is a response message to the first NGAP message described in step 1 or that can be the response to a data collection request from the RAN node 110 to the LMF node 310 signalled after Step 1. The failure can be indicated by cause value, e.g. the failure can be due to user consent not being available, or that positioning could not be performed.

[0381] • The alternative where the RAN node 110 receives data from the LMF node 310 is based on:

[0382] o receiving an acknowledgement message from the AMF node 210 that ground truth information is available and can be retrieved from the LMF node 310.o Sending a NRPPa request message to the LMF node 310 for the ground truth.

[0383] o Receiving the UE location information from the LMF node 310.

[0384]

[0201] AMF embodiments:

[0385] • Receiving a NGAP request message from NG-RAN indicating request for ground truth information a list of UE(s).

[0386] • Checking if data collection for the UE(s) indicated in step 1) is possible, e.g. if user consent for such UEs is in place.

[0387] • If data collection for the UE is possible, selecting an LMF node 310 for a specific UE.

[0388] • Triggering a service request to the selected LMF node 310 for the requested UE(s), optionally indicating that positioning is for data collection purpose.

[0389] • In one alternative, receiving the location information from the LMF node 310 after positioning is done and providing an NGAP response message to the RAN node 110 with location information, or acknowledgement or failure with cause value.

[0390] • In another alternative, the AMF node 210 does not provide the requested data to the RAN node 110, but the LMF node 310 provides them upon the RAN node 110 requesting them.

[0391]

[0202] LMF Embodiments:

[0392] • Receiving a data collection request implying positioning of one or more UEs.

[0393] Optionally, checking if data collection and reporting for such UEs is possible, e.g. if user consent is available for such UEs.

[0394] • Optionally Interacting with the RAN node 110 for any specific UL RS configurations at the UE.

[0395] • Signalling the results of the one or more UE positioning process to the RAN node 110, after the RAN node 110 has requested for such information.

[0396] • Alternatively, signalling the results of the one or more UE positioning process to the AMF node 210.

[0203] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0397]

[0204] Numerous modifications and variations of the present disclosure are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the disclosure may be practised otherwise than as specifically described herein.

Claims

Claims:

1. A method for execution by a first network node, comprising:sending, to another network node, a request for ground truth information for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit) or a served UE or PRU; andreceiving a response including either (i) the ground truth information for the at least one equipment or (ii) an indication that the ground truth information cannot be provided.

2. The method of claim 1, wherein the request concerns at least one nonserved UE, and wherein the request identifies the at least one non-served UE using an SRS (Sounding Reference Signal) configuration of the at least one non-served UE.

3. The method of claim 2, wherein the request further identifies the at least one non-served UE using an NRPPa (New Radio Positioning Protocol A) transaction ID (Identifier), an LMF (Location Management Function) measurement ID, and / or a RAN (Radio Access Network) measurement ID.

4. The method of claim 1, wherein the request concerns at least one PRU, and wherein the request identifies the at least one PRU using an area of interest and / or operating conditions.

5. The method of claim 4, wherein the request for ground truth information is a first request for data collection sent to a second network node to trigger positioning request with a third network node, and wherein the method further comprises:sending, to the third network node, a second request for data collection.

6. The method of claim 1 , wherein the request concerns at least one served UE.

7. The method of claim 6, wherein the response is received from a second network node which is same as the another network node to which the request is sent.

8. The method of claim 6, wherein the response is received from a third network node which is different from the another network node to which the request is sent.

9. The method of claim 8, comprising:receiving, from the third network node, an acknowledgement message that the ground truth information is available and can be retrieved from the third network node; andsending, to the third network node, a request message for the ground truth information.

10. The method of any one of claims 1 to 9, wherein the request for ground truth information indicates a time window within the ground truth information is to be received.

11. The method of any one of claims 1 to 10, wherein the response includes the ground truth information.

12. The method of claim 11 , further comprising:obtaining SRS measurements for the at least one equipment; andcombining the SRS measurements with the ground truth information to form training data set.

13. The method of any one of claims 1 to 10, wherein the response includes the indication that the ground truth information cannot be provided.

14. The method of claim 13, wherein the indication comprises a cause code indicating failure due to user consent not being available and / or a cause code indicating failure due to positioning could not be performed.

15. The method of any one of claims 1 to 14, wherein the first network node comprises a RAN (Radio Access Network) node, and the another network node comprises an AMF (Access and Mobility Management Function) node or an LMF (Location Management Function) node.

16. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a first network node, configure the first network node to implement a method according to any one of claims 1 to 15.

17. A first network node, comprising:a network interface configured to communicate with other network nodes;control circuitry coupled to the network interface and configured to:send, to another network node, a request for ground truth information for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit) or a served UE; andreceive a response including either (i) the ground truth information for the at least one equipment or (ii) an indication that the ground truth information cannot be provided.

18. The first network node of claim 17, wherein the control circuitry is further configured to implement a method according to any one of claims 2 to 15.

19. A method for execution by a second network node, comprising:receiving, from a first network node, a request for ground truth information for at least one equipment which can be a served UE (User Equipment) or a PRU (Positioning Reference Unit); andfacilitating transfer, to the first network node, the ground truth information or an indication that the ground truth information cannot be provided.

20. The method of claim 19, wherein the request concerns at least one PRU, and wherein the request identifies the at least one PRU using an area of interest and / or operating conditions.

21. The method of claim 19, wherein the request concerns at least one served UE, and wherein the method comprises:receiving an UL RS (Uplink Reference Signal) configuration for which data collection is performed.

22. The method of any one of claims 19 to 21, comprising:checking if data collection for the at least one equipment is possible; andif data collection for the at least one equipment is possible, selecting a third network node for the at least one equipment, triggering a service request to the third network node for the at least one equipment, and facilitating transfer of the ground truth information.

23. The method of any one of claims 19 to 21, comprising:checking if data collection for the at least one equipment is possible; andif data collection for the at least one equipment is not possible, facilitating transfer of the indication that the ground truth information cannot be provided.

24. The method of claim 23, wherein the indication comprises a cause code indicating failure due to user consent not being available and / or a cause code indicating failure due to positioning could not be performed.

25. The method of any one of claims 19 to 24, wherein the second network node comprises an AMF (Access and Mobility Management Function) node, and the first network node comprises a RAN (Radio Access Network) node.

26. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a second network node, configure the second network node to implement a method according to any one of claims 19 to 25.

27. A second network node, comprising:a network interface configured to communicate with other network nodes;control circuitry coupled to the network interface and configured to:receive, from a first network node, a request for ground truth information for at least one equipment which can be a served UE (User Equipment) or a PRU (Positioning Reference Unit); andfacilitate transfer, to the first network node, the ground truth information or an indication that the ground truth information cannot be provided.

28. The second network node of claim 27, wherein the control circuitry is further configured to implement a method according to any one of claims 20 to 25.

29. A method for execution by a third network node, comprising:receiving, from another network node, a request for ground truth information for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit) or a served UE; andsending the ground truth information or an indication that the ground truth information cannot be provided.

30. The method of claim 29, wherein the request concerns at least one nonserved UE, and wherein the request identifies the at least one non-served UE using an SRS (Sounding Reference Signal) configuration of the at least one non-served UE.

31. The method of claim 30, wherein the request further identifies the at least one non-served UE using an NRPPa (New Radio Positioning Protocol A) transaction ID (Identifier), an LMF measurement ID, and / or a RAN (Radio Access Network) measurement ID.

32. The method of claim 29, wherein the request concerns at least one PRU, and wherein the request identifies the at least one PRU using an area of interest and / or operating conditions.

33. The method of claim 32, wherein the request for ground truth information is a first request for data collection from a second network node (e.g. AMF), and wherein the method further comprises:receiving, from the first network node, a second request for data collection.

34. The method of claim 29, wherein the request concerns at least one served UE, and wherein the method comprises:receiving an UL RS (Uplink Reference Signal) configuration for which data collection is performed.

35. The method of any one of claims 29 to 34, comprising:checking if data collection for the at least one equipment is possible; andIf data collection for the at least one equipment is possible, sending the ground truth information.

36. The method of claim 34, wherein the ground truth information is sent to the first network node.

37. The method of any one of claims 29 to 33, comprising:checking if data collection for the at least one equipment is possible; andIf data collection for the at least one equipment is not possible, sending the indication that the ground truth information cannot be provided.

38. The method of claim 37, wherein the indication comprises a cause code indicating failure due to user consent not being available and / or a cause code indicating failure due to positioning could not be performed.

39. The method of any one of claims 29 to 38, wherein the third network node comprises an LMF (Location Management Function) node, and the another network node comprises a RAN (Radio Access Network) node or an AMF (Access and Mobility Management Function) node.

40. A non-transitory CRM (computer readable medium) having recorded thereon statements and instructions that, when executed by a processor of a third network node, configure the third network node to implement a method according to any one of claims 29 to 39.

41. A third network node, comprising:a network interface configured to communicate with other network nodes;control circuitry coupled to the network interface and configured to:receive, from another network node, a request for ground truth information for at least one equipment which can be a non-served UE (User Equipment) or a PRU (Positioning Reference Unit); andsend the ground truth information or an indication that the ground truth information cannot be provided.

42. The third network node of claim41, wherein the control circuitry is further configured to implement a method according to any one of claims 30 to 39.

Images