O-cloud data transport

Abstract

Example embodiments of the present disclosure relate to O-Cloud data transport. According to example embodiments, a system may include a first network entity that may be configured to communicate with a second network entity. The second network entity may be capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity. The plurality of streaming methods may include: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming. Further, the first network entity may be configured to communicate with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.

Description

O-CLOUD DATA TRANSPORTCROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to the U.S. Provisional Patent Application No.63 / 777,967, filed with the U.S. Patent and Trademark Office on March 26, 2025, the entire contents of which are incorporated herein by reference.TECHNICAL FIELD

[0002] The present disclosure relates to Open Radio Access Network (0-RAN) Cloud (O-Cloud) data transport.BACKGROUND

[0003] The information disclosed in this background section is only for the enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgment or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] A radio access network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network entities or network elements (NEs) that connect endusers to a core network. Traditionally, hardware and / or software of a particular RAN is vendorspecific.

[0005] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors areinvolved, the type of hardware and / or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form, or could be in physical hardware form.SUMMARY

[0006] Example embodiments of the present disclosure provide systems, methods, and the like, that effectively and efficiently implement 0-RAN Cloud (O-Cloud) data transport.

[0007] According to example embodiments, a system may include a first network entity that may be configured to communicate with a second network entity. The second network entity may be capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity. The plurality of streaming methods may include: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming. Further, the first network entity may be configured to communicate with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.

[0008] According to example embodiments, a method may include: a first network entity communicating with a second network entity. The second network entity may be capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity. The plurality of streaming methods may include: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming. Further, the method may include: the first network entity communicating with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.

[0009] According to example embodiments, a non-transitory computer-readable recording medium may have recorded thereon instructions executable by a first network entity to cause the first network entity to perform a method that may include: communicating with a second network entity. The second network entity may be capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity. The plurality of streaming methods may include: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming. Further, the method may include: communicating with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.

[0010] According to example embodiments, a system may include a first network entity that may be configured to provide, to a second network entity, information associated with one or more data reporting methods supported by the first network entity. Further, the first network entity may be configured to receive, from the second network entity, information associated with a data reporting method selected from among the one or more data reporting methods supported by the first network entity. Furthermore, the first network entity may be configured to establish, based on the selected data reporting method, a streaming session with the second network entity. Subsequently, the first network entity may be configured to provide, to the second network entity during the streaming session, an 02 Infrastructure Management Service (02ims) service.

[0011] According to example embodiments, a system may include a first network entity that may be configured to receive, from a second network entity, information associated with one or more data reporting methods supported by the second network entity. Further, the first network entity may be configured to select, from among the one or more data reporting methods supported by the second network entity, a data reporting method. Furthermore, the first network entity maybe configured to provide, to the second network entity, information associated with the selected data reporting method. Subsequently, the first network entity may be configured to receive, from the second network entity and during a streaming session associated with the selected data reporting method, an 02ims service.

[0012] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0014] FIG. 1 illustrates an example configuration for a service-based interaction between network entities in an 0-RAN, according to one or more example embodiments;

[0015] FIG. 2 and FIG. 3 each illustrates an example configuration of an example use case, according to one or more example embodiments;

[0016] FIG. 4A to FIG. 6B each illustrates an example configuration for implementing a specific data transport protocol or framework, according to one or more example embodiments;

[0017] FIG. 7 to FIG. 12 each illustrates an example method, according to one or more example embodiments;

[0018] FIG. 13A to FIG. 14 each illustrates an example use case, according to one or more example embodiments;

[0019] FIG. 15 illustrates an example device / apparatus that may implement one or more example embodiments; and

[0020] FIG. 16 illustrates a diagram of an example environment in which systems, devices, and / or methods, according to one or more example embodiments, may be implemented.DETAILED DESCRIPTION

[0021] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, the flowchart and description of operations provided below relate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part).

[0022] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the described implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It isunderstood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0023] Even though particular combinations of features are disclosed in the claims and / or in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0024] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Also, as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B]”, “[A] and / or [B]”, or “at least one of [A] or [B]”, are to be understood as including only A, only B, or both A and B.

[0025] Expressions such as “at least one processor,” where configured to implement a plurality of operations, execute a plurality of instructions, etc., are to be understood as a single processor implementing the plurality of operations, etc., or each of plural processors implementing at least some (but not necessarily all) of the plurality of operations, etc.

[0026] Reference throughout this specification to “one embodiment,” “embodiment,” “non-limiting exemplary embodiment,” “example embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the indicatedembodiment is included in at least one embodiment of the present solution. Thus, the phrases “in one embodiment”, “in an embodiment,” “in one non-limiting exemplary embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0027] Further, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more example embodiments. One skilled in the relevant art will recognize, in light of the description herein, that the present disclosure can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0028] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the Open Radio Access Network (O-RAN) Alliance, the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, and the like. For instance, the terms “02,” “IMS,” “02-IMS,” “SMO,” “FOCOM,” “PM,” “FM,” “02-IMS Consumer,” “02-IMS Producer,” “02ims service,” “WebSocket,” “HTTP,” “message bus,” and the like, as well as the associated features, operations, interfaces, and messages involved therein, are to be interpreted as consistent with those specified in one or more technical specifications, unless described otherwise.

[0029] In a telecommunication network, data may be transported via various data reporting / streaming methods, each of which may involve different types of data transport protocols or frameworks (e.g., a message bus data transport framework like Kafka framework, a WebSocket data transport protocol, a Hypertext Transfer Protocol (HTTP) data transport protocol, a RemoteProcedure Call (RPC) data transport protocol, etc.), different types of serialization formats (e.g., Prometheus, Protocol Buffers (protobuf), JavaScript Object Notation (JSON), etc.), and different types of compression algorithms (e.g., / standard (zstd), GNU zip (gzip), etc.). Nevertheless, not all data reporting / streaming methods have been implemented in the Open Radio Access Network (O-RAN)-based networks, particularly, for transporting data associated with an O-RAN Cloud (O-Cloud) to provide an 02 Infrastructure Management Service (02ims) service.

[0030] Further, although there are multiple data reporting / streaming methods that may theoretically be implemented in the O-RAN-based networks, there is no defined or standardized system configurations, architectures, mechanisms, and operations for implementing or supporting multiple data transport protocols or frameworks for providing 02ims services or the associated data, while ensuring the functional and performance requirements of O-Cloud, the compatibility to existing industry implementations, and the interoperability among different parties (e.g., vendors, operators, etc.).

[0031] As further described below, example embodiments of the present disclosure provide various example embodiments for efficiently and effectively transporting O-Cloud data, thereby providing various technical advantages. Amongst others, example embodiments introduce and specify a service-based architecture that supports various types of data reporting / streaming methods for O-Cloud data transportation, as well as providing various example operations, use cases, and mechanisms associated therewith, thereby clarifying and exemplifying an O-RAN network that supports multiple data reporting / streaming methods for providing 02ims services or the associated data, while ensuring the functional and performance requirements of O-Cloud, the compatibility to existing industry implementations, and the interoperability among different parties (e.g., vendors, operators, etc.). Further, example embodiments of the present disclosurespecify and supplement several features, mechanisms, and use cases in at least one technical specification associated with the O-RAN Alliance (e.g., O-RAN WG6 specifications, such as O-RAN-WG6.0RCH-USE-CASES, etc.), thereby introducing clear, specified, and standardized architecture, mechanisms, and approaches for supporting multiple data reporting / streaming methods for transporting O-Cloud data (and thereby providing the associated 02ims service) in the O-RAN-based networks.

[0032] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of the features, components, configuration, operations, and implementations of the example embodiments of the present disclosure are provided in the following.Example System Architecture and Configurations

[0033] FIG. 1 illustrates an example configuration 100 for a service-based interaction between network entities in an Open Radio Access Network (O-RAN), according to one or more example embodiments. As illustrated in FIG. 1, the configuration 100 is constituted of at least two components, i.e., a first network entity or network element 110 that serves as an O2-Infrastructure Management Service (IMS) producer and a second network entity or network element 120 that serves as an 02-IMS consumer. In this regard, an 02-IMS is a set of services or capabilities for the management and orchestration of O-RAN Cloud (O-Cloud) infrastructure resources, such as services or capabilities associated with infrastructure inventory (e.g., O-Cloud information query, O-Cloud inventory event notification, etc.), infrastructure monitoring (e.g., resource-health metric monitoring, alarm-event subscription, etc.), infrastructure lifecycle management (e.g., service onboarding and de-commissioning, etc.), infrastructure software management (e.g.,software / firmware update, vulnerability patching, etc.), infrastructure performance (e.g., performance measurement (PM), PM reporting, etc.), and the like. The 02-IMS producer may produce or provide one or more of the 02-IMS services or capabilities, while the 02-IMS consumer may consume one or more of the 02-IMS services or capabilities.

[0034] Herein, the terms “network entity” and “network element” may be used interchangeably, unless described otherwise. For instance, the “first network entity” may also be referred to as the “first network element”, while the “second network entity” may also be referred to as the “second network element”. Further, although the “02-IMS producer” such as “IMS of O-Cloud” may be used as the example of the “first network entity” and the “02-IMS consumer” such as “FOCOM of SMO” may be used as the example of the “second network entity”, the scope and interpretation of the present disclosure do not limit thereto. For instance, in some example embodiments, the “first network entity” may refer to the “02-IMS consumer” such as “FOCOM of SMO” while the “second network entity” may refer to the “02-IMS producer” such as “IMS of O-Cloud”. Furthermore, the terms “02-IMS service” and “02ims service” may also be used interchangeably, unless described otherwise.

[0035] The first network entity 110 may refer to any suitable entity / element that implements one of the 02-IMS producer or the 02-IMS consumer, while the second network entity 120 may refer to any suitable entity / element that implements another one of the 02-IMS producer or the 02-IMS consumer. For descriptive purposes, it may be assumed that the first network entity 110 implements the 02-IMS producer and the second network entity 120 implements the 02-IMS consumer, unless described otherwise. In some example embodiments, the first network entity 110 may include an Infrastructure Management Service (IMS) of the O-Cloud, while the second network entity 120 may include a Federated O-Cloud Orchestration and Management (FOCOM)of a Service Management and Orchestration (SMO). In this regard, the first network entity 110 and / or the second network entity 120 may include a logical entity (e.g., a Network Function (NF), a Management Function (MnF), an SMO Function (SMOF), an SMO Service (SMOS), etc.) that plays the role of the 02-IMS producer and / or O2-ZMS consumer, a physical entity (e.g., a server, a device, etc.) that implements the operations of the 02-IMS producer and / or 02-IMS consumer, or a combination thereof. Thus, it can be understood that the “first network entity” and “second network entity” described herein may refer to the respective logical entity and / or the underlying hardware component.

[0036] According to example embodiments, the data communication between the first network entity 110 (e.g., O-Cloud IMS) and the second network entity 120 (e.g., SMO FOCOM) may be performed via one or more data reporting / streaming methods, such as a connection-based streaming, an event notification-based streaming, and / or an active collection-based streaming. The data reporting / streaming method(s) may be based on one or more data transport protocols or frameworks, such as a message bus data transport framework, a WebSocket data transport protocol, a Hypertext Transfer Protocol (HTTP) data transport protocol, a Remote Procedure Call (RPC) data transport protocol, and the like. Further descriptions of the implementations of the message bus data transport framework, the WebSocket data transport protocol, and the HTTP data transport protocol, are provided below with reference to FIG. 4A to FIG. 6B. It is contemplated that, although the example embodiments may use the above-mentioned data transport protocols or frameworks (e.g., WebSocket, HTTP, message bus, RPC, etc.) as the examples, the scope of the present disclosure are not limited thereto and any other suitable data transport protocols or frameworks (e.g., File Transfer Protocol (FTP), Prometheus, etc.) may be included.

[0037] According to example embodiments, the first network entity 110 (e.g., O-Cloud IMS) may support any of the data reporting / streaming methods, the data transport protocols, or the data transport frameworks, while the second network entity 120 (e.g., SMO FOCOM) may support all available data reporting / streaming methods, data transport protocols, and data transport frameworks. Alternatively, both the first network entity 110 and the second network entity 120 may support any of the data reporting / streaming methods, data transport protocols, or data transport frameworks, and the interoperability may be defined or decided according to the network operator and / or the associated vendor product order negotiation. Alternatively or additionally, both the first network entity 110 and the second network entity 120 may support a common fallback option (e.g., event notification-based streaming based on HTTP data transport protocol, etc.) to guarantee compatibility, while other options (e.g., other event notification-based streaming such as those based on message bus data transport framework / RPC data transport protocol, a connection-based streaming based on Web Socket data transport protocol, etc.) may be the potential choices for better performance in certain deployment or implementation scenarios. In example implementations, the “data transport protocols” and “data transport frameworks” may be used interchangeably with the “data streaming protocols” and “data streaming frameworks”, respectively. Further, the “data transport protocols” and “data transport frameworks” may be collectively referred to as the “data reporting method” or “streaming method” herein. In this regard, a “data reporting method” or “streaming method” may (but not necessarily) support or be a collective of a specific data transport / streaming protocol or framework, a specific serialization format, and / or a compression algorithm. Alternatively, a “data reporting method” or “streaming method” may be described separately from a specific serialization format and / or a compressionalgorithm (in this case, the “data reporting method” / ”data streaming” may simply refer to a “data transport / streaming protocol” and / or “a data transport / streaming framework”).

[0038] According to example embodiments, the first network entity 110 (e.g., O-Cloud IMS) may be configured to communicate with the second network entity 120 (e.g., SMO FOCOM), wherein the first network entity and / or the second network entity 120 may be capable of a plurality of streaming methods (or data reporting methods), such as a connection-based streaming (e.g., a persistent connection-based streaming), an event notification-based streaming, and an active collection-based streaming. In this regard, the second network entity may be capable of using a streaming method (or data reporting method) selected from among the plurality of streaming methods (or data reporting methods) to communicate with the first network entity 120. For instance, the second network entity may use a streaming method that is supported by both the first network entity and the second network entity to communicate with the first network entity. In some example implementations, the first network entity 110 may communicate with the second network entity through a streaming session based on the streaming method (or data reporting method) selected from among the plurality of streaming methods.

[0039] For instance, assuming that the selected streaming method includes the connectionbased streaming (e.g., a persistent connection-based streaming), the streaming session may be initiated by the first network entity 110 and / or the second network entity 120. In case the streaming session is initiated by the first network entity 110, the first network entity 110 may be configured to communicate with the second network entity 120 through the streaming session by: (1) providing, to the second network entity 120, a request to open a connection between the first network entity 110 and the second network entity 120, (2) receiving, from the second network entity 120, a response indicating that the connection has successfully opened, and (3) providingdata to the second network entity 120 via the opened connection. In case the streaming session is initiated by the second network entity 120, the first network entity 110 may be configured to communicate with the second network entity 120 through the streaming session by: (1) receiving, from the second network entity 120, a request to open a connection between the first network entity 110 and the second network entity 120, (2) opening the connection in response to the request, and (3) providing data to the second network entity 120 via the opened connection.

[0040] As another example, assuming that the selected streaming method includes the event notification-based streaming, the first network entity 110 may be configured to communicate with the second network entity 120 through the streaming session by: (1) receiving, from the second network entity 120, a request to configure a streaming endpoint (e.g., a request that includes information specifying the streaming session, such as a network or Internet Protocol (IP) address, session context or identifiers, security keys, data transport protocol s / data transport frameworks, etc.), (2) configuring the streaming endpoint based on the request (e.g., allocating resources for the streaming session, configure the underlying software and / or physical elements like socket or router with the associated settings, instantiating or establishing the streaming session, etc.), and (3) providing data to the second network entity 120 via the streaming endpoint. In this regard, a “streaming endpoint” may refer to a point of access for dynamically delivering data from the 02-IMS producer (e.g., the first network entity 110) to the 02-IMS consumer (e.g., the second network entity 120), and may include a Uniform Resource Locator (URL), a Uniform Resource Identifier (URI), or network-accessible address through which the 02-IMS producer (e.g., the first network entity 110) may dynamically push the data and to which the 02-IMS consumer (e.g., the second network entity 120) may access and stream the data therefrom.

[0041] As yet another example, assuming that the selected streaming method includes the active collection-based streaming, the first network entity 110 may be configured to communicate with the second network entity 120 through the streaming session by: (1) receiving, from the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework, (2) applying a configuration based on the parameter (e.g., configuring the underlying software and / or physical components according to the transport protocol and / or transport framework, applying protocol-specific / framework-specific settings, generating / updating an associated URI, etc.), (3) providing, to the second network entity, a response that includes an associated URI (e.g., a URI that includes a URL and / or a Uniform Resource Name (URN) that is configured according to requirements of the transport protocol and / or transport framework), and (4) providing data to the second network entity 120 via the URI (e.g., in the form of data payload). In this regard, a “data payload” may refer to the actual data intended by the second network entity 120, which may be transmi tted / streamed to the second network entity 120 in a message or data packet without the header or metadata.

[0042] Further descriptions of each of the aforesaid data reporting / streaming methods (e g., connection-based streaming, event notification-based streaming, active collection-based streaming, etc.) are provided below with reference to FIG. 7. Further, descriptions of an example use case, which exemplifies the communication between an IMS (e.g., an example of the first network entity 110) and a FOCOM (e.g., an example of the second network entity 120) based on various types of data reporting / streaming methods, are provided below with reference to FIG. 13A and FIG. 13B.

[0043] According to example embodiments, the connection-based streaming may be based on a WebSocket data transport protocol, while the event notification-based streaming may be based on at least one of: a message bus data transport framework, an HTTP data transport protocol,or an RPC data transport protocol. Further, the first network entity 110 may be configured to communicate with the second network entity 120 through the streaming session to provide a data reporting service for reporting at least one of Performance Measurement (PM) data associated with an O-Cloud, Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud. By way of example, the PM data associated with the O-Cloud may include data defining the performance metrics and / or Key Performance Indicators (KPIs) associated with the infrastructures or resources of the O-Cloud (e.g., utilization of the computing resources such as central processing power (CPU) or number of processing cores, status of the memory and storage, the uplink and / or downlink throughput, packet-loss and error rates, energy consumption, etc.). On the other hand, the FM data associated with the O-Cloud may include data defining the errors, faults, and abnormality of the O-Cloud (e.g., alarm notifications, fault detection logs, error reports, fault / error counters, etc.). Further, the Tracing and Analytic data associated with the O-Cloud may include data that may be utilized for monitoring and diagnosing the O-Cloud, such as the transaction logs (e.g., sequenced events for a given session, etc.), resource dependency graphs (e.g., which service utilize which resource, etc ), KPI correlation reports / mappings (e.g., maximum CPU usage vs. failure rate, etc.), and the like. The aforementioned data (e.g., PM data, FM data, Tracing and Analytic data, etc.) may be provided by an 02-IMS producer (e.g., O-Cloud IMS) to an 02-IMS consumer (e.g., SMO FOCOM) in the form of an 02-IMS service (e.g., a data reporting / streaming service that is provided via the 02 interface, etc.), thus said data may also be collectively referred to herein as the “02ims data” or the “O-Cloud data”.

