Cloud native testboard generation and construction

Abstract

A method performed by a computing device for initiating construction of a cloud native radio access network (RAN) testboard is provided. The method comprises receiving (100) attributes of the requested cloud native RAN of the test bench; and generating (102) the requested configuration of the test bench based on the attribute. The configuration includes an identifier identifying at least one or more of the attributes of the cloud native RAN and at least one or more hardware components of the requested test bench. The method further comprises generating (104) an identification of a hardware component satisfying the configuration according to a machine learning, ML, model based on the configuration; and initiating (114) an automated build of the requested test bench in accordance with the identification.

Description

Technical Field

[0001] Generally speaking, the present disclosure relates to methods performed by a computing device for initiating construction of a cloud-native radio access network (RAN) test bed and related methods and devices. Background Art

[0002] In order to test cloud RAN applications, such as virtual distributed units (vDUs) and / or virtual centralized units (vCUs), a test environment (also referred to herein as a "test bed" and / or also referred to as a "test channel") may be required. A test bed may typically include several cloud native infrastructures, such as different hardware and software. Each test bed may have different capacities that can be used to test different features and therefore have different costs. As the number of cloud applications increases, more test beds may be required to test cloud application features before releasing the cloud applications to the market.

[0003] For example, during product development, full stack virtualization can be built by fifth generation (5G) new radio (NR) vCU and vDU based on commercial off-the-shelf (COTS) hardware using cloud native technologies; and the product development team can work with customers to deliver virtualized RAN. For example, during product development, vDU for low band (LB) (e.g., below 6GHz) can be developed. In order to accelerate product development, it may be necessary to leverage cloud native infrastructure and technologies. In addition, cloud products may need to be tested at several test levels, such as unit, integration, and system acceptance testing.

[0004] In order to test different parts of products and applications, it may be necessary to develop and test macro functions of the system. Features can be gradually specified using different cloud native test infrastructures during the testing process. As mentioned earlier, since the test bench can have different capacities, the test bench can also have different costs. Costs may include, but are not limited to: the construction cost of the test bench including assembling hardware components and software installation; maintenance costs; manpower (e.g., use of manpower) costs; footprint costs; licensing costs, etc. Various costs may be included in the total cost of the cloud native test bench. The total cost of the cloud native test bench can be expensive, especially for example for those test benches that have high capacity and are designed to test various features. An example of the total cost can be estimated to be between 0.2 million Swedish kronor and 7 million Swedish kronor, with a large part of the total cost being related to hardware components.

[0005] The challenges of building a new test bed may include matching capacity with actual requests and needs. Building a new test bed can be a time-consuming and resource-consuming process, in which several subject matter experts from different teams (e.g., design team, laboratory team, etc.) are involved. Building a test bed that can be used to test a wide range of functions (e.g., different radio frequencies, simulators, 4G, 5G, etc.) may be desirable. However, some methods may introduce problems, for example, including using manual prediction methods based on the needs of existing test beds or projects. Using manual prediction methods based on demand to build a new test bed can lead to overestimation or underestimation of the capabilities of the test bed. See, for example, Chinese Patent No. CN112598309A, Chinese Patent No. CN109388484A. Summary of the invention

[0006] Certain challenges currently exist. Automated generation of the configuration of a requested cloud-native RAN test bed and identification of hardware components that satisfy the configuration may be lacking. However, automated generation may be important for at least the following reasons: acceptable accuracy of construction of the requested test bed; generation of compatible configurations for testing cloud-based applications; scalability to handle multiple requests; generation of test bed configurations on demand; and / or construction of the requested test bed on demand.

[0007] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these or other challenges.

[0008] In some embodiments, a method for initiating the construction of a cloud native RAN test bed performed by a computing device is provided. The method includes: receiving (100) multiple attributes of the cloud native RAN of the requested test bed; and generating (102) a configuration of the requested test bed based on the multiple attributes. The configuration includes an identifier of at least one or more of the multiple attributes of the cloud native RAN and at least one or more hardware components of the requested test bed. The method also includes: generating (104) an identifier of a hardware component that satisfies the configuration according to a machine learning (ML) model based on the configuration; and initiating (114) an automated construction of the requested test bed according to the identifier.

[0009] In some embodiments, a computing device configured to initiate the construction of a cloud native RAN test bed is provided. The computing device includes a processing circuit and a memory coupled to the processing circuit. The memory includes instructions that, when executed by the processing circuit, cause the computing device to perform operations. The operations include: receiving multiple attributes of the cloud native RAN of the requested test bed; and generating a configuration of the requested test bed based on the multiple attributes. The configuration includes an identifier that identifies at least one or more of the multiple attributes of the cloud native RAN and at least one or more hardware components of the requested test bed. The operations also include: generating identifiers of multiple hardware components that satisfy the configuration according to an ML model based on the configuration; and initiating an automated construction of the requested test bed based on the identifier.

[0010] In some embodiments, a computing device configured to start the construction of a cloud native RAN test bed is provided. The computing device is suitable for performing operations. The operations include receiving multiple attributes of the cloud native RAN of the requested test bed; and generating a configuration of the requested test bed based on the multiple attributes. The configuration includes an identifier of at least one or more of the multiple attributes of the cloud native RAN and at least one or more hardware components of the requested test bed. The operation also includes: generating identifications of multiple hardware components that meet the configuration according to an ML model based on the configuration; and starting the automated construction of the requested test bed according to the identification.

[0011] In some embodiments, a computer program is provided, the computer program including program code to be executed by a processing circuit of a computing device, the computing device being configured to initiate the construction of a cloud native RAN test bed. The execution of the program code causes the computing device to perform operations. The operations include receiving multiple attributes of the cloud native RAN of the requested test bed; and generating a configuration of the requested test bed based on the multiple attributes. The configuration includes an identifier that identifies at least one or more of the multiple attributes of the cloud native RAN and at least one or more hardware components of the requested test bed. The operations also include: generating identifications of multiple hardware components that satisfy the configuration according to an ML model based on the configuration; and initiating an automated construction of the requested test bed according to the identification.

[0012] In some embodiments, a computer program product is provided that includes a non-transitory storage medium that includes a program code to be executed by a processing circuit of a computing device. Execution of the program code causes the computing device to perform operations. The operations include receiving multiple attributes of a cloud-native RAN of a requested test bed; and generating a configuration of the requested test bed based on the multiple attributes. The configuration includes an identifier that identifies at least one or more of the multiple attributes of the cloud-native RAN and at least one or more hardware components of the requested test bed. The operations also include: generating identifications of multiple hardware components that satisfy the configuration according to an ML model based on the configuration; and initiating an automated build of the requested test bed based on the identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of the inventive concepts. In the attached picture:

[0014] Figure 1 is a flow chart illustrating a method performed by a computing device according to some embodiments;

[0015] Figure 2 yes Figure 1 A block diagram of an example embodiment of the operation of a flowchart;

[0016] Figure 3 is a block diagram of rule-based operations of an example embodiment of a generation configuration;

[0017] Figure 4 is a block diagram of an example embodiment of generating an identification of hardware components that satisfy a configuration;

[0018] Figure 5 is a schematic diagram illustrating an example embodiment of generating a hardware component identification;

