Cross-layer intelligent beam management engine

Abstract

The technology described herein relates to a distributed cross-layer intelligent beam management engine that performs a beam alignment procedure including learning a site-specific sounding codebook and predicting an optimal narrow beam using the AI / ML method using sounding codebook measurements. The learned codebook determines a site-specific sounding beam that can capture specific characteristics of the propagation environment. The distributed engine includes distributed applications with different latency requirements that perform different portions of the beam alignment procedure. One application (e.g., in a non-real-time controller) provides probe codebook policy data and report policy data, and another application (e.g., in a near-real-time controller) learns a probe codebook based on the policy data. The third real-time application performs a beam scan based on the sounding codebook, where an optimal beam of the user equipment is identified by the user equipment.

Description

Cross-reference to related applications

[0001] This application claims priority to U.S. nonprovisional patent application No. 18 / 350,848, filed July 12, 2023, entitled “CROSS-LAYER INTELLIGENTBEAM MANAGEMENT ENGINE,” the entire contents of which are incorporated herein by reference. Background Technology

[0002] To facilitate accurate beam alignment between user equipment and serving base stations in New Radio (NR) networks, the 3GPP (3rd Generation Partnership Project) standard provides reasonable flexibility in configuring beam measurement, beam reporting, and beam indication. These configurations incur signaling overhead, leading to a trade-off between network performance and the implemented signaling overhead. For example, to ensure continuous connectivity between user equipment and base stations, frequent beam measurements and measurement reports are required, especially in high-mobility scenarios. This frequent beam measurement and measurement reporting increases signaling overhead, which often degrades overall network performance. Attached Figure Description

[0003] The techniques described herein are illustrated by way of example and are not limited to the accompanying drawings, in which the same reference numerals indicate similar elements, and wherein:

[0004] Figure 1 The system / architecture shown is an example block diagram representation of various aspects and implementations of this disclosure, which incorporates a distributed cross-layer beam management engine.

[0005] Figure 2 An example machine learning model structure for beam management policy control of an application (e.g., rApp) at the non-real-time radio access network (RAN) intelligent controller (RIC) layer of a distributed beam management engine, according to various aspects and implementations of this disclosure, is shown.

[0006] Figure 3 Based on various aspects and implementations of this disclosure, the distributed beam management engine operates at a near real-time RIC layer via an application (e.g., xApp) from the complete potential beam set (set). A Determine / select the set of sparse beam patterns (set) B Example representation of ).

[0007] Figure 4 This is an example timing and data flow diagram for a beam management strategy control application (e.g., rApp) running at a non-real-time RIC layer, based on various aspects and implementations of this disclosure.

[0008] Figure 5 These are example timing and data flow diagrams for a beam management measurement set selection application (e.g., xApp) operating at a near real-time RIC layer, based on various aspects and implementations of this disclosure.

[0009] Figure 6 This is an example timing and data flow diagram illustrating spatial domain beam management operations for determining the optimal communication beam between a node and a user equipment, according to various aspects and implementations of this disclosure.

[0010] Figure 7 This illustrates aspects and implementations of measurements from beam scanning (e.g., front beam scanning) according to this disclosure. K A flowchart illustrating an example operation related to determining the optimal communication beam in a subgroup of beams.

[0011] Figure 8 This is a flowchart illustrating example operations related to determining an optimal communication beam and using that beam to communicate with a user equipment, according to various aspects and implementations of this disclosure.

[0012] Figure 9 and Figure 10 This includes flowcharts illustrating example operations related to performing beam scanning using the highest-performance beam scanning measurement subgroup to determine the optimal communication beam for a user equipment, according to various aspects and implementations of this disclosure.

[0013] Figure 11 This is a block diagram representing an example computing environment in which various aspects of the topics described in this article can be incorporated.

[0014] Figure 12 Example schematic block diagrams depict computing environments according to various aspects and implementations of this disclosure, the disclosed subjects being able to interact with / be implemented at least in part with such computing environments. Detailed Implementation

[0015] The various aspects of the technology described in this paper largely relate to intelligent beam management, which improves overall network performance in terms of throughput and reliability. In one implementation, intelligent beam management is based on a distributed cross-layer beam management engine. This distributed cross-layer beam management engine can be based on an Open Radio Access Network (O-RAN) architecture, including distributing beam management processes as applications within the Radio Access Network (RAN) control framework.

[0016] In one particular implementation, these processes are implemented as artificial intelligence / machine learning (AI / ML) applications running within distributed controllers, including at the non-real-time RAN Intelligent Controller (RIC) layer, the near-real-time RAN Intelligent Controller layer, and the real-time Intelligent Controller layer. The distribution of beam management applications / processes is typically based on the latency budget and functionality of each process within a cross-layer intelligent beam management engine framework that includes data / control exchange between distributed controllers.

[0017] In this framework, the beam alignment process learns a site-specific probe codebook and uses measurements corresponding to the probe codebook to predict the optimal narrow beam. The learned codebook identifies site-specific probe beams that can capture specific characteristics of the propagation environment. To this end, an application in the non-real-time RIC (rApp or RAN application, which may be a microservice / function) provides probe codebook policies and reporting policies (e.g., based on a trained model). Another application (xApp or extended App) runs on the near real-time RIC and learns the probe codebook based on the probe codebook policy data. Based on the learned probe codebook, another application (dApp or distributed App) runs on the real-time RIC (e.g., a distributed cell) and performs beam scanning compatible with beam-scanning-based beam alignment frameworks in new radios (NR, including 5G and beyond).

[0018] Throughout this specification, references to "an embodiment," "an embodiment," "an implementation," "an implementation," etc., imply that a particular feature, structure, or characteristic described in connection with an embodiment / implementation is included in at least one embodiment / implementation. Therefore, the appearance of such phrases as "in one embodiment," "in an implementation," etc., throughout this specification does not necessarily refer to the same embodiment / implementation. Furthermore, a particular feature, structure, or characteristic may be combined in any suitable manner in one or more embodiments / implementations. It should also be noted that the terms used herein (such as "optimize," "optimization," "optimal," etc.) indicate only a goal of moving toward a better state, not necessarily an ideal result. For example, "optimal" may mean the highest-performing entity available (e.g., the highest-rated beam in a finite set of available beams), not necessarily achieving a completely optimal result. Similarly, "maximize" means moving toward a maximum state (e.g., reaching a threshold limit, if any), not necessarily achieving such a state.