[0044] According to example embodiments, the first network entity 110 (e.g., O-Cloud IMS) may be configured to provide, to the second network entity 120 (e.g., SMO FOCOM),information associated with one or more data reporting / streaming methods supported by the first network entity 110, such as one or more of: a transport protocol (e.g., WebSocket, HTTP, RPC, etc.) supported by the first network entity 110, a transport framework (e.g., message bus, Kafka, etc.) supported by the first network entity 110, a serialization format supported by the first network entity 110, or a compression algorithm supported by the first network entity 110.

[0045] Upon receiving the information associated with one or more data reporting / streaming methods supported by the first network entity 110, the second network entity 120 (e.g., SMO FOCOM) may be configured to select, from among the one or more data reporting / streaming methods supported by the first network entity 110, a data reporting / streaming method to be implemented. For instance, the second network entity 120 may be configured to select the data reporting / streaming method from among the one or more data reporting / streaming methods supported by the first network entity 110, based on a capability of the second network entity 120 (e.g., the transport protocol and / or framework supported by the second network entity 120, etc.) and / or a service quality requirement (e.g., a requirement defined in Quality of Service (QoS) agreement, etc.). Accordingly, the second network entity 120 may be configured to provide information associated with the selected data reporting / streaming method (e.g., a configuration associated with the selected data reporting / streaming method, a serialization format associated with the selected data reporting / streaming method, a compression algorithm associated with the selected data reporting / streaming method, etc.) to the first network entity 110.

[0046] Upon receiving the information associated with the selected data reporting / streaming method, the first network entity 110 may be configured to establish a streaming session with the second network entity 120 based thereon (e.g., establish a connectionbased streaming session by opening a connection or requesting the second network entity 120 toopen a connection therebetween based on the selected data reporting / streaming method, establish an event-notification based streaming session by configuring a streaming endpoint based on the selected data reporting / streaming method, establish an active collection-based streaming session by applying configuration of the selected data reporting / streaming method and providing an associated URI to the second network entity, etc.). In this regard, the streaming session may be based on, for example, a message bus data transport framework (e.g., Kafka framework), a WebSocket data transport protocol, an HTTP data transport protocol, an RPC data transport protocol, and / or the like. Upon establishing the streaming session, the first network entity 110 may communicate with the second network entity 120 through the streaming session to provide data thereto. For instance, the first network entity 110 may communicate with the second network entity through the streaming session to provide a data reporting service for reporting at least one of PM data associated with an O-Cloud, FM data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud. It is contemplated that the “streaming session” described herein may refer to a session or connection established for data communication among the first network entity 110 and second network entity 120, and shall include any suitable types of sessions / connections. For instance, the “streaming session” may include a persistent connection established between the first network entity 110 and second network entity 120 (e.g., when WebSocket data transport protocol or persistent connection-based streaming is involved), a non-persistent connection that establishes whenever a data communication is desired and terminates whenever the data communication is completed (e.g., when event notification-based streaming, message bus data transport framework, HTTP data transport protocol, or RPC data transport protocol is involved), and the like.

[0047] Referring still to FIG. 1, there are at least two types of communication between the first network entity 110 and the second network entity 120, i.e., a bidirectional control plane communication and a unidirectional data plane communication. Specifically, during the control plane communication, the first network entity 110 (e.g., O-Cloud IMS) may provide, to the second network entity 120 (e.g., SMO FOCOM) via the 02 interface, information associated with the supported data reporting / streaming method(s) for establishing a streaming session or communication for the data plane communication (e.g., supported data transport protocol, supported data transport framework, supported serialization format, supported compression algorithm, etc.). Accordingly, the second network entity 120 may select a data reporting / streaming method and provide control information (which may include information specifying the desired O-Cloud data, resource and resource type, measurement selection criteria, report format, measurement reporting frequency, selected data reporting method, configuration related to the selected reporting method, selected serialization format, selected compression algorithm, etc.) to the first network entity 110 via the 02 interface during the control plane communication. After the control plane communication, the first network entity 110 and / or the second network entity 120 may establish a streaming session or connection (e.g., connection-based streaming, event notification-based streaming, active collection-based streaming, etc.) based on the selected data reporting / streaming method. Subsequently, the data plane communication may start, and the first network entity 110 may provide the O-Cloud data (e.g., PM data, FM data, Tracing and Analytic data, etc.) to the second network entity 120 via providing the O-Cloud data (or information on the associated service) thereto.

[0048] FIG. 2 illustrates an example configuration of a first example use case 200, according to one or more example embodiments. In this example use case 200, a data reportingservice for reporting PM data associated with the O-Cloud is utilized as an example of the 02ims services, although it can be understood that example embodiments of the present disclosure may also be applicable for transporting data of any other suitable 02ims services (e.g., data reporting service for reporting FM data, etc.). In this regard, an Open Radio Access Network (0-RAN) may refer to a network with disaggregated architecture and open interfaces comply with those defined by the 0-RAN Alliance. For instance, 0-RAN disaggregates the network functions into various components (e.g., Service Management and Orchestration (SMO) framework, 0-RAN Central Unit (O-CU), 0-RAN Distributed Unit (0-DU), etc.) that communicate and interoperate with each other via various open interfaces (e g., Al interface, E2 interface, 01 interface, 02 interface, etc.). In this regard, an O-Cloud may be a cloud-computing platform that comprises a collection of physical infrastructures and network nodes that host the 0-RAN components (e.g., SMO, O-CU, 0-DU, etc ), the supporting software components (e.g., the operating systems and runtime environments), and the like.

[0049] Referring to FIG. 2, the example use case 200 may involve an IMS 210 that may be implemented as the 02-IMS producer (i.e., a producer of the PM data reporting service) and an FOCOM 220 that may be implemented as the 02-IMS consumer (i.e., a consumer of the PM data reporting service provided or exposed by the IMS 210). The IMS 210 and FOCOM 220 may correspond to the first network entity or network element 110 and second network entity or network element 120 in FIG. 1, respectively. It is contemplated that, in the actual implementation, the 02-IMS producer 210 may include any other suitable entities / elements capable of providing 02ims service(s) and the 02-IMS consumer 220 may include any other entities / elements in the O-RAN architecture that may consume the 02ims service(s).

[0050] As illustrated in FIG. 2, similar to FIG. 1, there are two types of communication between the IMS 210 (i.e., the 02-IMS producer) and the FOCOM 220 (i.e., 02-IMS consumer), i.e., a bidirectional communication and a unidirectional communication.

[0051] The bidirectional communication may refer to a control plane communication where the FOCOM 220 communicates with the IMS 210 via the 02 interface to perform and / or control a subscription to PM data of the O-Cloud. For instance, the FOCOM 220 may provide a subscription request (e.g., a request to create a subscription) for the PM data reporting service to the IMS 210 via the 02 interface, and the IMS 210 may respond with an acknowledge message to the FOCOM 220 via the 02 interface. For instance, the FOCOM 220 may send an HTTP or RPC request (which includes information defining the desired PM data, the subscriber endpoints, etc.) to the IMS 210 via the 02 interface, and the IMS 210 may respond to the request with an HTTP or RPC response (e.g., a success response, an error response, etc.) via the 02 interface. In example implementations where message bus framework is involved, the FOCOM 220 may provide (in the subscription request) the message bus information, such as a message broker endpoint (e.g., IP endpoint of a primary message broker, IP endpoint of a candidate message broker, etc ), a streaming session ID (e.g., a topic ID for Kafka, etc.), along with other data subscription parameters (e.g., consumer performance subscription ID, resource and resources types, measurement selection criteria, report format, callback, measurement reporting frequency, remote file location, etc.). It can be understood that the FOCOM 220 may provide information of other data reporting methods (e.g., WebSocket, HTTP, RPC, etc.) to the IMS 210, along with the associated data subscription parameters, in a similar manner without departing from the scope of the present disclosure.

[0052] Upon accepting the subscription request from the FOCOM 220 and responding thereto, the IMS 210 may create the subscription based on the information provided by FOCOM 220. For instance, assuming that the message bus framework is involved, the IMS 210 may store the streaming session ID(s) and the message broker endpoint(s), alongside the information of the desired PM data (e.g., topic name, etc.). Further, the FOCOM 220 may also update the associated fdter criteria, such that non-desirable data may be fdtered out when applicable.

[0053] Upon creating the subscription, the IMS 210 may monitor the O-Cloud resources (or the associated entities such as the O-Cloud infrastructure, inventory, fault buffers, performance data collectors, etc.) for PM data that matches the subscription (e.g., PM data that matches the resource and resources types, measurement selection criteria, etc.). Upon determining PM data that matches the subscription, the IMS 210 may collect the PM data and provide the PM data to the FOCOM 220. For instance, assuming that the message bus framework is involved, the IMS 210 may compile or batch the PM data in a message (e.g., a JSON message), and route the message to an associated message broker. It can be understood that the IMS 210 may implement other data reporting or streaming methods / protocols / frameworks (e.g., WebSocket, HTTP, RPC, etc.) to provide the PM data to the FOCOM 220 in a similar or any other suitable manner, without departing from the scope of the present disclosure.

[0054] According to example embodiments, the IMS 210 may serialize the collected data into one or more specific formats, before sending the data to the FOCOM 220. For instance, the IMS 210 and / or the FOCOM 220 may support one or more of the following serialization formats: Prometheus, ISON, Extensible Markup Language (XML), Abstract Syntax Notation One (ASN.1), Protocol Buffers (protobuf), and any other suitable O-RAN-specific serialization format. Advantageously, the serialization of the data may convert the data into a standardized format thatis suitable for storage and transmission, thereby increasing the implementation flexibility. In addition to or in alternative to data serialization, the IMS 210 may also compress the collected / serialized data, thereby optimizing the bandwidth utilization for reporting the data. In this regard, the IMS 210 and / or the FOCOM 220 may support one or more of the following compression algorithms: / standard (zstd), GNU zip (gzip), Lempel-Ziv (LZ) 4, Snappy, and the like. The serialization format and compression algorithm may be negotiated and decided between the O-Cloud and the management system / entity (e.g., SMO, etc.) in runtime. According to example implementations where Prometheus is utilized as the data collector or aggregator, the data collected / aggregated by Prometheus would be in simple text-based syntax which, when being combined with the gzip / zstd compression, provides an efficient and effective compression result. Thus, when Prometheus is utilized, the IMS 210 may not perform data serialization to convert the data and may directly compress the data aggregated / collected by Prometheus.

[0055] The 02-IMS producer 210 may include any suitable network entity / network element associated with an O-Cloud and is capable of producing and providing one or more 02ims services to the 02-IMS consumer 220. On the other hand, the 02-IMS consumer 220 may include any suitable network entity / network element that may consume the one or more 02ims services provided by the 02-IMS producer 210.

[0056] FIG. 3 illustrates an example configuration of a second example use case 300, according to one or more example embodiments. In example use case 300, an IMS 311 of an O-Cloud 310 is utilized as an example of the 02-IMS producer, and a FOCOM 321 of an SMO 320 is utilized as an example of the 02-IMS consumer.

[0057] The SMO 320 may refer to the automation layer or framework within an O-RAN architecture, which may apply intelligence and closed-loop control to manage, configure, andoptimize the underlying O-RAN components (e.g., O-CU, O-DU, O-RAN Radio Unit (O-RU), etc.). On the other hand, as described above with reference to FIG. 2, the O-Cloud may be a collection of physical network nodes that host the O-RAN components (e.g., SMO, O-CU, O-DU, etc.), the supporting software components (e.g., the operating systems and runtime environments), and the like. The O-Cloud 310 (and the IMS 311 associated therewith) may communicate with the SMO 320 (and the FOCOM 321 associated therewith) via the 02 interface.

[0058] The IMS 311 may refer to the network entity / network element that acts as the management-service endpoint within the O-Cloud 310. For instance, the IMS 311 may expose or publish one or more 02ims services to the SMO 320 / FOCOM 321 (via one or more Application Programming Interfaces (APIs), etc.), such that the SMO 320 / FOCOM 321 may subscribe to the O2ims service(s), query the O-Cloud inventory, perform lifecycle management (e.g., power-on, software update, etc.) to the underlying O-Cloud resources, and the like.

[0059] The FOCOM 321 may refer to the network entity / network element that acts as the endpoint within the SMO 320 that communicates with the IMS 311. For instance, the FOCOM 321 may communicate with multiple O-Clouds via interacting with the associated IMS, while abstracting each IMS into a single federated view (e.g., aggregating and unifying data from different O-Clouds into a single inventory, presenting the aggregated data as a common set of resource types, etc.), thereby enabling the SMO’s higher-level network functions (e.g., RAN Intelligent Controller (RIC), etc.) to control the O-Clouds without being tied to any specific cloud vendor.

[0060] The SMO 320 may obtain data from the O-Cloud 310 by implementing the FOCOM 321 (i.e., the 02-IMS consumer within the SMO 320), and then provide management to the O-Cloud 310 based on the obtained data. For instance, the FOCOM 321 may communicatewith the IMS 311 via the 02 interface, subscribe to an 02ims service (e.g., a data streaming service for streaming PM data of an O-Cloud node, etc ), and consume the subscribed 02ims service. Accordingly, the F0C0M 321 may process the obtained data (e.g., standardize the terminologies in the data, etc.) and provide the processed data to other entities or network functions of the SMO 320 (e.g., RIC, etc.) for further utilization. Accordingly, when said other entities / network functions of the SMO 320 would like to perform a management action on the O-Cloud 310, the FOCOM 321 may again communicate with the IMS 311 via the 02 interface, thereby enabling the SMO 320 to communicate with the O-Cloud 310 and manage the O-Cloud 310 accordingly.

[0061] The FOCOM 321 may provide, to the IMS 311 via the 02 interface, a subscription request for an 02ims service (e.g., a data streaming service for streaming data associated with the O-Cloud 310), and the IMS 311 may provide the 02ims service (or the associated O-Cloud data) to the FOCOM 321 according to the subscription request. The operations for providing and consuming an 02ims service may involve one or more data reporting / streaming methods that supports one or more data transport protocols / frameworks (e.g., message bus, WebSocket, HTTP, etc.), serialization formats, and / or compression algorithms.

[0062] FIG. 4A illustrates an example configuration 400 for implementing one or more example embodiments. Specifically, the example configuration 400 illustrates a multipoint-to-multipoint data communication via implementing a message bus data transport framework, according to one or more example embodiments.

[0063] As illustrated in FIG. 4A, example configuration 400 may include an O-Cloud 410, an SMO 420, and at least one message bus 430. The O-Cloud 410 may include a plurality of data producers 410-1 to 410-N (where N is any suitable natural number), and the SMO 420 may includea plurality of data consumers 420-1 to 420-N (where N is any suitable natural number). The O-Cloud 410 may communicate with the SMO 420 via the 02-IMS interface.

[0064] The message bus 430 may be a logical entity that is constituted of a plurality of message brokers 430-1 to 430-N (where N is any suitable natural number). Each of the message brokers 430-1 to 430-N may be deployed on one or more hardware components (e.g., servers, computing devices, etc.) and / or one or more software components (e.g., virtual machines, containers, etc.) that implement the operations of the message bus 430 (e.g., storing topic’s data, replicating messages for a topic, routing the data to subscribers, etc.). Each of the message brokers 430-1 to 430-N may maintain or manage an append-only log for every topic it hosts (e.g., when a message broker receives a message for “CPU usage” topic, the message broker may simply write that message to the end of the topic’ s ongoing log, thereby adding the new entries / contexts without changing the earlier entries / contexts).

[0065] As a non-limiting example, one or more of the data consumers 420-1 to 420-N may send a subscription request (e.g., a request to create a subscription) to one or more of the data producers 410-1 to 410-N to notify the desired O-Cloud data to stream (e.g., PM data, FM data, etc.) and the associated message bus parameters (e g., streaming session identifier (ID), message broker endpoints, target topic name, etc.). Accordingly, the associated data producer(s) may start reporting the subscribed O-Cloud data and publish the subscribed O-Cloud data (e.g., via a message bus producer client implemented thereby) to the associated message broker(s) whenever the O-Cloud data is ready. The O-Cloud data may be published in a self-contained message (e.g., a JavaScript Object Notation (JSON) record, etc.) to an associated topic (e.g., PM data, FM data, etc.) on the associated message broker(s). The associated message broker(s) may then append the message to one or more logs associated with the topic. Accordingly, the data consumer(s) maycommunicate with the associated message broker(s) (e.g., via a message bus consumer client implemented thereby) and subscribe to the desired topic(s), thereby streaming the O-Cloud data from the data producers to the data consumers in a multi-point to multi-point approach, without requiring a point-to-point connection between SMO 420 and O-Cloud 410.

[0066] In some example embodiments, the message bus may be implemented based on any suitable open-source streaming systems, platforms, or approaches, such as Apache Kafka. Specifically, a Kafka-based message bus may divide the message bus operations between a Kafka client and a Kafka broker, where the Kafka client may include a library that utilized by the network entities (e.g., the data producer(s) 410-1 to 410-N may utilize a producer client and the data consumer(s) 420-1 to 420-N may utilize a consumer client) and the Kafka broker may be utilized by a message broker. In this regard, when the data producer(s) publish the O-Cloud data, the associated Kafka client may communicate with the Kafka broker and provide the O-Cloud data thereto. On the other hand, when the data consumer(s) stream the O-Cloud data, the associated Kafka client may communicate with the Kafka broker and fetch the O-Cloud data therefrom. In other words, the Kafka broker enables a message bus to provide the publish-subscribe data communication while the Kafka client enables the network entities to publish and consume data therefrom.

[0067] Further, as illustrated in FIG. 4 A, each of the plurality of data producers 410-1 to 410-N and / or each of the plurality of data consumers 420-1 to 420-N may communicate with the plurality of message brokers 430-1 to 430-N in parallel. In this regard, one or more of the plurality of data producers 410-1 to 410-N may send data to multiple message brokers simultaneously. For instance, the data producer 410-1 may simultaneously send data to the message brokers 430-1 and 430-N. Similarly, a message broker may also receive data from multiple data producerssimultaneously. For instance, the message broker 430-1 may simultaneously receive data from the data producers 410-1 and 410-N. In addition, one or more of the plurality of data consumers 420-1 to 420-N may receive or stream data from multiple message brokers simultaneously. For instance, the data consumer 420-1 may simultaneously receive or stream data from the message brokers 430-1 and 430-N. Descriptions of the operations and data (e.g., subscription request from the SMO 420 that includes the message bus parameters and intended data, message from the O-Cloud 410 that includes the collected data and streaming session ID, etc.) have been provided above with reference to FIG. 1 to FIG. 3. Thus, further descriptions associated therewith may be omitted below for conciseness.

[0068] According to example embodiments, the plurality of message brokers 430-1 to 430- N may be the same type of message brokers (e.g., all message brokers are Kafka-based message brokers, etc.) or different types of message brokers (e.g., the message broker 430-1 may be a Kafka-based message broker while the message broker 430-N may include a message broker based on another technology, etc.).

[0069] According to example embodiments, one or more data collectors may be implemented to collect data from the O-Cloud resources (e.g., server nodes) and act as data producer to forward the same to the message bus 430. The data collector(s) may be implemented in software form (e.g., a virtualized or containerized network function), in hardware form (e.g., a device or apparatus that implements the data exposure network function), or a combination thereof. In addition, the data collector(s) may include a data log or a data collection tool that is based on any suitable technology (e.g., Prometheus, Zabbix, etc.). Further, the message bus streaming operations may also involve data collection / aggregation, with or without the data collector(s),according to various data hierarchy options (e.g., site-level data aggregation, cluster-level data aggregation, node group-level data aggregation, node-level data aggregation, etc ).