[0019] Figure 6 is a schematic diagram illustrating a graphical user interface according to some embodiments of the present disclosure;

[0020] Figure 7 is a flowchart of the operation of a computing device according to some embodiments of the present disclosure;

[0021] Figure 8 is a flowchart of the operation of a computing device according to some embodiments of the present disclosure;

[0022] Fig. 9 is a schematic diagram illustrating a graphical user interface according to some embodiments of the present disclosure;

[0023] Fig.10is a block diagram showing an overview of a cloud-implemented distributed computing device according to some embodiments of the present disclosure;

[0024] Fig.11 Three specific examples of computing devices that can be used to implement certain embodiments of the present disclosure are shown; and

[0025] Fig.12 Another implementation example of a specific embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0026] The inventive concept will now be described more fully below with reference to the accompanying drawings, in which examples of embodiments of the inventive concept are shown. However, the inventive concept can be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided so that this disclosure will be thorough and complete, and the scope of the inventive concept will be fully conveyed to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be defaulted to being present / used in another embodiment.

[0027] The following description presents various embodiments of the disclosed subject matter. These embodiments are presented as teaching examples and should not be interpreted as limiting the scope of the disclosed subject matter. For example, some details of the embodiments may be modified, omitted or expanded without departing from the scope of the subject matter.

[0028] The term “build” is used herein in a non-limiting manner and may refer to any type of activation (e.g., via a switch), connection between (e.g., via a wired or wireless communication link), or deployment of hardware components of a cloud-native RAN test bed.

[0029] To build a new test bed, several criteria may need to be considered, including, for example, a specific timeline for readiness and accurate capacity. Manual forecasting of the number of test beds required and their capacity can directly impact the use and timing of test resources. Furthermore, manual processes can suffer from errors, ambiguity, and uncertainty in human judgment. For example, using manual forecasts for building a test bed may result in the maximum capacity of the test bed not being used.

[0030] Some approaches lack automated generation of test beds and / or automated construction of test beds and may have one or more of the following challenges: manual data collection lacking the ability to automate the generation of inputs to ML models (e.g., deep reinforcement learning (RL) models); unsupervised learning approaches due to lack of labeled data; scalability challenges and sensitivity to changes in new requests; lack of automated generation of configurations of requested test beds; lack of automated construction of requested test beds; lack of provision and / or consideration of different scenarios of actions; and / or lack of acceptable accuracy for practical industrial applications.

[0031] Certain aspects of the present disclosure and its embodiments may provide solutions to these or other challenges. In some embodiments, a computer-implemented method is performed by a computing device to build a cloud-native RAN test bed. Cloud-native RAN refers to implementing RAN functions on a computing platform and using cloud computing to manage RAN application virtualization, for example, running (one or more) RAN network functions through a COTS hardware platform. The operation of some embodiments may include using an ML-based expert system (i.e., an ML model) to build a cloud-native RAN test bed based on input from an end user (e.g., a tester), wherein the capacity of the built test bed is based on actual requests and usage. In addition, the operation of some embodiments includes identifying dependencies between cloud RAN infrastructures, and providing options for maintaining, reusing, modifying, or disassembling a test bed that is built after the testing process is completed.

[0032] In some embodiments of operation, the ML model automatically captures input (e.g., input from an end user) and provides a list or other identification of cloud-native hardware components for building new test beds (one or more). The new test beds (one or more) can be built dynamically, and thus can facilitate the testing process and on-time delivery.

[0033] The ML model of some embodiments provides a set of high-level cloud RAN attributes (e.g., provided to an end user on a display) and can automatically generate a configuration for building a new cloud native test bed (e.g., the exact capabilities required). The ML model of some embodiments can also provide a dynamic inventory based on the generated configuration, and can dynamically select hardware components for the generated configuration. In addition, in some operations, the ML model can continuously consider the cost, compatibility, and / or availability of each cloud native hardware component used to build a new test bed. In addition, in some embodiments of the operation, the ML-based model can predict the availability of already allocated cloud native hardware components, while the ML model is considering the start date and lifespan (in other words, duration) of (one or more) cloud native test beds. In addition, the operation of some embodiments includes automated decisions by the ML model regarding maintaining, modifying, or disassembling a test bed.

[0034] For ease of discussion, the example embodiments of this document are explained in the non-limiting context of initiating an automated build of a requested cloud-native RAN test bed. However, the present disclosure is not limited thereto, and in some embodiments, the generated identification of hardware components that satisfy the configuration of the requested test bed is provided without initiating an automated build of the requested test bed. For example, in some embodiments, the build may not be automated (or may not be fully automated), such as when a control system for implementing the automated build is not available.

[0035] As used herein, the term "computing device" refers to a device capable of, configured to, arranged to, and / or operable to initiate the construction of a cloud-native RAN test bed according to an embodiment of the present disclosure. As further discussed herein, examples of computing devices include, but are not limited to, centralized devices, distributed devices with distributed logical and / or physical entities, independent devices located near a site, border devices, edge devices, cloud-based devices, and the like. For example, when a computing device includes a logical entity, a portion of the computing device may be cloud-based. For example, performing the operations of the method may be viewed as being on the same logical device, but with different physical devices, and the like.

[0036] Figure 1 is a diagram illustrating a method for performing a computation by a computing device (eg, using Fig.11 1 or 12 structure implementation computing device 1100, 1200) performed by the flowchart of the method. For ease of discussion, the following discussion Figure 1 An overview of some of the operations of the method is followed by a Figure 1 A more detailed discussion of the operation of . Figure 1 The operations in the flowchart of may be optional for some embodiments of the computing device and related methods. For example, the operations of blocks 106-112 may be optional.

[0037] refer to Figure 1 , a computer-implemented method for initiating the construction of a cloud native RAN test bed, performed by a computing device, is provided. The method includes receiving (100) a plurality of attributes of a cloud native RAN of a requested test bed. The method also includes generating (102) a configuration of the requested test bed based on the plurality of attributes. The configuration includes an identifier of at least one or more of the plurality of attributes of the cloud native RAN and at least one or more hardware components of the requested test bed. The method also includes generating (104) identifiers of a plurality of hardware components that satisfy the configuration according to an ML model based on the configuration. The method also includes initiating (114) an automated construction of the requested test bed based on the identifier.

[0038] The technical advantages provided by certain embodiments of the present disclosure may include: for example, compared to a method lacking automated generation of configurations, based on the method including automated generation of identifications of hardware components that satisfy the configuration, and / or initiating automated construction of the requested test bed based on the identification, accuracy can be increased based on the reduction of human errors; compatible configurations for testing cloud-based applications can be generated; and human knowledge required for building a cloud RAN domain for a new test bed may be reduced. Additional technical advantages may include: based on including different ML-based strategies (as further discussed herein), a large number of requests for building a cloud-native test bed can be implemented, so that the method can be scalable. In addition, technical advantages may include: based on identifications including dependencies between hardware components (for example, which may be missed in manual methods), the method can automatically select hardware components with dependencies taken into account. In addition, based on dynamic, on-demand generation of test bed configurations, on-demand construction of requested test beds, and / or dynamic inventory of hardware components (discussed further herein), the method can also reduce energy consumption of cloud-native infrastructure.

