Methods for collecting topology and inventory data, and systems for using them.

Abstract

A method for collecting, creating, or updating topology and inventory data for a network includes receiving a request via a Service Management and Orchestrator (SMO) interface, the request including instructions for topology and inventory information to be collected, created, or updated. The method further includes forwarding the request to a Topology and Inventory (TE&IV) management module. The method further includes collecting, creating, or updating topology and inventory data for at least a first component of the network based on the request. The topology and inventory data includes relationship information between the first component and at least a second component of the network, and capability information for the first component.

Description

Technical Field

[0001] Priority Claim and Cross - Reference This application claims priority to Provisional Patent Application No. 63 / 508,905, filed on June 19, 2023, the entire content of which is incorporated herein by reference.

Background Art

[0002] An Open Radio Access Network (O - RAN) uses a Service Management and Orchestrator (SMO) and a Non - Real Time RAN Intelligent Controller (NON - RT RIC) to assist in the management of devices within the O - RAN architecture. The SMO and NON - RT RIC can be used with O - RAN Alliance standards to provide services to an operator for tracking the inventory and topology of devices within the O - RAN architecture. The inventory service involves identifying and maintaining information related to devices within the O - RAN architecture. The topology service involves tracking links between devices to provide services to customers of the O - RAN system. In some cases, an Application Programming Interface (API) only provides configuration management and topology and inventory management within the O - RAN architecture is not possible. Further, some approaches are limited to accessing data only in a cloud network or only in a wireless network.

Summary of the Invention

[0003] One aspect of this specification relates to a method for collecting, creating, or updating topology and inventory data for a network. The method includes receiving a request via a Service Management and Orchestrator (SMO) interface, the request including instructions for topology and inventory information to be collected, created, or updated. The method further includes forwarding the request to a Topology and Inventory (TE&IV) management module. The method further includes collecting, creating, or updating topology and inventory data for at least a first component of the network based on the request. The topology and inventory data includes relationship information between the first component and at least a second component of the network, and capability information for the first component.

[0004] One aspect of this specification relates to a non-temporary computer-readable medium configured to store instructions for a system to perform a method. The method includes receiving a request via a service management and orchestrator (SMO) interface, the request including instructions for topology and inventory information to be collected, created, or updated. The method further includes forwarding the request to a topology and inventory (TE&IV) management module. The method further includes collecting, creating, or updating topology and inventory data for at least a first component of a network based on the request. The topology and inventory data includes relationship information between the first component and at least a second component of the network, and capability information for the first component.

[0005] One aspect of this specification relates to a system for collecting, creating, or updating topology and inventory data for a network. The system includes a service management and orchestrator (SMO). The SMO is configured to receive requests via an interface, the requests of which include topology and inventory information to be collected, created, or updated. The SMO is further configured to forward requests to a topology and inventory (TE&IV) management module. The SMO is further configured to collect, create, or update topology and inventory data for at least a first component of a network based on a query. The topology and inventory data includes relationship information between the first component and at least a second component of the network, and capability information about the first component. The SMO is further configured to output the collected topology and inventory data via an interface.

[0006] One aspect of this specification relates to a method for creating and updating topology and inventory data for a network. The method includes receiving a request via a service management and orchestrator (SMO) interface, the request including topology and inventory information to be created or updated. The method further includes forwarding the request to a topology and inventory (TE&IV) management module. The method further includes creating or updating topology and inventory data for at least a first component of the network based on the request. The topology and inventory data includes relationship information to indicate the relationship between the first component and at least a second component of the network, and capability information for the first component.

[0007] The aspects of this disclosure will be best understood by reading the following detailed description in conjunction with the attached figures. Note that, in accordance with standard industry practice, various features are not depicted to scale. In practice, the dimensions of various features may be arbitrarily enlarged or reduced for the sake of clarity in the discussion. [Brief explanation of the drawing]

[0008] [Figure 1] This is a block diagram of a service management and orchestrator (SMO) according to one embodiment.

[0009] [Figure 2] This is a schematic diagram of a wireless network component according to one embodiment.

[0010] [Figure 3] This is a block diagram of an Open Wireless Access Network (O-RAN) according to one embodiment.

[0011] [Figure 4] This is a schematic diagram of the topology and inventory arrangement of components within O-RAN according to one embodiment.

[0012] [Figure 5] This is a schematic diagram of the topology and inventory layout within O-RAN according to one embodiment.

[0013] [Figure 6] This is a diagram of topology data of components at different depths within O-RAN according to one embodiment.

[0014] [Figure 7] This is a table of sample queries for obtaining topology and inventory data for O-RAN according to one embodiment. [Figure 7C] This is a continuation of Figure 7.

[0015] [Figure 8] This is a flowchart of a method for collecting topology and inventory data from O-RAN according to one embodiment.

[0016] [Figure 9]This is a schematic diagram of a system for collecting topology and inventory data from O-RAN according to one embodiment. [Modes for carrying out the invention]

[0017] The following disclosure provides many different embodiments or examples for implementing different features of the subject matter provided. For the sake of simplicity, specific examples of components, values, behaviors, materials, arrangements, etc. are described below. Naturally, these are merely examples and are not intended to be limiting. Other components, values, behaviors, materials, arrangements, etc. are contemplated. For example, the formation of a first feature on or above a second feature in the following description may include embodiments in which the first and second features are formed in direct contact, or it may include embodiments in which an additional feature may be formed between the first and second features such that the first and second features are not in direct contact. In addition, the disclosure may repeat reference numbers and / or symbols in various examples. This repetition is for the sake of brevity and clarity and does not in itself define the relationships between the various embodiments and / or configurations discussed.

[0018] Furthermore, spatially relative terms such as “down,” “below,” “bottom,” “up,” and “top” may be used herein to facilitate descriptions of the relationship between one or more elements or features, as shown in the figures. Spatially relative terms are intended to encompass different orientations of the device in use or operation, in addition to the orientation shown in the figures. The device may also be oriented in other ways (rotated 90 degrees or in other orientations), and the spatially relative descriptors used herein may be interpreted accordingly.

[0019] This specification includes information related to APIs that help improve the management of topology and inventory within an O-RAN architecture. In 3GPP (registered trademark), the New Radio (NR) Network Resource Model (NRM) is being considered, but these NRMs are only applicable to RAN configuration management. Other approaches to topology and inventory management models for general telecommunications sites and equipment are not suitable for the deployment of O-RAN-based distributed and cloud-native networks. Other API frameworks for general cloud resource inventory management do not conform to mobile network-specific applications and do not have detailed API service operations, procedures, information, or data models.

[0020] This specification includes service API solutions to assist with concerns in O-RAN and 3GPP that are not addressed with respect to inventory and topology management and information disclosure in SMO. This specification includes a comprehensive API design for inventory and topology management of both RAN functions and O-Cloud resources in an O-RAN cloud-native network environment, as well as information disclosure, including service operations, procedures, and information and data models. The service operations, procedures, and information and data models are designed to be generic to enable the data model to be applied to a number of different interfaces within SMO for interoperability, such as the R1 interface, topology and inventory management services, and the SMO external interface to external functions, services, applications, and tools.

