Negotiating data format and metadata information in an open radio access network

The negotiation of data formats and metadata between producers and consumers in O-RAN systems addresses the lack of format selection in existing specifications, enhancing processing efficiency and interoperability.

WO2026096253A1PCT designated stage Publication Date: 2026-05-07RAKUTEN SYMPHONY INC +1
View PDF 5 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
RAKUTEN SYMPHONY INC
Filing Date
2025-10-22
Publication Date
2026-05-07

AI Technical Summary

Technical Problem

Current Open-Radio Access Network (O-RAN) specifications lack procedures for data producers to advertise supported data formats and metadata options to consumers, and consumers are unable to select specific data formats during data fetch registration.

Method used

A method and apparatus for negotiating data formats and metadata between producers and consumers, allowing consumers to request and select preferred formats and options through a negotiation process.

Benefits of technology

Enables effective and efficient data processing by allowing consumers to choose optimal data formats and metadata options, improving processing efficiency and interoperability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2025051959_07052026_PF_FP_ABST
    Figure US2025051959_07052026_PF_FP_ABST
Patent Text Reader

Abstract

A method (400) is disclosed. The method (400) includes transmitting (402), by a data consumer to a data producer, a first data subscription request. The method (400) also includes receiving (404), by the data consumer, a first response message based on the received first data subscription request. The first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer. The method (400) further includes selecting (406), by the data consumer, at least one data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options. Moreover, the method (400) includes transmitting (408) a second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.
Need to check novelty before this filing date? Find Prior Art

Description

NEGOTIATING DATA FORMAT AND METADATA INFORMATION IN AN OPENRADIO ACCESS NETWORKCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to India Non-Provisional Application No. 202411083472, filed on October 30, 2024, the entire contents of which are incorporated herein by reference.FIELD

[0002] The present disclosure relates to negotiating data format and metadata information in an Open-Radio Access Network (O-RAN).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] Near-real time Radio Access Network (RAN) Intelligent Controller (Near-RT RIC) is a software platform to allow extended applications (xApps) to control RAN functions. The Near-RT RIC enables near real-time control optimization of one or more RAN elements (called E2 nodes) via action commands transmitted over an E2 interface. The E2 interface is a closed loop within a RAN architecture, which is used to send RIC controls and policies towards the E2 Nodes, and further to share feedback from the E2 Nodes to the Near-RT RIC.

[0005] The xApps correspond to software applications used by the Near-RT RIC to implement specific functions or services in near real-time within an open RAN (O-RAN) architecture. These applications or services include functions like radio resource management, mobility management, and security. The xApps are typically deployed on top of the RIC and communicate with other components over the E2 interface within the O-RAN architecture.SUMMARY

[0006] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the disclosure nor is it intended to determine the scope of the disclosure.

[0007] Disclosed herein is a method. The method includes transmitting, by a data consumer to a data producer, a first data subscription request. The first data subscription request comprises one of: a first negotiation parameter, and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options. The method also includes receiving, by the data consumer from the data producer, a first response message based on the received first data subscription request. The first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer. The method further includes selecting, by the data consumer, at least one data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options. Moreover, the method includes transmitting, by the data consumer to the data producer, a second data subscription request. The second data subscription request is transmitted to request data andassociated metadata from the data producer based on the selected at least one of the data format and the metadata option.

[0008] Disclosed herein is an apparatus. The apparatus is configured to transmit, to a data producer, a first data subscription request. The first data subscription request comprises one of: a first negotiation parameter, and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options. The apparatus is also configured to receive, from the data producer, a first response message based on the received first data subscription request. The first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer. The apparatus is further configured to select at least one of a data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options. Moreover, the apparatus is configured to transmit, to the data producer, a second data subscription request. The apparatus transmits the second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