[0039] Figure 2 yes Figure 1 A block diagram of an example embodiment of operations 100, 102, 104, and 114 of a flowchart of FIG. A plurality of attributes of a requested test bed (e.g., advanced cloud native RAN attributes) may be provided to an end user for selection and captured as input by a computing device in operation 100. Figure 2 As shown in the example, the multiple attributes of receiving 100 may include, for example: radio spectrum (e.g., low band (LB), mid band (MB), high band (HB)); a type of RAN simulator (e.g., user equipment (UE) simulator, RAN simulator); a type of UE, a type of RAN support (e.g., fourth generation (4G), 5G), independent (SA) or non-independent (NSA) mode, a radio gateway (RGW), and a radio simulator. In an example embodiment, the multiple attributes include one or more of the following: (i) radio spectrum, (ii) model, brand or name of the simulator, (iii) UE type, (iv) cell type, (v) number of cells, (vi) type of RAN support, (vii) independent or non-independent mode, (viii) service type, and (ix) radio gateway. It should be understood that the attributes can be modified based on the new cloud-based application.

[0040] In operation 102, a configuration is generated using the attributes received 100. The computing device analyzes the information captured from operation 100 and automatically generates a configuration for building the requested test bed. In an example embodiment, generating (102) the configuration includes analyzing at least one or more of a plurality of attributes of the cloud-native RAN from the configuration and at least one or more hardware components of the requested test bed based on the use of a rule set, the rule set identifying (i) dependencies between at least two attributes from the configuration, and / or dependencies between at least one hardware component and at least one attribute from the configuration. The rules may include attributes that cannot be selected at the same time (e.g., because they are incompatible) and / or attributes that can be selected at the same time (e.g., because they are compatible or need to be together).

[0041] As previously described, the configuration generated 102 includes at least one or more attributes of the plurality of attributes identifying the cloud native RAN and an identifier of at least one or more hardware components of the requested test bed. Figure 2 As shown in the example of , the identifier of the configuration generated 102 includes a character sequence that identifies the configuration, for example, as shown in one of the following: HB.BB.BOTH.NSA.LCAP.SIM (i.e. HighBand.Baseband.Both.Non-Standalone.Low Capability.Simulator, where "BOTH" indicates the type / brand of simulator and UE) MB.RGW.NSA.LCAP.UE (Medium Band. Radio Gateway. Non-Standalone. Low Capability. User Equipment) LB.RGW.NSA.LCAP.SIM (Low Band. Radio Gateway. Non-Standalone. Low Capability. Simulator) LB.RGW.NSA.OAM (Low Band. Radio Gateway. Non-Standalone. Operation and Maintenance) ●LB.SFGW.NSA.OAM (Low Band. Software Front-end Gateway. Non-standalone. Operation and Maintenance)

[0042] The generated 102 configuration may be considered as an identifier representing the capabilities of the cloud-native RAN test bed.

[0043] Figure 3 is a block diagram of a rule-based operation of an example embodiment of generating 102 a configuration. As previously described, the rule-based operation 300 uses a set of rules that identify (i) dependencies between at least two attributes from the configuration, and / or dependencies between at least one hardware component and at least one attribute from the configuration. Thus, the operation assumes that there are some dependencies between the attributes, and thus some dependencies between the hardware components.

[0044] In contrast, some approaches do not take note of such dependencies and thus may be missing some hardware components for building the testbench. Furthermore, some approaches may not include dependencies because knowing the dependencies between properties and thus between hardware components may require in-depth knowledge in this area that may be missing.

[0045] In some embodiments of the present disclosure, in order to minimize the risk of missing such important information, a set of rules for identifying dependencies is included. For example, before generating a configuration, the rules can be checked to verify the dependencies between attributes. Figure 3 In the example embodiment of Figure 3 ), then due to the dependency between the two attributes, the computing device automatically selects a specific simulator (e.g., Figure 3 denoted by "XSIM" in the text). Table 1 below shows an example embodiment of a set of rules for identifying dependencies: root type Related(Leaf) type CTX property Radio Sim Hardware Unit RGW property ASIM, XSIM, BSIM Hardware Unit Server Type property Z Server Hardware Unit HB property MS-RBS Hardware Unit MB property Incompatible with RGW property

[0046] As shown in Table 1, there are some dependencies between attributes and also between hardware components.

[0047] refer to Figure 2 , operation 104 includes generating identifications of a plurality of hardware components that satisfy the configuration according to the ML model based on the configuration. Figure 2 In the example, the hardware components may include one of the following combinations: ●Core network+firewall+GNODEB+XSIM ●Remote login_switch+LTE UE simulator+3 cells+UESIM ●Switch+UE_module+multiplexer+attenuator

[0048] In other words, the configuration automatically generated from operation 102 for building the requested test bed is used in operation 104 to identify hardware components for building the requested test bed.

[0049] Figure 4 1 is a block diagram of an example embodiment of generating 104 identifications of multiple hardware components that satisfy the configuration according to an ML model based on the configuration. In the example embodiment, the ML model 400 includes one of a rule-based model and an ML regression model, and generating 104 identifications of multiple hardware components that satisfy the configuration includes: (i) providing the configuration to the ML model, and (iii) selecting the multiple hardware components that satisfy the configuration based on calculation of a reward value.

[0050] like Figure 4As shown in the example of FIG. 1 , the configuration generated in operation 102 is input to the ML model 400, and the ML model 400 can automatically generate the hardware components of the requested test bench. Figure 4 As shown, the identification of the hardware components may include the type / name of the corresponding hardware component and the corresponding quantity of each hardware component. In an example embodiment, the identification of the plurality of hardware components that satisfy the configuration includes an identification of the quantity of each hardware component from the plurality of hardware components.

[0051] In some embodiments, identification of multiple hardware components that satisfy the configuration is sent to a display (e.g., to a lab that built the requested test bed). Figure 1 In some of the illustrated embodiments, the method further includes displaying (106) on one of a graphical user interface or a display (i) the configuration, and (ii) an indicator to a user of the display to provide instructions for initiating the build.

[0052] As previously mentioned Figure 1 As discussed, the method also includes determining, based on the identifier (e.g., based on Figure 4 The example identification of the hardware component 104 shown) initiates (114) the automated build of the requested test bench.

[0053] Maintaining (one or more) built test beds for a long period of time may not be the best decision. In an attempt to increase the utilization of hardware components, in some embodiments, (one or more) test beds are created for on-demand use. In other words, if the computing device does not receive a new request to build a new test bed with the same configuration, the built test bed is disassembled and the hardware components can be returned to inventory. For example, in a Figure 1 In some of the illustrated embodiments, the method further includes disassembling (108) the existing test bed when the existing test bed including the plurality of hardware components does not satisfy the requested test bed and the usage period of the existing test bed has expired; and assigning (110) the plurality of hardware components of the disassembled test bed to the real-time inventory. As previously described, the computing device may use a rule-based or ML regression model (e.g., a deep RL model) to generate an identification for building the requested test bed(s). The identification may satisfy different requests from the end user.