[0021] This specification enables multi-vendor interoperability between the topology and inventory management functions within the SMO and other functions and applications inside and outside the SMO. The API also helps enable the disclosure of inventory and topology information for non-real-time network automation in the SMO / Non-RT RIC via the R1 interface. Using the topology and inventory management service API interface provided in this specification, it is possible to provide the operator with an integrated end-to-end multi-vendor environment / toolset to enable automated workflows from network planning, provisioning and deployment of network functions, O-Cloud resource orchestration and management to network performance optimization in the operation phase. This API significantly reduces the operation costs, time, complexity, and risks in the network O&M process compared to other approaches.

[0022] By using the API of this specification, both third-party applications such as rApps and network operators can query a network that includes both cloud computers and wireless network components to determine the topology and inventory of the entire network. This enhances the functionality and usefulness of the API compared to other approaches that are restricted based on the specific language or syntax requirements of a particular network or network type so that it is possible to effectively utilize the functionality of the components of the entire network from a single interface with the same query.

[0023] This specification also includes the ability to adjust access based on the identity of the query initiator, such as a network operator or the owner of an rApp. In some embodiments, access is adjusted to limit the depth of the query. In some embodiments, access is adjusted to limit the frequency of queries from the same initiator. In some embodiments, access is adjusted to limit access to one or more components within the network. In some embodiments, access is adjusted based on charges received from the initiator.

[0024] Figure 1 is a block diagram of a service management and orchestrator (SMO) 100 according to one embodiment.

[0025] Details of SMO100 will not be discussed in detail for brevity. SMO100 includes a non-real-time RAN intelligent controller (non-RT RIC) 110. The non-RT RIC 110 facilitates control of components within the O-RAN network and the resources of those components. SMO100 further includes several rApps 120. An rApp 120 is a software application that runs using the resources of the O-RAN network. The rApps 120 communicate with other modules of SMO100 via an R1 interface 130. The R1 interface 130 provides the rApps 120 with access to O-RAN for query or trigger operations via SMO100. SMO100 further includes a topology and inventory (TE&IV) management module 140. The TE&IV management module 140 contains information related to the O-RAN topology and the inventory of components within O-RAN. The topology includes information relating to the location of components, control of components by other components, control of other components by other components, connections between components, and / or other interrelationships between components in the O-RAN. The inventory includes information relating to the functionality of components within the O-RAN. Those skilled in the art will recognize that SMO100 includes additional modules and functionalities. For brevity, these modules and functionalities will not be discussed in detail here.

[0026] In one embodiment, one or more of the rApp120s are generated by a third party that does not control the O-RAN. In another embodiment, one or more of the rApp120s are generated by the O-RAN vendor or operator. The rApp120s are installed on a non-RT RIC110 to run using the components of the O-RAN. During operation, the rApp120s submit queries to the TE&IV management module 140 via the R1 interface 130 to obtain information related to the O-RAN topology and inventory so that the rApp120s can perform their functions. The queries help ensure that the rApp120s are able to operate properly using the components of the O-RAN. In response to the queries, the TE&IV management module 140 provides data to the rApp120s via the R1 interface 130. The data includes information about the O-RAN, which enables the rApp120s to generate a map of the O-RAN and submit commands to one or more components of the O-RAN to perform the functions of the rApp120s.

[0027] In one embodiment, the network operator also submits queries to the TE&IV management module 140. In one embodiment, the network operator submits queries that help determine the health of the O-RAN. In one embodiment, the network operator submits queries to determine the capabilities of the O-RAN. In one embodiment, the network operator submits queries to change the topology of the O-RAN, for example, by changing the connectivity between components, adding components, removing components, or other appropriate actions. In one embodiment, certain operations that change the topology of the O-RAN can only be performed by the network operator; that is, rApp 120 is prohibited from changing the O-RAN.

[0028] The query syntax is generic to enhance its usability across a wide range of networks owned and operated by different entities. By providing a generic syntax, rApp120 developers can save time and money by avoiding customization for various network-specific requirements.

[0029] The TE&IV management module 140 includes service operations, procedures, and information and data models, such as create, read, update, and delete (CRUD) operations. In one embodiment, the TE&IV management module 140 includes services, operations, procedures, and information and data models for at least the following use cases: • Cell Information: This service allows you to perform CRUD operations on aggregated information related to O-RAN cells. • Network Function Information: This service operation enables CRUD operations on aggregated information related to network functions, such as O-CU-CP, O-CU-UP, and O-DU. • Sector Carrier Information: This service allows you to perform CRUD operations on aggregated information related to sector carriers. • Sector device information: This service operation allows aggregated information related to sector devices, such as O-RUs, to be CRUD'd. • Sector Site Information: This service allows you to perform CRUD operations on aggregated information related to sector sites. • O-Cloud Infrastructure Inventory Information: This service allows for CRUD operations on aggregated information related to the O-Cloud infrastructure, such as O-Cloud sites, O-Cloud nodes and node clusters, servers, hardware accelerators, and storage. • O-Cloud Deployment Inventory Information: This service allows you to perform CRUD operations on aggregated information related to O-Cloud NF deployments. • Site location information: This service enables CRUD operations on aggregated information related to sectors and O-Cloud sites. • Topology Information: This service allows aggregated information related to the network topology to be CRUD-enabled.

[0030] The TE&IV management module 140 can perform CRUD operations to obtain data usable by rApp and other SMO internal and external functions 120. The topology and information model and class hierarchy of inventory CRUD operations are discussed below with reference to Figures 4 and 5, which can be implemented using SMO 100 in some embodiments.

[0031] The following sections provide a more detailed explanation of the information model and class hierarchy shown in Figures 4 and 5. NetworkFunction includes 0 to a large number of GNBDUFunction, GNBCUCPFunction, GNBCUUPFunction, or NearRTRICFunction representing inventory information for O-DU, O-CU-CP, O-CU-UP, and Near-RT RIC. The model fragment is the same as the NR NRM model defined in 3GPP TS 28.541 and can be used for the management representation of gNB and en-gNB for at least the NG-RAN deployment scenarios listed below. - The non-split NG-RAN deployment scenario represents the gNB as defined in TS 38.401. In this scenario, the gNB is represented by a combination of GNBCUCPFunction, one or more GNBCUUPFunctions, and one or more GNBDUFunctions. - The two-part NG-RAN deployment scenario represents gNB and includes gNB-CU and gNB-DU as defined in Section 6.1.1 of TS 38.401. In this scenario, gNB-CU is represented by a combination of GNBCUCPFunction and one or more GNBCUUPFunctions, while gNB-DU is represented by GNBDUFunction. - The 3-part NG-RAN deployment scenario represents gNB and includes gNB-CU-CP, gNB-CU-UP, and gNB-DU as defined in Section 6.1.2 of TS 38.401. In this scenario, gNB-CU-CP is represented by GNBCUCPFunction, gNB-CU-UP is represented by GNBCUUPFunction, and gNB-DU is represented by GNBDUFunction. GNBDUFunction includes the following: - A range of 0 to a number of NRCellDUs representing inventory information about an NR cell. - A SectorCarrier variable ranging from 0 to a large number, representing inventory information about sector carriers. The GNBDU function connects to a number of SectorEquipmentFunctions, ranging from 0 to many, that represent inventory information about the O-RU, and to the Open Fronthaul (O-FH) connection between the O-DU and the O-RU. Similar to the NR NRM model defined in 3GPP TS 28.541, an NRCellDU from 0 to 1 is mapped to a number of SectorCarriers, i.e., transmitted, which in turn is mapped to a SectorEquipmentFunction from 0 to 1, i.e., managed by it. • Numerous SectorEquipmentFunctions, starting from 0, are located in SectorSite, which represents inventory information about a sector, cell, or antenna site. The GNBCU function contains 0 to a large number of NRCellCUs, which represent a portion of the NR cell inventory information related to mobility and neighbor cell relationships. A Network Function connected to 0 to a number of other Network Functions, representing connections between RAN functions via interfaces such as F1, X2, Xn, E1, or E2 interfaces. A NodeCluster, which represents the inventory information of an O-Cloud node cluster, contains 0 to a large number of Nodes, each representing the inventory information of an O-Cloud node. • An OCloudSite contains 0 to a large number of ResourcePools, representing an O-Cloud resource pool. A ResourcePool includes 0 to a large number of HWAcc, Compute, and Storage (hardware accelerators, compute servers, and storage) that represent O-Cloud resources. HWAcc, Compute, and Storage resources from one or more resource pools are "assigned" to Nodes within a NodeCluster located in the OCloudSite. Network Functions are deployed on Node Clusters. SectorSite and OCloudSite are "located in" (located) in SiteLocation, which represents the site's location information. The inventory information for each RAN element in Figure 4 is encapsulated in a ResourceProperty inherited from the base class Resource. Topological information describing the relationships between O-RAN elements, such as contains, mapto, locatedin, and deployon (as shown in Figure 4), is encapsulated in ResourceRelationship, which is inherited from the base class Resource. The relation "mapto" can incorporate multiple relations, such as managedby, allocatedto, and transmittedover.