[0019] Various aspects of this disclosure will be described more fully below with reference to the accompanying drawings, which illustrate example components, diagrams, and / or operations. In the following description, several specific details are set forth for purposes of explanation in order to provide a thorough understanding of various embodiments. However, this disclosure may be embodied in many different forms and should not be construed as limited to the examples set forth herein.

[0020] Figure 1 An example system / architecture of a distributed cross-layer beam management engine 100 coupled to a radio unit (RU) 102 is shown. As described herein, in the distributed engine 100, different distributed applications play a significant role in reducing signaling overhead associated with beam management and improving overall accuracy and performance. It is important to note that the distributed engine 100 described herein operates in the opposite manner to traditional RAN systems, where beam management is centralized at the distributed unit and operates based on exhaustive / predetermined beam set scanning.

[0021] In the example system / architecture, the service management and orchestration framework 104 includes a non-real-time RIC layer 106 configured to run cloud-based applications (referred to as rApps in O-RAN), including the beam management policy control rApp 108 described herein. The beam management policy control rApp 108 learns policies via a model (e.g., the ML model described herein) to help configure beam measurement sets, beam reporting types and periods, and beam dwell times or prediction intervals. This policy data can be learned for different types of beam management (i.e., spatial, temporal, or both), and the model can be updated based on input parameters and / or as the environment changes. The beam management policy control rApp 108 is coupled to O1 service 110 via an R1 interface; O1 service 110 is in turn coupled to other distributed engine layers via O1 interfaces to deliver various data, including the beam set policy data described herein.

[0022] The near-real-time RIC layer 112 is coupled to the non-real-time RIC layer 106 via the A1 interface. The near-real-time RIC layer 112 is configured to run edge-based applications (e.g., xApps (extended apps) in O-RAN), including sparse beam sets (sets) based on beam set policy data from beam management policy control rApp 108 as described herein. B xApp 114 is selected. In one alternative, the ML inference host 116 is coupled to or incorporated into the sparse beam set selection xApp 114 to determine, based on beam set strategy data, which sparse beam subgroup to select from the full available set to perform beam scanning. Alternatively, or in addition to the ML inference host 116, other alternatives (e.g., lookup tables) may be used for sparse set selection.

[0023] More specifically, sparse beam set selection xApp 114 is used to determine / define the measurement set using enriched information (e.g., user equipment (UE) trajectory (location and velocity) data). In sparse beam set selection xApp 114, spatial / temporal correlations are incorporated into an intelligent model (ML inference host 116) to predict the optimal measurement set in advance based on previous (historical) measurements and corresponding indication sequences. B In simple cases, xApp 114 can be simplified to a lookup table, which can be merged with local edge applications (referred to as dApps (distributed applications)) such as real-time RICs running in distributed units. The dApp determines the service beam or optimal... K A beam, as described in further detail in this article.

[0024] like Figure 1 As shown, typically, the E2 node 118, coupled to the near real-time RIC layer via the E2 interface, includes a centralized unit (control plane) CU-CP 120 and a centralized unit (user plane) CU-UP 122 component. The E2 node 118 also includes a distributed unit (or distributed unit pool) 124, which includes a real-time RIC layer 126 with a distributed beam management engine. The real-time RIC layer 126 runs a dApp 128, which can perform the P2 and P3 phases / procedures of beam scanning as generally described herein. As currently defined by 3GPP, P2 is used to beamfine the base station transmit beams by performing a narrower beam scan over a narrower corner sector than in phase P1; in this procedure, the wide UE Rx beam is fixed. P3 is used to beamfine the UE receive beam by performing a narrower receive beam scan at the UE; in P3, the detected optimal Tx beam remains fixed during the UE receive beam scan.

[0025] exist Figure 1 The diagram also shows an external application server 130. The external application server 130 participates in various data collection activities, particularly information enrichment (see references in this document). Figure 4 and Figure 5 (Described user equipment trajectory data / location data / speed data).

[0026] like Figure 1 What we see here includes Figure 1The architecture of the distributed beam management engine 100 can be deployed in a simple manner, typically because distributed intelligence-based solutions can be encapsulated into cloud / edge applications (rApp, xApp) using existing RIC platforms (both non-real-time and near-real-time) and interfaces, as well as E2 service model radio control (E2SM RC) for beam management use cases. Local edge-based applications (dApp 128) can replace the existing refined beam management processes (P2 / P3) on the scheduler. Deployment of dApps on real-time RICs can be standardized in terms of their platforms and corresponding interfaces, for example, in O-RAN. Beam management dApp 128 deployed on real-time RICs can interface with O-CU (Open Centralized Unit / O-DU (Open Distributed Unit)), non-real-time, and near-real-time RIC platforms. In the case of deployment on a real-time RIC platform, a single instance of the beam management dApp can be used for pooled distributed unit scenarios.

[0027] Moving to further details of the beam management control strategy rApp 108, in the non-real-time layer 106, application 108 provides a case-based probe codebook strategy. This strategy can be used to reduce the number of beams in the probe codebook, where the probe codebook is a small, sparse set of beams used for beam scanning operations, rather than a complete set of beams. In other words, the complete set of beams has a larger cardinality relative to the smaller cardinality of the sparse beam probe codebook set. It's important to note that in this example implementation, rApp application 108 does not select a measurement set. B Instead, it provides strategy data for xApp 114 to use in order to intelligently and / or heuristically determine the set. B .

[0028] The beam management control strategy rApp 108 also provides report type and periodicity data based on environmental and measurement data, enriched information (UE location and velocity, environmental model from digital twin, etc.), and beam statistics feedback. Application 108 can adaptively change the reporting period based on fault statistics and UE profile data. Application 108 can also change the report type based on information required for refinement procedures (e.g., channel state information report feedback regarding refinement or scanning procedures) to reduce the cardinality of the probe codebook and / or improve accuracy.

[0029] Furthermore, by applying 108, dwell time can be estimated, which eliminates the conventional first beam scan procedure (P1) and reduces beam failure events within the prediction period. Dwell time estimation may also lead to an increase in the average prediction period for different scenarios with varying mobility patterns and environmental change rates. In addition to the advantages described above, dwell time estimation also helps save energy on the UE side because a beam scan procedure is not required within the prediction period.

[0030] Figure 2 An example is shown of modeling an AI / ML model 204 for beam management policy control rApp based on an input parameter set 232 and an output data policy structure 234. In this example, the (non-limiting) input parameters 232 may include environmental data, including but not limited to cell site information (e.g., location, inter-site distance), base station (BS) system configuration data, antenna configuration data at the UE and BS, a complete M-MIMO (Massive Multiple-Input Multiple-Output) configuration set, and digital twin information. Measurement data / performance management data are also input, including but not limited to periodic beam measurement data, beam fault indication data, service mode data, and quality of service (QoS) requirement data. UE profile data is another set of input parameters, including but not limited to UE location data, velocity data, and orientation data when available. Profile data of neighboring UEs may also be input into the model.