[0054] Figure 5 is a schematic diagram illustrating an example embodiment of generating (operation 104) identifications of a plurality of hardware components. The example embodiment also includes dynamically updating / notifying the inventory database. The deep RL model may be used to build the requested cloud-native testbed. Figure 5 As shown in the example embodiment of FIG. 1 , the identification of the hardware components and the data from the real-time dynamic inventory generated in operation 104 are inputs for initiating an automated build of the requested test bed.

[0055] Provided Figure 5 The computing device generates 104 identifiers of a plurality of hardware components satisfying the configuration according to the ML model based on the configuration. Figure 5 As shown in the example below, the identification includes the hardware components and their corresponding quantities:

[0056] The identification of the hardware components that satisfy the configuration is communicated to the real-time inventory 500. An automated build of the requested test bed is initiated 114 based on the identification; and the identification of the hardware type, quantity, and other data (such as the start date, end date of the request (and other requests)) is used to predict the availability of the hardware components. The predicted hardware availability is used to update the real-time inventory 500. Figure 5 As shown in the example embodiment of FIG. 1 , the predicted hardware availability includes the identification, hardware component type, cost, availability, and total quantity of the hardware component:

[0057] Including a real-time dynamic inventory can enable efficient use of cloud-native hardware components. Table 2 below is an example of the information that can be included in the dynamic inventory:

[0058] Hardware components can be dynamically allocated, assembled, and disassembled based on requests. In addition, hardware components can be labeled and classified based on their complexity and application. In some embodiments, hardware components are classified into the following groups, where each category has a different cost: ● Basic Cloud RAN Hardware Components (Cost 1, Basic). This category may indicate the hardware components and cloud infrastructure required to build a relatively simple testbed, e.g., the minimum foundation of hardware components required to build any type of cloud-native testbed. RGW Cloud RAN Hardware Components (Cost 2, Medium). This category may represent the hardware components and cloud infrastructure used to implement the RGW functionality of a basic testbed. Therefore, a testbed with RGW has a higher capacity compared to a basic testbed. UE Test Hardware Components (Cost 3, Complex). This category may represent hardware components and cloud infrastructure used to enable UE capacity in a cloud native testbed. UE capacity may be the maximum capacity a cloud native testbed may have. Therefore, this category of hardware components (e.g., compared to Cost 1, Basic and Cost 2, Medium) is the most complex and expensive type of hardware components.

[0059] In some embodiments, starting ( Figure 1 Operation 114) of the automated build also includes notifying the inventory of future availability times of the plurality of hardware components.

[0060] For a corresponding hardware component in the inventory, the inventory may include one or more of: (i) an identifier of the hardware component, (ii) a type of the hardware component, (iii) a capability type of the hardware component, (iv) an availability time of the hardware component, and (v) cost information of the hardware component.

[0061] An example embodiment of the method according to the present disclosure is implemented in Python. Note that although the implementation is done in Python, the method of the present disclosure is not limited thereto and can be implemented in the cloud. Figure 8 A schematic diagram of the cloud implementation is provided.

[0062] An example embodiment implemented in Python includes a graphical user interface (GUI). Figure 6 is a schematic diagram illustrating an example embodiment of a GUI 600 that can be used by an end user (eg, tester, integrator, etc.) to build a requested cloud-native test bed. The GUI 600 is used to capture properties and data that can be received by a computing device. Figure 6 The data in the example (which may also be referred to as metadata) includes a request number, a start date and an end date, and a priority level of the request for the test bed. Figure 6 The properties of the cloud native RAN of the requested testbed in the GUI 600 include mode (as NSA check), fronthaul (as RGW check), service (as OAM check), no operating system (OS), no cell check, no UE check, and other functional LB checks. The GUI 600 also includes a "Generated Testbed Suggestion" button and a "Submit" button. Figure 6 As shown in the example of , a suggested test bed configuration (LB.RGW.NSA.OAM) is displayed, which matches the input properties; and the display further indicates that there is an available test bed for the test bed configuration.

[0063] The data / metadata entered on the GUI 600 can be used to help estimate the useful life of each test bed. As previously mentioned, due to the dynamic changes in cloud applications, maintaining a test bed for a long time may not be the best decision. Figure 6 As shown, capturing data / metadata using end-user input can help computing devices perform the following operations, for example: 1. Estimate the start time for building a new cloud-native testbed. 2. Estimate the useful life of the test bench, which can be used for maintenance planning and floor space costs of the test bench. 3. The end date can help, for example, a lab team to plan the teardown of a test stand if the computing device does not receive similar requests to build a new test stand with the same configuration. 4. Prioritize incoming requests based on the priority of the requests. In a dynamic testing process for testing cloud applications, a computing device may receive several requests to build different cloud native test beds at or about the same time. In this case, several factors may be considered (e.g., availability of (one or more) hardware components, cost, manpower, etc.), among which the priority of each request may be the most important factor.

[0064] The properties selected on the GUI 600 may also be received by the computing device. As previously mentioned, the cloud native test bed may have a variety of capabilities / features. Understanding the configuration of the cloud native test bed may require in-depth knowledge of the cloud RAN field. Figure 6 As shown, important attributes (e.g., high-level cloud RAN attributes) are identified and provided on GUI 600 for selection by the end user. In addition, there may be binary relationships between some of the attributes that can be selected on GUI 600. For example, in Figure 6 In the example, the cloud-native testbed can be an OAM or a business. Although certain embodiments herein are discussed with respect to example dependencies and binary relationships, the present disclosure is not limited to these examples and includes other dependencies and binary relationships between attributes of a cloud-native cloud RAN testbed.