[0032] Table 700 in Figure 7 contains a non-restrictive list of service operations and HTTP methods supported by each modeled TE&IV resource class (in Figure 4), identified by its resource URI - / resource / {resourceName} / {resourceId}, where resourceName is the same as the resource class name shown in Figure 4, and resourceId is the identity for identifying a specific resource object instance that embodies the resource class. The URI structure, parameters, and message body supported by each HTTP method supporting the enumerated service operations, GET, PUT, POST, PATCH, and DELETE, are described in detail. Those skilled in the art will understand that different HTTP methods are within the scope of this specification.

[0033] Retrieve a resource (GET)

[0034] syntax GET / resource / {resourceName} / {resourceId}?fields=...&{depth}&{expand}&{relationships}

[0035] resourceName: Specifies the name of a component such as NetworkFunction, NRDUCell, or SectorEquipment.

[0036] resourceId: Specifies the identification number of the component.

[0037] fields: Specifies the properties of the component to include in the retrieved information. In some embodiments, all properties of the component are returned by default. In some embodiments, if one or more fields are specified, only the enumerated fields are returned.

[0038] depth: Specifies the number of hops allowed for searching from the initial O-RAN resource to other components of O-RAN. Increasing the depth beyond 0 allows queries to include additional related components. A depth value of 0 indicates that only information related to the initial resource is retrieved. A depth value of 1 includes components directly connected to the initial resource. Higher depth values ​​allow queries to retrieve information from components with more distant connections to the initial O-RAN resource. Further details of the depth parameter are discussed below with reference to Figure 6.

[0039] expand: Specifies which relationships to expand when including O-RAN components. The expansion parameter specifies whether to include details of the retrieved related components. In some embodiments, related components are included by default. In some embodiments, only retrieved components are included by default.

[0040] relationships: Specifies the type of relationship between components. The relationship parameter specifies which relationships to retrieve with the components. In some embodiments, all relationships are retrieved by default. In some embodiments, the relationship parameter is modified to include incoming and outgoing relationships. In some embodiments, the relationship parameter can be used to filter the relationships included by the type of related component.

[0041] In one embodiment, the relationship modification format includes the following: relationships = <relationshiptype> <direction>

[0042] The following format can be used to include all incoming connections: relationships=*.in

[0043] The following format can be used to include both incoming and outgoing call information. relationships=*.both

[0044] The following formats can be used to target specific relationships. relationships=containedin.in,locatedin.out

[0045] Command example 2: Create a resource (POST)

[0046] syntax POST / resource / {resourceName}(ResourceObject)

[0047] ResourceObject: Represents a component included in the message body that should be added to the O-RAN topology and inventory.

[0048] Command example 3: Update a resource (PUT)

[0049] syntax PUT / resource / {resourceName} / {resourceId}(ResourceObject)

[0050] ResourceObject: Represents a component included in the message body that should be updated.

[0051] Command example 4: Patch resources (PATCH)

[0052] syntax PATCH / resource / {resourceName} / {resourceId}(ResourceObject)

[0053] ResourceObject: Represents a component included in the message body that should be patched.

[0054] Command example 5: Delete a resource (DELETE)

[0055] syntax DELETE / resource / {resourceName} / {resourceId}

[0056] Resource name: Represents the component included in the message body that should be removed from the O-RAN topology and inventory.

[0057] Although the above description specifically refers to rApp120 and R1 interface 130, these are used only as examples for the purposes of this specification. Those skilled in the art will understand that this specification is not limited to the use of rApp120 and R1 interface 130. Furthermore, the above commands are merely examples to aid in understanding the functionality of this specification. Those skilled in the art will recognize that additional commands, such as the additional commands mentioned in Table 700 (Figure 7), are within the scope of this specification.

[0058] Figure 2 is a schematic diagram of a wireless network component 200 according to one embodiment. The wireless network component 200 includes a regional data center (DC) 210 and an edge DC 220. The regional DC 210 communicates with and controls the operation of an open central unit (O-CU) 230. The edge DC 220 communicates with and controls the operation of an open distributed unit (O-DU) 240. The O-CU 230 also controls some operation of the O-DU 240. The O-DU 240 then controls the operation of an open radio unit (O-RU) 250. The wireless network component 200 includes a plurality of O-DUs 240 and a plurality of O-RUs 250. The O-RUs 250 are located at base stations at site locations 260. Each site location 260 has a corresponding coverage area 265. User Equipment (UE) 270 within coverage area 265 can connect to O-RU 250 at site location 260. Through O-RU 250, UE 270 can exchange information with other components of the wireless network component 200.

[0059] In one embodiment, SMO100 (Figure 1) includes rApp120 which attempts to collect information from wireless network components such as wireless network component 200. In one embodiment, in response to a query from rApp120, the TE&IV management module 140 retrieves information from wireless network component 200 such as the geographical location of site location 260, the number of UE270 connected to O-RU250 within a specified time interval, the processing capacity of at least one of regional DC210 or edge DC220, or other appropriate information. Using SMO100 in conjunction with wireless network component 200 helps rApp120 developers collect additional information to enhance rApp120 and provide a better experience for users such as UE270 operators. Furthermore, by utilizing a generic syntax for queries, SMO100 enables rApp120 developers to program rApp120 independently of the owner of wireless network component 200.

[0060] Figure 3 is a block diagram of an open radio access network (O-RAN) 300 according to one embodiment.

[0061] In Figure 3, the Service Management and Orchestration (SMO) framework 310 is an automated platform for open RAN radio resources. SMO 310 oversees the lifecycle management of network functions and O-Cloud. SMO 310 includes a non-real-time (non-RT) radio access network (RAN) intelligent controller (RIC) 311. SMO 310 further defines various SMO interfaces, such as the O1 315, O2 316, and A1 318 interfaces. In one embodiment, SMO 310 is similar to SMO 100 (Figure 1).