[0031] Example non-restricted output strategy data 234 may include probe codebook strategy data, such as, but not limited to, the number of beams, information about narrow and / or wide beams, fixed beam data, random beam data, and custom designs (e.g., multi-arm beam designs, specific neural network-based designs). It also outputs reporting strategies, including reporting period, reporting type, beam dwell time, and corresponding prediction interval data.

[0032] Beam management probe codebook learning / selection in near real-time layer 112 xApp 114 Figure 1 The xApp 114 obtains output policy data 234. The xApp 114 defines the probe codebook by incorporating enrichment information (e.g., channel vectors, UE location and velocity at availability) and candidate recommendation data (e.g., number of beams, narrow or wide beams, fixed, random, and / or custom design) provided by the beam management policy control rApp 108. The xApp 114 sends the probe codebook candidates to the real-time beam predictor dApp 128 via the E2 interface.

[0033] AI / ML methods (e.g., neural network architectures such as Model 116) can be used to select probe codebook candidates. Alternatively, other solutions (e.g., lookup tables) can use beam management strategies to control the provided candidate recommendations to select probe codebooks.

[0034] As described in this article, rApp 108 defines a set of beam measurement tools. B Strategies for selecting, measuring, and controlling the types and time granularity of updated reports (Data 234). Figure 3 In the example, the set of all potential beams is called the set. A(labeled 340), and used for initial beam scanning instead of in the set A The smaller (reduced cardinality) sparse beam set that performs a full beam scan is called the ensemble. B .gather A yes K × K Discrete Fourier Transform (DFT) codebook, where K This indicates the number of gNB antenna elements. Figure 3 It shows K =8 measurement set B A design example of the pattern, where sets B 342 is the complete set of 64 beams. A A subset of 340 (beams 0 to 63). It is important to note that in... Figure 3 In the middle, the double boxes surrounding the beam number highlight which beams will be used for scanning; in the subgroup B In the example, only 16 of the 64 potential beams (beams 0, 2, 4...54) are used.

[0035] like Figure 1 As shown, rApp 108 sends measurement and reporting strategies to both beam management xApp 114 and beam management P2 / P3 dApp 128 via the O1 interface. xApp 114 combines enrichment information (EI) 344 to determine the beam measurement set. B Once the set is determined B xApp 114 application 114 uses the E2 interface to collect the collection B Candidates are sent to dApp 128, where inference is performed (e.g., an O-DU scheduler). dApp 128 combines EI (enriched information, such as UE location, velocity, and channel state information (CSI) feedback) to determine the serving beam for each UE. K The most likely beam. For example... Figure 1 As shown, dApp128 is deployed on real-time RIC (layer) 126, where inference is coupled to or incorporated into the DU scheduler, or as an AI / ML module deployed on DU124.

[0036] Figure 4 The beam management strategy control rApp 108 is shown. Figure 1 Example data flow / timing / call flowchart. (e.g.) Figure 4As can be seen at arrow one (1), the collection and control component 408 of SMO 104 is coupled to (or incorporated into) the non-real-time (RT) RIC 106, and collects environmental data, UE measurement data, network key performance indicator (KPI) data, and UE profile data. This data can be collected from O1 service 110 via the R1 interface. Figure 1 The collected data and enrichment information are acquired by the application server 130 (arrow three (3)). The training and deployment of (multiple) ML models are represented by arrows four (4) and five (5) in the ML workflow box 450, respectively.

[0037] Once trained, such as Figure 4 As shown in monitoring and optimization box 452, inference is performed on the current data obtained from (multiple) E2 nodes 118 via arrow six (6) and from application server 130 via arrow seven (7). rApp 108 obtains (arrow eight (8)) and uses measurements to configure the set. B Select policy data and reporting policy data (including report type, reporting period, and beam dwell time estimation) to generate a recommended set for beam management xApp 114 and / or dApp 128. Predicting beam dwell time enables the network to trigger beam reports at the expected time. Therefore, predicting beam dwell time can reduce the overhead of beam measurement reference signals and beam reporting, and can also reduce UE power consumption. B The strategy data includes the number of beams, beam type (narrow and / or wide), and set type (fixed, random, preset, and custom design). The recommended configuration is provided to the near real-time RIC 112 (xApp) and / or (multiple) E2 nodes (dApp) via the O1 interface, as indicated by arrows 10 (10) and 11 (11).

[0038] Figure 5 The beam management set selection xApp 114 is shown. Figure 1 Example data flow / timing / call flowchart. Typically, and as described herein, xApp application 114 determines the beam measurement set based on the collected enriched information (e.g., UE location and velocity) and the recommended policy data provided by beam management policy control rApp 108. B xApp 114 uses the E2 interface to store the collection B Candidates are sent to the dApp, where inference is performed by the dApp (i.e., the O-DU scheduler).