[0065] In an example embodiment, the receiving ( Figure 1 The operation 100 of claim 1 further includes receiving data including one or more of a time period of the requested test station, an identifier of the request for the requested test station, and a priority level of the requested test station, and generating ( Figure 1 Operation 102) uses the plurality of attributes to identify a configuration and uses the received data to identify at least one of a duration and a priority level of the requested test bed.

[0066] In some embodiments, Figure 6 As shown, the capabilities of the cloud native testbed are categorized into four main groups: (1) fronthaul capabilities, (2) business capabilities, (3) business-specific capabilities, and (4) platform capabilities. However, in other embodiments, some of these features / capabilities may be eliminated and merged, or (one or more) new features may be added to the cloud native testbed attributes. Therefore, the method of the present disclosure includes the ability to adapt to future changes.

[0067] As previously mentioned, some approaches do not pay attention to the configuration of the testbed, which may lead to overestimation or underestimation of the testbed's capabilities; this may also directly affect the overall cost of utilizing resources. In contrast, the operation of the present disclosure includes a set of rules for identifying dependencies, for example, as shown in the example of Table 1 of this article.

[0068] Figure 6 The test bed configuration shown on GUI 600 is a configuration generated according to some embodiments. After the end user selects properties for building the requested test bed on GUI 600, clicks Generate Test Bed Suggestions, and clicks Submit, the computing device may provide the corresponding generated test bed configuration. Figure 6 As shown, the generated configuration includes the identifier ( Figure 6 The generated configuration is used as input for generating according to the ML model based on the identification of multiple hardware components that satisfy the configuration (operation 104 discussed herein).

[0069] In an attempt to utilize the cloud RAN hardware components in an efficient manner, in an example implementation, the data / metadata entered on the GUI 600 and the following criteria are considered for building the requested cloud native testbed: a. Cost of each hardware component: As shown in Table 2, for each hardware component, there may be several types or brands with different costs (for example, a server can be ordered from Dell or HP). Hardware costs can be direct costs; however, the total cost of a cloud-native testbed may also include the following examples of indirect and direct costs: 1. Software cost + licensing (direct cost), platform cost (e.g., for a specific platform vendor). 2. Operational cost = test bench configuration, complexity and manpower cost (indirect cost). 3. Floor space and size (indirect costs). 4. Electricity and connection costs (indirect costs). b. The availability of each hardware component predicted by the ML model. In addition to the total cost of utilizing the cloud native testbed, the availability of each hardware component can also be monitored. In some embodiments, the task of building a cloud native testbed is a dynamic task. For example, several requests may be submitted every day, and each request may require different infrastructure. For each decision (i.e., building the requested cloud native testbed), the availability of the hardware component can be checked in advance. c. Priority of each request from the data / metadata. Each request to build a new cloud native testbed may have a different priority due to, for example, a delivery schedule. For example, the priorities may be indicated as A, B, and C or as numbers 1.2 and 2.2. Priority information may be included as part of the metadata extraction. Knowing the priority of each request in advance may help the computing device change some decisions (e.g., preemption) and / or predict the next testbed. d. The start date and duration of each request from the data / metadata. Because different requests to build new cloud-native test beds can have different priorities, the start data and lifetime of the newly built test beds can be pre-specified on the GUI 600. This information can help the computing device to predict when the cloud-native hardware components will be available for the next test bed.

[0070] Using the inputs and criteria discussed herein, a computing device can dynamically create a hardware component-level detailed plan for building a test bed. Figure 7 is a flow diagram of the operation of a computing device according to some embodiments. Two different strategies may be included to generate an identification (operation 104 discussed herein): a rule-based strategy 702 and / or an ML-based strategy 704 .

[0071] The rule-based strategy 702 may include (1) shortest duration first, where new requests with the shortest duration are scheduled; or (2) instantaneous maximum reward first, where new requests with the maximum reward calculated at each time step are scheduled. The ML-based strategy 704 may include deep Q-learning based scheduling.

[0072] The rule-based strategy 702 or the ML-based strategy 704 selects 706 a feasible action A t , based on action A t Update 708 hardware component availability and wait time, and observe corresponding to action A t Status S t . Observation results (S t ) may include, for example:

[0073] Figure 8 is a flow diagram of the operation of a computing device according to some embodiments including a deep Q-learning based strategy. Figure 8 The example deep Q-learning network 800 based strategy shown includes: 1. Observation results (S t )700 is the concatenation vector of: i. Waiting time for each testbench build request ii. The predicted usage duration of each request iii. Priority of each request (from data / metadata) iv. The predicted number of each cloud-native hardware component required per request v. The predicted availability of each hardware component type N time steps into the future 2. Select an action (A) in operation 708 t ), and the action (A t ) is a scalar indicating whether the request can be processed or whether the proxy should wait. 3. Round: Duration from the start time to the end time of the schedule (from data / metadata) 4. In operation 806, the reward (R t ). Reward (R t ) is the weighted sum of the following objectives: i. Target 1 = 1 / (∑ i (waiting time of request i)*(priority of request i) ii. Target 2 = 1 / (Hardware cost of allocated requests) iii. Target 3 = (terminal cost of unassigned requests at the end of the round) 5. Given the observations, the deep neural network 800 outputs a vector Q(S) with the predicted, expected reward for each action. t , A t ) 802. The deep network model 800 can be trained as follows: i. Start with any initial weights θ of the deep neural network 800 ii. Make observations (S t )700 and predict the Q value of all possible actions iii. Use the ε-greedy strategy to select an action 708. Using the ε probability, a random action with probability 1-ε can be selected, and the action with the maximum Q value can be selected iv. Calculate the reward (R t )806 and update the state of the environment 706 (S t+1 ) v. Using the gradient descent method, update 804 the network weights to θ′ that minimizes the mean square error (MSE) MSE=(R t +γ*max a Q(S t+1 ,a;θ′)-Q(S t , A t ;θ)) 2 , where γ is the discount factor.

[0074] In an example embodiment, the reward value comprises a weighted sum of: (i) a request latency and a priority level of a requested test bed, (ii) a cost of a plurality of hardware components to satisfy the configuration, and (iii) a cost of at least one unallocated request.

[0075] Fig. 9 9 is a schematic diagram of a GUI 900 from an example implementation showing identification of a number of hardware components that satisfy a configuration in an example implementation. Fig. 9 As shown in the example, the configuration is identified as LB.RGW.NSA.OAM; and the identification of the hardware components that satisfy the configuration includes three categories of hardware components: basic, RGW, and UE. As described above, the basic category includes the minimum requirements for hardware components and quantities required to satisfy the basic test bed. The basic category shown includes one frame, one global positioning system (GPS) splitter, one server, one remote login switch, two switches, and two protocol data units (PDUs); and there are no core networks, firewalls, media converters, racks, network emulators, power supply units (PSUs), packet processing units (PPUs), routers, remote procedure call (RPC)-routers, terminal servers, test tools, or network splitters.

[0076] Fig. 9 The RGW category shown in includes two digital units, one ENodeB, two GNodeBs, one multiplexing unit, three RU.LBs, one shielding box; and no attenuator, RU.MB, RU.HB, RBS, multiple-input multiple-output (MIMO) box, channel emulator or radio baseband unit (RBU).

[0077] Fig. 9 The UE categories shown in do not apply to the generated configuration and there is no Content Centric Networking (CCN), CCN Server, 5v USB Power, UE Board Computer, UE, UE Sim, UE Sim SC, UE Modem, UE Module or UE Control PC included.

[0078] GUI 900 also includes an optimized test bench that the end user can review and automatically build, and a schedule test bench button that the end user can click. In some embodiments, the method also includes scheduling ( Figure 1 Operation 112) schedules the construction of the requested test bed. The scheduling includes reserving multiple hardware components that satisfy the configuration for the duration of the requested test bed, and identifying a start time for the construction based on the availability of the multiple hardware components and the optimization goal.

[0079] As reference Figure 1As discussed in operation 114 of the present invention, the process of initiating the process according to the identification (e.g., according to Fig. 9 In an alternative embodiment, the requested test bench can be automatically constructed based on the identification (e.g., based on Fig. 9 The build is assembled (e.g., by a human) using the information shown in .

[0080] In an example implementation, performance measurements were performed on hardware component prediction. The dataset used for performance evaluation included 31 unique configurations; 190 unique hardware components; and a total of 2471 hardware components.

[0081] Table 3 below includes a summary of the performance evaluation of an example implementation using a rule-based approach: Hardware components (2471 in total) Accuracy CCN 0.73 Radio_Unit_LB 0.53 Radio_Unit_HB 0.73 Remote login_switch 0.53 Terminal_Server 0.92 …… …… average value 0.72

[0082] Table 4 below includes the following information: Figure 7 and Figure 8 Summary of the performance evaluation of the discussed rule-based and deep Q-learning strategies and a cloud-native testbed for dynamically building the example implementation for a total of 1000 episodes (duration from the start time to the end time of the schedule). Prior to the evaluation, the deep-Q learning neural network was trained for 15000 episodes: Testbench construction strategy method Average cumulative reward Rule-based policies Shortest duration first 325.5 Rule-based policies The instantaneous maximum reward is prioritized 325.9 ML-based strategies Deep-Q Learning 346.9

[0083] Including different strategies can allow for flexible selection of strategies based on the size of the infrastructure and / or the number of incoming requests. For example, a rule-based strategy can be selected for smaller data sets, while an ML-based strategy can be selected for larger data sets.

[0084] Thus, the methods of various embodiments may provide a platform for automatically capturing attributes of a cloud RAN to an end user, and may be compatible with any automated control system that configures a cloud native infrastructure to build a test bed directly based on end user input, which may eliminate the need for, for example, a lab technician. In some embodiments, dependencies may be automatically identified based on the inclusion of a set of rules that identify (i) dependencies between at least two attributes from a configuration and / or between at least one hardware component and at least one attribute from a configuration. ML-based and rule-based methods may be used to automate the automated generation of configurations for corresponding requests. In addition, some embodiments may generate identification of hardware components that satisfy the generated configuration by considering: the delivery and end dates of each test request; the cost of each hardware component (e.g., by selecting the cheapest hardware among all available hardware components); the priority of each request; the test duration of each request; and / or dependencies between cloud infrastructures. In addition, some embodiments provide a dynamic inventory that automatically and dynamically predicts the availability of cloud native hardware components. In an example embodiment, generation ( Figure 1 Operation 104) The identification of the plurality of hardware components satisfying the configuration is based on at least one of availability, compatibility, and cost of corresponding hardware components among the plurality of hardware components.

[0085] Therefore, human efforts to predict the capabilities of a cloud-native testbed may be reduced; testbed build time and cost may be reduced; decisions to tear down, modify, or keep a cloud-native testbed may be automatically made without any human involvement; and the total cost may be minimized. Furthermore, different testbed build strategies may be provided by considering the size of the cloud-native infrastructure, the use of the cloud-native infrastructure may be improved or optimized by considering the cost and automatically predicting the availability of the cloud-native infrastructure; and by prioritizing and scheduling testbed build requests, on-time delivery of cloud-based applications / products may be optimized or improved.

[0086] Fig.10 1 is a block diagram showing an overview of a cloud-implemented distributed computing device according to some embodiments. A web client 1000 is communicatively coupled to a distributed production 1002 logical device / physical device, which includes: a service front end 1004, a function as a service (FaaS) 1006 including configuration creation (as discussed herein), a FaaS 1010 including dependency identification (as discussed herein), a FaaS 1012 including hardware component prediction (as discussed herein), and a FaaS 1014 including testbed build identification (as discussed herein). FaaS 1012 and 1014 are communicatively coupled to a database 1016 and an object storage device 1018, respectively. Database 1016 includes training data. Object storage device 1018 includes ML models. Database 1016 and object storage device 1018 are communicatively coupled to an ML training cluster 1022 in a distributed development 1020 logical device / physical device. The distributed development 1020 logical device / physical device also includes: a GUI / display 1024 (as discussed herein) and a code base 1026 communicatively coupled to the GUI / display 1024. The GUI / display 1024 is communicatively coupled to the FaaS 1006, 1010, 1012, 1014 for performing the operations discussed herein.

[0087] The computing device 1000 may also include multiple component sets for different wireless technologies, such as Global System for Mobile Communications (GSM), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), New Radio (NR), Wireless Local Area Network (WLAN) standards such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi), Near Field Communication (NFC) Zigbee, Z-wave, Long Range Wide Area Network (LoRaWAN), Radio Frequency Identification (RFID), or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chips or chipsets and other components of the computing device 1000.

[0088] Embodiments of computing device 1000 may include, in addition to Fig.10 , to provide certain aspects of the functionality of the computing device, including any functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, computing device 1000 may include user interface devices to allow information to be entered into computing device 1000 and to allow information to be output from computing device 1000. This may allow a user to perform diagnostic, maintenance, repair, and other management functions on computing device 1000.

[0089] Fig.11 shows how computing device 1000 (in Fig.11 Two specific examples (referred to as computing device 1100 in the present invention) include: 1) a special-purpose computing device 1102, which uses customized processing circuits, such as an application-specific integrated circuit (ASIC) and a proprietary operating system (OS); and 2) a general-purpose computing device 1104 using a COTS processor and a standard OS that has been configured to provide one or more of the features or functions disclosed herein.