[0062] The A1 interface 318 enables communication between the non-RT RIC311 and the Near-RT RIC320, supporting policy management, data transfer, and ML management. The A1 interface 318 is further used for policy guidance. The SMO310 provides granular policy guidance, such as prompting user equipment to change frequencies, and other data enrichment to RAN functions via the A1 interface 318.

[0063] The O1 315 interface connects the SMO310 to RAN managed elements, including the Near-RT RIC320, O-RAN Centralized Uni (O-CU)330, O-RAN Distributed Unit (O-DU)340, and Open Evolved NodeB (O-eNB)360. Management and orchestration functions are received by the managed elements via the O1 interface 315. The SMO310 then receives data from the managed elements via the O1 interface 315 for AI model training on the non-RT RIC311. The O1 interface 315 is further used to manage the operation and maintenance (OAM) of multi-vendor open RAN functions, including fault, configuration, accounting, performance, and security management, software management, and file management capabilities.

[0064] The O2 interface 316 can be used to support cloud infrastructure management and deployment operations using O-Cloud infrastructure that hosts open RAN functionality within the network. The O2 interface 316 supports orchestration of O-Cloud infrastructure resource management (e.g., inventory, monitoring, provisioning, software management, and lifecycle management) and deployment of open RAN network functionality, and provides logical services for managing the lifecycle of deployments that use cloud resources.

[0065] SMO310 provides a common data collection platform for managing RAN data and mediating for O1 315, O2 316, and A1 318 interfaces. Licensing, access control, and AI / ML lifecycle management are supported by SMO310, along with legacy northbound interfaces. SMO310 further supports existing OSS functions such as service orchestration, inventory, topology, and policy control.

[0066] The non-RT RIC311 enables non-real-time (>1 second) control of RAN elements and their resources via a cloud-native microservice-based application called rApp312. rApp312 implements a smart service analyzer 313, including a Key Performance Indicator (KPI) normalizer 314. The non-RT RIC311 communicates with an application called xApp322, running on the Near-RT RIC311, to provide policy-based guidance for edge control of RAN elements and their resources. The non-RT RIC311 provides non-real-time control and optimization of RAN elements and resources, AI / ML workflows including model training and updating of the KPI normalizer 314 in the smart service analyzer 313, and policy-based guidance for applications / functions within the Near-RT RIC320.

[0067] The Near-RT RIC320 controls the RAN infrastructure at the cloud edge. The Near-RT RIC320 controls RAN elements and their resources with optimization actions that typically take 10 milliseconds to 1 second to complete. The Near-RT RIC320 receives policy guidance from the non-RT RIC311 and provides policy feedback to the non-RT RIC311 via xApp322.

[0068] xApp322 is used to enhance the spectral efficiency of the RAN. The Near-RT RIC320 manages a distributed collection of “southbound” RAN functions and further provides “northbound” interfaces for operators, namely the O1 315 and A1 318 interfaces, to the non-RT RIC311 for RAN management and optimization. Thus, the Near-RT RIC320 can self-optimize across different RAN types such as macro, large-scale MIMO, and small cells, maximizing network resource utilization for 5G network scaling.

[0069] Within the Near-RT RIC320, xApp322 communicates via defined interface channels. The internal messaging infrastructure provides a framework for handling contention mitigation, subscription management, application lifecycle management, and security. Data transfer is performed via the E2 interface 324.

[0070] The O-RAN is divided into a Central Unit (CU) 330, a Distributed Unit (DU) 340, and a Radio Unit (RU) 350. The CU 330 is further divided into two logical components: one for the Control Plane (CP) 332 and the other for the User Plane (UP) 334. By logically dividing the CU 330 into CP 332 and UP 334, it becomes possible to deploy different functions in different locations on the network and on different hardware platforms. For example, the CU 330 and DU 340 can be virtualized on edge white-box servers, and the RU 350 can be implemented on Field Programmable Gate Array (FPGA) and Application-Specific Integrated Circuit (ASIC) boards and deployed near the RF antenna.

[0071] The O-RAN distributed unit (O-DU) 340 is an edge server that includes baseband processing and radio frequency (RF) functions. The O-DU 340 hosts the physical layer with Radio Link Control (RLC), MAC, and network function virtualization or containers. The O-DU 340 supports one or more cells and supports one or more beams to provide operational support to the O-RU 350 via the Control, User, and Synchronization (CUS) plane 352 and Management (M) plane 354 through the fronthaul interface.

[0072] The O-RU350 processes radio frequencies received by the network's physical layer. The processed radio frequencies are sent to the O-DU340 via fronthaul interfaces 352 and 354. The O-RU350 is designed to host lower PHY layer baseband processing and the RF Front End (RF FE), and to support multiple 3GPP partitioning options.

[0073] The Open-Evolved Node B (O-eNB) 360 provides a hardware configuration for the O-RAN. Management and orchestration functions are received by managed elements via the O1 interface 315. The SMO 310 then receives data from managed elements via the O1 interface 315 for the KPI normalizer 314 of the Smart Service Analyzer 313, which is implemented by rApp 312 in the non-RT RIC 311. The O-eNB 360 communicates with the Near-RT RIC 320 via the E2 interface 324. The E2 324 enables a near real-time loop through streaming of telemetry from the RAN and controlled feedback from the Near-RT RIC 320. The E2 interface 324 connects the Near-RT RIC 320 to E2 nodes such as the O-CU-CP 332, O-CU-UP 334, O-DU 340, and O-eNB 360. An E2 node is connected to one Near-RT RIC320, while a Near-RT RIC320 is connected to multiple E2 nodes. The protocol on the E2 interface 324 is based on the control plane and supports the services and functions of the Near-RT RIC320.

[0074] The F1 interface 336 connects the O-CU-CP332 and O-CU-UP334 to the O-DU340. Therefore, the F1 interface 336 is divided into a control plane subtype and a user plane subtype, which exchange data regarding frequency resource sharing and other network status. One O-CU330 can communicate with multiple O-DU340s via the F1 interface 336.

[0075] The E1 338 interface connects the O-CU-CP332 and the O-CU-UP334. The E1 interface 338 can be used to transfer configuration data and capacity information between the O-CU-CP332 and the O-CU-UP334. The configuration data ensures that the O-CU-CP332 and O-CU-UP334 are interoperable. Capacity information is sent from the O-CU-UP334 to the O-CU-CP332 and includes the status of the O-CU-UP334.

[0076] The O-DU340 communicates with the O-RU350 via the Open Fronthaul (FH) control, user, and synchronization (CUS) plane interface 352 and the Open Fronthaul (FH) M-plane (management plane) interface 354. As part of the CUS plane interface 352, the C-plane (control plane) is a frame format that carries data in real-time control messages between the O-DU340 and the O-RU350 for use in controlling user data scheduling, beamforming weight selection, neurology selection, etc. Control messages are sent separately for downlink (DL) related commands and uplink (UL) related commands.

[0077] The U-plane of the CUS plane interface 352 carries user data messages, such as in-phase and quadrature-phase (IQ) sample sequences of orthogonal frequency division multiplexing (OFDM) signals, between the O-DU340 and O-RU350. The S-plane of the CUS plane interface 352 contains synchronization messages used for timing synchronization between the O-DU340 and O-RU350. The control and user planes of the CUS plane interface 352 are further used to send information specifying beamforming weights from the O-DU340 to the O-RU350. Other information includes time resource and frequency resource information.