[0039] like Figure 5As can be seen at arrow one (1), the collection and control component 408 of SMO 104 is coupled to (or incorporated into) the non-real-time (RT) RIC 104 and collects model training data from (multiple) E2 nodes 118. At arrow two (2), enrichment information is collected from application server 130. This can be achieved via the R1 interface from O1 service 110 (… Figure 1 The collected data and enrichment information are obtained by the application server 130 (arrow three (3)). In this example, the training and deployment of (multiple) ML models are represented by arrows four (4) and five (5) in the ML workflow box 550, respectively; it should be noted that this is only an example implementation and alternative solutions such as lookup tables may be used.

[0040] In this example, such as Figure 4 As shown in monitoring and optimization box 452, once trained, enriched information is collected for inference (box 552). This enriched information is obtained via a request to application server 130, indicated by arrow six (6), and a response from application server 130, indicated by arrow seven (7). The enriched information is acquired (arrow eight (8)) by rApp 108 in non-real-time RIC 106, and then sent to / collected by xApp 114 in near real-time RIC 112 (arrow nine (9)). Data collection for inference is sent from near real-time RIC 112 to E2 nodes (multiple) 118 (arrow ten (10)).

[0041] xApp 114 uses the collected measurement data to estimate the optimal probe beam measurement set for different scenarios. B , as the total is represented by arrow eleven (11). The determined set of measurements B It is provided to (multiple) E2 nodes 118, that is, to P2 / P3 dApp 128 via the E2 interface (arrow twelve (12)).

[0042] Figure 6 This is an example spatial domain beam management data flow / timing diagram of the network-side AI / ML spatial beam management process, where AI / ML dApp model training and inference are performed at the base station. For the training phase, the network scans all potential beams (set). A This enables the UE 660 to determine and report the optimal beam ID, as shown by arrow 1 (1). The UE 660 feeds back the reference signal received power data (RSRP) of the small sparse beam set (set B) and the corresponding optimal beam ID obtained from the full scan beam set to facilitate the collection of training input data, as shown by box 2 (2) and arrow 3 (3).

[0043] The network collects these training input data (RSRP of the small beam set and its corresponding optimal beam ID) from multiple UEs within the coverage area. For the model training phase, the sparse set... B The report RSRP and optimal beam ID were used to train cell-specific AI / ML models (arrow four (4)).

[0044] During the model inference phase (Box 4(4)), the network (E2 node) only needs to be in the small sparse SSB set (synchronization signal block) beam (set) B The UE scans the SSB beam as shown by arrow five (5). Then, the UE measures the scanned SSB beam and feeds its corresponding RSRP back to the network (arrow six (6)). The network inputs the UE measurements into the trained AI / ML model (arrow seven (7)), which outputs the front... K A narrow beam (arrow eight (8)); (compared to other beams with poorer performance, this front beam) K A narrow beam subgroup can be considered as at least a threshold high-performance beam scanning measurement subgroup determined by AI / ML-based beam inference in box seven (7).

[0045] As if Figure 6 As shown by arrow eight (8) and box nine (9), the inferred front is scanned via CSI-RS (Channel State Information-Reference Signal) scanning. K A narrow beam is used to determine the final optimal narrow beam. The UE returns the channel state information reference signal identifier (ID) of the optimal beam, as shown by arrow 10 (10); (the optimal can be considered as the beam that achieves at least a threshold of high performance, for example, relative to the beam from the previous...) K (The highest performance of other candidate beams in the subgroup). Then, the network uses the identified optimal beam to transmit data to the UE, as shown by arrow eleven (11).

[0046] In summary, the architecture described in this paper provides a distributed, cross-layer beam management engine that distributes beam management phases based on the latency budgets of beam management phases P1, P2, and P3, as well as the granularity required for control / insertion and reporting commands. The distributed beam management engine comprises three distinct applications distributed across the network (referred to as the beam management policy control rApp, ensemble selection xApp, and P2 / P3 beam management dApp). Based on this architecture, the training, deployment, inference, and performance monitoring of up to three different ML models deployed on non-RT RICs (rApp), near-RT RICs (xApp), and RT RICs (dApp), respectively, are coordinated. This coordination of the different layer applications may include the evaluation of dependencies between the rApp, xApp, and dApp and their corresponding impact on prediction accuracy.

[0047] One or more aspects can be embodied in network devices (such as...) Figure 7 (as illustrated in the example operations), and may include, for example, memory storing computer-executable components and / or operations, and a processor executing the computer-executable components and / or operations stored in the memory. Example operations may include operation 702, which represents determining probe codebook policy data representing a probe codebook policy for a cell site. Example operation 704 represents determining reporting policy data representing a reporting policy for a cell site. Example operation 706 represents estimating candidate sparse probe beam scan measurement subgroups with a first cardinality less than a second cardinality of potential probe beam scan measurement subgroups based on the probe codebook policy data and user equipment measurement data representing user equipment measurements. Example operation 708 represents performing a synchronization signal block beam scan based on sparse candidate probe beam scan measurement subgroups to determine at least a threshold high-performance beam subgroup from the candidate probe beam scan measurement subgroups based on reference received power signal data returned according to the reporting policy data, wherein the at least threshold high-performance beam scan measurement subgroup has a third cardinality less than the second cardinality. Example operation 710 represents performing a channel state information-reference signal beam scan based on at least a threshold high-performance beam scan measurement subgroup to determine a communication beam from a candidate probe beam scan measurement subgroup based on identifier information returned from the user equipment, which can be used to achieve at least a threshold high performance.

[0048] At least the threshold high-performance beam scanning measurement can be the highest performance beam scanning measurement. The determination of the communication beam can include determining the optimal communication beam that can be used to achieve optimal performance from the candidate probe beam scanning measurement subgroup, and further operations can include communicating with the user equipment via the optimal communication beam.

[0049] Determining the probe codebook strategy data and the cell site reporting strategy data may include inputting at least one of the following into the model: environmental data representing environmental characteristics associated with the cell site, measurement data representing measurements applicable to the cell site, performance management data related to performance management applicable to the cell site, or user equipment profile data representing user equipment profiles; the model may be trained using at least one of the following: previously collected environmental data representing past environmental characteristics associated with the cell site, previously collected measurement data representing past measurements associated with the cell site, previously collected performance management data related to past performance management applicable to the cell site, or previously collected user equipment profile data representing past user equipment profiles. Environmental data may include at least one of the following: cell site information, base station system configuration data, base station antenna configuration data, user equipment antenna configuration data, transmit beamform information, receive beamform information, or digital twin data. Measurement data may include periodic beam measurement data, and performance management data may include at least one of the following: beam fault indication data, service mode data, or quality of service data.

[0050] User equipment profile data may include at least one of the following: user equipment location data, user equipment speed data, user equipment orientation data, or adjacent user equipment profile data.

[0051] The probe codebook strategy data may include at least one of the following: beam count data, narrow beam data, wide beam data, fixed beam data, random beam data, preset beam data, or beam design data.

[0052] Reporting strategy data may include at least one of the following: report type data, report cycle data, beam dwell time data, or prediction interval data.

[0053] It is determined that the probe codebook policy data can be executed by the first layer of the distributed cross-layer beam management engine, and further operations may include transferring the probe codebook policy data from the first layer of the distributed cross-layer beam management engine to the second layer of the distributed cross-layer beam management engine.

[0054] The first layer of the distributed cross-layer beam management engine can be incorporated into the non-real-time radio access network controller, and the second layer of the distributed cross-layer beam management engine can be incorporated into the near real-time radio access network controller.

[0055] The estimation of candidate sparse probe beam scanning measurement subgroups can be performed by the second layer of the distributed cross-layer beam management engine, and further operations may include transferring candidate sparse probe beam scanning measurement subgroups from the second layer of the distributed cross-layer beam management engine to the third layer.

[0056] The execution of synchronization signal block beam scanning and channel state information-reference signal beam scanning can be performed by the third layer of the distributed cross-layer beam management engine.

[0057] The third layer of the distributed cross-layer beam management engine can be incorporated into the distributed unit.

[0058] exist Figure 8 The text illustrates one or more example aspects, such as example operations corresponding to methods. Example operation 802 represents obtaining cell site probe codebook policy data via a first model of a system including a processor, based on a first dataset including environmental data, measurement data, performance management data, and user equipment profile data as input to the model. Example operation 804 represents determining candidate sparse probe beam scan measurement subgroups by the system based on the probe codebook policy data and user equipment measurement data. Example operation 806 represents performing a synchronization block beam scan by the system based on the sparse candidate probe beam scan measurement subgroups to obtain returned reference received power signal data corresponding to the synchronization block beam scan from the user equipment. Example operation 808 represents determining at least a threshold high-performance beam subgroup from candidate probe beam scan measurements via a second model of the system, based on the returned reference received power signal data corresponding to the synchronization block beam scan. Example operation 810 represents the system performing a channel state information-reference signal beam scan based on at least a threshold high-performance beam scan measurement subgroup to determine a communication beam from a candidate probe beam scan measurement subgroup based on identifier information returned from the user equipment, the communication beam satisfying at least a defined threshold performance criterion. Example operation 812 represents the system communicating with the user equipment via the communication beam.

[0059] Further operations may include obtaining reporting strategy data for cell sites via the system's first model.

[0060] The first model can be incorporated into the non-real-time radio access network intelligent controller, and obtaining probe codebook policy data can include obtaining a first dataset at the non-real-time radio access network intelligent controller and inputting the first dataset into the first model.

[0061] The first model can be coupled to a near real-time wireless access network intelligent controller; the determination of candidate sparse probe beam scanning measurement subgroups can be performed by an application of the near real-time wireless access network intelligent controller, and the near real-time wireless access network intelligent controller can be coupled to a distributed unit including the second model; further operations may include transferring candidate sparse probe beam scanning measurement subgroups from the near real-time wireless access network intelligent controller to the distributed unit.

[0062] At least the threshold high-performance beam scanning measurement can be the highest performance beam scanning measurement, and determining the communication beam can include determining the optimal communication beam that can be used to achieve optimal performance from a candidate probe beam scanning measurement subgroup.

[0063] Figure 9 and 10 It summarizes various example operations, such as those corresponding to machine-readable media containing executable instructions that facilitate the execution of operations when executed by a processor. Figure 9 Example operation 902 represents distributing the beam management engine across a first layer including a non-real-time WLAN intelligent controller, a second layer including a near real-time WLAN intelligent controller, and a third layer including distributed units. Example operation 904 represents using a first model from the first layer to determine probe codebook policy data. Example operation 906 represents transmitting probe codebook policy data from the first layer to the second layer. Example operation 908 represents the second layer determining a sparse probe beam scanning measurement subgroup of potential probe beams based on the probe codebook policy data. Example operation 910 represents transmitting the sparse probe beam scanning measurement subgroup from the second layer to the third layer. Operations continue to... Figure 10 Example operation 1002 represents performing a synchronization signal block beam scan by a third-layer measurement subgroup based on sparse candidate probe beam scan measurements. Example operation 1004 represents determining the highest-performance beam subgroup from candidate probe beam scan measurements using a second model of the third layer, based on the returned reference received power signal data corresponding to the synchronization signal block beam scan. Example operation 1006 represents performing a channel state information-reference signal beam scan using the highest-performance beam scan measurement subgroup. Example operation 1008 represents determining the optimal communication beam for the user equipment from the highest-performance beam scan measurement subgroup based on identifier information returned from the user equipment.

[0064] Further operations may include using the first model of the first layer to determine the reporting strategy data, and transferring the reporting strategy data from the first layer to the second and third layers.

[0065] As can be seen, the techniques described in this paper improve reliability and throughput in communication networks while reducing latency and signaling overhead. A distributed cross-layer beam management engine based on the O-RAN architecture facilitates the distribution of beam management P1, P2, and P3 processes across the RAN control framework. In O-RAN, this can be achieved via beam management policy control (rApp), set selection (xApp), and P2 / P3 beam management (dApp) distributed across the network. Enriched information (e.g., UE location and velocity), spatial / temporal dependencies, and cross-UE correlations can be incorporated into the beam measurement and beam selection processes, thereby improving overall performance.

[0066] Figure 11 This is a schematic block diagram of a computing environment 1100 with which the disclosed subject can interact. System 1100 includes one or more remote components 1110. The remote components 1110 may be hardware and / or software (e.g., threads, processes, computing devices). In some embodiments, the remote components 1110 may be a distributed computer system connected via a communication framework 1140 to local auto-scaling components and / or programs using the resources of the distributed computer system. The communication framework 1140 may include wired network devices, wireless network devices, mobile devices, wearable devices, wireless access network devices, gateway devices, microcellular devices, servers, etc.

[0067] System 1100 also includes one or more local components 1120. The local components 1120 may be hardware and / or software (e.g., threads, processes, computing devices). In some embodiments, the local components 1120 may include auto-expansion components and / or programs that deliver / use remote resources 1110, which are connected to the remote distributed computing system via communication framework 1140.

[0068] One possible communication between (multiple) remote components 1110 and (multiple) local components 1120 may be in the form of data packets suitable for transmission between two or more computer processes. Another possible communication between (multiple) remote components 1110 and (multiple) local components 1120 may be in the form of circuit-switched data suitable for transmission between two or more computer processes in a radio time slot. System 1100 includes a communication framework 1140, which can be used to facilitate communication between (multiple) remote components 1110 and (multiple) local components 1120, and may include an air interface, such as a Uu interface of a UMTS network via a Long Term Evolution (LTE) network. (Multiple) remote components 1110 may be operatively connected to one or more remote data repositories 1150 (such as hard disk drives, solid-state drives, SIM cards, device memory, etc.), which can be used to store information on the (multiple) remote component 1110 side of the communication framework 1140. Similarly, the local components 1120 can be operatively connected to one or more local data repositories 1130, which can be used to store information on the local component 1120 side of the communication framework 1140.

[0069] To provide additional context for the various embodiments described herein, Figure 12The following discussion is intended to provide a brief, general description of a suitable computing environment 1200 that can implement the various embodiments described herein. While the embodiments have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that these embodiments can also be implemented in combination with other program modules and / or as a combination of hardware and software.

[0070] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will appreciate that this method can be practiced using other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframes, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, each of which can be operatively coupled to one or more associated devices.

[0071] The embodiments described herein can also be practiced in a distributed computing environment, where certain tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote memory storage devices.

[0072] Computing devices typically include a variety of media, which may include computer-readable storage media, machine-readable storage media, and / or communication media, these two terms being used herein as distinct from each other as follows. A computer-readable storage medium or a machine-readable storage medium can be any available storage medium accessible to a computer, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, a computer-readable storage medium or a machine-readable storage medium can be implemented using any method or technology for storing information, such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0073] Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital universal disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transient media that can be used to store desired information. In this regard, the terms “tangible” or “non-transient” used herein to describe storage devices, memories, or computer-readable media should be understood to exclude the use of transient signals that are merely propagating themselves as modifiers, and without waiving the rights to all standard storage devices, memories, or computer-readable media that are not merely propagating transient signals themselves.