[0070] Further, example embodiments also introduce various data streaming modes via the message bus 430 (or the message brokers 430-1 to 430-N). For instance, by implementing the message bus data streaming, the example embodiments enable periodic data streaming and eventbased data streaming.

[0071] Advantageously, by implementing the message bus 430, multiple message brokers 430-1 to 430-N can exist simultaneously with parallel connections to the data producers of the O-Cloud 410 and the data consumers of the SMO 420 to scale up the transport capacity. Further, the number of parallel streaming connections with the message broker may be scaled in and out dynamically depending on the real-time demand. Furthermore, additional redundant message brokers and connections may be implemented to provide fault protection and resiliency.

[0072] FIG. 4B illustrates an example system configuration 401 for implementing a message bus data transport framework, according to one or more example embodiments. System configuration 401 may be an example implementation of the system configuration 400 in FIG. 4A. For instance, the IMS 411 in system configuration 401 may be implemented in or by the O-Cloud 410 in system configuration 400, the PM reporting workload 411-1 to 411-N and the O-Cloud nodes 412-1 to 412-N in system configuration 401 may be the examples of (at least in part of) the data producers 410-1 to 410-N in system configuration 400, the Kafka cluster 431 may be an example of the message bus 430 in system configuration 400, the Kafka message brokers 431-1 to 431-N in system configuration 401 may be the examples of (at least in part of) the message broker 430-1 to 430-N in system configuration 400, the PM application instances 421-1 to 421-N in system configuration 401 may be the examples of (at least in part of) the data consumers 420-1 to420-N in system configuration 400, and the FOCOM 441 may be implemented in or by the SMO 420 in system configuration 400. Thus, it can be understood that the features and mechanisms (as well as the data, parameters, and messages) described above with reference to system configuration 400 in FIG. 4A may be similarly applicable to system configuration 401 in FIG. 4B (unless described otherwise), and the associated descriptions may be omitted below for conciseness.

[0073] Referring still to FIG. 4B, the components may be categorized into “02-IMS producer side components” and “02-IMS consumer side components”. The 02-IMS producer side components may include an IMS 411, a plurality of PM reporting workloads 411-1 to 411-N (where N is any suitable natural number), and a plurality of O-Cloud nodes 412-1 to 412-N (where N is any suitable natural number). On the other hand, the 02-IMS consumer side components may include a FOCOM 441, a Kafka cluster 431 (that hosts or implements a plurality of Kafka message brokers 431-1 to 431-N, where N is any suitable natural number), and a plurality of PM application instances 421-1 to 421-N (where N is any suitable natural number).

[0074] The O-Cloud nodes 412-1 to 412-N may represent the underlying network or computing resources (e.g., a physical server, a virtual machine, a container, etc.) in the O-Cloud. On the other hand, the PM reporting workloads 411-1 to 411-N may refer to the virtualized / containerized 02-IMS PM reporting service implementations that run on the one or more O-Cloud nodes 412-1 to 412-N (e.g., each of the PM reporting workloads may measure and monitor the performance of one or more of the O-Cloud nodes 412-1 to 412-N and publish the measurement data to the associated consumer). In some example implementations, each of the O-Cloud nodes 412-1 to 412-N may host zero to multiple PM reporting workloads 411-1 to 411-N, for redundancy, multi-tenancy, or service isolation purposes. In some example embodiments, the IMS 411 (or one or more of the PM reporting workloads 411-1 to 411-N) may implement or hosta Kafka client that may be configured to communicate with and provide data to one or more of the Kafka message brokers 431-1 to 431 -N in the Kafka cluster 431. In this way, the IMS 411 may send or publish data to the 02-IMS consumer (e.g., an SMO or the FOCOM 411) using the Kafka framework or protocol.

[0075] The Kafka cluster 431 may represent a message bus that are formed by the plurality of Kafka message brokers 431-1 to 431-N. In some example implementations, each of the Kafka message brokers 431-1 to 431-N may be configured to manage one or more topics, and the Kafka cluster 431 may be configured to provide one or more of: append-only logging upon successful data delivery (e.g., each incoming data / message is appended to the end of the topic’s log, etc.), data replication (e.g., data / messages managed by broker one server node may be synchronously and / or asynchronously copied to another broker server node for fault tolerance, etc.), load balancing (e.g., data topics may be allocated across the broker server nodes to avoid overloading a specific broker server node, etc.), auto-scaling (e.g., adding / reducing the number of Kafka message broker server nodes according to the volume of data, etc.), and the like.

[0076] The PM application instances 421-1 to 421-N are the examples of the data consumers described above with reference to FIG. 4 A. In this regard, one or more of the PM application instances 421 may be implemented in an SMO framework (e.g., implemented in an rApp of a Non-Real-Time RAN Intelligent Controller (Non-RT RIC), implemented as a SMO Service for performance monitoring and service assurance, etc.). One or more of the PM application instances 421-1 to 421-N may implement a Kafka consumer client that communicates with one or more of the Kafka message broker server nodes 431-1 to 431-N and subscribe to one or more topics (e.g., “PM Data”, etc.) manage thereby.

[0077] The FOCOM 441 may act on behalf of one or more of the PM application instances 421-1 to 421-N. For instance, the FOCOM 441 may send a subscription request to the IMS 411 to subscribe and notify the IMS 411 regarding the desired PM data. The FOCOM 411 may also provide the associated message bus parameters (e.g., streaming session ID, message broker endpoints, etc.) to the IMS 411. Upon receiving the subscription request, the IMS 411 may configure the associated PM reporting workload(s) and / or O-Cloud node(s), and then start collecting and reporting the PM data subscribed by the FOCOM 441.

[0078] In view of the above, by implementing the Kafka framework, the IMS 411 (or the PM reporting workloads 411-1 to 411-N associated therewith) may publish the O-Cloud data (e.g., PM data) to the Kafka cluster (or the Kafka message brokers 431-1 to 431-N). The Kafka cluster (or the Kafka message brokers 431-1 to 431-N) may automatically route the data to the associated data consumers at the backend upon successful data delivery, and may handle one or more of: a load balancing, a data replication for fault-tolerance, and an auto-scaling. The PM application instances 421-1 to 421-N (i.e., the data consumers) may receive the data from the Kafka cluster (or the Kafka message broker server nodes 431-1 to 431-N) when the data is ready. Advantageously, by leveraging the Kafka framework (i.e., a message bus data transport framework) for transporting O-Cloud data, the complexity in handling scaling, load balancing, fault-tolerance, data integrity, and delivery performance, can be reduced (if not completely offloaded). Further, Kafka framework may also enable the automatic data delivery repetition that provide strong network resiliency (e.g., if a lead data path fails, a follower data path may still be utilized to ensure that the data can be delivered).

[0079] FIG. 5A illustrates another example configuration 500 for implementing one or more example embodiments. Specifically, the example configuration 500 illustrates an examplesystem configuration for implementing one or more example embodiments using the WebSocket data transport protocol.

[0080] As illustrated in FIG. 5A, example configuration 500 may include an O-Cloud 510 and an SMO 520. The O-Cloud 510 may include a plurality of data producers 510-1 to 510-N (where N is any suitable natural number), each of which may be similar to the respective components described above with reference to FIG. 1 to FIG. 4B. The SMO 520 may include a plurality of data consumers 520-1 to 520-N (where N is any suitable natural number), each of which may be similar to the respective components described above with reference to FIG. 1 to FIG. 4B. Thus, the detailed descriptions associated therewith may be omitted below for conciseness. The O-Cloud 510 may communicate with the SMO 520 via the 02-IMS interface.

[0081] As also illustrated in FIG. 5A, the SMO 520 may also include a plurality of WebSocket components 530-1 to 530-N. As further described below with reference to FIG. 5B, one or more of the WebSocket components 530-1 to 530-N may include one or more server nodes that host or implement the WebSocket data transportation (“WebSocket server nodes” herein) and a load balancer that distributes incoming data across the WebSocket server nodes (“WebSocket load balancer” herein).

[0082] According to example embodiments, one or more of the data producers 510-1 to 510-N may establish a point-to-point connection to one or more of the WebSocket components 530-1 to 530-N. For instance, the data producer 510-1 may send a handshake message to the WebSocket Component 530-1, thereby establishing or opening a persistent connection therewith. Once the connection is established or opened, the data producer 510-1 may continuously stream data to the data consumer 520-1 via the WebSocket component 530-1, without requiring any further handshaking. In some example embodiments, connection-based data streaming may beutilized to enable the data producer 510-1 to send a flow of data bursts (e.g., PM data bursts) to the data consumer 520-1. For data streaming purposes, the WebSocket connect! on / session connection is typically opened and kept open without having to renegotiate. Once the WebSocket connection / session is opened or established, the metadata about the streams is exchanged, the data consumer 520-1 can then receive the serialized data, without requiring the metadata to be exchanged with every data burst.

[0083] Advantageously, by implementing the WebSocket data transport protocol, multiple WebSocket components 530-1 to 530-N can be deployed in parallel, each of which may be configured to maintain a persistent connection-based streaming session with one or more data producers 510-1 to 510-N, enabling the one or more data producers 510-1 to 510-N and the corresponding data consumers 520-1 to 520-N to continuously exchange date without requiring multiple data bursts and enabling the scaling of the overall streaming capacity without introducing polling overhead. Further, the low-latency nature of WebSocket removes the need for repeated handshakes or long-polling, enabling fast delivery of O-Cloud data and rapid upstream signaling when applicable .

[0084] FIG. 5B illustrates an example system configuration 501 for implementing a WebSocket data transport protocol, according to one or more example embodiments. System configuration 501 may be an example implementation of the system configuration 500 in FIG. 5 A. For instance, the IMS 511 in system configuration 501 may be implemented in or by the O-Cloud 510 in system configuration 500, the FOCOM 541 in system configuration 501 may be implemented in or by the SMO 520 in system configuration 500, the WebSocket Clients 511-1 to 511-N and the O-Cloud nodes 512-1 to 512-N in system configuration 501 may be the examples of (at least in part of) the data producers 510-1 to 510-N in system configuration 500, theWebSocket load balancer 531 and the WebSocket server nodes 532-1 to 532-N may be examples of (at least in part of) the WebSocket components 530-1 to 530-N in system configuration 500, and the SMO Functions (SMOFs) 521-1 to 521-N may be the examples of (at least in part of) the data consumers 520-1 to 520-N in system configuration 500. Similarly, one or more components in system configuration 501 may also be similar to those described above with reference to FIG.4A and FIG. 4B. For instance, the optional message bus / broker 533 may be similar to the message bus 430 / message brokers 430-1 to 430-N in FIG. 4A and / or the Kafka cluster 431 / Kafka message brokers 431-1 to 431-N in FIG. 4B, the O-Cloud nodes 512-1 to 512-N may be similar to the O-Cloud nodes 412-1 to 412-N in FIG. 4B, and the like. Thus, it can be understood that the features and mechanisms (as well as the data, parameters, and messages) described above with reference to FIG. 4A to FIG. 5A may be similarly applicable to system configuration 501 in FIG. 5B (unless described otherwise), and the associated descriptions may be omitted below for conciseness.

[0085] Referring to FIG. 5B, the components may be categorized into “02-IMS producer side components” and “02-IMS consumer side components”. The 02-IMS producer side components may include an IMS 511, a plurality of WebSocket clients 511-1 to 511-N (where N is any suitable natural number), and a plurality of O-Cloud nodes 512-1 to 512-N (where N is any suitable natural number). On the other hand, the 02-IMS consumer side components may include a FOCOM 541, a WebSocket load balancer 531, a plurality of WebSocket server nodes 532-1 to 532-N (where N is any suitable natural number), a plurality of SMOF 521-1 to 521-N (where N is any suitable natural number), and an optional message bus / broker 533.

[0086] As described above with reference to FIG. 4B, the O-Cloud nodes 512-1 to 512-N may represent the underlying network or computing resources (e.g., a physical server, a virtual machine, a container, etc.) in the O-Cloud. On the other hand, the WebSocket clients 511-1 to 511-N may refer to the WebSocket components deployed or implemented by the IMS 511 to establish or open connect! ons / sessions with the WebSocket server node(s) when required. For instance, during startup and / or when a streaming session is established or enabled, the WebSocket client 511-1 may setup one or more persistent connections / streaming sessions (e.g., via sending a handshake message to the upstream component, etc.), each of the persistent connections / streaming sessions may be established / opened with a respective WebSocket server node. Accordingly, the IMS 511 may provide data (e.g., PM data) associated with one or more of the O-Cloud nodes 512-1 to 512-N to the associated WebSocket server node(s) via the respective persistent connection / streaming session.

[0087] The WebSocket load balancer 531 may refer to a traffic-distribution layer that sits between the WebSocket clients 511-1 to 511-N and the WebSocket server nodes 532-1 and 532-N. According to example embodiments, the WebSocket load balancer 531 may be implemented in the form of a virtualized / containerized service, and may / may not reside in one or more of the WebSocket server nodes 532-1 and 532-N. The WebSocket load balancer 531 may be configured to distribute the connections from the IMS 511 (or the WebSocket clients 511-1 to 511-N) to one or more of the WebSocket server nodes 532-1 and 532-N within the FOCOM 541, thereby balancing the load on each of the WebSocket server nodes 532-1 to 532-N. Once a connection / session is established between a WebSocket client and a WebSocket server node, the connection / session may remain persistent, and the data may be streamed directly from the WebSocket client to the WebSocket server node via the connection / session without passing through the WebSocket load balancer 531.

[0088] The WebSocket server nodes 532-1 to 532-N may refer to the server nodes that terminate the WebSocket data transport protocol. For instance, one or more of the WebSocketserver nodes 532-1 to 532-N may receive a handshake message from one or more of the WebSocket clients 511-1 to 511-N, may manage the persistent connect! on(s) / session(s) with one or more of the WebSocket clients 511-1 to 511-N, may receive incoming data from one or more of the WebSocket clients 511-1 to 511-N, and may provide the received data to one or more of the SMOF 521-1 to 521-N directly (e.g., via WebSocket data transportation) and / or via the optional message bus / broker 533.

[0089] According to example embodiments, one or more of the WebSocket server nodes 532-1 to 532-N are included to provide high availability. In this way, the WebSocket server nodes may be scaled up (when required) to, for example, match the increasing traffic demand from the IMS 511 (e.g., when IMS 511 make connections to more WebSocket server nodes, etc.), avoid failure or down time due to single server node or single transport path failure, and the like.

[0090] The optional message bus / broker 533 may be implemented as a middleware layer that decouples the front-end WebSocket server nodes 532-1 to 532-N from the back-end services (e.g., SMOF 521-1 to 521-N). In this way, the back-end services may see data from all independent WebSocket server nodes 532-1 to 532-N, the routing of data to back-end services may be independent to data routing at the front-end, data transport protocol may be independent, and the backend service and front-end WebSocket server nodes may be scaled independently. The detailed implementations of a message bus / broker for transporting data have been described above with reference to FIG. 4A to FIG. 4B, and it is contemplated that similar mechanisms, operations, and configurations may be applicable herein in a similar manner.

[0091] The SMOFs 521-1 to 521-N may each be a data consumer that receive the data of the O-Cloud node(s) 512-1 to 512-N, and then utilize the received O-Cloud data to perform various operations, such as policy decision making / updating, Artificial Intelligence / Machine Learning(AI / ML) inference or model training, further data distribution (e.g., to an Near-Real-Time (Near-RT) RIC, etc ), and the like. The SMOFs 521-1 to 521-N can also be implemented as applications within the SMO (e g., rApps). When the optional message bus / broker 533 is involved, the SMOFs 521-1 to 521-N may subscribe to one or more message bus topics (e.g., “PM data”, etc.), thereby retrieving or streaming the O-Cloud data (e.g., PM data) from the message bus / broker 533 without requiring direct connections to the associated Web Socket server node(s). On the other hand, when the optional message bus / broker 533 is not involved, the SMOFs 521-1 to 521-N may establish or open a persistent connection / session with each of the associated WebSocket server node(s) (in a similar manner on how the WebSocket client(s) establishes / opens the persistent connection / session), and then obtain or stream the O-Cloud data directly from the associated WebSocket server node(s).

[0092] In view of the above, by implementing WebSocket data transport protocol, the IMS 511 (or the WebSocket clients 511-1 to 511-N associated therewith) may establish a persistent connection(s) / session(s) with the associated WebSocket server node(s), such that the O-Cloud data can be efficiently and timely provided to the associated WebSocket server node(s) when available, without requiring repeated handshake or polling procedure.

[0093] FIG. 6A illustrates yet another example configuration 600 for implementing one or more example embodiments. Specifically, the example configuration 600 illustrates an example system configuration for implementing one or more example embodiments using the HTTP data transport protocol. +

[0094] As illustrated in FIG. 6A, example configuration 600 may include an O-Cloud 610 and an SMO 620. The O-Cloud 610 may include a plurality of data producers 610-1 to 610-N (where N is any suitable natural number), each of which may be similar to the respectivecomponents described above with reference to FIG. 1 to FIG. 5B. The SMO 620 may include a plurality of data consumers 620-1 to 620-N (where N is any suitable natural number), each of which may be similar to the respective components described above with reference to FIG. 1 to FIG. 5B. Thus, the detailed descriptions associated therewith may be omitted below for conciseness.

[0095] As also illustrated in FIG. 6A, the SMO 620 may also include a plurality of HTTP components 630-1 to 630-N (where N is any suitable natural number). As further described below with reference to FIG. 6B, one or more of the HTTP components 630-1 to 630-N may include one or more server nodes that host or implement the HTTP data transportation (“HTTP server nodes” herein) and a load balancer that distributes incoming data across the HTTP server nodes (“HTTP load balancer” herein).

[0096] According to example embodiments, one or more of the data producers 610-1 to 610-N may establish / reestablish a new connection to one or more of the data consumers 620-1 to 620-N (via one or more of the HTTP components 630-1 to 630-N) when required. Unlike WebSocket data transport protocol that establishes a persistent connection and provide data therethrough, HTTP data transport protocol is an event notification-based transport protocol that establish / reestablish a connection or streaming session for each data reporting / transportation, when receiving an event notification (e.g., whenever an O-Cloud data is available, the data may be sent as a payload of a notification that triggers the establishment / reestablishment of the connection for data transportation, etc.). In other words, HTTP data transport protocol leverages a per-burst connection establishment / reestablishment when data transportation is required. During establishment / reestablishment of the HTTP connection / session, the data producer(s) 610-1 to 610- N may send an HTTP request (e.g., POST, GET, etc.) to the HTTP component(s) 630-1 to 630-N.The HTTP component(s) 630-1 to 630-N may process the HTTP request and return an HTTP response (e.g., 200 OK status code), at which point the exchange for the data burst is completed.

[0097] Advantageously, by implementing the HTTP data transport protocol, multiple HTTP components 630-1 to 630-N can be deployed in parallel, each of which may be configured to handle discrete O-Cloud data transportation from the data producers 610-1 to 610-N and the corresponding data consumers via stateless HTTP requests and responses. Accordingly, the data transportation connections / sessions can be established / reestablished when required (without the need for maintaining persistent connections / sessions), and the data may be dynamically loaded to any suitable / available server nodes, thereby increasing the deployment flexibility and scalability, simplifying the load balancing, and reducing the data transportation overhead.