[0009] Disclosed herein is a non-transitory computer-readable medium storing instructions. The instructions comprises one or more instructions that are executed by a data consumer. The data consumer comprises one or more processors. The instructions cause the one or more processors to transmit, to a data producer, a first data subscription request. The first data subscription request comprises one of: a first negotiation parameter, and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options. The instructions also cause the one or more processors to receive, from the data producer, a first response message based on the received first data subscription request. The first response message comprises at least oneof one or more data formats and one or more metadata options supported by the data producer.The instructions further cause the one or more processors to select at least one of a data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options. Moreover, the instructions cause the one or more processors to transmit, to the data producer, a second data subscription request. The second data subscription request is transmitted to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

[0010] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawing. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] 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:FIG. 1 illustrates an internal architecture of a near-RT RIC, in accordance with an existing art;FIG. 2 illustrates an example block diagram depicting a configuration of a network management system, in accordance with an embodiment of the present disclosure;FIGS. 3A-3B illustrate a sequence flow diagram illustrating negotiation of at least one of a data format and metadata information in an open radio access network (O-RAN) architecture, in accordance with an embodiment of the present disclosure;FIG. 4 illustrates a flowchart depicting a method for negotiating at least one of a data format and metadata information in the O-RAN architecture, in accordance with an embodiment of the present disclosure; andFIG. 5 is a diagram of example components of a wireless communication device, in accordance with an embodiment of the present disclosure.DETAILED DESCRIPTION

[0012] The following detailed description of example embodiments refers to the accompanying drawings. The present disclosure provides illustrations and descriptions, 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 present disclosure or may be acquired from the 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 at least one of the embodiments in the present disclosure. 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).

[0013] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, software, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods should not limit their implementations. Thus, the operation and behavior of the systems and / or methods are 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.

[0014] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, the particular 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. Even if a dependent claim directly depends on only one claim, the present disclosure may indicate that the dependent claim is dependent on other claims in the claim set.

[0015] 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” (in other words, nouns not mentioned in the plural) 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.

[0016] Currently, in Open-Radio Access Network (O-RAN) specifications, data that is shared between an extended Application (xAPP) and at least one a Near Real-Time Radio Access Network (RAN) Intelligent Controller (Near RT-RIC) and another xAPP, include metadata information. However, in such current specifications, no procedure has been defined to enable a producer of the data to advertise and / or inform different supported data formats (in the metadata) to a subscriber or a data consumer. Furthermore, no procedure has been defined to enable the subscriber or the data consumer to select a specific data format during a data fetch registration.

[0017] The present disclosure provides a method and an apparatus to overcome the one or more above-mentioned problems and achieve a negotiation on at least one of the data format and the metadata between the producer and the consumer.

[0018] FIG. 1 illustrates an internal architecture of a near-RT RIC 100 with a messaging infrastructure 102, in accordance with the existing art. The near-RT RIC 100 may reside within an edge cloud or a regional cloud and is responsible for intelligent edge control of RAN nodes and resources. The near-RT RIC 100 may control one or more RAN elements and corresponding resources with quick optimization actions that typically take 10 milliseconds to one second to complete. The near-RT RIC 100 receives policy guidance from a non-RT RIC 101 and provides policy feedback to the non-RT RIC 101 through specialized applications called xApps. The xApps correspond to xApp 1, xApp 2 .. . xApp N, which are collectively referred to as the xApps 104. In particular, the near-RT RIC 100 is a microservice-based software platform for hosting microservice-based applications, such as the xApps 104. The non-RT RIC 101 may be implemented as an element of an operator’s Service Management and Orchestration (SMO) framework. The non-RT RIC 101 utilizes network data, performance metrics, and subscriber datato provide Al-based recommendations for network optimization and policy guidance to the xApps 104 running on the near-RT RIC 100.

[0019] The xApps 104 correspond to applications that automate and optimize RAN operations while supporting various use cases that reduce mobile operators’ total cost of ownership (TCO) and enhance customers’ quality of experience (QoE). The xApps 104 are used to control a distributed collection of RAN infrastructure (for example, evolved Node B (eNB), gNodeB (gNB), Control Unit (CU), and Distributed Unit (DU)) via E2 protocol. The xApps 104 may be developed or implemented by third-party developers, network operators, RIC platform vendors, and RAN Network equipment vendors.