[0074] Computer-readable storage media can be accessed by one or more local or remote computing devices (e.g., via access requests, queries, or other data retrieval protocols) for various operations on the information stored in the media.

[0075] Communication media typically embody computer-readable instructions, data structures, program modules, or other structured or unstructured data in data signals such as modulated data signals (e.g., carrier waves or other transmission mechanisms), and include any information delivery or transmission medium. The term "modulated data signal" or signal refers to a signal in which one or more characteristics are set or altered to encode information in one or more signals. By way of example and not limitation, communication media include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0076] Refer again Figure 12 An example environment 1200 for implementing various embodiments of the aspects described herein includes a computer 1202, which includes a processing unit 1204, system memory 1206, and a system bus 1208. The system bus 1208 couples system components, including but not limited to system memory 1206, to the processing unit 1204. The processing unit 1204 can be any of a variety of commercially available processors. Dual microprocessors and other multiprocessor architectures can also be used as the processing unit 1204.

[0077] System bus 1208 can be any of several types of bus architectures, which can use any of a variety of commercially available bus architectures to further interconnect to memory buses (with or without memory controllers), peripheral buses, and local buses. System memory 1206 includes ROM 1210 and RAM 1212. The basic input / output system (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, where the BIOS contains basic routines that facilitate the transfer of information between components within computer 1202 (such as during startup). RAM 1212 may also include high-speed RAM, such as static RAM for caching data.

[0078] Computer 1202 also includes an internal hard disk drive (HDD) 1214 (e.g., EIDE, SATA) and may include one or more external storage devices 1216 (e.g., floppy disk drive (FDD) 1216, memory stick or flash drive reader, memory card reader, etc.). Although the internal HDD 1214 is illustrated as being located within computer 1202, the internal HDD 1214 may also be configured for external use in a suitable rack (not shown). Additionally, although not shown in environment 1200, solid-state drives (SSDs) may be used in addition to or in place of HDD 1214.

[0079] Other internal or external storage devices may include at least one other storage device 1220 having storage medium 1222 (e.g., solid-state storage device, non-volatile memory device, and / or optical disc drive that can be read from or written to removable media such as CD-ROM, DVD, BD, etc.). External storage device 1216 may be facilitated by a network virtual machine. HDD 1214, (multiple) external storage devices 1216 and storage devices (e.g., drives) 1220 may be connected to system bus 1208 via HDD interface 1224, external storage interface 1226 and drive interface 1228, respectively.

[0080] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, etc. For computer 1202, the drive and storage medium accommodate storage of any data in a suitable digital format. Although the above description of computer-readable storage media refers to a corresponding type of storage device, those skilled in the art should understand that other types of computer-readable storage media (whether currently existing or developed in the future) can also be used in the example operating environment, and further, any such storage medium can contain computer-executable instructions for performing the methods described herein.

[0081] Multiple program modules can be stored in the drive and RAM 1212, including the operating system 1230, one or more application programs 1232, other program modules 1234, and program data 1236. All or part of the operating system, applications, modules, and / or data can also be cached in RAM 1212. The systems and methods described herein can be implemented using various commercially available operating systems or combinations of operating systems.

[0082] Computer 1202 may optionally include emulation technology. For example, a hypervisor (not shown) or other middleware may emulate the hardware environment of operating system 1230, and the emulated hardware may optionally be compatible with... Figure 12 The hardware illustrated differs. In this embodiment, the operating system 1230 may include one of a plurality of virtual machines (VMs) hosted on the computer 1202. Furthermore, the operating system 1230 may provide a runtime environment for the application 1232, such as the Java Runtime Environment or the .NET Framework. A runtime environment is a consistent execution environment that allows the application 1232 to run on any operating system that includes a runtime environment. Similarly, the operating system 1230 may support containers, and the application 1232 may be in the form of a container, which is a lightweight, standalone, executable software package that includes, for example, code, runtime, system tools, system libraries, and application settings.

[0083] Furthermore, computer 1202 can be equipped with security modules, such as a Trusted Processing Module (TPM). For example, using a TPM, before loading the next boot component, the boot component hashes the next boot component in time and waits for the result to match a security value. This process can occur at any layer of the computer 1202's code execution stack (e.g., at the application execution level or at the operating system (OS) kernel level), thus achieving security at any code execution level.

[0084] Users can type commands and information into computer 1202 using one or more wired / wireless input devices (e.g., keyboard 1238, touchscreen 1240, and pointing devices such as mouse 1242). Other input devices (not shown) may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls or other remote controls, joysticks, virtual reality controllers and / or virtual reality headsets, gamepads, styluses, image input devices (e.g., cameras), gesture sensor input devices, visual motion sensor input devices, emotion or face detection devices, biometric input devices (e.g., fingerprint or iris scanners), etc. These and other input devices are typically connected to processing unit 1204 via input device interface 1244 (which may be coupled to system bus 1208), but may also be connected via other interfaces such as parallel ports, IEEE 1294 serial ports, game ports, USB ports, IR interfaces, Bluetooth® interfaces, etc.

[0085] Monitor 1246 or other types of display devices can also be connected to system bus 1208 via an interface such as video adapter 1248. In addition to monitor 1246, the computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0086] Computer 1202 can operate in a networked environment using logical connections to one or more remote computers (such as (multiple) remote computers 1250) via wired and / or wireless communications. The (multiple) remote computers 1250 can be workstations, server computers, routers, personal computers, laptops, microprocessor-based entertainment devices, peer-to-peer devices, or other public network nodes, and typically include many or all of the elements described relative to computer 1202, although for simplicity, only memory / storage device 1252 is illustrated. The depicted logical connections include wired / wireless connections to a local area network (LAN) 1254 and / or a larger network (e.g., a wide area network (WAN) 1256). Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks (such as intranets), all of which can connect to global communication networks, such as the Internet.