[0098] FIG. 6B illustrates an example system configuration 601 for implementing an HTTP data transport protocol, according to one or more example embodiments. System configuration 601 may be an example implementation of the system configuration 600 in FIG. 6A. For instance, the IMS 611 in system configuration 601 may be implemented in or by the O-Cloud 610 in system configuration 600, the PM reporting workloads 611-1 to 611-N and the O-Cloud nodes 612-1 to 612-N in system configuration 601 may be the examples of (at least in part of) the data producers 610-1 to 610-N in system configuration 600, the FOCOM 641 in system configuration 601 may be implemented in or by the SMO 620 in system configuration 600, the HTTP load balancer 631 and the HTTP server nodes 632-1 to 632-N may be examples of (at least in part of) the HTTP components 630-1 to 630-N in system configuration 600, and the SMO Functions (SMOFs) 621-1 to 621-N may be the examples of (at least in part of) the data consumers 620-1 to 620-N in system configuration 600. Similarly, one or more components in system configuration 601 may also be similar to those described above with reference to FIG. 4A to FIG5B. For instance, the PM reporting workload 611-1 to 611-N may be similar to the PM reporting workload 411-1 to 411-N in FIG. 4B; the optional message bus / broker 633 may be similar to the message bus 430 / message brokers 430-1 to 430-N in FIG. 4A, the Kafka cluster 431 / Kafka message broker server nodes 431-1 to 431-N in FIG. 4B, and / or the message bus / broker 533 in FIG. 5B; the O-cloud nodes 612-1 to 612-N may be similar to the O-Cloud nodes 412-1 to 412-N in FIG. 4B and / or the O-Cloud nodes 512-1 to 512-N in FIG. 5B; and the SMOFs 621-1 to 621-N may be similar to the SMOFs 521-1 to 521-N in FIG. 5B. Thus, it can be understood that the features and mechanisms (as well as the data, parameters, and messages) described above with reference to FIG. 4A to FIG. 5B may be similarly applicable to system configuration 601 in FIG.6B (unless described otherwise), and the associated descriptions may be omitted below for conciseness.

[0099] Referring to FIG. 6B, the components may be categorized into “02-IMS producer side components” and “02-IMS consumer side components”. The 02-IMS producer side components may include an IMS 611, a plurality of PM reporting workload 611-1 to 611-N (where N is any suitable natural number), and a plurality of O-Cloud nodes 612-1 to 612-N (where N is any suitable natural number). On the other hand, the 02-IMS consumer side components may include a FOCOM 641, an HTTP load balancer 631, a plurality of HTTP server nodes 632-1 to 632-N (where N is any suitable natural number), a plurality of SMOF 621-1 to 621-N (where N is any suitable natural number), and an optional message bus / broker 633.

[0100] As described above with reference to FIG. 4B and FIG. 5B, the O-Cloud nodes 612-1 to 612-N may represent to the underlying network or computing resources (e.g., a physical server, a virtual machine, a container, etc.) in the O-Cloud. As also described above with reference to FIG. 4B, the PM reporting workloads 611-1 to 611-N may refer to the virtualized / containerizedPM reporting services that run on the one or more O-Cloud nodes 612-1 to 612-N (e.g., each of the PM reporting workloads may measure and monitor the performance of one or more of the O-Cloud nodes 612-1 to 612-N and provide the measurement data to the associated HTTP server node(s)). In some example implementations, each of the O-Cloud nodes 612-1 to 612-N may host zero to multiple PM reporting workloads 611-1 to 611-N, for redundancy, multi-tenancy, or service isolation purposes. The PM reporting workload 611-1 to 611-N may establish or reestablish connections / sessions with the HTTP server node(s), when required. For instance, whenever an O-Cloud data is available (or when the IMS 611 decides to send / resend an O-Cloud data), the PM reporting workload 611-1 may send an HTTP message (e.g., HTTP POST request for push delivery, HTTP GET response for polling, etc.) to the HTTP server node 632-1 (via the HTTP load balancer 631), along with the O-Cloud data (and any other associated metadata) included in the HTTP message, thereby providing the O-Cloud data (e.g., PM data, etc.) associated with one or more of the O-Cloud nodes 612-1 to 612-N to the associated HTTP server node(s) by establishing a respective connection / session.

[0101] The HTTP load balancer 631 may refer to a traffic-distribution layer that sits between the PM reporting workloads 611-1 to 611-N and the HTTP server nodes 632-1 and 632-N. According to example embodiments, the HTTP load balancer 631 may be implemented in the form of a virtualized / containerized service, and may / may not reside in one or more of the HTTP server nodes 632-1 and 632-N. The HTTP load balancer 631 may be configured to distribute the connections from the IMS 611 (or the PM reporting workload 611-1 to 611-N) to one or more of the HTTP server nodes 632-1 and 632-N, thereby balancing the load on each of the HTTP server nodes 632-1 and 632-N. For instance, whenever the HTTP load balancer 631 receives an HTTP message from a PM reporting workload(s), the HTTP load balancer 631 may determine the statusof each of the HTTP server nodes 632-1 to 632-N and then appropriate forward the HTTP message to the HTTP server node(s) that has less load. Unlike the Web Socket-based data transportation where a connection persistently may stay with a particular server node, the HTTP request / response can be forwarded to any of the suitable HTTP server node(s) without requiring persistent attachment with a particular HTTP server node(s).

[0102] The HTTP server nodes 632-1 to 632-N may refer to the server nodes that terminate the HTTP data transport protocol. For instance, one or more of the HTTP server nodes 632-1 to 632-N may receive an HTTP message from one or more of the PM reporting workload 611-1 to 611-N (via the HTTP load balancer 631), may process the HTTP message to obtain the O-Cloud data (e.g., PM data), may provide the received data to one or more of the SMOF 621-1 to 621-N directly (e.g., via HTTP data transportation) and / or via the optional message bus / broker 633, and may provide another HTTP message (e.g., 200 OK status code) to response to the HTTP message from the PM reporting workload(s).

[0103] According to example embodiments, one or more of the HTTP server nodes 632-1 to 632-N are included to provide high availability. In this way, the HTTP server nodes may be scaled up (when required) to, for example, match the increasing traffic demand from the IMS 611 (e.g., when the IMS 611 makes connections to more HTTP server nodes, etc.), avoid failure or down time due to single server node or single transport path failure, and the like.

[0104] The optional message bus / broker 633 may be implemented as a middleware layer that decouples the front-end HTTP server nodes 632-1 to 632-N from the back-end services (e.g., SMOFs 621-1 to 621-N). In this way, the back-end services may see data from all independent HTTP server nodes 632-1 to 632-N, the routing of data to back-end services may be independent to data routing at the front-end, data transport protocol may be independent, and the backendservice and front-end HTTP server nodes may be scaled independently. The detailed implementations of a message bus / broker for transporting data have been described above with reference to FIG. 4A to FIG. 4B, and it is contemplated that similar mechanisms, operations, and configurations may be applicable herein in a similar manner.

[0105] The SMOFs 621-1 to 621-N may each be a data consumer that receive the data of the O-Cloud node(s) 612-1 to 612-N, and then utilize the received O-Cloud data to perform various operations, such as policy decision making / updating, AI / ML inference or model training, further data distribution (e.g., to a Near-RT RIC, etc.), and the like. The SMOFs 621-1 to 621-N may also be implemented as applications within the SMO (e.g., rApps). When the optional message bus / broker 633 is involved, the SMOFs 621-1 to 621-N may subscribe to one or more message bus topics (e.g., “PM data”, etc.), thereby retrieving or streaming the O-Cloud data from the message bus / broker 633 without requiring direct connections to the associated HTTP server node(s). On the other hand, when the optional message bus / broker 633 is not involved, the HTTP server node(s) may provide the O-Cloud data to the associated SMOFs 621-1 to 621-N via a respective HTTP message, and the SMOFs 621-1 to 621-N may receive the HTTP message and obtain the O-Cloud data therefrom.

[0106] In view of the above, by implementing HTTP data transport protocol, the IMS 611 (or the PM reporting workload 611 -1 to 611 -N associated therewith) may establish a non-persistent connection(s) / session(s) with the associated HTTP server node(s) when required (e.g., when a data transportation is needed, etc.), without requiring the establishment and maintenance of any persistent connection(s) / session(s) with any of the server node(s). Advantageously, the network resource utilization may be optimized (since the resource overhead of persistent connections / sessions can be avoided), and the HTTP server nodes can be easily scaled-up and / orscaled-down according to the actual demand (since no persistent connection is established or maintained between the HTTP server nodes and the IMS 611).

[0107] In view of the above, FIG. 1 to FIG. 6B provide and exemplify various system configurations, architectures, and mechanisms for efficiently and effectively implementing various types of data reporting / streaming methods (that may support or utilize various types of transport protocols or frameworks) in transporting O-Cloud data in the O-RAN-based networks, thereby increasing the flexibility, effectiveness, and efficiency for delivering the O-Cloud data (and the associated 02ims service).

[0108] Specifically, FIG. 1 to FIG. 3 provide example embodiments that clarify and exemplify how various types of data transport / streaming methods (that support various types of data transport protocols or frameworks, serialization formats, and compression algorithms) may be implemented seamlessly in the O-RAN-based networks via utilizing existing 0-RAN components (e.g., SMO, O-Cloud, IMS, FOCOM, etc.) and existing 0-RAN interface (e.g., 02 interface). The example embodiments of FIG. 1 to FIG. 3 also clarify and exemplify how a first network entity (e.g., 02-IMS producer like an IMS of an O-Cloud) and a second network entity (e g., 02-IMS consumer like a FOCOM of an SMO) may interoperate to communicate with each other via the supported data reporting / streaming methods. For instance, the first network entity may communicate with the second network entity through a connection / streaming session based on a data reporting / streaming method selected from among a plurality of data reporting / streaming methods (e.g., connection-based streaming that utilizes WebSocket data transport protocol, event notification-based streaming that utilizes HTTP data transport protocol / RPC data transport protocol / message bus data transport framework, active collection-based streaming, etc.). Further, the example embodiments of FIG. 1 to FIG. 3 also clarify and exemplify how the first networkentity may communicate with the second network entity to share information on the supported data reporting / streaming method(s), select an appropriate data reporting / streaming method, establish a connection / streaming session based on the selected data reporting / streaming method, and provide / consume an 02ims service (or the associated data) during the established connection / streaming session. Accordingly, the example embodiments of FIG. 1 to FIG. 3 clarify and exemplify how multiple data reporting / streaming methods may be effectively and efficiently implemented for providing O-Cloud data and 02ims services (e.g., data reporting service, etc.) in the O-RAN-based networks, while ensuring the functional and performance requirements of O-Cloud, the compatibility to existing industry implementations, and the interoperability among different parties (e.g., vendors, operators, etc.).

[0109] Further, FIG. 4A to FIG. 6B provide example embodiments that clarify and exemplify the detailed system configurations, architectures, and mechanisms for implementing different types of data transport protocols or frameworks in the O-RAN-based networks (e.g., when the associated data reporting / streaming method is selected by the 02-IMS consumer for O-Cloud data transportation). For instance, example embodiments of FIG. 4A and FIG. 4B clarify and exemplify how the message bus framework (e.g., Kafka framework) can be implemented by utilizing existing 0-RAN components (e.g., SMO, O-Cloud, IMS, FOCOM, etc.) and existing O-RAN interface (e.g., 02 interface), example embodiments of FIG. 5A and FIG. 5B clarify and exemplify how the WebSocket data transport protocol can be implemented via utilizing existing 0-RAN components (e.g., SMO, O-Cloud, IMS, FOCOM, etc.) and existing 0-RAN interface (e.g., 02 interface), and example embodiments of FIG. 6A and FIG. 6B clarify and exemplify how the HTTP data transport protocol can be implemented via utilizing existing 0-RAN components (e.g., SMO, O-Cloud, IMS, FOCOM, etc.) and existing 0-RAN interface (e.g., 02 interface). Thecharacteristics and technical advantages of each type of data transport protocol / framework are also clarified.

[0110] To this end, example embodiments of the present disclosure provide comprehensive clarifications and exemplifications for efficiently and effectively implementing multiple types of data transport / streaming methods in the O-RAN-based networks for O-Cloud data transportation.[0U1] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure. Further descriptions of example methods and operations of example embodiments are provided below with reference to FIG. 7 to FIG. 12, descriptions of several example use cases are provided below with reference to FIG. 13A to FIG. 14, descriptions of an example device for implementing one or more example embodiments are provided below with reference to FIG. 15, and descriptions of an example environment for implementing one or more example embodiments are provided below with reference to FIG. 16.Example Methods and Operations

[0112] As described above with reference to FIG. 1 to FIG. 6B, network entities of an O-RAN-based network (e.g., 02-IMS producer like an IMS of an O-Cloud, 02-IMS consumer like a FOCOM of an SMO, etc.) may interoperate to implement multiple data reporting / streaming methods based on multiple types of data transport protocols / frameworks for transporting O-Cloud data (e.g., data associated with an 02ims service, such as PM data associated with a PM data reporting service, etc.). Several example methods and operations for implementing one or more example embodiments are described below with reference to FIG. 7 to FIG. 12. One or morefeatures, parameters, and operations associated with FIG. 7 to FIG. 12 may be similar to or involve one or more features, parameters, and operations described above with reference to FIG. 1 to FIG.6B, thus redundant descriptions associated therewith may be omitted below for conciseness.

[0113] For descriptive purposes, the methods and operations may be mainly illustrated in FIG. 7 to FIG. 12 as being performed by one or more specific network entities, elements or components, although it can be understood that, in actual implementations, another related network entity(s) may perform similar / related operations, without departing from the scope of the present disclosure. For instance, an operation of a first network entity (e g., an O-Cloud IMS) providing a data to a second network entity (e.g., an SMO FOCOM) may suggest or indicate an operation of the second network entity receiving the data from the first network entity, and the like.

[0114] According to example embodiments, one or more operations of described herein may be implemented in one or more devices or hardware components. For instance, the network entity or network element, such as the IMS of O-Cloud or FOCOM of SMO (or one or more associated operations), may be implemented in an apparatus or a device that includes a processor and a memory storage (or any other suitable storage mediums), wherein the memory storage may include computer-executable instructions which, when being executed by the processor, cause the processor to perform one or more operations associated therewith. Descriptions of an example device / apparatus are provided below with reference to FIG. 15.

[0115] FIG. 7 illustrates a first example method 700, according to one or more example embodiments. One or more operations in method 700 may be implemented by a network entity or network element (or a system that includes the network entity / network element) that implements one of an 02-IMS producer or an 02-IMS consumer to communicate with another network entity or network element that implements another one of the 02-IMS producer or the 02-IMS consumer.For descriptive purposes, the network entity that performs the operations of method 700 may be referred to as the “first network entity”, while the another network entity may be referred to as the “second network entity”.

[0116] Referring to FIG. 7, at operation S710, the first network entity may be configured to communicate with a second network entity capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity. In this regard, the plurality of streaming methods may include: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming.

[0117] Generally, the connection-based streaming and event notification-based streaming may be initiated by the 02-IMS producer (e.g., the IMS of the O-Cloud) to actively provide data to the 02-IMS consumer (e.g., the FOCOM of the SMO), while the active collection-based streaming may be initiated by the 02-IMS consumer (i.e., the FOCOM of the SMO) to actively collect data from the 02-IMS producer (i.e., the IMS of the O-Cloud).

[0118] In this regard, the connection-based streaming may implement the WebSocket data transport protocol (e.g., example system configurations for implementing the WebSocket data transport protocol have been described above with reference to FIG. 5A and FIG. 5B). Namely, the connection-based streaming may include a persistent connection-based streaming, in which the established connection / streaming session is typically opened and kept open without having to renegotiate or reestablished. Further, connection-based streaming may be used to send a flow of data bursts. Once the WebSocket session / connection is opened, the metadata about the streams is exchanged, the 02-IMS producer (e.g., the IMS of the O-Cloud) may then provide data via the opened connection and the 02-IMS consumer (e.g., the FOCOM of the SMO) may receive the data via the opened connection. One of the characteristics of persistent connection-based streamingis that the date (e.g., metadata, etc.) does not need to be exchanged with every data burst. The connection-based streaming may include a persistent connection-based streaming, and the establishment of the connection / streaming session associated therewith may be triggered by the 02-IMS producer and / or the 02-IMS consumer. Upon establishing the connection / streaming session, the 02-IMS producer may actively provide data to the 02-IMS consumer therethrough.

[0119] Further, event notification-based streaming may implement various data transport protocols or frameworks, such as the message bus data transport framework like Kafka framework (e g., example system configurations for implementing the message bus data transport framework have been described above with reference to FIG. 4A and FIG. 4B), HTTP data transport protocol (e.g., example system configurations for implementing the HTTP data transport protocol have been described above with reference to FIG. 6A and FIG. 6B), the RPC data transport protocol like gRPC, and the like. For the event notification-based streaming, a new connection / streaming session is established / reestablished between the 02-IMS producer (e.g., the IMS of the O-Cloud) and the 02-IMS consumer (e.g., the FOCOM of the SMO) for each data reporting. In this regard, the data may be sent as a data payload of a notification.

[0120] On the other hand, active collection-based streaming may be implemented by the 02-IMS consumer (e.g., the FOCOM of the SMO) to actively pull data (e.g., PM data, FM data, etc.) from the 02-IMS producer (e.g., the IMS of the O-Cloud). In this regard, active collectionbased streaming may implement one or more of a configuration management read operation and a data scraping operation. The configuration management read operation may include reusing of a configuration management approach where attributes (e.g., read-only attributes, etc.) conveying the value of data (e.g., performance data, etc.) is read by the second network entity like any other configuration management attribute. For instance, the 02-IMS producer (e.g., the IMS of the O-Cloud) may continuously / periodically expose the value of the data as read-only attributes in the associated management data model, and the 02-IMS consumer (e.g., the FOCOM of the SMO) may periodically read or retrieve the current value of the data. On the other hand, the data scraping operation may include utilizing a collector (or any other suitable data scraping tools) to obtain the data (e.g., PM data, FM data, etc.) from a pre-defined URI. For instance, the 02-IMS producer (e.g., the IMS of the O-Cloud) may host the data at a predefined streaming endpoint (e.g., HTTP endpoint, etc.), and the 02-IMS consumer (e.g., the FOCOM of the SMO) may scrape or obtain the data therefrom.

[0121] In view of the above, various types of data streaming / reporting methods may be supported by the first network entity and the second network entity, each of which may be designed to meet certain cloud requirements and may excel in certain scenarios. According to example embodiments, the first network entity may include one of an 02-IMS producer (e.g., an IMS of an O-Cloud) or an 02-IMS consumer (e.g., a FOCOM of an SMO), and the second network entity may include the another one of the O2-IM producer (e.g., the IMS of the O-Cloud) or the 02-IMS consumer (e.g., the FOCOM of the SMO). The descriptions of FIG. 7 will be provided by (1) first assuming that the first network entity includes the 02-IMS producer such as the IMS of the O-Cloud, and the second network entity includes the 02-IMS consumer such as the FOCOM of the SMO, and then (2) assuming that the first network entity includes the 02-IMS consumer such as the FOCOM of the SMO, and the second network entity includes the 02-IMS producer such as the IMS of the O-Cloud.