[0078] The open FH M plane 354 connects the O-RU350 to the O-DU340, and the optional open FH M plane 356 connects the O-RU350 to the SMO310. The O-DU340 uses the open FH M plane 354 to manage the O-RU350, while the SMO310 provides the O-RU350 with Fault, Configuration, Accounting, Performance, and Security (FCAPS) services. The open FH M plane 354 supports management functions including boot installation, software management, configuration management, performance management, fault management, and file management.

[0079] The open FH M-plane 354 can be used by the O-DU340 to acquire the capabilities of the O-RU350 and send the relevant configuration related to the C-plane and U-plane (data plane) of the open FH CUS interface 352 to the O-RU350. Together, the O1 315 interface and the open FH M-plane 354 interface provide the FCAPS interface with the exchange of configuration, reconfiguration, registration, security, performance, and monitoring modes with individual nodes such as the O-CU-CP332, O-CU-UP334, O-DU340, and O-RU350, as well as the non-RT RIC 320.

[0080] The infrastructure-COTS / whitebox / peripheral hardware and virtualization layer 370 connects to the infrastructure management framework 380 via the Network Function Virtualization Interface (NFVI) 372. The Virtualized Infrastructure Manager (VIM) 382 in the infrastructure management framework 380 controls and manages virtual network functions.

[0081] Figure 4 is a schematic diagram 400 of a topology and inventory information model that models the arrangement of components within an O-RAN according to one embodiment. This diagram includes numerous components of the O-RAN. For the sake of brevity, not all components are labeled or discussed in detail. The components included in Figure 400 are merely examples to aid in understanding this specification. Those skilled in the art will understand that different components are within the scope of this disclosure.

[0082] This figure includes multiple wireless network components 410 and multiple cloud computing components 420. Figure 400 includes relationship information between various components, such as contains, deployed, managed by, and connects. These relationships define the topology of the components in Figure 400. Furthermore, geographical relationships, such as located, provide information about the physical location of the components, as does site location 260 (Figure 2). In response to queries from rApps, such as rApp 120 (Figure 1), TE&IV management modules, such as TE&IV management module 140 (Figure 1), can provide information related to the relationships between O-RAN components, as well as information related to the capabilities or inventory of the O-RAN components. In one embodiment, topology and inventory information are stored in a database accessible by the TE&IV management module.

[0083] The following example of a response to a query is provided solely to aid in understanding this specification and does not limit the scope of this disclosure. In at least one example in which the TE&IV management module receives a query from rApp regarding the topology and inventory of wireless network components 410, the TE&IV management module returns information indicating the following relationships: GNBDUFunction440 is included in NetworkFunction430 at a depth of 1 from NetworkFunction430. NRCellDU450 is included in GNBDUFunction440 at a depth of 2 from NetworkFunction430. NRCellDU450 is mapped to and transmitted through SectorCarrier452, and SectorCarrier452 is included in GNBDUFunction440. SectorCarrier452 is mapped to and managed by SectorEquipmentFunction454, and SectorEquipmentFunction454 connects to GNBDUFunction440. SectorEquipmentFunction454 is located in SectorSite460, which is located in SiteLocation462. Based on the topology information above, the rApp can collect data on both how it performs its functionality and at what geographical location that functionality is performed using the wireless network component 410.

[0084] Similarly, in at least one example where the TE&IV management module receives queries from the rApp regarding the topology and inventory of the cloud computing component 420, the TE&IV management module returns information indicating the following relationships: NetworkFunction440 is deployed on NodeCluster470, which is 1 depth from NetworkFunction440. NodeCluster470 is located at OCloudSite472, which is 2 depths from NetworkFunction440. ResourcePool474 is contained within OCloudSite472, which is located at SiteLocation462. The topology information above allows the rApp to collect data on both how it runs its functionality and the geographical locations where that functionality runs using the cloud computing component 420.

[0085] As shown in Figure 400, the geographical location of at least one of the wireless network component 410 and the cloud computing component 420 is the same location, i.e., site location 462. For example, as described above with respect to SMO100 (Figure 1), by utilizing the query functionality of this application, rApp developers can use a common query to collect information about the entire O-RAN in Figure 400. In comparison, other methods force rApp developers to consider different queries to collect information related to the wireless network component 410 and the cloud computing component 420. Therefore, the query functionality of this specification provides rApp developers seeking to utilize O-RAN with improved efficiency and reduced complexity.

[0086] The above explanation concerns obtaining topology information related to O-RAN. However, query functionality can also determine the inventory or capabilities of O-RAN components. An explanation of obtaining both topology and inventory is provided below with reference to Figure 5.

[0087] Figure 5 is a schematic diagram 500 of the base class Resource for a specific resource class in Figure 4. In one embodiment, Figure 500 is applicable to each component of Figure 400 (Figure 4). In one embodiment, Figure 500 provides an example of data returned to an rApp, for example, rApp120 (Figure 1), by a TE&IV management module, for example, TE&IV management module 140 (Figure 1), in response to topology and inventory queries.

[0088] Figure 500 includes Resource 510. Resource 510 includes both ResourceProperty 520 and ResourceRelationship 530. ResourceRelationship 530 describes how Resource 510 relates to other components of O-RAN. That is, similar to the above description of Figure 400 (Figure 4), ResourceRelationship 530 provides topology information for responding to queries from rApp or other SMO internal and external functions. ResourceProperty 520 provides information related to the capabilities of Resource 510, enabling rApp to determine what instructions Resource 510 is capable of executing. These capabilities are inventory information. Using both topology and inventory information, rApp can determine how to collect data, execute functions, process data, route instructions through O-RAN, or other activities for rApp and other SMO internal and external functions to operate on O-RAN.

[0089] Figure 600 is a topology data of components at different depths within O-RAN according to one embodiment. Figure 600 includes a first node 640 located at a first level 610 of the network. The first node 640 is topologically at the top of the network, similar to NetworkFunction 430 (Figure 4). A query returning information related to the first node 640 indicates that the first node 640 is located at a depth of 0. That is, there are no hops in the network to collect information from the first node 640. Figure 600 further includes a number of second nodes 650 located at a second level 620 of the network. Each second node 650 is 1 hop away from the first node 640. As a result, each of the second nodes 650 is at a depth of 1 in the network. Figure 600 further includes a number of third nodes 660 located at a third level 630 of the network. Each of the third nodes 660 is 2 hops away from the first node 640. As a result, the third node, 660, is at a depth of 2 in the network.

[0090] Figure 600 provides usable information regarding the query functionality described above for SMO100 (Figure 1). Utilizing depth information to determine the scope of queries helps minimize the impact on network operation while responding to queries and reduces the risk of third parties obtaining excessive or confidential information about the network. In one embodiment, the rApp is limited to a maximum depth of query information. Limiting the rApp to a maximum depth controls the processing load on the network to respond to queries from the rApp. In one embodiment, the maximum depth allowed for the rApp is based on the identity of the rApp owner, the subscription fee paid to the network by the rApp, the network's processing capacity, or other appropriate criteria. For example, a network operator using the rApp is allowed to query deeper into the network than the third-party owner of the rApp. In a further example, in one embodiment, the maximum depth to which the rApp can query the network is reduced when there is a high processing load on the network. By controlling the depth within the network that the rApp can query, network operators can adjust the processing load on the network and maintain the confidentiality associated with the network.