[0087] When used in a LAN networking environment, computer 1202 can be connected to local network 1254 via a wired and / or wireless communication network interface or adapter 1258. Adapter 1258 can facilitate wired or wireless communication with LAN 1254, which may also include a wireless access point (AP) configured thereon for wireless communication with adapter 1258.

[0088] When used in a WAN networking environment, computer 1202 may include modem 1260 or may be connected to a communication server on WAN 1256 via other means (such as via the Internet) for establishing communication on WAN 1256. Modem 1260, which may be internal or external and wired or wireless, may be connected to system bus 1208 via input device interface 1244. In a networking environment, program modules depicted relative to computer 1202 or portions thereof may be stored in remote memory / storage device 1252. It should be understood that the network connection shown is an example, and other means of establishing communication links between computers may be used.

[0089] When used in a LAN or WAN networking environment, computer 1202 can access cloud storage systems or other network-based storage systems, in addition to or replacing the external storage device 1216 described above. Typically, the connection between computer 1202 and the cloud storage system can be established on LAN 1254 or WAN 1256 via, for example, adapter 1258 or modem 1260. When computer 1202 is connected to an associated cloud storage system, external storage interface 1226 can manage the storage devices provided by the cloud storage system with the assistance of adapter 1258 and / or modem 1260, just like other types of external storage devices. For example, external storage interface 1226 can be configured to provide access to cloud storage sources as if these sources were physically connected to computer 1202.