[0020] The messaging infrastructure 102 is introduced in the O-RAN RIC architecture by the WG3 near-RT RIC group. The messaging infrastructure 102 provides low-latency message delivery services between the near-RT RIC platform services and xApps 104. The near-RT RIC platform services include conflict mitigation, xApp subscription management, management function, security, AI-ML support, and xApp repository functions and the like.

[0021] In one non-limiting example, the messaging infrastructure 102 uses a RIC Message Router (RMR) library which provides a user application (for example, a near-RT RIC E2 Termination (near-RT RIC E2T) 108) the ability to send and receive messages from / to other RMR-based applications (for example, xApps). Elowever, embodiments either cover or intend to cover use of any suitable message library by the messaging infrastructure 102 to implement the desired functionality. The xApps 104 uses an E2 interface to collect near RT information (on a UE or cell basis).

[0022] The near-RT RIC 100 provides interfaces for an Al termination 112 and an 01 termination110 to the non-RT RIC 101 for the management and optimization of the RAN. The near-RT RIC is responsible for necessary optimization-related tasks across different RANs, utilizing available RAN data from all RAN types (macro / small cells, Massive Multiple-Input Multiple-Output (MIMO)). The near-RT RIC 100 also provides a Y1 interface for the exposure of analytics information from the near-RT RIC 100 to authorized consumers (e.g., Y1 consumers 116) via a Y1 termination 114. The Y1 termination 114 terminates the Y1 interface from the Y1 consumer 116. The Y1 termination 114 communicates with the Y1 consumers 116 via the Y1 interface and exposes RAN analytics information service(s) from the near-RT RIC 100. Specifically, the Y1 interface allows the Y1 consumers 116 to subscribe to or request the RAN analytics information service(s) provided by the near-RT RIC 100.

[0023] The near-RT RIC 100 control over an E2 node 106 is steered via policies and data provided via an Al-interface from the non-RT RIC 101. The E2 node 106 may be able to function independently of the near-RT RIC 100 in case at least one of the E2 interface and the near-RT RIC 100 fails. The E2 node 106 refers to any entity that supports the E2 interface such as, but not limited to, an O-CU-Control Plane (O-CU-CP), an O-CU-User Plane (O-CU-UP), an O-DU, and an O-eNB.

[0024] FIG. 2 illustrates an example block diagram depicting a configuration of a network system 200 (hereinafter referred to as “the system 200”), in accordance with an embodiment of the present disclosure.

[0025] The system 200 may include a data consumer 210, and a data producer 220. The data consumer 210 may be configured to communicate with the data producer 220, as depicted in FIG.2. The data producer 220 may be configured to generate data and transmit the generated data to the data consumer 210. Example of the data may include, but not limited to, performance metrices, radio condition data, user experience metrices, resource utilization data, traffic pattern information, fault-related data, historical data, policy data, and so forth. The data consumer 210 receives the data from the data producer 220 and processes the received data to perform one or more required functions. Examples of such functions may include, but are not limited to, network management, service optimization, resource allocation, and so forth. In one or more embodiments, at least one of the data consumer 210 and the data producer 220 may correspond to an 0-RAN Management Function (MnF). In one embodiment, at least one of the data consumer 210 and the data producer 220 may correspond to the Near-RT RIC 100 or the xApp 104 in any suitable configuration. The configurations as disclosed in FIG. 2 may be understood as parts of the configuration of the data consumer 210 and the data producer 220. Hereinafter, it is understood that terms including “unit” at the end may refer to the unit for processing at least one function or operation and may be implemented in hardware, software, or a combination of hardware and software.