[0090] The dedicated computing device 1102 includes hardware 1110, which includes (one or more) processors 1112 and interfaces 1116 and memory 1118 in which software 1120 is stored. In one embodiment, the software 1120 implements the modules described with respect to the previous figures. During operation, the software 1120 can be executed by the hardware 1110 to instantiate a set of one or more software instances 1122. Each software instance of the (one or more) software instances 1122 and the portion of the hardware 1110 that executes the software instance (whether hardware dedicated to the software instance, hardware using a portion of available physical resources (e.g., processor cores), and / or a time slice of the hardware that the software instance temporarily shares with other software instances of the (one or more) software instances 1122) form a separate virtual network element 1130A-R. Therefore, in the presence of multiple virtual network elements 1130A-R, each virtual network element operates as one of the network devices from the previous figures.

[0091] Back to Fig.11, the example general purpose computing device 1104 includes hardware 1140, which includes a set of one or more processors 1142 (which are typically COTS processors) and an interface 1146, and a memory 1148 in which software 1150 is stored. During operation, the (one or more) processors 1142 execute the software 1150 to instantiate one or more sets of one or more applications 1164A-R. Although some embodiments do not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in some alternative embodiments, the virtualization layer 1154 represents the kernel of the operating system (or a shim executed on the base operating system), which allows the creation of multiple instances 1162A-R, referred to as software containers, which can each be used to execute one (or more) of the sets of applications 1164A-R. In this embodiment, the software containers 1162A-R (also known as virtualization engines, virtual private servers, or isolated environments (jails)) are user spaces (typically virtual memory spaces) that can be separated from each other and are separated from the kernel space in which the operating system runs. In some embodiments, a set of applications running in a given user space may be prevented from accessing the memory of other processes unless explicitly allowed. In other such alternative embodiments, the virtualization layer 1154 may represent a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executed on top of a host operating system; and each of the sets of applications 1164A-R may run on top of a client operating system within an instance 1162A-R called a virtual machine (which in some cases may be considered a tightly isolated form of a software container run by a hypervisor). In some embodiments, one, some, or all applications are implemented as (one or more) monolithic kernels, which may be generated by directly compiling only a limited set of libraries (e.g., from a library operating system (LibOS) that includes drivers / libraries of OS services) with the application, which provide specific OS services required by the application. Since a single kernel can be implemented to run directly on hardware 1140, directly on a hypervisor (in which case the single kernel is sometimes described as running within a LibOS virtual machine), or within a software container, embodiments can be implemented entirely with a single kernel running directly on a hypervisor represented by virtualization layer 1154, a single kernel running within a software container represented by instances 1162A-R, or as a single kernel and a combination of the foregoing techniques (e.g., a single kernel and a virtual machine both running directly on a hypervisor, a single kernel and a collection of applications running in different software containers).