[0122] Assuming that the first network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud) and the second network entity includes the 02-IMS consumer (e g., a FOCOM of an SMO), at operation S710, the first network entity may communicate with the second networkentity to, for example, exchange information associated with the preparatory stage of a data reporting / streaming session. For instance, at operation S710, the first network entity may communicate with the second network entity to exchange information of the supported data reporting / streaming methods, the selected data reporting / streaming method, and the like. Descriptions of example operations associated therewith are provided below with reference to FIG.12. Accordingly, at operation S720, the first network entity may be configured to communicate with the second network entity through a streaming session based on the data reporting / streaming method selected from among the plurality of data reporting / streaming methods, to thereby provide O-Cloud data (or an associated data reporting service, etc.) to the second network entity. In this regard, the data reporting service may include a service for reporting at least one of PM data associated with an O-Cloud, FM data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud. For instance, the first network entity may communicate with the second network entity through the streaming session to provide, to the second network entity, one or more of the PM data, the FM data, and the Tracing and Analytic data associated with the O-Cloud.

[0123] Next, assuming that the first network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO) and the second network entity is an 02-IMS producer (e.g., an IMS of an O-Cloud), the first network entity may be capable of using a data reporting / streaming method selected from among a plurality of data reporting / streaming methods (e.g., a connection-based streaming, an event notification-based streaming, an active collection-based streaming) to communicate with the second network entity. In this regard, at operation S710, the first network entity may communicate with the second network entity to, for example, exchange information associated with the preparatory stage of a data reporting / streaming session (e.g., information of the supporteddata reporting / streaming methods, information of the selected data reporting / streaming method, etc.). Accordingly, at operation S720, the first network entity may be configured to communicate with the second network entity, through a streaming session based on the data reporting / streaming method selected from among the plurality of data reporting / streaming methods, to receive O-Cloud data (or an associated data reporting service, such as a data reporting service for reporting at least one of: PM data associated with an O-Cloud, FM data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud, etc.). For instance, the first network entity may communicate with the second network entity through the streaming session to receive, from the second network entity, one or more of the PM data, the FM data, and the Tracing and Analytic data associated with the O-Cloud.

[0124] Descriptions of several example operations, where the first network entity is configured to implement various types of data reporting / streaming methods to communicate and provide data to (or receive data from) the second network entity, are provided below with reference to FIG. 8 to FIG. 11.

[0125] Referring next to FIG. 8, which illustrates a second example method 800, according to one or more example embodiments. One or more operations in method 800 may be part of or similar to operation S720 in method 700. Specifically, one or more operations in method 800 may be performed by the first network entity to communicate with the second network entity through the streaming session, when the data reporting / streaming method selected from among the plurality of data reporting / streaming methods includes the connection-based streaming (e.g., persistent connection-based streaming) that is initiated by the network entity that acts as the 02-IMS producer.

[0126] As described above, the first network entity may include one of an 02-IMS producer (e.g., an IMS of an O-Cloud) or an 02-IMS consumer (a FOCOM of an SMO), and the second network entity may include the another one of the 02-IMS producer (e.g., the IMS of the O-Cloud) or the 02-IMS consumer (e.g., the FOCOM of the SMO).

[0127] Assuming that the first network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud) and the second network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO), at operation S810, the first network entity may be configured to provide, to the second network entity, a request to open a connection between the first network entity and the second network entity. At this operation, the first network entity (i.e., the 02-IMS producer) may attempt to open the connection to the subscription endpoint. Accordingly, at operation S820, the first network entity may receive, from the second network entity, a response indicating that the connection has successfully opened. Subsequently, at operation S830, the first network entity may provide data (e.g., PM data, FM data, Tracing and Analytic data, etc.) to the second network entity via the opened connection.

[0128] It is contemplated that the operations illustrated in FIG. 8 are merely examples and the scope of the present disclosure should not be limited thereto. For instance, although the operations in FIG. 8 are illustrated as being performed by the first network entity when the first network entity is an 02-IMS producer (e.g., an IMS of an O-Cloud), it can be understood that, in example embodiments where the first network entity is an 02-IMS consumer (e.g., a FOCOM of an SMO), the first network entity may perform similar / related operations from the opposite site, without departing from the scope of the present disclosure.

[0129] For instance, assuming that the first network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO) and the second network entity includes the 02-IMS producer (e.g.,an IMS of an O-Cloud), at operation S810, the first network entity may be configured to receive, from the second network entity, a request to open a connection between the first network entity and the second network entity. Accordingly, at operation S820, the first network entity may open the connection (e.g., by provisioning the subscriber endpoint, etc.) in response to the request, and then provide a response (that indicates that the connection has successfully opened) to the second network entity. Accordingly, at operation S830, the first network entity may receive data (e.g., PM data, FM data, Tracing and Analytic data, etc.) from the second network entity via the opened connection.

[0130] Referring next to FIG. 9, which illustrates a third example method 900, according to one or more example embodiments. One or more operations in method 900 may be part of or similar to operation S720 in method 700. Specifically, one or more operations in method 900 may be performed by the first network entity to communicate with the second network entity through the streaming session, when the data reporting / streaming method selected from among the plurality of data reporting / streaming methods includes the connection-based streaming (e.g., persistent connection-based streaming) that is initiated by the network entity that acts as the 02-IMS consumer.

[0131] As described above, the first network entity may include one of an 02-IMS producer (e.g., an IMS of an O-Cloud) or an 02-IMS consumer (a FOCOM of an SMO), and the second network entity may include the another one of the 02-IMS producer (e.g., the IMS of the O-Cloud) or the 02-IMS consumer (e.g., the FOCOM of the SMO).

[0132] Assuming that the first network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud) and the second network entity includes the 02-IMS consumer (e g., a FOCOM of an SMO), at operation S910, the first network entity may be configured to receive, from the secondnetwork entity, a request to open a connection between the first network entity and the second network entity. At this operation, the second network entity (i.e., the 02-IMS consumer) may attempt to open the connection to the producer / publisher endpoint. Accordingly, at operation S920, the first network entity may open the connection (e.g., by provisioning the producer / publisher endpoint, etc.) in response to the request, and then provide a response (that indicates that the connection has successfully opened) to the second network entity. Accordingly, at operation S930, the first network entity may provide data (e.g., PM data, FM data, Tracing and Analytic data, etc.) to the second network entity via the opened connection.

[0133] It is contemplated that the operations illustrated in FIG. 9 are merely examples and the scope of the present disclosure should not be limited thereto. For instance, although the operations in FIG. 9 are illustrated as being performed by the first network entity when the first network entity is an 02-IMS producer (e.g., an IMS of an O-Cloud), it can be understood that, in example embodiments where the first network entity is an 02-IMS consumer (e.g., a FOCOM of an SMO), the first network entity may perform similar / related operations from the opposite site, without departing from the scope of the present disclosure.

[0134] For instance, assuming that the first network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO) and the second network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud), at operation S910, the first network entity may be configured to provide, to the second network entity, a request to open a connection between the first network entity and the second network entity. Accordingly, at operation S920, the first network entity may receive, from the second network entity, a response indicating that the connection has successfully opened. Accordingly, at operation S930, the first network entity may receive data (e.g., PM data, FM data, Tracing and Analytic data, etc.) from the second network entity via the opened connection.

[0135] Referring next to FIG. 10, which illustrates a fourth example method 1000, according to one or more example embodiments. One or more operations in method 1000 may be part of or similar to operation S720 in method 700. Specifically, one or more operations in method 1000 may be performed by the first network entity to communicate with the second network entity through the streaming session, when the data reporting / streaming method selected from among the plurality of data reporting / streaming methods includes the event notification-based streaming (e.g., streaming based on at least one of a message bus data transport framework, an HTTP data transport protocol, or an RPC data transport protocol, etc ).

[0136] As described above, the first network entity may include one of an 02-IMS producer (e.g., an IMS of an O-Cloud) or an 02-IMS consumer (a FOCOM of an SMO), and the second network entity may include the another one of the 02-IMS producer (e.g., the IMS of the O-Cloud) or the 02-IMS consumer (e.g., the FOCOM of the SMO).

[0137] Assuming that the first network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud) and the second network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO), at operation S1010, the first network entity may be configured to receive, from the second network entity, a request to configure a streaming endpoint. At this operation, the second network entity may attempt to configure the streaming endpoint(s) to the first network entity, along with other transport protocol and / or transport framework-specific parameters. Accordingly, at operation SI 020, the first network entity may configure the streaming endpoint based on the request, and then provide a response (that indicates that the streaming endpoint is configured successfully) to the second network entity. Subsequently, at operation S1030, the first network entity may provide data (e.g., PM data, FM data, Tracing and Analytic data, etc.) to the second network entity via the streaming endpoint.

[0138] It is contemplated that the operations illustrated in FIG. 10 are merely examples and the scope of the present disclosure should not be limited thereto. For instance, although the operations in FIG. 10 are illustrated as being performed by the first network entity when the first network entity is an 02-IMS producer (e.g., an IMS of an O-Cloud), it can be understood that, in example embodiments where the first network entity is an 02-IMS consumer (e.g., a FOCOM of an SMO), the first network entity may perform similar / related operations from the opposite site, without departing from the scope of the present disclosure.

[0139] For instance, assuming that the first network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO) and the second network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud), at operation S 1010, the first network entity may be configured to provide, to the second network entity, a request to configure a streaming endpoint. Accordingly, at operation SI 020, the first network entity may receive, from the second network entity, a response indicating that the streaming endpoint is configured successfully. Accordingly, at operation S1030, the first network entity may receive data (e.g., PM data, FM data, Tracing and Analytic data, etc.) from the second network entity via the streaming endpoint.

[0140] Referring next to FIG. 11, which illustrates a fifth example method 1100, according to one or more example embodiments. One or more operations in method 1100 may be part of or similar to operation S720 in method 700. Specifically, one or more operations in method 1100 may be performed by the first network entity to communicate with the second network entity through the streaming session, when the streaming method selected from among the plurality of streaming methods includes the active collection-based streaming.

[0141] As described above, the first network entity may include one of an 02-IMS producer (e.g., an IMS of an O-Cloud) or an 02-IMS consumer (a FOCOM of an SMO), and thesecond network entity may include the another one of the 02-IMS producer (e.g., the IMS of the O-Cloud) or the 02-IMS consumer (e.g., the FOCOM of the SMO).

[0142] Assuming that the first network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud) and the second network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO), at operation SI 110, the first network entity may be configured to receive, from the second network entity, a parameter associated with at least one of a transport protocol or a transport framework. At this operation, the second network entity may attempt to configure the first network entity to be ready for data collection, along with other transport protocol and / or transport framework-specific parameters. Accordingly, at operation SI 120, the first network entity may apply a configuration based on the parameter (e.g., configuring the underlying software and / or physical components according to the transport protocol and / or transport framework, applying protocol-specific / framework-specific settings, generating / updating an associated URI, etc.), such that the first network entity is ready for data to be collected by the second network entity. Accordingly, at operation S 1130, the first network entity may provide, to the second network entity, a response that includes a URI (e.g., an URI that includes a URL / URN that is configured according to the configuration defined by the parameter and enables the second network entity to obtain data therefrom). Subsequently, at operation S I 140, the first network entity may provide data (e.g., PM data, FM data, Tracing and Analytic data, etc.) to the second network entity via the URI. In some example embodiments, the data may be provided in the form of data payload. For instance, the second network entity may attempt to collect the data payload (e.g., PM data, FM data, Tracing and Analytic data, etc.) by sending a data collection request to the provided URI. If the data payload is ready to be collected from the first network entity, a data collection response that includes the data payload may be provided to the second network entity.

[0143] It is contemplated that the operations illustrated in FIG. 11 are merely examples and the scope of the present disclosure should not be limited thereto. For instance, although the operations in FIG. 11 are illustrated as being performed by the first network entity when the first network entity is an 02-IMS producer (e.g., an IMS of an O-Cloud), it can be understood that, in example embodiments where the first network entity is an 02-IMS consumer (e.g., a FOCOM of an SMO), the first network entity may perform similar / related operations from the opposite site, without departing from the scope of the present disclosure.

[0144] For instance, assuming that the first network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO) and the second network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud), at operation SI 110, the first network entity may be configured to provide, to the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework. Accordingly, the second network entity may apply a configuration based on the provided parameter, and then provide a response that includes an associated URI. Thus, at operation SI 130, the first network entity may receive, from the second network entity, the response that includes the URI. Accordingly, at operation SI 140, the first network entity may receive data (e.g., PM data, FM data, Tracing and Analytic data, etc.) from the second network entity via the URI (e.g., in the form of data payload, etc.).

[0145] Referring next to FIG. 12, which illustrates a sixth example method 1200, according to one or more example embodiments. One or more operations in method 1200 may be part of or similar to one or more operations in methods 700-1100. For instance, operations S1210-S1230 in method 1200 may be part of or similar to operation S710 in method 700, where the first network entity may communicate with the second network entity to exchange information associated with the preparatory stage of a data reporting / streaming session. Further, operation S1240 may be partof or similar to operation S720 in method 700, and / or may involve one or more operations in methods 800-1100, where the first network entity may communicate with the second network entity through a streaming session based on the data reporting / streaming method selected from among the plurality of data reporting / streaming methods, to thereby provide / receive a data reporting service to / from the second network entity.

[0146] As described above, the first network entity may include one of an 02-IMS producer (e.g., an IMS of an O-Cloud) or an 02-IMS consumer (a FOCOM of an SMO), and the second network entity may include the another one of the 02-IMS producer (e.g., the IMS of the O-Cloud) or the 02-IMS consumer (e.g., the FOCOM of the SMO).

[0147] Assuming that the first network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud) and the second network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO), at operation S1210, the first network entity may be configured to provide, to a second network entity, information associated with one or more data reporting / streaming methods supported by the first network entity.

[0148] According to example embodiments, the information associated with the one or more data reporting / streaming methods supported by the first network entity may include at least one of: a data reporting / transport protocol supported by the first network entity, a data reporting / transport framework supported by the first network entity, a serialization format supported by the first network entity, or a compression algorithm supported by the first network entity. According to example embodiments, the first network entity may provide the information associated with the supported data reporting / streaming method(s) to the second network entity via an 02 interface. For example, the first network entity may provide said information to the second network entity via a control plane communication (e.g., via one or more HTTP / RPC messages,etc.) during the service subscription stage (e.g., when the second network entity subscribe to a data streaming / reporting service provided by the first network entity, etc ).

[0149] Referring still to FIG. 12, at operation S1220, the first network entity may be configured to receive, from the second network entity, information associated with a data reporting / streaming method selected from among the one or more data reporting / streaming methods supported by the first network entity. Specifically, upon providing the information associated with the supported data reporting method(s) to the second network entity, the second network entity may select an appropriate / optimal data reporting / streaming method (e.g., data reporting / streaming method that are supported by both the first network entity and the second network entity, data reporting / streaming method that may comply to the QoS requirements, etc.) and provide the information associated therewith to the first network entity.

[0150] According to example embodiments, the information associated with the selected data reporting / streaming method may include at least one of a configuration associated with the selected data reporting / streaming method, a serialization format associated with the selected data reporting / streaming method, or a compression algorithm associated with the selected data reporting method. According to example embodiments, the first network entity may receive the information associated with the selected data reporting / streaming method from the second network entity via the 02 interface. For example, the first network entity may receive said information from the second network entity via the control plane communication (e.g., via one or more HTTP / RPC messages, etc.) during the service subscription stage (e.g., when the second network entity subscribe to a data streaming / reporting service provided by the first network entity, etc.).

[0151] Referring still to FIG. 12, at operation S1230, the first network entity may be configured to establish, based on the selected data reporting / streaming method, a streaming sessionwith the second network entity. The established streaming session may be persistent or non-persistent, and may be based on at least one of: a connection-based streaming, an event notification-based streaming, or an active collection-based streaming. Further, the data streaming session may be based on at least one of: a message bus data transport framework, a Web Socket data transport protocol, an HTTP data transport protocol, or an RPC data transport protocol. Accordingly, at operation S1240, the first network entity may be configured to provide data (e.g., PM data, FM data, Tracing and Analytic data, etc.) to the second network entity during the streaming operation.

[0152] By way of examples, assuming that the data includes PM data associated an O-Cloud, if the selected data reporting / streaming method is associated with an event notificationbased streaming that is based on a message bus framework, the first network entity may be configured to initialize an associated message bus client (e.g., Kafka client) to communicate with a message bus broker (e.g., a Kafka message broker server node), and join a data topic (e.g., “PM data”) managed by the message bus broker. Subsequently, each time the O-Cloud data (e.g., PM data) is available, the first network entity may provide the O-Cloud data to the message bus broker, and the message bus broker may publish the O-Cloud data such that the second network entity may obtain or stream the O-Cloud data therefrom.

[0153] On the other hand, if the selected data reporting / streaming method is associated with a connection-based streaming that is based on a WebSocket data transport protocol, the first network entity may be configured to initialize a WebSocket client to send a handshake message to a WebSocket server node (via a WebSocket load balancer) to establish or open a session / connection (e.g., persistent connection) therewith. Accordingly, whenever the O-Cloud data (e.g., PM data) is available, the first network entity may push the O-Cloud data to theWebSocket server node in real-time (or near-real-time). Subsequently, the WebSocket server node may provide the O-Cloud data to the second network entity directly (e.g., via establishing another persistent WebSocket session / connection) and / or via a message bus / broker.

[0154] Further, if the selected data reporting / streaming method is associated with an event notification-based streaming that is based on an HTTP data transport protocol, whenever an O-Cloud data (e.g., PM data) is available, the first network entity may provide an HTTP message (e.g., POST, GET, etc.) that includes the O-Cloud data to an HTTP load balancer, and the HTTP load balancer may forward the HTTP message to an appropriate HTTP server node(s). Subsequently, the HTTP server node may provide the O-Cloud data to the second network entity directly (e.g., via sending the HTTP message / another HTTP message to the second network entity) and / or via a message bus / broker.

[0155] According to example embodiments, assuming that the information received from the second network entity (at operation SI 220) includes information on a serialization format associated with the selected data reporting / streaming method, the first network entity may perform one or more operations to serialize the associated O-Cloud data (e.g., converting the O-Cloud data into a specific format such as JSON, XML ASN.l, protobuf, etc.) according to the serialization format associated with the selected data reporting / streaming method, before providing the 02ims service (or the associated O-Cloud data) to the second network entity. Additionally or alternatively, assuming that the information received from the second network entity (at operation SI 220) includes information on a compression algorithm associated with the selected data reporting / streaming method, the first network entity may perform one or more operations to compress the associated O-Cloud data according to the serialization format (e.g., zstd, gzip, LZ4,Snappy, etc.) associated with the selected data reporting / streaming method, before providing the 02ims service (or the associated O-Cloud data) to the second network entity.

[0156] It is contemplated that the operations illustrated in FIG. 12 are merely examples and the scope of the present disclosure should not be limited thereto. For instance, although the operations in FIG. 12 are illustrated as being performed by the first network entity when the first network entity is an 02-IMS producer (e.g., an IMS of an O-Cloud), it can be understood that, in example embodiments where the first network entity is an 02-IMS consumer (e.g., a FOCOM of an SMO), the first network entity may perform similar / related operations from the opposite site, without departing from the scope of the present disclosure.