[0026] Referring to FIG. 2, the data consumer 210 may include an apparatus 201. The apparatus 201 includes one or more processor(s) 202 (also, referred to as the processor 202), a memory 204, and a communication unit 206 (e.g., communicator or communication interface). The communication unit 206 may include communication devices / components such as antennas, transmitters, receivers, communication interfaces, etc.

[0027] The communication unit 206 may perform functions such as transmitting and receiving signals while communicating with at least one other communication entity / device, such as the data producer 220. The memory 204 may include executable instructions that, when executed by theprocessor 202, cause the apparatus 201 to perform the steps as described with reference to FIGS.3 and 4.

[0028] As an example, the processor 202 may be a single processing unit or a number of units, all of which could include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and / or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions and data stored in the memory 204. The processor 202 may include one or a plurality of processors. At this time, one or a plurality of processors 202 may be a general -purpose processor, such as a Central Processing Unit (CPU), an Application Processor (AP), or the like, and an Al-dedicated processor such as a Neural Processing Unit (NPU). The processor 202 may control the processing of input data in accordance with a predefined operating rule or Artificial Intelligence (Al) model stored in the non-volatile memory and the volatile memory, i.e., the memory 204. The predefined operating rule or artificial intelligence model is provided through training or learning.

[0029] The memory 204 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as Static Random-Access Memory (SRAM) and Dynamic Random-Access Memory (DRAM), and / or non-volatile memory, such as Read-Only Memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.

[0030] In some embodiments, the apparatus 201 may be implemented as dedicated hardware units.In some embodiments, the apparatus 201 may be implemented in the form of virtualized software units in hardware or cloud environments,

[0031] Further, the data producer 220 may also include an apparatus 203. The apparatus 203 may include one or more processor(s) 212 (also, referred to as the processor 212), a memory 214, and a communication unit 216 (e.g., communicator or communication interface). The functionalities and features of the processor 212, the communication unit 216, and the memory 214 may be similar to those of the processor 202, the communication unit 206, and the memory 204, respectively of the data consumer 210. Therefore, a detailed explanation of the same is omitted herein for the sake of brevity of the present disclosure.

[0032] FIGS. 3A-3B illustrate a sequence flow diagram 300 illustrating negotiation of at least one of a data format and metadata information in an open radio access network (O-RAN) architecture, in accordance with an embodiment of the present disclosure. The sequence flow diagram 300 illustrates the exchange of messages between the data consumer 210 and the data producer 220. In one or more embodiments, the data consumer 210 may also be referred to subscribers of data, and may be the x-App 104 or the Near-RT RIC 100.

[0033] In one embodiment, when the data consumer 210 has no specific preferences with respect to at least one of the data formats and metadata options, the data consumer 210 may transmit a data subscription request to the data producer, as shown by operation 302. The data subscription request may include a negotiation flag or a negotiation parameter (referred to as the negotiation flag). The negotiation flag may be set “true” to indicate that the data consumer 210 has requested at least one of the data formats and the metadata options supported by the data producer 210. Inone or more embodiments, the data subscription request indicates specific data that is required by the data consumer 210. The data subscription request may include information such as, but not limited to, a type of data, a frequency of the data, and a duration of the subscription.

[0034] At operation 303, the data producer 220 may identify that the data subscription request includes the negotiation flag. Furthermore, the data producer 220 may determine the value of the negotiation flag. In response to determining that the negotiation flag is set to true, the data producer 220 may determine a need to share one or more of the supported data formats and metadata options or information for the data being subscribed (i.e., the data requested in the data subscription request). In one or more embodiments, the data formats may correspond to structures or specifications that define how data is organized and represented for transmission and processing. The data formats may vary depending on the type of information being exchanged with the data consumer. Examples of different type of information may include, but are not limited to, performance metrics, configuration data, and telemetry information. The data formats may be standardized to ensure interoperability among different data producers and the data consumers. Examples of the data format may include, but are not limited to, JavaScript Object Notation (JSON), extensible Markup Language (XML), and protocol buffers. The metadata may include data that provides information about other data (i.e., the data being subscribed to or requested). In one or more embodiments, the metadata may describe characteristics of the data being transmitted or shared. The metadata may include information such as, but not limited to, a source, a type, a timestamp, Quality of Service (QoS) attributes, data scheme, and so forth.