[0092] The instantiation and virtualization (if implemented) of one or more sets of one or more applications 1164A-R are collectively referred to as software instance(s) 1152. Each set of applications 1164A-R, the corresponding virtualization construct (e.g., instance 1162A-R) (if implemented), and the portion of hardware 1140 on which they execute (whether dedicated to that execution and / or a time slice of hardware temporarily shared by software containers 1162A-R) form separate virtual network element(s) 1160A-R.

[0093] (One or more) virtual network elements 1160A-R perform functions similar to (one or more) virtual network elements 1130A-R. Such virtualization of hardware 1140 is sometimes referred to as network function virtualization (NFV). Thus, NFV can be used to integrate many network device types onto industry-standard high-volume server hardware, physical switches, and physical storage devices, which may be located, for example, in data centers and customer premises equipment (CPE). However, different embodiments of the present invention may implement one or more software containers 1162A-R in different ways. Although embodiments of the present invention are shown as each instance 1162A-R corresponding to one VNE 1160A-R, alternative embodiments may implement such correspondence at a finer level of granularity; it should be understood that the techniques described herein with reference to the correspondence of instances 1162A-R to VNEs are also applicable to embodiments using such finer levels of granularity and / or a single core.

[0094] Fig.11 A third example computing device implementation in is a hybrid computing device 1106 that includes both a custom ASIC / proprietary OS and a COTS processor / standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid computing device, a platform virtual machine (VM), such as a VM that implements the functionality of a dedicated computing device 1102, can specify paravirtualization for the hardware present in the hybrid computing device 1106.

[0095] For reasons of simplicity and space, the previous reference Fig.11 Many of the functions of the computing device described in Fig.12 has been omitted.

[0096] Although the devices described herein may include a combination of hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that these devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, calculation, acquisition, or similar operations described herein may be performed by a processing circuit, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or the converted information with the information stored in the device, and / or performing one or more operations based on the obtained information or the converted information, and making a determination as a result of the processing. In addition, although the components are depicted as a single box located within a larger box, or nested within multiple boxes, in reality, the device may include multiple different physical components constituting a single illustrated component, and the functions may be divided between separate components. For example, a communication interface may be configured to include any component described herein, and / or the functions of the components may be divided between a processing circuit and a communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, while the computationally intensive functions may be implemented in hardware.

[0097] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit that executes instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by a processing circuit without executing instructions stored on a separate or discrete device-readable storage medium, such as provided in a hardwired manner. In any of these specific embodiments, the processing circuit may be configured to perform the described functionality, regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to just the processing circuit or other components of the computing device, but are generally enjoyed by the computing device as a whole and / or the wireless network.

[0098] Further definitions and embodiments are discussed below.

[0099] In the above description of various embodiments of the inventive concept, it should be understood that the terms used herein are only for the purpose of describing specific embodiments, rather than for limiting the inventive concept. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meanings as those commonly understood by those of ordinary skill in the art to which the inventive concept belongs. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having meanings consistent with their meanings in the context of this specification and the related art, and will not be interpreted as idealized or overly formal meanings, unless clearly defined herein.

[0100] When an element is referred to as being "connected", "coupled", "responded" or a variation thereof to another element, it may be directly connected, coupled or responded to another element, or there may be an intermediate element. On the contrary, when an element is referred to as being "directly connected", "directly coupled", "directly responded" or a variation thereof to another element, there is no intermediate element. The same number always refers to the same element. In addition, "coupling", "connection", "response" or a variation thereof used herein may include wireless coupling, connection or response. As used herein, the singular forms "a", "an" and "the" are intended to also include plural forms, unless the context clearly indicates otherwise. For the sake of brevity and / or clarity, well-known functions or structures may not be described in detail. The term "and / or" (abbreviated as " / ") includes any and all combinations of one or more items in the associated listed items.

[0101] It will be understood that although the terms first, second, third, etc. may be used to describe various elements / operations herein, these elements / operations should not be limited by these terms. These terms are only used to distinguish an element / operation from another element / operation. Therefore, without departing from the teaching of the present invention, the first element / operation in some embodiments may be referred to as the second element / operation in other embodiments. Throughout the specification, the same reference numerals or the same reference signs represent the same or similar elements.

[0102] As used herein, the terms "comprises," "includes," "having," or variations thereof are open ended and include one or more of the described features, integers, elements, steps, components, or functions, but do not exclude the presence or addition of one or more other features, integers, elements, steps, components, functions, or combinations thereof. In addition, as used herein, the common abbreviation "eg," derived from the Latin phrase "exempli gratia," may be used to introduce or specify one or more general examples of the aforementioned items, and is not intended to limit such items. The common abbreviation "ie," derived from the Latin phrase "id est," may be used to specify a specific item in a more general narrative.

[0103] Example embodiments are described herein with reference to block diagrams and / or flow charts of computer-implemented methods, devices (systems and / or apparatuses), and / or computer program products. It should be understood that the blocks in the block diagrams and / or flow charts and the combination of blocks in the block diagrams and / or flow charts can be implemented by computer program instructions executed by one or more computer circuits. These computer program instructions can be provided to processor circuits of general-purpose computer circuits, special-purpose computer circuits, and / or other programmable data processing circuits to produce a machine so that instructions executed by processors of computers and / or other programmable data processing devices convert and control transistors, values ​​stored in memory locations, and other hardware components within such circuits to implement the functions / actions specified in the block diagrams and / or one or more flow chart blocks, thereby creating components (functions) and / or structures for implementing the functions / actions specified in the block diagrams and / or (one or more) flow chart blocks.

[0104] These computer program instructions may also be stored in a tangible computer-readable medium, which may direct a computer or other programmable data processing device to function in a particular manner, so that the instructions stored in the computer-readable medium produce an article of manufacture including instructions for implementing the functions / actions specified in the block diagram and / or one or more flowchart blocks. Therefore, embodiments of the inventive concept may be embodied in hardware and / or software (including firmware, resident software, microcode, etc.) running on a processor such as a digital signal processor, which may be collectively referred to as "circuit", "module" or variations thereof.

[0105] It should also be noted that in some alternative implementations, the function / action marked in the frame may not occur in the order marked in the flow chart. For example, the two frames shown in succession can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the function / action involved. In addition, the function of a given frame of a flow chart and / or block diagram can be divided into multiple frames, and / or the function of two or more frames of a flow chart and / or block diagram can be at least partially integrated. Finally, without departing from the scope of the inventive concept, other frames can be added / inserted between the frames shown, and / or frames / operations can be omitted. In addition, although some of the figures include arrows on the communication path to show the main direction of communication, it should be understood that communication can occur in the direction opposite to the arrows shown.

[0106] Many changes and modifications may be made to the embodiments without substantially departing from the principles of the inventive concept. All such changes and modifications are intended to be included within the scope of the inventive concept. Therefore, the subject matter disclosed above should be considered illustrative rather than restrictive, and the examples of the embodiments are intended to cover all such modifications, enhancements, and other embodiments, which all fall within the spirit and scope of the inventive concept. Therefore, to the maximum extent permitted by law, the scope of the inventive concept is to be determined by the broadest permissible interpretation of the present disclosure, including examples of the embodiments and their equivalents, and should not be constrained or limited by the foregoing detailed description.

Claims