[0090] Computer 1202 is operable to communicate with any wireless device or entity operably configured for wireless communication, such as printers, scanners, desktop and / or portable computers, portable data assistants, communication satellites, any device or location associated with a wirelessly detectable tag (e.g., kiosks, newsstands, store shelves, etc.), and telephones. This can include Wi-Fi and Bluetooth® wireless technologies. Therefore, communication can be a predefined structure like a conventional network or simply ad hoc communication between at least two devices.

[0091] The above description of the embodiments illustrated in this disclosure (including those described in the abstract) is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. Although specific embodiments and examples have been described herein for illustrative purposes, various modifications are possible within the scope of such embodiments and examples, as will be appreciated by those skilled in the art.

[0092] In this regard, although the disclosed subject matter has been described in conjunction with various embodiments and corresponding drawings, it is to be understood that other similar embodiments may be used where applicable, or modifications and additions may be made to the described embodiments to perform the same, similar, alternative, or alternative functions of the disclosed subject matter without departing from the scope of the disclosed subject matter. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but should be interpreted in breadth and scope according to the appended claims.

[0093] As used herein, the term "processor" can refer to virtually any computing processing unit or device, including but not limited to: a single-core processor; a single processor with software multithreading capabilities; a multi-core processor; a multi-core processor with software multithreading capabilities; a multi-core processor with hardware multithreading technology; a parallel platform; and a parallel platform with distributed shared memory. Additionally, a processor can refer to an integrated circuit, application-specific integrated circuit, digital signal processor, field-programmable gate array, programmable logic controller, complex programmable logic device, discrete gate or transistor logic, discrete hardware component, or any combination thereof, designed to perform the functions described herein. Processors can utilize nanoscale architectures (such as, but not limited to, molecular and quantum dot-based transistors, switches, and gates) to optimize space utilization or enhance the performance of user devices. Processors can also be implemented as a combination of computing processing units.

[0094] As used herein, the terms “component,” “system,” “platform,” “layer,” “selector,” “interface,” etc., are intended to refer to a computer-related entity or an entity associated with an operating device having one or more specific functions, wherein the entity may be hardware, a combination of hardware and software, software, or software in execution. As an example, a component may be (but is not limited to) a process running on a processor, a processor, an object, an executable file, an execution thread, a program, and / or a computer. By way of illustration and not limitation, applications running on a server and servers themselves can be components. One or more components may reside within a process and / or an execution thread, and components may be located on a single computer and / or distributed across two or more computers. Furthermore, these components may execute via various computer-readable media on which various data structures are stored. These components may communicate via local and / or remote processes, such as based on signals having one or more data packets (e.g., data from a component that interacts with another component in a distributed system, and / or with other systems across a network such as the Internet). As another example, a component can be a device having specific functions provided by mechanical parts operated by an electrical or electronic circuit system, operated by a software or firmware application executed by a processor, wherein the processor may be internal or external to the device and execute at least a portion of the software or firmware application. As another example, a component can be a device providing specific functions through an electronic component without mechanical parts, which may include a processor to execute software or firmware that at least partially endows the electronic component with functionality.

[0095] Furthermore, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or obvious from the context, "X takes A or B" is intended to mean any permutation of natural inclusive arrangements. That is, if X takes A; X takes B; or X takes both A and B, then any of the foregoing conditions satisfies "X takes A or B".

[0096] While the embodiments are readily adaptable to various modifications and alternative constructions, some illustrative implementations are shown in the accompanying drawings and have already been described in detail above. However, it should be understood that this document is not intended to limit the various embodiments to the specific forms disclosed; rather, it is intended to cover all modifications, alternative constructions, and equivalents falling within its spirit and scope.

[0097] In addition to the various implementations described herein, it should be understood that other similar implementations may also be used, or modifications and additions may be made to the described implementation(s) to perform the same or equivalent functions of the corresponding implementation(s) without departing from their scope. Furthermore, multiple processing chips or multiple devices may share the execution of one or more functions described herein, and similarly, storage may be implemented across multiple devices. Therefore, the various embodiments are not limited to any single implementation, but should be interpreted in terms of breadth, spirit, and scope in accordance with the appended claims.

Claims

1. A network device, comprising: a processor; and a memory storing executable instructions that, when executed by the processor, facilitate the execution of operations, the operations including: determining probe codebook policy data representing a probe codebook policy for a cell site; determining reporting policy data representing a reporting policy for the cell site; estimating a candidate sparse probe beam sweep measurement subgroup having a first cardinality, the first cardinality being less than a second cardinality of a potential probe beam sweep measurement group, based on the probe codebook policy data and user equipment measurement data representing measurements of a user equipment; performing a synchronization signal block beam sweep based on the sparse candidate probe beam sweep measurement subgroup to determine at least a threshold high-performance beam subgroup from the candidate probe beam sweep measurement subgroup based on reference received power signal data returned according to the reporting policy data, wherein at least the threshold high-performance beam sweep measurement subgroup has a third cardinality less than the second cardinality; and performing a channel state information-reference signal beam sweep based on at least the threshold high-performance beam sweep measurement subgroup to determine a communication beam from the candidate probe beam sweep measurement subgroup based on identifier information returned from a user equipment, the communication beam being usable to achieve at least threshold high performance.