[0035] In another embodiment, when the data consumer 210 has data preferences, the data consumer 210 may transmit the data subscription request with client preferences and thenegotiation flag, to the data producer 220, as shown by operation 304. The client preferences may include one or more data formats, or one or more metadata options preferred by the data consumer 210.

[0036] In response, at operation 305, the data producer 220 may identify that the data subscription request includes the client preferences and the negotiation flag. Furthermore, the data producer 220 may determine the value of the negotiation flag. In response to determining that the negotiation flag is set to true, the data producer 220 may determine a requirement to share one or more of the supported data formats and metadata options or information for the data being subscribed (i.e., the data requested in the data subscription request).

[0037] At operation 306, the data producer 220 may transmit a response based on the received data subscription request, to the data consumer 210. The response may include a list of data formats and metadata options supported by the data producer 220. In one embodiment, the response may indicate that the data producer 220 supports the one or more data formats, or the one or more metadata options included as client preferences in the data subscription request. In another embodiment, the response may indicate that the data producer 220 does not support the one or more data formats, or the one or more metadata options included as client preferences in the data subscription request.

[0038] At operation 307, the data consumer 210 may select one or more specific data format, or one or more metadata options for subscription of the data, based on the received response. For example, the data consumer 210 may select a data format or a metadata option from the list of data formats and metadata options supported by the data producer 220.

[0039] At operation 308, the data consumer 210 may transmit another data subscription request with the selected one or more specific data formats, or one or more metadata options, and the negotiation flag is set as “false”. The negotiation flag set as false may indicate that the data producer 220 is no longer required to share the supported list of data formats or the metadata options with the data consumer 210. However, the data producer 220 may determine whether the selected one or more specific data formats, or one or more metadata options included in the data subscription request are valid or not.

[0040] In response to determining that the selected one or more specific data formats, or one or more metadata options, is valid, the data producer 220 may transmit a subscription data response with a success indication, as shown by operation 310. The transmission of the subscription data response may indicate that the data producer 220 will now provide the requested data to the data consumer 210 in the requested format. This improves processing efficiency at the data consumer 210.

[0041] However, in response to determining that the selected one or more specific data formats, or one or more metadata options, is invalid, the data producer 220 may transmit a subscription data response with a failure indication, as shown by operation 312. In such a case, the data producer 220 may also indicate a reason for failure of the data subscription request. Further, the subscription data response with the failure indication may indicate to the data consumer 210 that the data producer 220 may not be able to provide the requested data in the requested data format or with the requested metadata option.

[0042] Further, upon successful completion of the data subscription request, the data producer 220 may transmit the subscribed data to the data consumer 210, as shown by operation 314. The dataproducer 220 may push the subscribed data and associated metadata in the requested data format or with the metadata option, whenever the subscribed data is available. The data producer 220 may either transmit the data in a file or in a continuous stream.

[0043] Thus, the system 200 is able to achieve a negotiation on the data format or the metadata option between the data producer 220 and the data consumer 210. This enables effective and efficient processing of the data received by the data consumer 210 from the data producer 220.

[0044] FIG. 4 illustrates a flowchart depicting a method 400 for negotiating at least one of data format and metadata information in the 0-RAN, in accordance with an embodiment of the present disclosure. The method 400 may be performed by the data consumer 210.

[0045] At step 402, the data consumer 210 may transmit to a data producer 220, a first data subscription request. In one embodiment, the first data subscription request may include a first negotiation parameter. In another embodiment, the first data subscription request may include the first negotiation parameter and at least one of one or more client-preferred data formats and preferred metadata options. In an embodiment, the first negotiation parameter is set as true to request the at least one of one or more data formats and one or more metadata options supported by the data producer 220. In an embodiment, the data consumer 210 corresponds to an xApp, and the data producer 210 corresponds to one of the xApp 104 or the near-RT RIC platform 100.