1. A computer-implemented method performed by a computing device for initiating construction of a cloud-native radio access network (RAN) test bed, the method comprising: Receiving (100) a plurality of properties of the cloud-native RAN of the requested test bed; generating (102) a configuration of the requested test bed based on the plurality of attributes, the configuration comprising an identifier identifying at least one or more of the plurality of attributes of the cloud-native RAN and at least one or more hardware components of the requested test bed; Based on the configuration, generating (104) identifications of a plurality of hardware components satisfying the configuration according to a machine learning (ML) model; as well as An automated build of the requested test bench is initiated (114) based on the identification.

2. The method according to claim 1, further comprising: A build of the requested test bed is scheduled (112), the scheduling comprising reserving a plurality of hardware components that satisfy the configuration for a duration of the requested test bed and identifying a start time for the build based on availability of the plurality of hardware components and optimization goals.

3. The method according to any one of claims 1 to 2, wherein: The generating (104) identification of the plurality of hardware components that satisfy the configuration is based on at least one of availability, compatibility, and cost of respective hardware components of the plurality of hardware components.

4. The method according to any one of claims 1 to 3, wherein: The multiple attributes include one or more of the following: (i) radio spectrum, (ii) model, brand or name of the simulator, (iii) type of user equipment (UE), (iv) cell type, (v) number of cells, (vi) type of RAN support, (vii) independent or non-independent mode, (viii) service type, and (ix) radio gateway.

5. The method according to any one of claims 1 to 4, wherein: The receiving (100) also includes receiving data, the data including one or more of a time period of the requested test bed, an identifier of the request for the requested test bed, and a priority level of the requested test bed, and the generating (102) uses the multiple attributes to identify the configuration and uses the received data to identify at least one of a duration and a priority level of the requested test bed.

6. The method according to claims 1 to 5, wherein: The generating (102) of the configuration includes analyzing at least one or more of the multiple attributes of the cloud native RAN and at least one or more hardware components of the requested test bed according to the configuration based on the use of a rule set, wherein the rule set identifies (i) dependencies between at least two attributes from the configuration, and / or dependencies between at least one hardware component and at least one attribute from the configuration.

7. The method of any one of claims 1 to 6, wherein the ML model comprises one of a rule-based model and an ML regression model, and wherein generating identifications of the plurality of hardware components that satisfy the configuration comprises: (i) providing the configuration to the ML model, and (ii) selecting the plurality of hardware components that satisfy the configuration based on calculation of a reward value.

8. The method of claim 7, wherein the reward value comprises a weighted sum of: (i) a wait time for a request to the requested test bed and a priority level of the request, (ii) a cost of the plurality of hardware components to satisfy the configuration, and (iii) a cost of at least one unallocated request.

9. The method according to any one of claims 1 to 8, wherein the identification of the plurality of hardware components satisfying the configuration comprises an identification of the quantity of each hardware component from the plurality of hardware components.

10. The method according to any one of claims 1 to 9, further comprising: When an existing test bed including a plurality of hardware components does not satisfy the requested test bed and a usage period of the existing test bed has expired, disassembling (108) the existing test bed; as well as The plurality of hardware components of the disassembled test station are assigned (110) to a real-time inventory.

11. The method according to any one of claims 1 to 10, wherein said initiating (114) said automated build further comprises notifying an inventory of future availability times of said plurality of hardware components.

12. The method according to any one of claims 10 to 11, wherein: For corresponding hardware components in the inventory, the inventory includes one or more of the following: (i) an identifier of the hardware component, (ii) a type of the hardware component, (iii) a capability type of the hardware component, (iv) an availability time of the hardware component, and (v) cost information of the hardware component.

13. The method according to any one of claims 1 to 12, further comprising: Displaying (106) (i) the configuration on one of a graphical user interface or a display, and (ii) an indicator to a user of the display to provide instructions for initiating the build.

14. A computing device (1100, 1200) configured to initiate construction of a cloud-native radio access network (RAN) test bed, the computing device comprising: Processing circuit (1112, 1142, 1203); A memory (1118, 1148, 1205) coupled to the processing circuit, wherein the memory includes instructions that, when executed by the processing circuit, cause the computing device to perform operations including: receiving a plurality of properties of the cloud-native RAN of the requested test bed; generating, based on the plurality of attributes, a configuration of the requested test bed, the configuration comprising an identifier identifying at least one or more of the plurality of attributes of the cloud-native RAN and at least one or more hardware components of the requested test bed; Based on the configuration, generating identifications of multiple hardware components that satisfy the configuration according to a machine learning (ML) model; as well as An automated construction of the requested test bench is initiated according to the identification.

15. The computing device of claim 14, wherein: The memory comprises instructions which, when executed by the processing circuit, cause the computing device to perform further operations, the further operations comprising any of the operations of any one of claims 2 to 13.

16. A computing device (1100, 1200) configured to initiate construction of a cloud-native radio access network (RAN) test bed, the computing device being adapted to perform operations comprising: receiving a plurality of properties of the cloud-native RAN of the requested test bed; generating, based on the plurality of attributes, a configuration of the requested test bed, the configuration comprising an identifier identifying at least one or more of the plurality of attributes of the cloud native RAN and at least one or more hardware components of the requested test bed; Based on the configuration, generating identifications of multiple hardware components that satisfy the configuration according to a machine learning (ML) model; as well as An automated construction of the requested test bench is initiated according to the identification.

17. The computing device of claim 16, adapted to perform the further operations of any one of claims 2 to 13.

18. A computer program comprising program code to be executed by a processing circuit (1112, 1142, 1203) of a computing device (1100, 1200), the computing device being configured to initiate construction of a Cloud Native Radio Access Network (RAN) test bed, whereby execution of the program code causes the computing device to perform operations comprising: receiving a plurality of properties of the cloud-native RAN of the requested test bed; generating, based on the plurality of attributes, a configuration of the requested test bed, the configuration comprising an identifier identifying at least one or more of the plurality of attributes of the cloud native RAN and at least one or more hardware components of the requested test bed; Based on the configuration, generating identifications of multiple hardware components that satisfy the configuration according to a machine learning (ML) model; as well as An automated construction of the requested test bench is initiated according to the identification.

19. The computer program of claim 18, wherein execution of the program code causes the computing device to perform the operations of any one of claims 2 to 13.

20. A computer program product comprising a non-transitory storage medium (1118, 1148, 1205), the non-transitory storage medium comprising program code to be executed by a processing circuit (1112, 1142, 1203) of a computing device (1100, 1200), the computing device (1100, 1200) being configured to initiate construction of a Cloud Native Radio Access Network (RAN) test bed, whereby execution of the program code causes the computing device to perform operations comprising: receiving a plurality of properties of the cloud-native RAN of the requested test bed; generating, based on the plurality of attributes, a configuration of the requested test bed, the configuration comprising an identifier identifying at least one or more of the plurality of attributes of the cloud native RAN and at least one or more hardware components of the requested test bed; Based on the configuration, generating identifications of multiple hardware components that satisfy the configuration according to a machine learning (ML) model; as well as An automated construction of the requested test bench is initiated according to the identification.

21. The computer program product of claim 20, wherein execution of the program code causes the computing device to perform the operations of any one of claims 2 to 13.

Images