[0091] Figures 7 and 7C are Table 700 of sample service operations and HTTP methods supported by each TE&IV resource class modeled in Figure 4 for retrieving and updating topology and inventory data for O-RAN components, according to one embodiment. While Table 700 includes sample operations, those skilled in the art will understand that different operations are within the scope of this disclosure. In one embodiment, the service operations from Table 700 are utilized in SMO 100 (Figure 1) to provide topology and inventory information to rApp 120 (Figure 1) or other internal and external SMO functions. In one embodiment, each operation in Table 700 can be utilized by any rApp or other SMO internal and external functions or TE&IV service consumers. In one embodiment, at least a portion of the operations in Table 700 are restricted based on, for example, the identity of the rApp owner. For example, in one embodiment, only a network operator can execute the options from Table 700 to create, delete, or update network components. In one embodiment, an rApp owned by a third party is limited to read-based queries.

[0092] By using queries such as those in Table 700, rApps can gather network information in order to route instructions for executing their functionality. Restricting the availability of some of the queries in Table 700 based on the rApp owner's identity helps to manage the processing load on the network and reduces the risk of disclosing sensitive network information.

[0093] Figure 8 is a flowchart of a method 800 for collecting topology and inventory data from O-RAN according to one embodiment. In one embodiment, method 800 is performed by SMO100 (Figure 1). In another embodiment, method 800 is performed by network components other than SMO100 (Figure 1).

[0094] In operation 805, queries are received via an interface. In one embodiment, queries are received from an rApp, for example, rApp120 (Figure 1), via the R1 interface, for example, R1 interface 130 (Figure 1). In one embodiment, queries are received from a network operator via the R1 interface. In one embodiment, queries are received by a network operator via an interface other than the R1 interface. In one embodiment, queries include the queries described above with respect to SMO100 (Figure 1).

[0095] In operation 810, the content of the query is determined. In some embodiments, the content of the query includes information relating to the type of action the query is performing, e.g., read, update, delete, create, or other appropriate action. In some embodiments, the content of the query includes information relating to the depth in the network from which the query is seeking information. In some embodiments, the content of the query includes information relating to the number of resources or components from which the query is seeking information. In some embodiments, the query further includes identification information of the source of the query, e.g., the owner of the rApp, a network operator, or other appropriate identification information. In some embodiments, the content of the query is determined based on the parsing of the syntax described above with respect to SMO100 (Figure 1).

[0096] Operation 815 determines whether the query is permitted. This determination is based on the content of the query. In one embodiment, the determination is based on a combination of the query content and the identification information associated with the query. In another embodiment, the determination is based on a combination of the query content and the current processing load on the network. In yet another embodiment, the determination is based on the fee that rApp will pay to query the network.

[0097] In one embodiment, a query is not permitted in response to a third-party-owned rApp requesting information greater than a threshold depth on the network. In one embodiment, the threshold depth is determined based on the third party's identification information. In one embodiment, the threshold depth is determined based on the fees paid by the third party. In one embodiment, the threshold depth is determined based on the current processing load on the network. For example, a first depth is permitted when the processing load on the network is low, and a second depth smaller than the first depth is permitted when the processing load on the network is high. In one embodiment, the network operator is permitted to query to any depth. By adjusting the query depth to suit different circumstances, Method 800 provides flexibility to adjust the processing load on the network and reduce the risk of sensitive network information being collected by the rApp, while simultaneously providing the rApp with enough data to implement its functionality.

[0098] In one embodiment, queries are not permitted in response to queries from third parties that contain content for changing the network topology. Changes to the network topology are carried out by the content of the query, which includes instructions to delete, update, or post resources or components within the network. In one embodiment, only queries that attempt to change the network topology and are from the network operator are permitted. By restricting the ability of third parties to change the network topology, Method 800 helps reduce the risk of accidental damage to the network.

[0099] In response to a determination that the query is permitted, method 800 proceeds to operation 825. In response to a determination that the query is not permitted, method 800 proceeds to operation 820.

[0100] In operation 820, a query rejection is output. In one embodiment, the rejection is sent to the rApp. In one embodiment, the rejection is stored in the rApp's log data. In one embodiment, the rejection includes the reason why the query was not permitted. For example, in one embodiment, the reason includes information indicating that the query attempted to access a portion of the network that was unavailable to the rApp. In one embodiment, in response to the same rApp receiving multiple rejections within a threshold time period, all queries from the rApp are denied. In one embodiment, action by the network operator is required to permit future queries from an rApp that has received multiple rejections within a threshold time period. In one embodiment, permission to submit permitted queries is granted to the rApp after the expiration of an exclusion time period.

[0101] In one embodiment, the denial is sent to the network operator as an alert of a potential unauthorized access attempt to the network. In one embodiment, the alert includes an audible or visual alert. In one embodiment, the alert is sent to a terminal accessible by the network operator. In one embodiment, the alert includes a command to automatically display the alert on the terminal.

[0102] In operation 825, the TE&IV management module is accessed to attempt to fulfill the query. In one embodiment, the TE&IV management module is TE&IV management module 140 (Figure 1). The TE&IV management module accesses a database containing topology and inventory information about the network in order to respond to the query received in operation 805.

[0103] Operation 830 determines whether the information requested by the query is available. To make this determination, the TE&IV management module accesses the database to attempt to execute the query. In response to a determination that the query was successfully executed, it is determined that the information is available. In response to a determination that the query was not successfully executed, it is determined that the information is unavailable.

[0104] In response to a determination that the queried data is available, method 800 proceeds to operation 840. In response to a determination that the queried data is not available, method 800 proceeds to operation 835.

[0105] In operation 835, a notification is output indicating that the query failed. In one embodiment, the notification is sent to rApp. In another embodiment, the notification is stored in the rApp's log data.

[0106] In one embodiment, the notification is sent to the network operator as an alert of a potential unauthorized access attempt to the network. In one embodiment, the alert includes an audible or visual alert. In one embodiment, the alert is sent to a terminal accessible by the network operator. In one embodiment, the alert includes a command to automatically display the alert on the terminal. By sending a notification to the network operator, the network operator can determine whether the requested information should have been available in order to efficiently and effectively diagnose potential problems in the network.

[0107] In operation 840, data is retrieved to satisfy the query. The data is retrieved by the TE&IV management module by accessing the database.

[0108] In operation 845, the acquired data is output via the interface. In one embodiment, the acquired data is sent to rApp via the R1 interface. In another embodiment, successful reception of the acquired data is recorded in the rApp's log data.

[0109] Those skilled in the art will recognize that modifications to Method 800 are within the scope of this disclosure. In some embodiments, at least one of the operations of Method 800 is omitted. For example, in some embodiments, operation 820 is omitted, and unauthorized queries are discarded without outputting any notice. In some embodiments, the order of the operations of Method 800 is adjusted. For example, in some embodiments, operations 825 and 830 are executed simultaneously. In some embodiments, at least one additional operation is included in Method 800. For example, in some embodiments, Method 800 includes an operation in which an SMO, e.g., SMO100 (Figure 1), stores a log of received queries and the results of processing the received queries.

[0110] Using Method 800 helps provide the rApp with relevant information to perform the rApp's functionality without placing an excessive burden on the network, and reduces the risk of providing network-related sensitive information. In one embodiment using SMO100 (Figure 1), Method 800 provides the rApp with the ability to obtain network information in a general way to reduce the burden on the rApp developer to customize the rApp for use across multiple networks.