[0046] At step 404, the data consumer 210 may receive from the data producer 220, a first response message based on the received first data subscription request. The first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer.

[0047] At step 406, the data consumer 210 may select at least one data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options.

[0048] At step 408, the data consumer 210 may transmit, to the data producer, a second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option. In an embodiment, the second data subscription request comprises a second negotiation parameter set as false. In one embodiment, upon transmitting the second data subscription request, the data consumer 210 may receive a second response message from the data producer 220. The second response message may indicate one of a success or a failure of the second data subscription request.

[0049] In one embodiment, when the received second response message indicates the success of the second data subscription request, the data consumer 210 may receive from the data producer 220, data and associated metadata based on the second data subscription request. In an embodiment, the method 400 may include receiving iteratively, by the data consumer 210 from the data producer 220, the data and the associated metadata after a predefined timer interval or detecting of an event.

[0050] While the above-discussed steps in FIG. 4 are shown and described in a particular sequence, the steps may occur in variations to the sequence in accordance with various embodiments. Further, a detailed description related to the various steps of FIG. 4 is already covered in the description related to FIGS. 3A-3B and is omitted herein for the sake of brevity.

[0051] FIG. 5 is a diagram of example components of a wireless communication device 500 (also referred to as the device or the apparatus 500), in accordance with an embodiment of the present disclosure. In one or more embodiments, the wireless communication device 500 may correspondto the data producer 220 or the data consumer 210. The device 500 may also correspond to the apparatus 201 or the apparatus 203. As shown in FIG. 5, the device 500 includes a processor 510, a memory 520, a storage component 530, an input component 540, an output component 550, a communication interface 560, and a bus 570.

[0052] The processor 510, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 510 may be embodied as a multi-core processor, a single-core processor, or a combination of one or more multi-core processors or one or more single-core processors, a distributed processing system, or the like. The processor 510 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.

[0053] The memory 520 includes a non-transitory computer-readable medium. The memory 520 may include, but not limited to, a Random-Access Memory (RAM), a Read Only Memory (ROM), or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, or an optical memory) that stores information or instructions for use by the processor 510. The memory 520 comprises machine-readable instructions which are executable by the processor 510. These machine-readable instructions when executed by the processor 510 cause the processor 510 to perform one or more method steps of an embodiment described above.