[0157] For instance, assuming that the first network entity includes the 02-IMS consumer (e.g., a FOCOM of an SMO) and the second network entity includes the 02-IMS producer (e.g., an IMS of an O-Cloud), at operation S1210, the first network entity may be configured to receive, from a second network entity, information associated with one or more data reporting / streaming methods supported by the second network entity.

[0158] According to example embodiments, the information associated with the one or more data reporting / streaming methods supported by the second network entity may include at least one of: a data reporting / transport protocol supported by the second network entity, a data reporting / transport framework supported by the second network entity, a serialization format supported by the second network entity, or a compression algorithm supported by the second network entity. According to example embodiments, the first network entity may receive the information associated with the supported data reporting / streaming method(s) from the second network entity via an 02 interface. For example, the first network entity may receive said information from the second network entity via a control plane communication (e.g., via one ormore HTTP / RPC messages, etc.) during the service subscription stage (e.g., when the first network entity subscribes to a data streaming / reporting service provided by the second network entity, etc.).

[0159] Further, assuming that the first network entity includes the O2-IMS consumer (e.g., a FOCOM of an SMO) and the second network entity includes the O2-IMS producer (e.g., an IMS of an O-Cloud), at operation SI 220, the first network entity may be configured to select, from among the one or more data reporting / streaming methods supported by the second network entity, a data reporting / streaming method. For instance, the first network entity may select the data reporting / streaming method from among the one or more data reporting / streaming methods supported by the second network entity, based on a capability of the first network entity (e.g., data reporting method that are supported by the first network entity, etc.), a service quality requirement (e.g., a requirement defined in a QoS agreement, etc.), and / or the like. In some example implementations, the first network entity may be configured to select one or more of: a data transport protocol, a data transport framework, a serialization format, and a compression algorithm. In this way, the first network entity may select the most appropriate / optimal data reporting / streaming method (e.g., data transport protocol, data transport framework, serialization format, a compression algorithm, etc.) that are supported by both the first network entity and the second network entity and ensuring the selected data reporting / streaming method can fulfill other network requirement (e.g., service quality requirement, etc.).

[0160] Upon selecting the data reporting / streaming method, the first network entity may provide, to the second network entity, the information associated with the selected data reporting / streaming method. According to example embodiments, the information associated with the selected data reporting / streaming method may include at least one of: a configuration associated with the selected data reporting / streaming method, a serialization format associatedwith the selected data reporting method, or a compression algorithm associated with the selected data reporting / streaming method.

[0161] According to example embodiments, the first network entity may provide the information associated with the selected data reporting method to the second network entity via the 02 interface. For example, the first network entity may provide said information to the second network entity via the control plane communication (e.g., via one or more HTTP / RPC messages, etc.) during the service subscription stage (e.g., when the first network entity subscribes to a data streaming / reporting service provided by the second network entity, etc.).

[0162] Accordingly, at operation S1240, the first network entity may be configured to receive data (e.g., PM data, FM data, Tracing and Analytic data, etc.) from the second network entity and during a streaming session associated with the selected data reporting / streaming method. Specifically, upon providing the information of the selected data reporting method to the second network entity, the second network entity may establish a streaming session based on the provided information. The established streaming session may be persistent or non-persistent, and may be based on at least one of: a connection-based streaming, an event notification-based streaming, or an active collection-based streaming. Further, the streaming session may be based on at least one of: a message bus framework, a WebSocket data transport protocol, an HTTP data transport protocol, or an RPC data transport protocol.

[0163] By way of examples, assuming that data includes PM data associated an O-Cloud, if the selected data reporting / streaming method is associated with an event notification-based streaming that is based on a message bus framework, the second network entity may establish the streaming session with a message bus broker and publish the associated O-Cloud data (e.g., PM data) to the message bus broker. In this case, the first network entity may access the message busbroker and receive the O-Cloud data therefrom. On the other hand, if the selected data reporting / streaming method is associated with an connection-based streaming that is based on a WebSocket data transport protocol, the second network entity may establish the streaming session with a WebSocket server node and push the O-Cloud data to the WebSocket server node. In this case, the first network entity may directly receive the O-Cloud data from the WebSocket server node (via a persistent WebSocket session / connection) and / or from a message bus / broker to which the WebSocket server node provides the O-Cloud data. Further, if the selected data reporting / streaming method is associated with an event notification-based streaming that is based on an HTTP data transport protocol, the second network entity may establish the streaming session with an HTTP server node and provide the O-Cloud data to the HTTP server node. In this case, the first network entity may directly receive the O-Cloud data from the HTTP server node (via one or more HTTP messages) and / or from a message bus / broker to which the HTTP server node provides the O-Cloud data.

[0164] Further detailed descriptions on how the first network entity and the second network entity communicate and interoperate via various types of data reporting / streaming methods have been provided above with reference to FIG. 1 to FIG. 11. Thus, redundant descriptions associated therewith may be omitted herein for conciseness.

[0165] In view of the above, example embodiments provide methods and operations for effectively and efficiently implementing O-Cloud data transport, thereby providing various technical advantages. To begin with, the operations of method 700 in FIG. 7 may be implemented by a network entity (that acts as one of an 02-IMS producer or an 02-IMS consumer) to effectively and efficiently communicate with another network entity (that acts as the another one of the 02- IMS producer or the 02-IMS consumer) using a data reporting / streaming method selected fromamong a plurality of supported data reporting / streaming methods, such as the connection-based streaming, event notification-based streaming, and active collection-based streaming. Further, the operations of method 800 in FIG. 8 may be implemented by a network entity to effectively and efficiently communicate with another network entity via implementing a connection-based streaming (e.g., persistent connection-based streaming) that is initiated by the network entity. Similarly, the operations of method 900 in FIG. 9 may be implemented by the network entity to effectively and efficiently communicate with the another network entity via implementing a connection-based streaming (e.g., persistent connection-based streaming) that is initiated by the another network entity. Further, the operations of method 1000 in FIG. 10 may be implemented by the network entity to effectively and efficiently communicate with the another network entity via implementing an event notification-based streaming. Furthermore, the operations of method 1100 in FIG. 11 may be implemented by the network entity to effectively and efficiently communicate with the another network entity via implementing an active collection-based streaming.

[0166] Further, the operations of method 1200 in FIG. 12 may be implemented by the network entity to effective and efficiently communicate with the another network entity to exchange information associated with the preparatory stage of a data reporting / streaming session, such as exchanging information of the supported data reporting / streaming methods(s)(e.g., supported transport protocol, supported transport framework, supported serialization format, supported compression algorithm, etc.) and information of the selected data reporting / streaming method(s) (e.g., configuration of the selected data reporting / streaming method, transport protocol / transport framework associated with the selected data reporting / streaming method, etc.).

[0167] To this end, FIG. 7 to FIG. 12 provide example embodiments that clarify and exemplify the methods, operations, and mechanisms that may be implemented by various network entities / network elements of an O-RAN-based network (e.g.., 02-IMS producer like an IMS of an O-Cloud, 02-IMS consumer like a FOCOM of an SMO, etc.) to efficiently and effectively implement various types of data reporting / streaming methods (e.g., streaming methods that may be based on multiple data transport protocol s / firam eworks, multiple serialization formats, multiple compressing algorithms, etc.) to transport O-Cloud data, while ensuring the functional and performance requirements of O-Cloud, the compatibility to existing industry implementations, and the interoperability among different parties (e.g., vendors, operators, etc.). Ultimately, by implementing operations and methods of example embodiments, the O-Cloud data may be transported among the network entities more efficiently and effectively. Further technical advantages have been described above with reference to FIG. 1 to FIG. 6B, and it is contemplated that similar technical advantages may be applicable by implementing the methods and operations of FIG. 7 to FIG. 12.

[0168] It is contemplated that, the methods, operations, advantages, and significances described above with reference to FIG. 7 to FIG. 12 are merely examples and the scope of the present disclosure should not be limited thereto. Specifically, one or more operations in FIG. 7 to FIG. 12 may be performed differently, less or additional operations may be involved, the messages or commands involved therein may include less or additional parameters, additional advantages may be achieved, and the like, without departing from the scope of the present disclosure. Further, it is contemplated that one or more of the above-described parameters, messages, and the like, may be consistent with those specified in one or more standard specifications (e.g., O-RAN.WG6.0RCH-USE-CASES, etc.), with additional parameters, attributes, and mechanisms supplemented thereto.Example Use Cases

[0169] Several example use cases for implementing one or more example embodiments are described below with reference to FIG. 13A o FIG. 14. One or more example use cases described below may involve one or more components, entities, operations, parameters, and / or configurations described above with reference to FIG. 1 to FIG. 6B. Additionally or alternatively, one or more example use cases described below may involve one or more methods described above with reference to FIG. 7 to FIG. 12. Thus, it is contemplated that the example use cases in FIG.13A to FIG. 14 may achieve one or more technical advantages described above with reference to FIG. 1 to FIG. 12.

[0170] FIG. 13 A and FIG. 13B illustrate an example use case of performance measurement (PM) data streaming / reporting, according to one or more example embodiments. In this regard, although example use case 1300 is described herewith with reference to PM data streaming / reporting, similar operations, call flows or mechanisms in FIG. 13A and FIG. 13B may be similarly applicable to any other suitable 02ims services (e.g., data reporting / streaming service for reporting / streaming FM data), without departing from the scope of the present disclosure.

[0171] As illustrated in FIG. 13A and FIG. 13B, example use case 1300 may involve various components from the O-Cloud 1310 (Publisher) (may also be referred to as “Producer” or “02-IMS producer” in some example implementations) and the SMO 1320 (Subscriber) (may also be referred to as “Consumer” or “02-IMS consumer” in some example implementations). Specifically, at the O-Cloud side, an IMS 1311 may be involved; on the other hand, at the SMO side, a FOCOM 1321 may be involved. The O-Cloud 1310, IMS 1311, SMO 1320, and FOCOM1321 in example use case 1300 may be similar to respective components described above with reference to FIG. 1 to FIG. 12.

[0172] One of the goals of example use case 1300 is to exemplify the implementation of PM streaming / reporting, where PM data (or performance data) may be sent or triggered as specified by the subscription filter for connection-based streaming, event notification-based streaming, and active collection-based streaming mechanisms / data reporting methods. In example use case 1300, the FOCOM 1321 is used to represent any consumer of PM data, while the IMS 1311 is used to represent any publisher or producer of the PM data. It may be assumed that, in example use case 1300, the PM subscription has been established and exists at the beginning of the use case. Further, it may be assumed that, in example use case 1300, the data reporting / streaming method (e.g., as well as the associated data model, serialization format, compression algorithm, streaming mechanism, transport protocol / framework, etc.) to be used for streaming / reporting the PM data have been agreed between the SMO 1320 (i.e., the Subscriber) and the O-Cloud 1310 (i.e., the Publisher). Furthermore, it is assumed that, in example use case 1300, the PM job subscription has successfully completed. In addition, it is assumed that, in example use case 1300, the following preconditions are fulfilled: (1) the SMO 1320 (i.e., the Subscriber) has connectivity to the O-Cloud 1310 (i.e., the Publisher) (e.g., via 02 interface, etc.) and the connectivity requirements are fulfilled, (2) the O-Cloud 1310 (i.e., the Publisher) has user credentials for the endpoint of the SMO 1320 (i.e., the Subscriber) and the authentication requirements are fulfilled, and (3) PM Job(s) (e.g., PM reporting workload(s), etc.) are running and actively collecting PM data.

[0173] Example use case 1300 may begin when the subscription filter at the IMS 1311 determines or indicates that a performance data streaming session should be opened. Additionallyor alternatively, example use case 1300 may begin when the SMO 1320 / FOCOM 1321 (i.e., the Subscriber) initiates a streaming session.

[0174] Referring to FIG. 13A, the O-Cloud 1310 (or the IMS 1311) may implement a Performance Subscription Manager (PSM) that may be configured to determine when to send data and what data to send. In this regard, at step 1.1, the PSM may determine (e.g., based on the active subscription(s), etc.) that a specific performance data (e.g., PM data) needs to be sent, and the subscription filter indicates that the data should be sent with a PM streaming / reporting. Accordingly, at step 1.2, the PSM may retrieve the performance data (e.g., PM data) from, for example, a local storage. The performance data (e.g., PM data) may be written by one or more PM Jobs within the O-Cloud, and may be composed to be ready to be sent.

[0175] Upon retrieving the performance data, the O-Cloud 1310 (or the IMS 1311) may transport the data to the SMO 1320 (or the FOCOM 1321) via various data streaming or reporting methods. In example use case 1300, three streaming / reporting methods are illustrated, i.e., a connection-based streaming / data reporting, an event notification-based streaming / data reporting, and an active collection-based streaming / data reporting, which may be similar to those described above with reference to FIG. 1 to FIG. 12. Thus, detailed descriptions associated with the streaming / reporting methods may be omitted below for conciseness. Various types of data streaming / reporting methods may be supported by the O-Cloud 1310 / IMS 1311 (i.e., the Producer) and the SMO 1320 / FOCOM 1321 (i.e., the Consumer), each of which may be designed to meet certain cloud requirements and may excel in certain scenarios. As described above, it is assumed that, in example use case 1300, the data streaming / reporting method to be used for streaming / reporting the PM data have been selected and agreed between the SMO 1320 / FOCOM 1321 (i.e., the Subscriber) and the O-Cloud 1310 / IMS 1311 (i.e., the Producer). In example usecase 1300, after step 1.2, if the connection-based streaming is selected, the use case may proceed to steps 2.1-2.5. On the other hand, if the event notification-based streaming is selected, the use case may proceed to steps 3.1-3.3. Further, if the active collection-based streaming is selected, the use case may proceed to steps 4.1-4.4.

[0176] Referring still to FIG. 13A, steps 2.1-2.5 may begin if the connection-based streaming is selected. In this regard, steps 2.1-2.4 may begin if there is no active or available connection. Otherwise, if a persistent connection is already established and is available, steps 2.1-2.4 may be skipped and example use case 1300 may begin with step 2.5.

[0177] Steps 2.1-2.2 may begin if the IMS O-Cloud 1310 / IMS 1311 (i.e., the Producer) does not already have a connection to the SMO 1320 / FOCOM 1321 (i.e., the Subscriber) and decides to initiate the session connection establishment. At step 2.1, the IMS 1311 may attempt to establish or open a session or connection with the subscription endpoint (e g., a WebSocket server node). The subscription endpoint is typically associated with or managed by the SMO 1320, but any other suitable entity may also be utilized. Assuming that the connection / session is successfully established or opened, the FOCOM 1321 may provide a success response to the IMS 1321 at step 2.2. Accordingly, example use case 1300 may proceed to step 2.5.

[0178] Alternatively, steps 2.3-2.4 may begin if the SMO 1320 / FOCOM 1321 (i.e., the Subscriber) does not already have a connection to the IMS O-Cloud 1310 / IMS 1311 (i.e., the Producer) and decides to initiate the session connection establishment. At step 2.3, the FOCOM 1321 may attempt to establish or open a session or connection with the publisher endpoint (e.g., a WebSocket server node, a WebSocket client, etc.). The publisher endpoint may be associated with or managed by the O-Cloud 1310 / IMS 1311 (or any other suitable entity). Assuming that the connection / session is successfully established or opened, the IMS 1311 may provide a successresponse to the FOCOM 1321 at step 2.4. Accordingly, example use case 1300 may proceed to step 2.5.

[0179] Step 2.5 may begin when a connect! on / session already exists between the IMS O-Cloud 1310 / IMS 1311 (i.e., the Producer / Publisher) and the SMO 1320 / FOCOM 1321 (i.e., the Subscriber / Consumer), or a connection / session has been successfully established therebetween. At this step, the IMS 1311 may send performance data (e.g., in a performance stream, etc.) to the FOCOM 1321. In some example implementations, the IMS 1311 may send the performance data to the FOCOM 1321 via the WebSocket data transport protocol.

[0180] Referring next to FIG. 13B, steps 3.1-3.3 may begin if the event notification-based streaming is selected. At step 3.1, the FOCOM 1321 may attempt to configure or provide information associated with the streaming endpoint(s)(e.g., message bus broker, HTTP server node, etc.) to the IMS 1311 (i.e., the Publisher), along with other transport protocol / framework-specific parameters (e.g., parameters associated with HTTP data transport protocol, message bus data transport framework, RPC data transport protocol / framework, etc.). Assuming that the streaming endpoint(s) and other transport protocol / framework-specific parameters are successfully configured or provided, the IMS 1311 may provide a response to the FOCOM 1321 at step 3.2. Accordingly, at step 3.3, the IMS 1311 may send the performance data (e.g., in the form of payload, etc.) to the streaming endpoint(s) according to the transport protocol / framework specific parameters. In some example implementations, the IMS 1311 may send the performance data to the FOCOM 1321 via HTTP data transport protocol, message bus data transport framework (e.g., Kafka framework), RPC data transport protocol, or any other suitable data transport protocol or framework.

[0181] Referring still to FIG. 13B, steps 4.1-4.4 may begin if the active collection-based streaming is selected. At step 4.1, the FOCOM 1321 may attempt to configure the IMS 1311 (i.e., the Publisher) to be ready for data collection, along with transport protocol / framework-specific parameter. Assuming that the streaming endpoint(s) and other transport protocol / framework-specific parameters are successfully configured or provided, the IMS 1311 may provide a response (along with data collection URI) to the FOCOM 1321 at step 4.2, thereby notifying the FOCOM 1321 that the IMS 1311 is ready for data collection and the FOCOM 1321 may start collection the data from the URI. Accordingly, at step 4.3, the FOCOM 1321 may attempt to collect the data (e.g., by sending a data collection request to the data collection URI, etc.). If the data (e.g., data payload) is ready to be collected, at step 4.4, the IMS 1311 may provide a response (along with the data / data payload) to the FOCOM 921.

[0182] Example use case 1300 may end when either the performance data has been successfully transported or streamed, or when one or more exceptions have been encountered. In this case, an exception may include one or more of a connection cannot be established (e.g., a persistent connection to the subscriber endpoint does not exist and was attempted but could not be established, a connection to the publisher endpoint could not be established, etc.), a configuration cannot be applied (e.g., the IMS 1311 has failed to apply the configuration provided by the FOCOM 1321, etc.), a receiver has rejected a request (e.g., the FOCOM 1321 has indicated that a provided data is rejected thereby), and the like.

[0183] Next, descriptions of an example use case that implements one or more example embodiments to provide an 02ims service are provided below with reference to FIG. 14. Specifically, FIG. 14 illustrates an example use case 1400 that involves an 02-IMS data reporting / streaming service, according to one or more example embodiments. It can be understoodthat one or more components, operations, features, technical advantages, and the like, described above with reference to FIG. 1 to FIG. 13B, may be similarly applicable to example use case 1400.

[0184] Referring to FIG. 14, example use case 1400 may involve an IMS 1410 of an Ci-Cloud 1430 (i.e., an 02-IMS producer) and an 02-IMS consumer 1420 (e.g., a FOCOM). Generally, the 02-IMS consumer 1420 may subscribe to a data reporting / streaming service (e.g., PM data reporting / streaming, etc.) by providing a subscription request (e.g., a request to create a subscription, etc.) to the IMS 1410 via the 02 interface. The subscription request may include information on the desired data and various configuration parameters (e.g., streaming session ID, resource and resource types, measurement selection criteria, report format, measurement report frequency, data reporting / streaming method configurations, etc.). Accordingly, the IMS 1410 may collect the data and provide the data to the 02-IMS consumer 1420 (e.g., publish the data to a message bus / message broker, send an HTTP message that includes the data to the 02-IMS consumer 1420, establish a persistent connection with the 02-IMS consumer / a consumer endpoint and push the data thereto, etc.), thereby enabling the 02-IMS consumer 1420 to stream and obtain the data.