[0111] Figure 9 is a schematic diagram of a system 900 for collecting topology and inventory information according to one embodiment. The system 900 includes a hardware processor 902 and a non-temporary computer-readable storage medium 904 that stores computer program code 906, i.e., a set of executable instructions. The computer-readable storage medium 904 is also encoded with instructions 907 for interfacing with external devices. The processor 902 is electrically coupled to the computer-readable storage medium 904 via a bus 908. The processor 902 is also electrically coupled to an input / output (I / O) interface 910 via the bus 908. A network interface 912 is also electrically connected to the processor 902 via the bus 908. The network interface 912 is connected to a network 914 so that the processor 902 and the computer-readable storage medium 904 can connect to external elements via the network 914. The processor 902 is configured to execute computer program code 906 encoded in a computer-readable storage medium 904 in order to make the system 900 available to perform some or all of the operations described in SMO100 (Figure 1), O-RAN300 (Figure 3), or Method 800 (Figure 8).

[0112] In one embodiment, the processor 902 is a central processing unit (CPU), a multiprocessor, a distributed processing system, an application-specific integrated circuit (ASIC), and / or a suitable processing unit.

[0113] In some embodiments, the computer-readable storage medium 904 is an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system (or apparatus or device). For example, the computer-readable storage medium 904 includes semiconductors or solid-state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), rigid magnetic disks, and / or optical disks. In some embodiments using optical disks, the computer-readable storage medium 904 includes compact disk-read-only memory (CD-ROM), compact disk-read / write (CD-R / W), and / or digital video discs (DVD).

[0114] In one embodiment, the storage medium 904 stores computer program code 906 configured to cause the system 900 to perform part or all of the operations described in SMO100 (Figure 1), O-RAN300 (Figure 3), or Method 800 (Figure 8). In another embodiment, the storage medium 904 also stores information for performing part or all of the operations described in SMO100 (Figure 1), O-RAN300 (Figure 3), or Method 800 (Figure 8), as well as information generated during the execution of part or all of the operations described in SMO100 (Figure 1), O-RAN300 (Figure 3), or Method 800 (Figure 8), such as query parameters 916, authentication parameters 918, inventory parameters 920, topology parameters 922, and / or a set of executable instructions for performing part or all of the operations described in SMO100 (Figure 1), O-RAN300 (Figure 3), or Method 800 (Figure 8).

[0115] In one embodiment, the storage medium 904 stores instructions 907 for interfacing with an external device. The instructions 907 enable the processor 902 to generate instructions readable by the external device in order to effectively perform part or all of the operations described in SMO100 (Figure 1), O-RAN300 (Figure 3), or Method 800 (Figure 8).

[0116] The system 900 includes an I / O interface 910. The I / O interface 910 is coupled to external circuitry. In one embodiment, the I / O interface 910 includes a keyboard, keypad, mouse, trackball, trackpad, and / or cursor directional keys for communicating information and commands to the processor 902.

[0117] System 900 also includes a network interface 912 coupled to processor 902. The network interface 912 enables System 900 to communicate with a network 914 to which one or more other computer systems are connected. The network interface 912 includes wireless network interfaces such as BLUETOOTH®, WIFI, WiMAX, GPRS, or WCDMA®, or wired network interfaces such as ETHERNET, USB, or IEEE-1394. In some embodiments, some or all of the operations described in SMO100 (Figure 1), O-RAN300 (Figure 3), or Method 800 (Figure 8) are implemented in two or more systems 900, and information such as queries, authentication, inventory, or topology is exchanged between different systems 900 via the network 914.

[0118] Note 1 A method for collecting, creating, or updating topology and inventory data for a network includes receiving a request via a Service Management and Orchestrator (SMO) interface, the request including instructions for topology and inventory information to be collected, created, or updated. The method further includes forwarding the request to a Topology and Inventory (TE&IV) management module. The method further includes collecting, creating, or updating topology and inventory data for at least a first component of the network based on the request. The topology and inventory data includes relationship information between the first component and at least a second component of the network, and capability information for the first component.

[0119] Note 2

[0120] The method described in Appendix 1, wherein the interface is the R1 Service Application Programming Interface (API) or the SMO TE&IV Service API.

[0121] Note 3

[0122] The method according to Appendix 1 or 2, further comprising collecting topology and inventory data based on an information model of the network for a third component of the network, wherein the first component is part of a wireless network within the network and the third component is part of a cloud computing network within the network.

[0123] Note 4

[0124] The method according to any of the appendices 1 to 3, further comprising limiting the depth of collection of topology and inventory data within the network topology based on at least one of the source identity or search depth parameters in the query.

[0125] Note 5

[0126] The method according to any of the appendices 1 to 4, wherein the request includes identification information about the first component.

[0127] Note 6

[0128] A method according to any of the appendices 1 to 5, wherein the request specifies the type of relationship to be searched in the layer below the first component in the network topology.

[0129] Appendix 7

[0130] The method according to any of the appendices 1 to 6, wherein the request includes a depth parameter that limits the number of layers in the network topology below the first component that should be included to respond to the query.

[0131] Note 8 A non-temporary computer-readable medium configured to store instructions for a system to perform a method including receiving requests via a Service Management and Orchestrator (SMO) interface, wherein the requests include instructions for topology and inventory information to be collected, created, or updated. The method further includes forwarding the requests to a topology and inventory (TE&IV) management module. The method further includes collecting, creating, or updating topology and inventory data for at least a first component of a network based on the requests. The topology and inventory data includes relationship information between the first component and at least a second component of the network, and capability information for the first component.

[0132] Note 9 A non-temporary computer-readable medium as described in Appendix 8, wherein the interface is the R1 Service Application Programming Interface (API) or the SMO TE&IV Service API.

[0133] Note 10

[0134] The instructions are further configured to cause the system to collect topology and inventory data based on an information model of the network for a third component of the network, wherein the first component is part of a wireless network within the network and the third component is part of a cloud computing network within the network, as described in Appendix 8 or 9.

[0135] Note 11

[0136] A non-temporary computer-readable medium as described in any of Annexes 8 to 10, wherein the instructions are further configured to cause the system to limit the depth of collection of topology and inventory data in the network topology based on at least one of the source identity or search depth parameters in the query.

[0137] Note 12

[0138] A non-temporary computer-readable medium as described in any of Annexes 8 to 11, wherein the request includes identification information about the first component.

[0139] Note 13

[0140] A non-temporary computer-readable medium as described in any of appendices 8 to 12, in which the request specifies the type of relationship to be searched in the layer below the first component in the network topology.

[0141] Note 14

[0142] A non-temporary computer-readable medium as described in any of Appendix 8 to 13, in which the request includes a depth parameter that limits the number of layers in the network topology below the first component that should be included to respond to the query.

[0143] Note 15 A system for collecting, creating, or updating topology and inventory data for a network includes a Service Management and Orchestrator (SMO). The SMO is configured to receive requests via an interface, which include topology and inventory information to be collected, created, or updated. The SMO is further configured to forward requests to a Topology and Inventory (TE&IV) management module. The SMO is further configured to collect, create, or update topology and inventory data for at least a first component of the network based on queries. The topology and inventory data includes relationship information between the first component and at least a second component of the network, and capability information about the first component. The SMO is further configured to output the collected topology and inventory data via the interface.