[0054] The storage component 530 stores information or software related to the operation and use of the device 500. For example, the storage component 530 may include one or more of a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, or a solid-state disk), a CompactDisc (CD), a Digital Versatile Disc (DVD), a floppy disk, a cartridge, a magnetic tape, or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0055] The input component 540 is configured to receive information, such as user input. For example, the input component 540 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 540 may include a sensor for sensing information (e.g., a Global Positioning System (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0056] The output component 550 is configured to provide output information from the device 500. For example, the output component 550 maybe, but is not limited to, a display, a speaker, an instruction device to an external device, and / or one or more Light-Emitting Diodes (LEDs).

[0057] The communication interface 560 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 560 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 500 and other devices. In other words, the standard of the communication interface 560 is not limited.

[0058] The bus 570 acts as an interconnect between the processor 510, the memory 520, the storage component 530, the input component 540, the output component 550, and the communication interface 560 of the device 500. The bus 570 may include a wired interconnection or a wireless interconnection.

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

[0060] It is understood that terms including “unit” at the end may refer to the unit for processing at least one function or operation and may be implemented in hardware, software, or a combination of hardware and software.

[0061] In one embodiment, a method is described. The method includes transmitting, by a data consumer to a data producer, a first data subscription request. The first data subscription request comprises one of a first negotiation parameter and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options. The method also includes receiving, by the data consumer from the data producer, a first response message based on the received first data subscription request. The first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer. The method further includes selecting, by the data consumer, at least one data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options. Moreover, the method includes transmitting, by the data consumer to the data producer, a second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

[0062] The method as described in

[0060] , wherein upon transmitting the second data subscription request, the method comprises:receiving, by the data consumer from the data producer, a second response message indicating one of a success or a failure of the second data subscription request.

[0063] The method as described in any one of

[0060] -

[0061] , wherein when the received second response message indicates the success of the second data subscription request, the method comprises: receiving, by the data consumer from the data producer, data and associated metadata based on the second data subscription request.

[0064] The method as described in any one of

[0060] -

[0062] , wherein receiving the data and the associated metadata comprises: receiving iteratively, by the data consumer from the data producer, the data and the associated metadata after a predefined timer interval or detecting of an event.

[0065] The method as described in any one of

[0060] -

[0063] , wherein the first negotiation parameter is set as true to request the at least one of one or more data formats and one or more metadata options supported by the data producer.

[0066] The method as described in any one of

[0060] -

[0064] , wherein the second data subscription request comprises a second negotiation parameter set as false.

[0067] The method as described in any one of

[0060] -

[0065] , wherein the data consumer corresponds to an xApp, and the data producer corresponds to one of another xApp or a near-Real Time Radio access network Intelligent Controller (near-RT RIC) platform.

[0068] In one embodiment, an apparatus is described. The apparatus is configured to transmit, to a data producer, a first data subscription request. The first data subscription request comprises one of: a first negotiation parameter and the first negotiation parameter and at least one of one or moreclient preferred data formats and preferred metadata options. The apparatus is also configured to receive, from the data producer, a first response message based on the received first data subscription request. The first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer. The apparatus is further configured to select at least one of a data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options. Moreover, the apparatus is configured to transmit, to the data producer, a second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

[0069] The apparatus as described in

[0067] , wherein the apparatus is further configured to: receive, from the data producer, a second response message indicating one of a success or a failure of the second data subscription request.

[0070] The apparatus as described in any one of

[0067] -

[0068] , wherein when the received second response message indicates the success of the second data subscription request, the apparatus is configured to: receive, from the data producer, data and associated metadata based on the second data subscription request.

[0071] The apparatus as described in any one of

[0067] -

[0069] , wherein to receive the data and the associated metadata, the apparatus is configured to: receive iteratively, from the data producer, the data and the associated metadata after a predefined timer interval or detecting of an event.

[0072] The apparatus as described in any one of

[0067] -

[0070] , wherein the first negotiation parameter is set as true to request the at least one of one or more data formats and one or more metadata options supported by the data producer.

[0073] The apparatus as described in any one of

[0067] -

[0071] , wherein the second data subscription request comprises a second negotiation parameter set as false.

[0074] The apparatus as described in any one of

[0067] -

[0072] , wherein the apparatus corresponds to a data consumer.

[0075] The apparatus as described in any one of

[0067] -

[0073] , wherein the data consumer corresponds to an xApp, and the data producer corresponds to one of an xApp or a near-Real Time Radio access network Intelligent Controller (near-RT RIC) platform.

[0076] A non-transitory computer-readable medium storing instructions is described. The instructions comprising one or more instructions that are a data consumer comprising one or more processors. The instructions cause the one or more processors to transmit, to a data producer, a first data subscription request. The first data subscription request comprises one of: a first negotiation parameter and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options. The instructions also cause the one or more processors to receive, from the data producer, a first response message based on the received first data subscription request. The first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer. The instructions further cause the one or more processors to select at least one of a data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options. Moreover, the instructions cause the one or more processors to transmit, to the data producer, asecond data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

[0077] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

[0078] The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein.

[0079] Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.

[0080] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any component(s) that may cause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essential feature or component of any or all the claims.

[0081] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

Claims

We Claim:

1. A method compri sing : transmitting, by a data consumer to a data producer, a first data subscription request, wherein the first data subscription request comprises one of: a first negotiation parameter; and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options; receiving, by the data consumer from the data producer, a first response message based on the received first data subscription request, wherein the first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer; selecting, by the data consumer, at least one data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options; and transmitting, by the data consumer to the data producer, a second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

2. The method as claimed in claim 1, wherein upon transmitting the second data subscription request, the method comprises: receiving, by the data consumer from the data producer, a second response message indicating one of a success or a failure of the second data subscription request.

3. The method as claimed in claim 2, wherein when the received second response message indicates the success of the second data subscription request, the method comprises: receiving, by the data consumer from the data producer, data and associated metadata based on the second data subscription request.

4. The method as claimed in claim 3, wherein receiving the data and the associated metadata comprises: receiving iteratively, by the data consumer from the data producer, the data and the associated metadata after a predefined timer interval or detecting of an event.

5. The method as claimed in claim 1, wherein the first negotiation parameter is set as true to request the at least one of one or more data formats and one or more metadata options supported by the data producer.

6. The method as claimed in claim 1, wherein the second data subscription request comprises a second negotiation parameter set as false.

7. The method as claimed in claim 1, wherein the data consumer corresponds to an xApp, and the data producer corresponds to one of an xApp or a near-Real Time Radio access network Intelligent Controller (near-RT RIC) platform.

8. An apparatus configured to:transmit, to a data producer, a first data subscription request, wherein the first data subscription request comprises one of: a first negotiation parameter; and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options; receive, from the data producer, a first response message based on the received first data subscription request, wherein the first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer; select at least one of a data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options; and transmit, to the data producer, a second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

9. The apparatus as claimed in claim 8, wherein the apparatus is further configured to: receive, from the data producer, a second response message indicating one of a success or a failure of the second data subscription request.

10. The apparatus as claimed in claim 9, wherein when the received second response message indicates the success of the second data subscription request, the apparatus is configured to: receive, from the data producer, data and associated metadata based on the second data subscription request.

11. The apparatus as claimed in claim 10, wherein to receive the data and the associated metadata, the apparatus is configured to: receive iteratively, from the data producer, the data and the associated metadata after a predefined timer interval or detecting of an event.

12. The apparatus as claimed in claim 8, wherein the first negotiation parameter is set as true to request the at least one of one or more data formats and one or more metadata options supported by the data producer.

13. The apparatus as claimed in claim 8, wherein the second data subscription request comprises a second negotiation parameter set as false.

14. The apparatus as claimed in claim 8, wherein the apparatus corresponds to a data consumer.

15. The apparatus as claimed in claim 14, wherein the data consumer corresponds to an xApp, and the data producer corresponds to one of an xApp or a near-Real Time Radio access network Intelligent Controller (near-RT RIC) platform.

16. A non-transitory computer-readable medium storing instructions, the instructions comprising: one or more instructions that, when executed by a data consumer, the data consumer comprising one or more processors, cause the one or more processors to:transmit, to a data producer, a first data subscription request, wherein the first data subscription request comprises one of: a first negotiation parameter; and the first negotiation parameter and at least one of one or more client preferred data formats and preferred metadata options; receive, from the data producer, a first response message based on the received first data subscription request, wherein the first response message comprises at least one of one or more data formats and one or more metadata options supported by the data producer; select at least one of a data format and a metadata option among the received at least one of the one or more data formats and one or more metadata options; and transmit, to the data producer, a second data subscription request to request data and associated metadata from the data producer based on the selected at least one of the data format and the metadata option.

Citation Information

Patent Citations

  • Radio Access Network (RAN) System for Optimized Spectrum Sharing

    US20240236691A1

  • Radio access network intelligent application manager

    US20240259879A1

  • System, method, and apparatus for providing optimized network resources

    US20240298184A1

  • Radio resource planning and slice-aware scheduling for intelligent radio access network slicing

    US20240305533A1

  • Radio access network (RAN) analytics exposure mechanism

    WO2023186724A1