[0185] In this example use case, it is assumed that the 02-IMS consumer 1420 creates two subscription requests, i.e., one for a 30-minute PM data reporting and one for a 60-minute PM data reporting. Upon receiving the subscription requests from the 02-IMS consumer 1420, the IMS 1410 may implement a performance subscription manager 1411 to create a record for each of the subscription requests (illustrated as “subscription #1” and “subscription #2” in FIG. 14). Accordingly, the IMS 1410 may implement the performance subscription manager 1411 to obtain the associated PM data according to the respective time intervals. For instance, the IMS 1410 may implement the performance subscription manager 1411 to access the storage 1434 every 30minutes and 60 minutes to obtain the latest PM data (e.g., file, stream, event, etc.) therefrom, process the collected PM data (e.g.., serialize the data, compress the serialized / collected data, generate measurement reports that include the processed data, etc.), and provide PM data to the 02-IMS consumer 1420. Accordingly, the IMS 1410 may send a PM notification to the 02-IMS consumer 1420 (e.g., send the PM notification directly via the 02 interface, instruct an intermediate component like the message bus / broker to send the PM notification, etc.) to notify the 02-IMS consumer 1420 that the PM data is available or has been provided.

[0186] Referring still to FIG. 14, a plurality of PM jobs 1433 may be executed (by the IMS 1410, the performance subscription manager 1411, or any other suitable entity associated with the O-Cloud 1430) to periodically collect measurement data (e.g., measurements 1432) from a plurality of O-Cloud resources 1431 (e.g., computing resources, memory, storage, bandwidth, etc.). The measurement data may include various PM data, and may optionally include other data associated with the PM data (e.g., fault data, error data, etc.). The collected measurement data may be stored in the storage 1434, which may be a local repository within the O-Cloud 1430. In addition to providing the PM data to the IMS 1410, the storage 1434 may also be configured to perform various management operations, such as data management (e.g., deleting old PM data, etc.), access management, and the like.

[0187] It can be understood that the configuration in example use case 1400 is merely an example, and the scope of the present disclosure should not be limited thereto. Further, it can also be understood that similar data streaming approaches may be applied to any other suitable 02ims services, such as tracing / log data reporting.

[0188] In view of the above, example use cases in FIG. 13A to FIG. 14 exemplify that the example embodiments of the present disclosure can be efficiently and effectively implemented inthe existing O-RAN network architecture without substantive modification thereto, thereby advantageously reducing the roll-out period and implementation difficulty. It is also contemplated that the technical advantages described above with reference to FIG. 1 to FIG. 12 may be similarly applied to the example use cases in FIG. 13A to FIG. 14, without departing from the scope of the present disclosure.Example Device

[0189] One or more components of the example embodiments (e.g., network entity / network element such as IMS, FOCOM, etc.), as well as the operations associated therewith, may include or be implemented in one or more devices or hardware components. For instance, one or more components / operations of the network entity / network element may include or be implemented in one or more devices like a server(s), and the like.

[0190] In the following, descriptions of a device in which the example embodiments may be implemented are provided. It is contemplated that one or more features, operations, and methods described above may be performed by the device. For instance, the one or more operations or methods associated with a network entity may be performed by at least one processor of the device upon executing machine-readable instructions or computer-readable instructions stored in a memory or a storage component of the device.

[0191] FIG. 15 illustrates an embodiment of a device 1500. As shown in FIG. 15, the device 1500 may include a processor 1510, a memory 1520, a storage component 1530, an input component 1540, an output component 1550, a communication interface 1560, and a bus 1570.

[0192] The processor 1510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 1510 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-coreprocessors and / or one or more single core processors, a distributed processing system, or the like. The processor 1510 may be a Central Processing Unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0193] Memory 1520 includes a non-transitory computer readable medium. Memory 1520 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 1510. The memory 1520 comprises machine-readable instructions which are executable by the processor 1510. These machine-readable instructions when executed by the processor 1510 cause the processor 1510 to perform one or more method steps of an embodiment described above.

[0194] Storage component 1530 stores information and / or software related to the operation and use of the device 1500. For example, storage component 1530 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0195] Input component 1540 is configured to receive information, such as user input. For example, the input component 1540 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 1540 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0196] Output component 1550 is configured to provide output information from the device 1500. For example, the output component 1550 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0197] Communication interface 1560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 1560 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the device 1500 and other devices. In other words, the standard of the communication interface 1560 is not limited.

[0198] The bus 1570 acts as an interconnect between the processor 1510, the memory 1520, the storage component 1530, the input component 1540, the output component 1550, and the communication interface 1560 of the device 1500. The bus 1570 may include a wired interconnection or a wireless interconnection.

[0199] The number and arrangement of components shown in FIG. 15 are provided as an example. In practice, device 1500 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 15. Additionally, or alternatively, a set of components (e.g., one or more components) of device 1500 may perform one or more functions described as being performed by another set of components of device 1500. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of devices 1500 in communication with one another.Example Implementation Environment

[0200] Example embodiments of the present disclosure may be implemented in any suitable type of environment. In the following, an example environment (in which the example embodiments may be implemented) is described.

[0201] FIG. 16 illustrates a block diagram of an example environment 1600 in which systems and / or method, described herein, may be implemented. The implementation environment 1600 includes a UE (User equipment) 1610, a service environment 1620, and a network 1630. The service environment 1620 includes one or more sub-environments 1621. To illustrate this, FIG. 16 shows, for convenience, examples of a 1st sub-environment 1621-1, a 2nd sub-environment 1621-2, and an N-th sub-environment 1621-N (where N is any natural number).

[0202] The UE 1610 is connected to the network 1630, and the network 1630 is connected to the service environment 1620. The connections may be wired, wireless, or a combination of both wired and wireless. The UE 1610 and the service environment 1620 are connected via the network 1630.

[0203] The UE 1610 is a device that communicates with the service environment 1620. The UE 1610 receives information from the service environment 1620 and / or sends information to the service environment 1620. Also, the UE 1610 may generate and / or store information to be transmitted, as necessary. Also, the UE 1610 may store and / or process information that is received, as necessary.

[0204] The example FIG. 16 refers to the “UE”. However, it should be understood by those skilled in the art that general terms such as “user device,” “terminal,” “terminal device,” “communication device,” and “communication terminal” can be used interchangeably with the term “UE.”

[0205] For example, the UE 1610 may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a wearable device (e.g., a pair of smart glasses or a smart watch), or a similar device.

[0206] The service environment 1620 is an environment that communicates with the UE 1610 to provide one or more services. The service environment 1620 receives information from the UE 1610 and / or sends information to the UE 1610. Also, the service environment 1620 may generate and / or store information to be transmitted, as necessary. Also, the service environment 1620 may store and / or process information that is received, as necessary. For example, the service environment 1620 may provide computing resources as one of the services. It should be noted that the service is not limited to being provided to the UE; it may also be provided to devices other than the UE. For example, based on communication from the UE, the service may perform processes such as anomaly detection or traffic analysis and notify the results to a predetermined destination.

[0207] The example FIG. 16 refers to the “service environment”. The term "service environment" is used to refer to the broader context within which services operate. For example, cloud environments, platforms, computing systems, network systems, and cloud systems generally represent the environments in which services are conducted, and these are included within the "service environment." However, the "service environment" is not limited to these examples. Additionally, the specific types of environments within the "service environment" are not restricted. For instance, cloud environments and cloud systems can be categorized as private cloud, public cloud, hybrid cloud, or multi-cloud, all of which are included within the "service environment."

[0208] The one or more services provided by the service environment 1620 is not specifically limited and can be adjusted according to the embodiments. For example, the services may include a service that provides information to the UE 1610, a service that stores information from the UE 1610, or a service that performs processing based on information from the UE 1610 and returns the results of the processing.

[0209] In an embodiment, the Service Environments 1620 may also provide computing resources as the service. The computing resources can be hardware resources and / or software resources. For example, applications, processors, memory, and storage can be included in the provided computing resources. Each computing resource can communicate with other computing resources via wired connections, wireless connections, or a combination of wired and wireless connections.

[0210] The provided computing resources can be actual resources (also referred to as physical resources) and / or virtual resources. Furthermore, means of virtualization for virtual resources can be selected as appropriate. That is, in this disclosure, the use of adjectives such as "Virtual" or "Virtualized" to describe names does not imply that they are virtualized by a specific means of virtualization. For example, “virtual machine” refers to software that operates like an actual computer, realized through means of virtualization, and it is not intended to exclude those realized by specific means of virtualization such as Hypervisors or Containers. Conversely, when means of virtualization such as Hypervisors or containers are mentioned in this disclosure, it is merely cited as a general method of implementation. It should also be interpreted that embodiments implemented with other virtualization means are also disclosed. Also, the services may also be provided using resources virtualized by different means.

[0211] The service environment 1620 includes one or more devices, such as servers and network devices, which provide services or perform processes. The placement of these devices within the service environment 1620 can be determined as appropriate. Additionally, if the service environment 1620 includes one or more sub-environments 1621, the placement of devices can be determined based on predetermined policies for each sub-environment 1621. For example, devices related to the first service may be placed in the 1st sub-environment 1621-1, and devices related to the second service may be placed in the 2nd sub-environment 1621-2. In another example, devices expected to have a higher load than a predetermined threshold may be placed in the 1st sub-environment 1621-1, while devices expected to have a lower load than the predetermined threshold may be placed in the 2nd sub-environment 1621-2. In this way, specific devices can be placed in specific sub-environments 1621. Conversely, each sub-environment 1621 can be specialized for a particular purpose.

[0212] In an embodiment, all processes executed in a single service may run within a single service environment, or in multiple service environments. Multiple processes executed in a single service could be provided by different service environments.

[0213] The network 1630 is a network that exchanges information between the UE 1610 and the service environment 1620. The network 1630 includes one or more wired and / or wireless networks.

[0214] For example, the network 1630 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, anad hoc network, an intranet, the Internet, a fiber optic-based network, or the like, a non-terrestrial network (NTN), and / or a combination of these or other types of networks.

[0215] The network 1630 can be a part of a network. For example, in a 5G network that includes a RAN, a transport network, and a core network, the network 1630 can be at least one of the RAN, the transport network, or the core network. For example, the service environment 1620 could be in the core network, in which case the network 1630 could correspond to a network that is a combination of a RAN and a transport network and is part of the 5G network.

[0216] The number and arrangement of devices and networks shown in FIG. 16 are provided as an example. It should be understood that any changes that may be implemented by those skilled in the art, such as the addition or rearrangement of well-known devices or networks at the time of implementation, are included in this disclosure.Various Aspects of Embodiments

[0217] As described above, example embodiments efficiently and effectively implement 02ims data transport in an O-RAN-based network. Among others, example embodiments introduces new mechanisms and features (e.g., the end-to-end system architecture, the interoperations between the O-RAN components, the mechanisms for utilizing existing 0-RAN interfaces, etc.) for implementing various data reporting methods (e.g., various data transport protocols, data transport frameworks, serialization formats, compression algorithms, etc.) for transporting 02ims data in the 0-RAN architecture. As a non-limiting example, example embodiments specify and supplement several features, mechanisms, and use cases in at least one technical specification associated with the 0-RAN Alliance (e.g., O-RAN-WG6.ORCH-USE-CASES), as detailed below (the supplementations and enhancements provided by example embodiments are presented in table and / or bold format).

[0218] To begin with, “3.8.4.1 High Level Description” of O-RAN-WG6.ORCH-USE- CASES is supplemented as follows (the supplemented portions are reflected in bold):&

[0219] Further, “3.8.3.2 Sequence Description” of O-RAN-WG6.ORCH-USE-CASES is supplemented as follows (the supplemented portions are reflected in bold). The associated call flow may be consistent with, for example, the example use case illustrated in FIG. 13 A and FIG.13B.

[0220] Further, “4.3 Orchestration Requirements Relating to 02” of 0-RAN- WG6.0RCH-USE-CASES is supplemented as follows (the supplemented portions are reflected in

[0221] In view of the above, example embodiments introduce specified and standardized approaches for implementing the multiple data transport methods (e.g., persistent connectionbased streaming that may involve the WebSocket data transport protocol, event notification-based streaming that may involve the message bus framework and / or the HTTP data transport protocols, etc.) in the 0-RAN architecture. Specifically, example embodiments clarify how specifically the components in the O-RAN architecture (e.g., SMO, FOCOM, O-Cloud, IMS, etc.) and the existing 0-RAN interfaces (e.g., 02 interface, etc.) can be utilized to implement various types of data transport / streaming methods for transporting O-Cloud data (e.g., PM data) in the 0-RAN architecture. Accordingly, the example embodiments, which are associated with O-Cloud data transport, may be implemented in the O-RAN-based networks in a clear and standardized manner.

[0222] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely examples of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0223] Specifically, the foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0224] Some embodiments may relate to a device, a system, a method, and / or a computer-readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or media) having computer-readable program instructions thereon for causing aprocessor to carry out operations.

[0225] The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), electrically erasable programmable read-only memory (EEPROM), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0226] Computer-readable program instructions described herein can be downloaded to respective computing / processing devices from a computer-readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in eachcomputing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0227] Computer-readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages.