2. The network device of claim 1, wherein at least the threshold high-performance beam scanning measurement is the highest performance beam scanning measurement, wherein the determination of the communication beam includes: Determining an optimal communication beam from the candidate probe beam sweep measurement subgroup that is usable to achieve optimal performance, and wherein the operations further include communicating with the user equipment via the optimal communication beam.

3. The network device according to claim 1, wherein the determination of the probe codebook policy data for the cell site and the determination of the reporting policy data include inputting at least one of the following to a model: environment data representing characteristics of an environment associated with the cell site, measurement data representing measurements applicable to the cell site, performance management data related to the management of performance applicable to the cell site, or user equipment profile data representing a user equipment profile, and wherein the model is trained using at least one of the following: previously collected environment data representing past characteristics of the environment associated with the cell site, previously collected measurement data representing past measurements associated with the cell site, previously collected performance management data related to the past management of performance applicable to the cell site, or previously collected user equipment profile data representing past user equipment profiles.

4. The network device according to claim 3, wherein the environment data includes at least one of the following: cell site information, base station system configuration data, base station antenna configuration data, user equipment antenna configuration data, transmission beam shape information, reception beam shape information, or digital twin data.

5. The network device according to claim 3, wherein the measurement data includes periodic beam measurement data, and wherein the performance management data includes at least one of the following: beam failure indication data, traffic mode data, or quality of service data.

6. The network device according to claim 3, wherein the user equipment configuration file data includes at least one of the following: user equipment location data, user equipment speed data, user equipment orientation data, or adjacent user equipment configuration file data.

7. The network device according to claim 3, wherein the probe codebook strategy data includes at least one of the following: beam count data, narrow beam data, wide beam data, fixed beam data, random beam data, preset beam data, or beam design data.

8. The network device according to claim 3, wherein the reporting policy data includes at least one of the following: report type data, report cycle data, beam dwell time data, or prediction interval data.

9. The network device of claim 1, wherein the determination of the probe codebook policy data is performed by a first layer of a distributed cross-layer beam management engine, and wherein the operation further includes transmitting the probe codebook policy data from the first layer of the distributed cross-layer beam management engine to a second layer of the distributed cross-layer beam management engine.

10. The network device of claim 9, wherein the first layer of the distributed cross-layer beam management engine is incorporated into a non-real-time radio access network controller, and wherein the second layer of the distributed cross-layer beam management engine is incorporated into a near real-time radio access network controller.

11. The network device of claim 9, wherein the estimation of the candidate sparse probe beam scanning measurement subgroup is performed by a second layer of the distributed cross-layer beam management engine, and wherein the operation further includes transferring the candidate sparse probe beam scanning measurement subgroup from the second layer of the distributed cross-layer beam management engine to a third layer of the distributed cross-layer beam management engine.

12. The network device of claim 11, wherein the execution of the synchronization signal block beam scan and the execution of the channel state information-reference signal beam scan are executed by the third layer of the distributed cross-layer beam management engine.

13. The network device of claim 11, wherein the third layer of the distributed cross-layer beam management engine is incorporated into a distributed unit.

14. A method comprising: By means of a first model of a system including a processor, and based on a first dataset including environmental data, measurement data, performance management data, and user equipment configuration data input to the model, probe codebook strategy data for cell sites is obtained; The system determines candidate sparse probe beam scanning measurement subgroups based on the probe codebook strategy data and user equipment measurement data; Based on the sparse candidate probe beam scanning measurement subgroup, the system performs a synchronization signal block beam scan to obtain the returned reference received power signal data corresponding to the synchronization signal block beam scan from the user equipment. A minimum threshold high-performance beam subgroup is determined from the candidate probe beam scan measurement based on the returned reference received power signal data corresponding to the synchronization signal block beam scan via the second model of the system. The system performs channel state information-reference signal beam scanning based on at least the threshold high-performance beam scanning measurement subgroup to determine a communication beam from the candidate probe beam scanning measurement subgroup based on identifier information returned from the user equipment, the communication beam satisfying at least a defined threshold performance criterion; as well as The system communicates with the user equipment via the communication beam.

15. The method of claim 14, further comprising obtaining reporting policy data for the cell site via the first model of the system.

16. The method of claim 14, wherein the first model is incorporated into a non-real-time wireless access network intelligent controller, and wherein obtaining the probe codebook policy data comprises: The first dataset is obtained at the non-real-time wireless access network intelligent controller and input into the first model.

17. The method of claim 16, wherein the first model is coupled to a near real-time radio access network intelligent controller, wherein the determination of the candidate sparse probe beam scanning measurement subgroup is performed by an application of the near real-time radio access network intelligent controller, and wherein the near real-time radio access network intelligent controller is coupled to a distributed unit including the second model, and the method further comprises: The candidate sparse probe beam scanning measurement subgroup is transmitted from the near real-time wireless access network intelligent controller to the distributed unit.

18. The method of claim 17, wherein at least the threshold high-performance beam scanning measurement is the highest performance beam scanning measurement, and wherein the determination of the communication beam includes determining the optimal communication beam available for achieving optimal performance from the candidate probe beam scanning measurement subgroup.

19. A non-transient machine-readable medium, the non-transient machine-readable medium comprising executable instructions that, when executed by a processor, facilitate the execution of operations, the operations including: The beam management engine is distributed across a first layer including a non-real-time wireless access network intelligent controller, a second layer including a near real-time wireless access network intelligent controller, and a third layer including distributed units. The first model of the first layer is used to determine the probe codebook strategy data; Transmit the probe codebook strategy data from the first layer to the second layer; The second layer determines the sparse probe beam scanning measurement subgroup of potential probe beams based on the probe codebook strategy data; The sparse probe beam scanning measurement subgroup is transferred from the second layer to the third layer; The synchronization signal block beam scan is performed by the third layer based on the sparse candidate probe beam scan measurement subgroup; Based on the returned reference received power signal data corresponding to the synchronization signal block beam scan, the second model of the third layer is used to determine the highest performance beam subgroup from the candidate probe beam scan measurements; The highest-performance beam scanning measurement subgroup is used to perform channel state information-reference signal beam scanning; as well as Based on the identifier information returned from the user equipment, the optimal communication beam for the user equipment is determined from the highest performance beam scanning measurement subgroup.

20. The non-transitory machine-readable medium according to claim 19, wherein the operation further comprises: The first model of the first layer is used to determine the reporting strategy data, and the reporting strategy data is transmitted from the first layer to the second layer and the third layer.

Images