[0144] Note 16

[0145] The system described in Appendix 15, wherein the interface is the R1 Service Application Programming Interface (API) or the SMO TE&IV Service API.

[0146] Note 17

[0147] The system as described in Appendix 15 or 16, wherein the SMO is further configured to collect, create, or update topology and inventory data for a third component of the network, and the first component is part of a wireless network within the network, and the third component is part of a cloud computing network within the network.

[0148] Note 18

[0149] The system described in any of Appendix 15-17, wherein the SMO is further configured to limit the depth of the collection of topology and inventory data within the network topology based on at least one of the query source identity or depth parameters.

[0150] Note 19

[0151] A system as described in any of Annexes 15 to 18, wherein the requirement includes identification information about the first component.

[0152] Note 20

[0153] A system as described in any of appendices 15 to 19, wherein the request specifies the type of relation to be searched in a layer below the first component.

[0154] Note 21

[0155] A method for modeling the placement of O-RAN components within an O-RAN network, the relationship information between each O-RAN component in the network, and the capability information of each O-RAN component includes a base TE&IV resource class that includes a first property for storing inventory data of an O-RAN component and a second property for storing relationship information of the O-RAN component to at least another O-RAN component. The method further includes at least one concrete class that inherits two properties from the base class, the realized object instances of this concrete class for storing actual inventory and topology data of the modeled O-RAN component. The method further includes inventory data corresponding to the capability of the modeled O-RAN component, stored in the first property, and topology data corresponding to the relationship of the modeled O-RAN component to at least another modeled O-RAN component, stored in the second property.

[0156] Note 22

[0157] The method according to Appendix 21, wherein the modeled O-RAN component includes at least one of GNBCUCPFunction, GNBDUFunction, or OCloudNode.

[0158] Note 23

[0159] A system for modeling the placement of O-RAN components within an O-RAN network, the relationship information between each O-RAN component in the network, and the capability information of each O-RAN component includes a base TE&IV resource class that includes a first property for storing inventory data of an O-RAN component and a second property for storing relationship information of the O-RAN component to at least another O-RAN component. The system further includes at least one concrete class for inheriting two properties from the base class, and an realized object instance of this concrete class is configured to store actual inventory and topology data of the modeled O-RAN component. The system further includes inventory data corresponding to the capability of the modeled O-RAN component, stored in the first property, and topology data corresponding to the relationship of the modeled O-RAN component to at least another modeled O-RAN component, stored in the second property.

[0160] Note 24

[0161] The system described in Appendix 23, wherein the modeled O-RAN component includes at least one of GNBCUCPFunction, GNBDUFunction, or OCloudNode.

[0162] The above outlines the features of certain embodiments so that those skilled in the art may better understand aspects of the present disclosure. Those skilled in the art will understand that the present disclosure may readily be used as a basis for designing or modifying other processes and structures to perform the same purposes and / or achieve the same advantages as the embodiments described herein. Those skilled in the art should also recognize that such equivalent configurations will not depart from the spirit and scope of the present disclosure, and that various changes, substitutions, and modifications may be made herein without departing from the spirit and scope of the present disclosure.< / direction> < / relationshiptype>

Claims

1. A method for collecting, creating, or updating topology and inventory data for a network, Receiving a request via a Service Management and Orchestrator (SMO) interface, wherein the request includes instructions regarding topology and inventory information to be collected, created, or updated. The aforementioned request is forwarded to the Topology and Inventory (TE&IV) management module, To collect, create, or update topology and inventory data for at least a first component of the network based on the above request, wherein the topology and inventory data Relationship information between the first component and at least the second component of the network, and Capability information for the first component described above Including collecting, creating, or updating, Outputting the collected topology and inventory data via the interface. Methods that include...

2. The method according to claim 1, wherein the interface is the R1 Service Application Programming Interface (API) or the SMO TE&IV Service API.

3. The method according to claim 1, further comprising collecting topology and inventory data based on an information model of the network for a third component of the network, wherein the first component is part of a wireless network within the network and the third component is part of a cloud computing network within the network.

4. The method according to claim 1, further comprising limiting the depth of collection of topology and inventory data in the network topology based on at least one of the source identity or search depth parameter in the query.

5. The method according to claim 1, wherein the requirement includes identification information for the first component.

6. The method according to claim 5, wherein the request specifies a type of relationship to be searched in a layer below the first component in the network topology.

7. The method according to claim 6, wherein the request includes a depth parameter that limits the number of layers in the network topology below the first component to be included in response to the query.

8. A non-temporary computer-readable medium configured to store instructions for causing a system to perform a method, wherein the method is Receiving a request via a Service Management and Orchestrator (SMO) interface, wherein the request includes instructions regarding topology and inventory information to be collected, created, or updated. The aforementioned request is forwarded to the Topology and Inventory (TE&IV) management module, To collect, create, or update topology and inventory data for at least a first component of the network based on the above request, wherein the topology and inventory data Relationship information between the first component and at least the second component of the network, and Capability information for the first component described above Including collecting, creating, or updating Non-temporary computer-readable media, including [specific examples of such media].

9. The non-temporary computer-readable medium according to claim 8, wherein the interface is the R1 Service Application Programming Interface (API) or the SMO TE&IV Service API.

10. The non-temporary computer-readable medium according to claim 8, wherein the instruction is further configured to cause the system to collect topology and inventory data based on an information model of the network for a third component of the network, the first component being part of a wireless network within the network, and the third component being part of a cloud computing network within the network.

11. The non-temporary computer-readable medium according to claim 8, wherein the instruction is further configured to cause the system to limit the depth of the collection of topology and inventory data in the network topology based on at least one of the source identity or search depth parameter in the query.

12. The non-temporary computer-readable medium according to claim 8, wherein the requirement includes identification information for the first component.

13. The non-temporary computer-readable medium according to claim 12, wherein the request specifies a type of relationship to be searched in a layer below the first component in the network topology.

14. The non-transient computer-readable medium according to claim 13, wherein the request includes a depth parameter that limits the number of layers in the network topology below the first component to be included in response to the query.

15. A system for collecting, creating, or updating topology and inventory data for a network, The system includes a Service Management and Orchestrator (SMO), and the SMO is: Receiving a request via an interface, wherein the request includes topology and inventory information to be collected, created, or updated. The aforementioned request is forwarded to the Topology and Inventory (TE&IV) management module, Collecting, creating, or updating topology and inventory data for at least a first component of the network based on the aforementioned query, wherein the topology and inventory data Relationship information between the first component and at least the second component of the network, and Capability information for the first component described above Including collecting, creating, or updating, Outputting the collected topology and inventory data via the interface. It is configured to do the following: system.

16. The system according to claim 15, wherein the interface is the R1 Service Application Programming Interface (API) or the SMO TE&IV Service API.

17. The system according to claim 15, wherein the SMO is further configured to collect, create, or update topology and inventory data for a third component of the network, the first component being part of a wireless network within the network, and the third component being part of a cloud computing network within the network.

18. The system according to claim 15, wherein the SMO is further configured to limit the depth of the collection of topology and inventory data in the network topology based on at least one of the source identity or depth parameters in the query.

19. The system according to claim 15, wherein the requirement includes identification information for the first component.

20. The system according to claim 19, wherein the request specifies a type of relation to be searched in a layer below the first component.

Images