[0228] The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0229] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processingapparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0230] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0231] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer-readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrentlyor substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0232] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limited to the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code — it is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0233] In view of the above, various further respective aspects and features of embodiments of the present disclosure may be defined by the following items:Item [1]: A system comprises: a first network entity configured to: communicate with a second network entity capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity, wherein the plurality of streaming methods comprise: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming; and communicate with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.Item [2]: The system according to item [1], wherein the first network entity comprises one of: an Infrastructure Management Service (IMS) of the O-Cloud or a Federated O-Cloud Orchestration and Management (FOCOM) of a Service Management and Orchestration (SMO), and wherein the second network entity comprises another one of: the IMS of the O-Cloud or the FOCOM of the SMO.Item [3]: The system according to one or more of items [l]-[2], wherein the connectionbased streaming is based on a WebSocket data transport protocol, and wherein the event notification-based streaming is based on at least one of: a message bus data transport framework, a Hypertext Transfer Protocol (HTTP) data transport protocol, or a Remote Procedure Call (RPC) data transport protocol.Item [4]: The system according to one or more of items [l]-[3], wherein the connectionbased streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the first network entity is configured to communicate with the second network entity through the streaming session by: providing, to the second network entity, a request to open a connection between the first network entity and the second network entity; receiving, from the second network entity, a response indicating that the connection has successfully opened; and providing data to the second network entity via the opened connection.Item [5]: The system according to one or more of items [l]-[3], wherein the connectionbased streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the first network entity is configured tocommunicate with the second network entity through the streaming session by: receiving, from the second network entity, a request to open a connection between the first network entity and the second network entity; opening the connection in response to the request; and providing data to the second network entity via the opened connection.Item [6]: The system according to one or more of items [l]-[3], wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, and wherein the first network entity is configured to communicate with the second network entity through the streaming session by: receiving, from the second network entity, a request to configure a streaming endpoint; configuring the streaming endpoint based on the request; and providing data to the second network entity via the streaming endpoint.Item [7]: The system according to one or more of items [l]-[3], wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, and wherein the first network entity is configured to communicate with the second network entity through the streaming session by: receiving, from the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework; applying a configuration based on the parameter; providing, to the second network entity, a response that includes a uniform resource identifier (URI); and providing data to the second network entity via the URI .Item [8]: The system according to one or more of items [l]-[7], wherein the first network entity is configured to communicate with the second network entity through the streaming session to provide at least one of: Performance Measurement (PM) data associated with anOpen Radio Access Network (O-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud. Item [9]: The system according to one or more of items [l]-[8], wherein the first network entity is configured to communicate with the second network entity by: providing, to the second network entity, information associated with one or more streaming methods supported by the first network entity; and receiving, from the second network entity, information associated with a streaming method selected from among the one or more streaming methods supported by the first network entity.Item

[0010] : The system according to item [9], wherein the information associated with the one or more streaming methods supported by the first network entity comprises at least one of: a transport protocol supported by the first network entity, a transport framework supported by the first network entity, a serialization format supported by the first network entity, or a compression algorithm supported by the first network entity.Item

[0011] : The system according to one or more of items [9]-

[0010] , wherein the information associated with the selected streaming method comprises at least one of: a configuration associated with the selected streaming method, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.Item

[0012] : The system according to one or more of items [l]-[3], wherein the connectionbased streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the first network entity is configured to communicate with the second network entity through the streaming session by: receiving,from the second network entity, a request to open a connection between the first network entity and the second network entity; opening the connection in response to the request; and receiving data from the second network entity via the opened connection.Item

[0013] : The system according to one or more of items [l]-[3], wherein the connectionbased streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the first network entity is configured to communicate with the second network entity through the streaming session by: providing, to the second network entity, a request to open a connection between the first network entity and the second network entity; receiving, from the second network entity, a response indicating that the connection has successfully opened; and receiving data from the second network entity via the opened connection.Item

[0014] : The system according to one or more of items [l]-[3], wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, and wherein the first network entity is configured to communicate with the second network entity through the streaming session by: providing, to the second network entity, a request to configure a streaming endpoint; receiving, from the second network entity, a response indicating that the streaming endpoint is configured successfully; and receiving data from the second network entity via the streaming endpoint. Item

[0015] : The system according to one or more of items [l]-[3], wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, and wherein the first network entity is configured to communicate with the second network entity through the streaming session by: providing,to the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework; receiving, from the second network entity, a response indicating that the parameter is configured successfully, wherein the response includes a uniform resource identifier (URI); and receive data from the second network entity via the URLItem

[0016] : The system according to one or more of items [l]-[3] and items

[0012] -

[0015] , wherein the first network entity is configured to communicate with the second network entity through the streaming session to receive at least one of: Performance Measurement (PM) data associated with an Open Radio Access Network (O-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud.Item

[0017] : The system according to one or more of items [l]-[3] and items

[0012] -

[0016] , wherein the first network entity is configured to communicate with the second network entity by: receiving, from the second network entity, information associated with one or more streaming methods supported by the second network entity; selecting a streaming method from among the one or more streaming methods supported by the second network entity; and providing, to the second network entity, information associated with the streaming method selected from among the one or more streaming methods supported by the second network entity.Item

[0018] : The system according to item

[0017] , wherein the information associated with the one or more streaming methods supported by the second network entity comprises at least one of: a transport protocol supported by the second network entity, a transport frameworksupported by the second network entity, a serialization format supported by the second network entity, or a compression algorithm supported by the second network entity.Item

[0019] : The system according to one or more of items

[0017] -

[0018] , wherein the information associated with the selected streaming method comprises at least one of: a configuration associated with the selected streaming method, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.Item

[0020] : A method comprising: communicating, by a first network entity, with a second network entity capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity, wherein the plurality of streaming methods comprise: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming; and communicating, by the first network entity, with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.Item

[0021] : The method according to item

[0020] , wherein the first network entity comprises one of: an Infrastructure Management Service (IMS) of the O-Cloud or a Federated O-Cloud Orchestration and Management (FOCOM) of a Service Management and Orchestration (SMO), and wherein the second network entity comprises the another one of: the IMS of the O-Cloud or the FOCOM of the SMO.Item

[0022] : The method according to one or more of items

[0020] -

[0021] , wherein the connection-based streaming is based on a WebSocket data transport protocol, and wherein the event notification-based streaming is based on at least one of: a message bus datatransport framework, a Hypertext Transfer Protocol (HTTP) data transport protocol , or a Remote Procedure Call (RPC) data transport protocol.Item

[0023] : The method according to one or more of items

[0020] -

[0022] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: providing, to the second network entity, a request to open a connection between the first network entity and the second network entity; receiving, from the second network entity, a response indicating that the connection has successfully opened; and providing data to the second network entity via the opened connection.Item

[0024] : The method according to one or more of items

[0020] -

[0022] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity, a request to open a connection between the first network entity and the second network entity; opening the connection in response to the request; and providing data to the second network entity via the opened connection.Item

[0025] : The method according to one or more of items

[0020] -

[0022] , wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity,a request to configure a streaming endpoint; configuring the streaming endpoint based on the request; and providing data to the second network entity via the streaming endpoint. Item

[0026] : The method according to one or more of items

[0020] -

[0022] , wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework; applying a configuration based on the parameter; providing, to the second network entity, a response that includes a uniform resource identifier (URI); and providing data to the second network entity via the URI.Item

[0027] : The method according to one or more of items

[0020] -

[0026] , wherein the communicating with the second network entity through the streaming session comprises: providing at least one of: Performance Measurement (PM) data associated with an Open Radio Access Network (0-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud. Item

[0028] : The method according to one or more of items

[0020] -

[0027] , wherein the communicating with the second network entity comprises: providing, to the second network entity, information associated with one or more streaming methods supported by the first network entity; and receiving, from the second network entity, information associated with a streaming method selected from among the one or more streaming methods supported by the first network entity.Item

[0029] : The method according to item

[0028] , wherein the information associated with the one or more streaming methods supported by the first network entity comprises at least oneof: a transport protocol supported by the first network entity, a transport framework supported by the first network entity , a serialization format supported by the first network entity, or a compression algorithm supported by the first network entity.Item

[0030] : The method according to one or more of items

[0028] -

[0029] , wherein the information associated with the selected streaming method comprises at least one of: a configuration associated with the selected streaming method, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.Item

[0031] : The method according to one or more of items

[0020] -

[0022] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity, a request to open a connection between the first network entity and the second network entity; opening the connection in response to the request; and receiving data from the second network entity via the opened connection.Item

[0032] : The method according to one or more of items

[0020] -

[0022] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: providing, to the second network entity, a request to open a connection between the first network entity and the second network entity; receiving, from the second network entity, a response indicatingthat the connection has successfully opened; and receiving data from the second network entity via the opened connection.Item

[0033] : The method according to one or more of items

[0020] -

[0022] , wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: providing, to the second network entity, a request to configure a streaming endpoint; receiving, from the second network entity, a response indicating that the streaming endpoint is configured successfully; and receiving data from the second network entity via the streaming endpoint.Item

[0034] : The method according to one or more of items

[0020] -

[0022] , wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: providing, to the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework; receiving, from the second network entity, a response indicating that the parameter is configured successfully, wherein the response includes a uniform resource identifier (URI); and receive data from the second network entity via the URI.Item

[0035] : The method according to one or more of items

[0020] -

[0022] and items [3 l]-

[0034] , wherein the communicating with the second network entity through the streaming session comprises: receiving at least one of: Performance Measurement (PM) data associated with an Open Radio Access Network (O-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud.Item

[0036] : The method according to one or more of items

[0020] -

[0022] and items [3 l]-

[0035] , wherein the communicating with the second network entity comprises: receiving, from the second network entity, information associated with one or more streaming methods supported by the second network entity; selecting a streaming method from among the one or more streaming methods supported by the second network entity; and providing, to the second network entity, information associated with the streaming method selected from among the one or more streaming methods supported by the second network entity.Item

[0037] : The method according to item

[0036] , wherein the information associated with the one or more streaming methods supported by the second network entity comprises at least one of: a transport protocol supported by the second network entity, a transport framework supported by the second network entity, a serialization format supported by the second network entity, or a compression algorithm supported by the second network entity. Item

[0038] : The method according to items

[0036] -

[0037] , wherein the information associated with the selected streaming method comprises at least one of: a configuration associated with the selected streaming method, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.Item

[0039] : A non-transitory computer-readable recording medium having recorded thereon instructions executable by a first network entity to cause the first network entity to perform a method comprising: communicating with a second network entity capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity, wherein the plurality of streaming methods comprise: a connection-based streaming, an event notification-based streaming, and an activecollection-based streaming; and communicating with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.Item

[0040] : The non-transitory computer-readable recording medium according to item

[0039] , wherein the first network entity comprises one of: an Infrastructure Management Service (IMS) of the O-Cloud or a Federated O-Cloud Orchestration and Management (FOCOM) of a Service Management and Orchestration (SMO), and wherein the second network entity comprises the another one of: the IMS of the O-Cloud or the FOCOM of the SMO.Item

[0041] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0040] , wherein the connection-based streaming is based on a WebSocket data transport protocol, and wherein the event notification-based streaming is based on at least one of: a message bus data transport framework, a Hypertext Transfer Protocol (HTTP) data transport protocol , or a Remote Procedure Call (RPC) data transport protocol.Item

[0042] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: providing, to the second network entity, a request to open a connection between the first network entity and the second network entity; receiving, from the second network entity, a response indicating that the connection has successfully opened; and providing data to the second network entity via the opened connection.Item

[0043] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity, a request to open a connection between the first network entity and the second network entity; opening the connection in response to the request; and providing data to the second network entity via the opened connection.Item

[0044] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity, a request to configure a streaming endpoint; configuring the streaming endpoint based on the request; and providing data to the second network entity via the streaming endpoint.Item

[0045] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework; applying a configuration based on theparameter; providing, to the second network entity, a response that includes a uniform resource identifier (URI); and providing data to the second network entity via the URL Item

[0046] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0045] , wherein the communicating with the second network entity through the streaming session comprises: providing at least one of: Performance Measurement (PM) data associated with an Open Radio Access Network (O-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud.Item

[0047] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0046] , wherein the communicating with the second network entity comprises: providing, to the second network entity, information associated with one or more streaming methods supported by the first network entity; and receiving, from the second network entity, information associated with a streaming method selected from among the one or more streaming methods supported by the first network entity.Item

[0048] : The non-transitory computer-readable recording medium according to item

[0047] , wherein the information associated with the one or more streaming methods supported by the first network entity comprises at least one of: a transport protocol supported by the first network entity, a transport framework supported by the first network entity , a serialization format supported by the first network entity, or a compression algorithm supported by the first network entity.Item

[0049] : The non-transitory computer-readable recording medium according to one or more of items

[0047] -

[0048] , wherein the information associated with the selected streaming method comprises at least one of: a configuration associated with the selected streamingmethod, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.Item

[0050] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: receiving, from the second network entity, a request to open a connection between the first network entity and the second network entity; opening the connection in response to the request; and receiving data from the second network entity via the opened connection.Item

[0051] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the connection-based streaming comprises a persistent connection-based streaming, wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: providing, to the second network entity, a request to open a connection between the first network entity and the second network entity; receiving, from the second network entity, a response indicating that the connection has successfully opened; and receiving data from the second network entity via the opened connection.Item

[0052] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, and wherein theIllcommunicating with the second network entity through the streaming session comprises: providing, to the second network entity, a request to configure a streaming endpoint; receiving, from the second network entity, a response indicating that the streaming endpoint is configured successfully; and receiving data from the second network entity via the streaming endpoint.Item

[0053] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] , wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, and wherein the communicating with the second network entity through the streaming session comprises: providing, to the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework; receiving, from the second network entity, a response indicating that the parameter is configured successfully, wherein the response includes a uniform resource identifier (URI); and receive data from the second network entity via the URI.Item

[0054] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] and items

[0050] -

[0054] , wherein the communicating with the second network entity through the streaming session comprises: receiving at least one of: Performance Measurement (PM) data associated with an Open Radio Access Network (O-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud.Item

[0055] : The non-transitory computer-readable recording medium according to one or more of items

[0039] -

[0041] and items

[0050] -

[0055] , wherein the communicating with the second network entity comprises: receiving, from the second network entity, informationassociated with one or more streaming methods supported by the second network entity; selecting a streaming method from among the one or more streaming methods supported by the second network entity; and providing, to the second network entity, information associated with the streaming method selected from among the one or more streaming methods supported by the second network entity.Item

[0056] : The non-transitory computer-readable recording medium according to item

[0055] , wherein the information associated with the one or more streaming methods supported by the second network entity comprises at least one of: a transport protocol supported by the second network entity, a transport framework supported by the second network entity, a serialization format supported by the second network entity, or a compression algorithm supported by the second network entity.Item

[0057] : The non-transitory computer-readable recording medium according to one or more of items

[0055] -

[0056] , wherein the information associated with the selected streaming method comprises at least one of: a configuration associated with the selected streaming method, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.Item

[0058] : A system comprises: a first network entity configured to: provide, to a second network entity, information associated with one or more data reporting methods supported by the first network entity; receive, from the second network entity, information associated with a data reporting method selected from among the one or more data reporting methods supported by the first network entity; establish, based on the selected data reporting method, a streaming session with the second network entity; and provide, to the second networkentity during the streaming operation, an 02 Infrastructure Management Service (02ims) service.Item

[0059] : The system according to item

[0058] , wherein the data streaming session is based on at least one of: a message bus data transport framework, a Web Socket data transport protocol, a Hypertext Transfer Protocol (HTTP) data transport protocol, or a Remote Procedure Call (RPC) data transport protocol.Item

[0060] : The system according to one or more of items

[0058] -

[0059] , wherein the first network entity comprises an Infrastructure Management Service (IMS) of the O-Cloud, and wherein the second network entity comprises a Federated O-Cloud Orchestration and Management (FOCOM) of a Service Management and Orchestration (SMO).Item

[0061] : The system according to one or more of items

[0058] -

[0060] , wherein the 02ims service comprises a data reporting service for reporting at least one of: Performance Measurement (PM) data associated with an Open Radio Access Network (0-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud.Item

[0062] : The system according to one or more ofitems

[0058] -

[0061] , wherein the information associated with the one or more data reporting methods supported by the first network entity comprises at least one of: a data reporting protocol supported by the first network entity, a data reporting framework supported by the first network entity, a serialization format supported by the first network entity, or a compression algorithm supported by the first network entity.Item

[0063] : The system according to one or more ofitems

[0058] -

[0062] , wherein the information associated with the selected data reporting method comprises at least one of: aconfiguration associated with the selected data reporting method, a serialization format associated with the selected data reporting method, or a compression algorithm associated with the selected data reporting method.Item

[0064] : A system comprises: a first network entity configured to: receive, from a second network entity, information associated with one or more data reporting methods supported by the second network entity; select, from among the one or more data reporting methods supported by the second network entity, a data reporting method; provide, to the second network entity, information associated with the selected data reporting method; and receive, from the second network entity and during a streaming session associated with the selected data reporting method, an 02 Infrastructure Management Service (02ims) service.Item

[0065] : The system according to item

[0064] , wherein the data streaming session is based on at least one of: a message bus data transport framework, a Web Socket data transport protocol, a Hypertext Transfer Protocol (HTTP) data transport protocol, or a Remote Procedure Call (RPC) data transport protocol.Item

[0066] : The system according to one or more of items

[0064] -

[0065] , wherein the first network entity comprises a Federated O-Cloud Orchestration and Management (FOCOM) of a Service Management and Orchestration (SMO), and wherein the second network entity comprises an Infrastructure Management Service (IMS) of the O-Cloud.Item

[0067] : The system according to one or more of items

[0064] -

[0066] , wherein the 02ims service comprises a data reporting service for reporting at least one of: Performance Measurement (PM) data associated with an Open Radio Access Network (0-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O-Cloud, or Tracing and Analytic data associated with the O-Cloud.Item

[0068] : The system according to one or more of items

[0064] -

[0067] , wherein the information associated with the one or more data reporting methods supported by the second network entity comprises at least one of: a data reporting protocol supported by the second network entity, a data reporting framework supported by the second network entity, a serialization format supported by the second network entity, or a compression algorithm supported by the second network entity.Item

[0069] : The system according to one or more of items

[0064] -

[0068] , wherein the information associated with the selected data reporting method comprises at least one of: a configuration associated with the selected data reporting method, a serialization format associated with the selected data reporting method, or a compression algorithm associated with the selected data reporting method.Item

[0070] : The system according to one or more of items

[0064] -

[0069] , wherein the first network entity is configured to select the data reporting method by: selecting, based on at least one of: a capability of the first network entity or a service quality requirement, the data reporting from among the one or more data reporting methods supported by the second network entity.

[0234] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein.

Claims

What is claimed is:

1. A system comprises:a first network entity configured to:communicate with a second network entity capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity, wherein the plurality of streaming methods comprise: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming; andcommunicate with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.

2. The system according to claim 1, wherein the first network entity comprises one of: an Infrastructure Management Service (IMS) of the O-Cloud or a Federated O-Cloud Orchestration and Management (FOCOM) of a Service Management and Orchestration (SMO), and wherein the second network entity comprises another one of: the IMS of the O-Cloud or the FOCOM of the SMO.

3. The system according to claim 1, wherein the connection-based streaming is based on a WebSocket data transport protocol, and wherein the event notification-based streaming is based on at least one of: a message bus data transport framework, a Hypertext Transfer Protocol (HTTP) data transport protocol, or a Remote Procedure Call (RPC) data transport protocol.

4. The system according to claim 1,wherein the connection-based streaming comprises a persistent connection-based streaming,wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:providing, to the second network entity, a request to open a connection between the first network entity and the second network entity;receiving, from the second network entity, a response indicating that the connection has successfully opened; andproviding data to the second network entity via the opened connection.

5. The system according to claim 1,wherein the connection-based streaming comprises a persistent connection-based streaming,wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:receiving, from the second network entity, a request to open a connection between the first network entity and the second network entity;opening the connection in response to the request; and providing data to the second network entity via the opened connection.

6. The system according to clam 1,wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:receiving, from the second network entity, a request to configure a streaming endpoint;configuring the streaming endpoint based on the request; and providing data to the second network entity via the streaming endpoint.

7. The system according to clam 1,wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:receiving, from the second network entity, a parameter associated with at least one of: a transport protocol or a transport framework;applying a configuration based on the parameter;providing, to the second network entity, a response that includes a uniform resource identifier (URI); andproviding data to the second network entity via the URI .

8. The system according to claim 1, wherein the first network entity is configured to communicate with the second network entity through the streaming session to provide at least one of Performance Measurement (PM) data associated with an Open Radio Access Network (O-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O- Cloud, or Tracing and Analytic data associated with the O-Cloud.

9. The system according to claim 1, wherein the first network entity is configured to communicate with the second network entity by:providing, to the second network entity, information associated with one or more streaming methods supported by the first network entity; andreceiving, from the second network entity, information associated with a streaming method selected from among the one or more streaming methods supported by the first network entity.

10. The system according to claim 9, wherein the information associated with the one or more streaming methods supported by the first network entity comprises at least one of a transport protocol supported by the first network entity, a transport framework supported by the first network entity, a serialization format supported by the first network entity, or a compression algorithm supported by the first network entity.

11. The system according to claim 9, wherein the information associated with the selected streaming method comprises at least one of: a configuration associated with the selected streaming method, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.

12. The system according to claim 1,wherein the connection-based streaming comprises a persistent connection-based streaming,wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:receiving, from the second network entity, a request to open a connection between the first network entity and the second network entity;opening the connection in response to the request; andreceiving data from the second network entity via the opened connection.

13. The system according to claim 1,wherein the connection-based streaming comprises a persistent connection-based streaming,wherein the streaming method selected from among the plurality of streaming methods comprises the persistent connection-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:providing, to the second network entity, a request to open a connection between the first network entity and the second network entity;receiving, from the second network entity, a response indicating that the connection has successfully opened; andreceiving data from the second network entity via the opened connection.

14. The system according to clam 1,wherein the streaming method selected from among the plurality of streaming methods comprises the event notification-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:providing, to the second network entity, a request to configure a streaming endpoint;receiving, from the second network entity, a response indicating that the streaming endpoint is configured successfully; andreceiving data from the second network entity via the streaming endpoint.

15. The system according to clam 1,wherein the streaming method selected from among the plurality of streaming methods comprises the active collection-based streaming, andwherein the first network entity is configured to communicate with the second network entity through the streaming session by:providing, to the second network entity, a parameter associated with at least one of a transport protocol or a transport framework;receiving, from the second network entity, a response indicating that the parameter is configured successfully, wherein the response includes a uniform resource identifier (URI); andreceive data from the second network entity via the URI.

16. The system according to claim 1, wherein the first network entity is configured to communicate with the second network entity through the streaming session to receive at least one of Performance Measurement (PM) data associated with an Open Radio Access Network (O-RAN) Cloud (O-Cloud), Fault Management (FM) data associated with the O- Cloud, or Tracing and Analytic data associated with the O-Cloud.

17. The system according to claim 1, wherein the first network entity is configured to communicate with the second network entity by:receiving, from the second network entity, information associated with one or more streaming methods supported by the second network entity;selecting a streaming method from among the one or more streaming methods supported by the second network entity; andproviding, to the second network entity, information associated with the streaming method selected from among the one or more streaming methods supported by the second network entity.

18. The system according to claim 17, wherein the information associated with the one or more streaming methods supported by the second network entity comprises at least one of a transport protocol supported by the second network entity, a transport framework supported by the second network entity, a serialization format supported by the second network entity, or a compression algorithm supported by the second network entity.

19. The system according to claim 17, wherein the information associated with the selected streaming method comprises at least one of a configuration associated with the selected streaming method, a serialization format associated with the selected streaming method, or a compression algorithm associated with the selected streaming method.

20. A method comprising:communicating, by a first network entity, with a second network entity capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity, wherein the plurality of streaming methods comprise: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming; andcommunicating, by the first network entity, with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.

21. A non-transitory computer-readable recording medium having recorded thereon instructions executable by a first network entity to cause the first network entity to perform a method comprising:communicating with a second network entity capable of using a streaming method selected from among a plurality of streaming methods to communicate with the first network entity, wherein the plurality of streaming methods comprise: a connection-based streaming, an event notification-based streaming, and an active collection-based streaming; andcommunicating with the second network entity through a streaming session based on the streaming method selected from among the plurality of streaming methods.

22. A system comprises:a first network entity configured to:provide, to a second network entity, information associated with one or more data reporting methods supported by the first network entity;receive, from the second network entity, information associated with a data reporting method selected from among the one or more data reporting methods supported by the first network entity;establish, based on the selected data reporting method, a streaming session with the second network entity; andprovide, to the second network entity during the streaming operation, an 02 Infrastructure Management Service (02ims) service.

23. A system comprises:a first network entity configured to:receive, from a second network entity, information associated with one or more data reporting methods supported by the second network entity;select, from among the one or more data reporting methods supported by the second network entity, a data reporting method;provide, to the second network entity, information associated with the selected data reporting method; andreceive, from the second network entity and during a streaming session associated with the selected data reporting method, an 02 Infrastructure Management Service (02ims) service.

Images