DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/19/2025 was filed with a fee after the mailing date of the First Office Action on merits on 04/18/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendment
The amendment to the claims filed on 08/18/2025 complies with the requirements of 37 CFR 1.121(c) and has been entered.
Response to Arguments
Applicant's arguments filed 08/18/2025 have been fully considered herein as follows.
Regarding Claims 1-5, 7, 9-12 and 14-19 being provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over Claims 1-5,7, 9-12 and 14-19, respectively, of copending Application No. 18/018,399, PG-Pub US 2024/0259836 (reference application) in view of O-RAN Alliance Working Group 4 "Management Plane Specification," ORAN.WG4.MP.0-v09.00 Technical Specification, July 2022 (available for download at https://specifications.o-ran.org/specifications) (hereinafter O-RAN.WG4.MP) the provisional nonstatutory double patenting rejection is maintained.
In response to applicant's other arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Regarding the argument that Wang et al, U.S. Patent Application Publication No. 20220407664 (hereinafter Wang) does not suggest its collected data as being obtained from the O-RU, but only suggests collecting data of the E2 nodes ([0130]), which does not include the O-RU ([0064]), examiner respectfully disagrees.
First, although it is true that Applicant’s Drawings show O-RU as outside the E2 Node – See, e.g., Figs. 6-9, the same drawings show the E2 nodes collecting O-RU data by the O-DU, a E2 node component, using the Front-Haul interface towards the O-RU1. To be sure, Applicant’s Specification discloses “collect configurations, performance indicators and measurement reports (e.g., cell load-related information and traffic information, energy efficiency EE and/ or energy consumption EC measurement reports, geolocation information, etc.) from the E2 nodes and the O-RUs (via the E2 nodes forwarded by the SMO)” – See [¶0095] (emphasis added); see also [¶0112] (“The SMO framework may function as a mediator between the rApps and the E2 nodes and the O-RUs (via the E2 nodes) within the O-RAN”). Therefore, Applicant’s Specification, like Wang, discloses embodiments where collection of O-RU data is made through E2 nodes.
Second, Wang discloses that “[t]he base station may be an E2 node corresponding to a RAN in O-RAN system or a network entity, in an NR system” – See [¶0050]; see also Fig. 5.1.1-1, O-RAN.WG4.MP:16, showing O-RAN WG4 FH functional split mapped to a NR gNB and reproduced hereinafter.
PNG
media_image1.png
549
562
media_image1.png
Greyscale
In an embodiment, Wang specifically teaches that “[t]he E2 Node 104 is a logical node terminating the E2 interface” and “O-RAN nodes terminating the E2 interface may be . . . any combination for NR access or O-eNB for E-UTRA access,” whereby “[t]he O-RAN Radio Unit (O-RU) is a logical node hosting Low-PHY layer and radio frequency (RF) processing based on a lower layer functional split. This is similar to 3GPP's ‘Transmission/Reception Point (TRP)’ or ‘remote radio head (RRH)’ but more specific in including the Low-PHY layer” – See [¶0064] and Fig. 1, including an embodiment of a O-RU Controller (“the E2 Node terminating the E2 Interface is assumed to host one or more instances of the RAN Function ‘RAN Control’” – See [¶0067], whereby examples of ‘RAN Control’ functions are listed in Table 1 and include radio bearer, radio access, radio resource, dual-connectivity, carrier aggregation and cell activation/deactivation, i.e., Low-PHY layer and radio frequency (RF) processing functions specific to RUs – See [¶0096]; and “[t]he E2 node(s) report/transmit relevant network parameters, such as updates of the cell loads, to the non-RT RIC and/or Near-RT RIC” – See [¶0116] using “a method performed by a radio access network (RAN) controlled controller (RIC)” to request “information on a specific to RAN function specific to a service model” – See [¶0117]). Furthermore, Wang teaches that the O-RU can be configured, e.g., for reporting, through both the O1 and the Open FH interfaces (“thresholds parameters [from the rApp] can then be configured through the O1 interface to eNB, or through open fronthaul to O-RU” – See [¶0120]). Therefore, Wang, no less than the Applicant, suggests requesting and obtaining data from the O-RU through the O1 interface, via E2 nodes2. In addition, several references, including the secondary reference used in the 103 rejection of Claim 1, Polese et al., "Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges"; arXiv: 2202.01032v2; 1 August 2022 (hereinafter Polese) teaches the O-RAN reference architecture as known in the art in Fig. 4, showing an O-RU as part of the E2 node, also showing all the interfaces to reach the O-RU, specifically, O1 and Open FH for data, and the Open FH/M-Plane for NETCONF/YANG model based management.
Third, Polese teaches an open front haul management plane (FH M-Plane) interface between the E2 node and an open radio unit (O-RU) used to collect O1-related data and to send instructions from the E2 node to the O-RU to execute (“The O-RAN Fronthaul (FH) interface connects a DU to one or multiple RUs inside the same gNB” – See § V.D, at page 13, col. 1, first paragraph, and Fig. 12; e.g., “the O-RAN FH can function as the O1 interface of the RU” and “takes care of several operations related to the life cycle of the RU” such as “the start-up, during which the RU establishes the management with the DU and/or the SMO” and “configuration management, performance and fault monitoring, and file management for bulk transfer of data” – See id, at page 14, col. 2, second and third paragraph). Therefore, Wang in view of Polese teaches the feature at issue in the argument.
Regarding the argument that Wang discloses that its rApp calculates energy consumption, as opposed to receiving an energy consumption measurement report ([0130]), Applicant refers to just one embodiment of Wang rApp. Wang has other embodiments collecting such information directly from the O-RU/E2 nodes – See, e.g., [¶¶0121,0125] (“This embodiment may involve at least one of the following features . . . Reporting of the KPIs from E2 nodes to Non-RT RIC (e.g., cell throughput, instantaneous energy consumption, number of handovers) through O1 interface”) (emphasis added), cited in the Non Final Office action, at page 14-15. Furthermore, a person of ordinary skills in the art would expect an “energy saving” rApp, such as that disclosed in Wang, to perform additional energy consumption calculations as needed (e.g., for averages over a certain period of time or during specific times, and/or predictions of energy consumptions). What is not expected from an rApp is to calculate the instantaneous energy consumption of a radio unit at least because of the remoteness position of a rApp from an E2 node and also because measurements are done inside the equipment3. In addition, Applicant dismisses Polese as only disclosing its "M-plane ... enables ... performance and fault monitoring," without any suggestion of receiving energy consumption or energy efficiency measurements reports from the O-RU. To the contrary, Polese cites to the O-RAN.WG4.MP reference [110] that details how a O-DU in a E2 node collects performance data from the O-RU (“O-RAN Fronthaul (FH) interface connects a DU to one or multiple RUs inside the same gNB [109, 110]” – See § V.D, ¶3:col1, at page 13), the reference specifically disclosing the epe-stats measurements reported by the O-RU to the O-DU, as further explained in this Office action. Polese also teaches that “[t]he performance metrics are also either based on 3GPP documents [95], vendor specific, or standardized by the different WGs of the O-RAN Alliance” – See §V.B, ¶4:col1, at page 12, citing precisely to the 3GPP document that specifies the energy, power and environmental measurements collected from the network. To be noted, Applicant’s Specification discloses no more than the claimed “collecting, by the E2 node, the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on from the O-RU via an open front haul management plane FH M-Plane interface between the E2 node and the open radio unit O-RU” – See [¶0181], with no indication of the origin or procedure of obtaining an energy efficiency (EE) measurement report or energy consumption (EC) measurement report that would distinguish the present application from the techniques known in the art. Thus, this last argument is also unpersuasive.
In sum, all Applicant’s arguments have been fully considered but they do not persuasive.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim1-5, 7, 9-12 and 14-19, as amended, are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-5, 7, 9-12 and 14-19, respectively, of U.S. Patent No. 18/018,399, PG-Pub US 2024/0259836 (reference application) in view of O-RAN Alliance Working Group 4 “Management Plane Specification,” O-RAN.WG4.MP.0-v09.00 Technical Specification, July 2022 (available for download at https://specifications.o-ran.org/specifications) (hereinafter O-RAN.WG4.MP). Although the claims at issue are not identical, they are not patentably distinct from each other because the technique of optimizing for energy savings a carrier and/or cell switch off/on was obvious to a person of ordinary skills in the art, in view of the teaching of the technique for improvement for energy savings a radio frequency (RF) reconfiguration in the reference application, and further in view of O-RU Configuration Management taught by O-RAN.WG4.MP.
Only Claims 1 and 4 are presented and analyzed below. Provisionally rejected Claims 11 and 18 follow the same rationale as in Claim 4 analysis, all the other provisionally rejected claims follow the same rationale as in Claim 1.
Clm.
18/016,814
Clm.
18/018,399
1
A system for implementing an optimization of a carrier and/or cell switch off/on in an open radio access network (O-RAN) by a service management and orchestration (SMO) framework, the system comprising:
1
A system for implementing an optimization of an radio frequency (RF) reconfiguration within an open radio access network (0-RAN) by a service management and orchestration (SMO) framework, the system comprising:
a memory storing instructions; and at least one processor configured to implement a non-real-time radio intelligent controller (NRT-RIC), an NRT-RIC framework, at least one SMO function and an rApp hosted by the NRT-RIC,
a memory storing instructions; and at least one processor configured to implement a non-real-time radio intelligent controller (NRT-RIC), an NRT-RIC framework, at least one SMO function and an rApp hosted by the NRT-RIC,
the at least one processor configured to execute the instructions to:
the at least one processor configured to execute the instructions to:
collect, by an rApp, O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on via an R1 interface through an NRT-RIC framework and via an O1 interface through a SMO function within the SMO framework from an E2 node,
collect, by an rApp, O1-related data providing O1 configurations required to perform the RF channel reconfiguration via an R1 interface through an NRT-RIC framework and via an 01 interface through a SMO function within the SMO framework from an E2 node,
wherein the O1-related data are collected via an open front haul management plane (FH M-Plane) interface between the E2 node and an open radio unit (O-RU);
wherein the O1- related data are collected via an open front haul management plane (FH M-Plane) interface between the E2 node and an open radio unit (O-RU);
based on the collected O1-related data, by the SMO, re-train at least one artificial intelligence/ machine learning (AI/ML) model and, among the at least one re-trained AI/ML, deploy and activate, by the rApp,
one re-trained AI/ML model for inferring data providing O1 configurations required to perform the cell and/or carrier switch off/on within the O-RAN;
based on the collected O1-related data, by the SMO, re-train at least one artificial intelligence/ machine learning (AI/ML) model and, among the at least one re-trained AI/ML, deploy and activate, by the rApp, one re-trained AI/ML model for inferring data providing O1 configurations required to perform the RF channel reconfiguration within the O-RAN;
monitor, by the rApp, via the R1 interface through the NRT-RIC framework and via an O1 interface through the SMO function within the SMO framework the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on;
monitor, by the rApp, via the R1 interface through the NRT-RIC framework and via an O1 interface through the SMO function within the SMO framework the O1-related data providing O1 configurations required to perform the RF channel reconfiguration;
evaluate, by the rApp, the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on;
evaluate, by the rApp, the O1-related data providing O1 configurations required to perform the RF channel reconfiguration
determine, by the rApp, to generate O1 configuration data to prepare and execute the cell and/or carrier switch off/on and
determine, by the rApp, to generate O1 configuration data to prepare and execute the RF channel reconfiguration and
send, by the rApp, via the R1 interface through the NRT-RIC framework and via the O1 interface through the at the least one SMO function within the SMO framework, the O1 configuration data to prepare and execute the cell and/or carrier switch off/on to the least one E2 node;
send, by the rApp, via the R1 interface through the NRT-RIC framework and via the O1 interface through the at the least one SMO function within the SMO framework, the O1 configuration data to prepare and execute the RF channel reconfiguration to the least one E2 node;
implement, by the E2 node and the O-RU, the cell and/or carrier switch off/on within the O-RAN,
implement, by the E2 node and the O-RU, the RF channel reconfiguration within the O- RAN,
wherein while implementing the at least one processor is further configured to: convert, by the E2 node, the O1 configuration data to prepare and execute the cell and/or carrier switch off/on and
wherein while implementing the at least one processor is further configured to: convert, by the E2 node, the O1 configuration data to prepare and execute the RF channel reconfiguration and
instruct, by the E2 node, the O-RU to execute the cell and/or carrier switch off/on via the open FH M-Plane.
instruct, by the E2 node, the O-RU to execute the RF channel reconfiguration via the open FH M-Plane.
4
The system as claimed in claim 1
The system as claimed in claim 1
wherein the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on comprise at least one of configurations, performance indicators and measurement reports provided from the O-RU,
wherein the O1-related data providing O1 configurations required to perform the RF channel reconfiguration at least one of configurations, performance indicators and measurement reports provided from the O-RU,
wherein the measurement reports comprise at least one of a cell load related information, traffic information, energy efficiency/energy consumption EE/EC measurement report, and
wherein the measurement reports comprise at least one of a cell load related information, traffic information, energy efficiency/energy consumption EE/EC measurement report, and
wherein the energy efficiency/energy consumption (EE/EC) measurement report comprises at least one of an energy consumption of the E2 Node, an energy consumption of the O-RU and one or more performance-related key performance indicators of the E2 node.
wherein the energy efficiency/energy consumption (EE/EC) measurement report comprises at least one of Reference Signal Received Quality (RSRQ) measurement per Synchronization Signal Block (SSB) per cell, Reference Signals Received Power (RSRP) measurement per SSB per cell, Signal to Interference plus Noise Ratio (SINR) measurement per SSB per cell, energy consumption, power consumed by hardware component, transmit power, load statistics per cell and per carrier, such as number of active users, average number of Radio Resource Control (RRC) connections, average number of scheduled active users per Transmission Time Interval (TTI), Physical Resource Block (PRB) utilization, DownLink/UpLink (DL/UL) Cell/User throughput, Precoding Matrix Indicator/Channel State Information (PMI/CSI) reports, latency statistics per cell and power consumption metrics information on supported Tx/Rx array selections together with power consumption key performance indicators.
Regarding Claim 1 of the ‘814 application, Claim 1 of the ‘339 application teaches the same system comprising a non-real-time radio intelligent controller (NRT-RIC), a SMO function and a rApp, all within the meaning of O-RAN as understood by one of ordinary skills in the art, for implementing the same AI/ML technique only this time for optimization of a radio frequency reconfiguration. Claim 1 of the ‘339 application does not teach that the same system and technique can be applied to a carrier and/or cell switch off/on for the same optimization result.
Nevertheless, in light of O-RAN.WG4 .MP, a person of ordinary skills in the art following RF (channel) reconfiguration and a carrier and/or cell switch off/on are similar devices because: (1) a person of ordinary skills in the art knows that both RF (channels) and carrier/cells (switches) sit in the O-RU of (a E2 node such as a gNB) of an O-RAN system; (2) both RF (channels) and carrier/cells (switches) are concerned with Rx/Tx at radio unit (O-RU) physical layer – See O-RAN.WG4 .MP, Figure 5.1.1-1; and (3) similar O1 configuration is required to perform RF (channels) reconfiguration and carrier/cells (switches) on/off at the FH M-Plane interface, specifically NETCONF/YANG as the network element management protocol and data modelling language – See id., § 5.1.2 and § 9.
Thus, considering the carrier/cells (switch) as base device/method upon which the AI/ML technique of Claim 1 of the ‘814 application is applied as an improvement (“optimization”), Claim 1 of the ‘399 applications shows that a comparable device, an RF (channel) reconfiguration device/method, has been improved (“optimized”) in the same way as the claimed invention. Therefore, one of ordinary skill in the art could have applied the known improvement technique in the ‘339 application same way to the carrier/cells (switch) on/off device/method and the results would have been predictable to one of ordinary skill in the art – See MPEP § 2143.D; See also KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).
Therefore, Claim 1 of the ‘814 and Claim 1 of the ‘339 application are obvious variants.
Claims 2-3, 7, 9-10 and 14-17 in both applications follow the same rationale to explain why they are, respectively, obvious variants and therefore provisionally rejected for nonstatutory double patenting.
Regarding Claim 4 of the ‘814 application, Claim 4 of the ‘339 application is a specialization of the claim in the present application because the required energy efficiency/energy consumption (EE/EC) measurement report comprises power consumption metrics information on supported Tx/Rx array selections together with power consumption key performance indicators, i.e., energy consumption of the O-RU, as in Claim 4 of the ‘814 application. Therefore Claim 4 of the ‘339 application anticipates Claim 4 of the ‘814 application. The same rationale for provisional nonstatutory double patenting applies to Claims 8 and 11.
Therefore, Claim 1-5, 7, 9-12 and 14-19 provisionally rejected on the ground of nonstatutory double patenting over Claims 1-5, 7, 9-12 and 14-19, respectively, of copending Application No. 18/018,399 (reference application) in view of O-RAN.WG4 .MP
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 4-6, 8, 11-13, 15, and 18- 20, as amended, are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al., U.S. Patent Application Publication No. 20220407664 (hereinafter Wang), and further in view of Polese et al., “Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges”; arXiv: 2202.01032v2; 1 August 2022 (hereinafter Polese) and O-RAN Alliance Working Group 4 “Management Plane Specification,” O-RAN.WG4.MP.0-v09.00 Technical Specification, July 2022 (available for download at https://specifications.o-ran.org/specifications) (hereinafter O-RAN.WG4.MP) (Polese reference [110]) .
Regarding Claim 1, Wang teaches in Fig. 8 a system for implementing an optimization of a carrier and/or cell switch off/on in an open radio access network (O-RAN) by a service management and orchestration (SMO) framework (“a method and apparatus for RAN energy saving in a wireless communication system using O-RAN” – See [¶0010]) the system comprising:
a memory storing instructions (“computer program instructions may also be stored in a computer usable or computer readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner” – See [¶0052]); and
at least one processor configured to implement a non-real-time radio intelligent controller (NRT-RIC), an NRT-RIC framework, at least one SMO function – See [¶0134], and
an rApp hosted by the NRT-RIC (a Non-RT RIC for RAN in the SMO framework as shown in Fig. 1; whereby “the Service Management and Orchestration (SMO) 301 (including non-RT RIC 301a) can perform one or more” management functions “to drive energy saving at RAN level in terms of expected behaviour” – See [¶¶0134-39] and Fig. 8, a “[n]ew enabler within Non-RT RIC for RAN energy saving by semi-dynamically turning cells on/off” including “a new rApp, namely the energy saving rApp, at Non-RT RIC,” and a “RAN function that control Cell Activation and De-Activation at the E2 nodes” – See [¶¶0122-23]; whereby “the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors” –See [¶0140]), the at least one processor configured to execute the instructions to:
collect, by an rApp, O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on via an O1 interface through a SMO function within the SMO framework from an E2 node (“the non-RT RIC 301a in service orchestration and management 301 enables non-realtime control and optimization of RAN elements and resources to the applications/features in E2 Node(s) 306 based on the KPI report 304 and Cell Configuration 305 through O1 interface” – See [¶0129] and Fig. 8; wherein “[t]he energy saving rApp 803 in Non-RT RIC 301a . . . uses cell statistics collected from E2 Node(s) 306, such as load statistics, and calculates the energy consumption” and “parameters obtained from O1 interface” – See [¶0130]; and wherein “O1 interfaces parameters between Non-RT RIC and the E2 nodes” include “a list of the IDs of the cells to be activated/deactivated” – See [¶0124] and Fig. 8);
based on the collected O1-related data, by the SMO, re-train at least one artificial intelligence/ machine learning (AI/ML) model (the “Service Management and Orchestration (SMO) 301 . . . can perform . . . [t]raining of potential Machine Learning, ML, models for energy optimization, which may respectively autonomously recognize traffic types, predict throughput and energy consumption under a certain traffic pattern” – See [¶0136]), therefore, an AI/ML model is trained to infer data providing O1 configurations required to perform the cell and/or carrier switch off/on within the O-RAN (e.g., when “there is a (predicted) traffic increase . . . the energy saving rApp 803 shall activate a list of cells” – See [¶0130]);
monitor, by the rApp, via an O1 interface through the SMO function within the SMO framework O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on wherein the O1-related data comprises measurement reports provided from the O-RU, the measurement reports comprising at least one of an energy efficiency (EE) measurement report indicating energy efficiency of the O-RU or an energy consumption (EC) measurement report indicating energy consumed by the O-RU (“The second embodiment of the present disclosure relates to energy saving and concerns semi-dynamically configuring the cell activation and deactivation policy” – See [¶0120], using “[a] procedure related to enabling the energy saving rApp and its control of cell activation/deactivation” – See [¶0127]; whereby “[t]his embodiment may involve at least one of the following features 1) to 6):” – See [¶0121] including “ 4) [r]eporting of the KPIs from E2 nodes to non-RT RIC (e.g., cell throughput, instantaneous energy consumption, number of handovers),” i.e., radio-unit type of parameters, and “5) [r]eporting of cell activation and deactivation status from E2 nodes to Non-RT RIC [happen] through O1 interface” – See [¶¶0125-26]; and a SMO function that “[r]etrieve[s] necessary performance, configuration, and load statistics of the cells, and other data for defining and updating policies to guide the behaviour of energy saving” – See [¶0135]; whereby “[t]he rApp 803 uses cell statistics collected from E2 Node(s) 306 . . . and calculates energy consumption” – See [¶ 0130])
evaluate, by the rApp, the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on (“the energy saving rApp 803 in Non-RT RIC 301a . . . makes a decision, according to the parameters obtained from O1 interface, e.g., instantaneous as well as average cell loads and KPIs of theE2 node(s), decides a list of cells to be activated and/or deactivated” – See [¶0130]);
determine, by the rApp, to generate O1 configuration data to prepare and execute the cell and/or carrier switch off/on (“the energy saving rApp 803 may decide to deactivate some cells and re-locate the UEs of these cells to the other cells, for energy saving purpose . . . in circumstance when, e.g., 1) KPI degradations may occur, e.g., throughput drop, or 2) there is a (predicted) traffic increase and the energy saving rApp 803 shall activate a list of cells” – See id; and “[t]he decision made by rApp 803 may lead to update of the list of the cells to be activated and deactivated” – See [¶0131]; whereby the list of cell IDs is part of “O1 interfaces parameters” – See [¶0124] and Fig. 8) and;
send, by the rApp, via the O1 interface through the at the least one SMO function within the SMO framework, the O1 configuration data to prepare and execute the cell and/or carrier switch off/on to the least one E2 node (after “optimal energy saving configuration parameters calculated in the analytics rApp from the non-RT RIC 101 . . . new thresholds parameters can then be configured through the O1 interface to eNB, or through open fronthaul to O-RU” and “cells are then activated or deactivated, once the cell load is lower than the specified thresholds” – See [¶0120] and Fig. 8; or “the Service Management and Orchestration (SMO) 301” can “Send policies/intents to near-RT RIC 302 to drive energy saving at RAN level in terms of expected behaviour” – See [¶0138]; and Fig. 7, whereby “decision made by rApp 803 may lead to update of the list of the cells to be activated and deactivated” and “parameters 305 shall be passed from non-RT RIC 301a to the E2 node(s) 306, and E2 node(s) shall be activated and/or deactivated accordingly” – [¶0131]); and
implement, by the E2 node and the O-RU, the cell and/or carrier switch off/on within the O-RAN (“a high level architecture for energy saving using RAN control CONTROL service style” – See [¶0091]; wherein RIC “E2 control message flows and Message Information Elements” are shown in Fig. 5, and “CONTROL Service RIC Control Message IE” may contain the list of cells to be activated and/or deactivated by E2 node, based on RIC style type in Table 1 – See [¶0097] in the “RIC CONTROL REQUEST sent from Near-RT RIC 102 to E2 Node 106 (step 511)” based on “E2 Application Protocol message” and the “RIC CONTROL ACKNOWLEDGE sent” back by the E2 Node – See [¶0093] );
wherein while implementing the at least one processor is further configured to: convert, by the E2 node, the O1 configuration data to prepare and execute the cell and/or carrier switch off/on (“Table 1 which represents a CONTROL Service style list . . . based on O-RAN standard . . . provides support of the CONTROL services on Cell Activation Control, which is used for modification of the configuration . . . due to energy saving” including “Cell activation/deactivation” – See [¶0096] and Table 1, whereby, for example, the E2 node receives “a CONTROL Service RIC Control Message IE, where the contents of the RIC Control Message is the list of cells to be activated and/or deactivated” – See [¶0097] and converts the received control message at cell level or UE level as shown in Fig. 6; furthermore the “[n]ew O1 interfaces parameters between Non-RT RIC and the E2 nodes, where the interfaces are: (1) a list of the IDs of the cells to be activated; (2) a list of the IDs of the cells to be deactivated” – See [¶0124] and Fig. 7, steps 706 and 707) and
instruct, by the E2 node, the O-RU to execute the cell and/or carrier switch off/on (“E2 nodes described above, could include but not be limited to, eNB, O-CU and O-DU” and “the cell activation/deactivation configuration can be passed from O-CU to O-RU, to activate and deactivate RU” or “the on/off configuration could be passed from O-CU to O-DU, to instruct servers in the O-DU to be turned on or off, for energy saving purposes” – See [¶0099]).
Wang does not teach:
an R1 interface through an NRT-RIC framework used by the rApp to collect and monitor O1-related data and to send O1 configuration data;
an open front haul management plane (FH M-Plane) interface between the E2 node and an open radio unit (O-RU) used to collect O1-related data (although Wang teaches that “new thresholds parameters can then be configured . . . through open fronthaul to O-RU” – See [¶0120]); and
among the at least one re-trained AI/ML, deploy and activate, by the rApp, one re-trained AI/ML model for inferring data providing 01 configurations required to perform the cell and/or carrier switch off/on within the O-RAN.
Polese draws information from many referenced O-RAN technical specifications to provide a “deep dive” describing O-RAN architecture, design principles, and the O-RAN interfaces, “including the Artificial Intelligence (AI) and Machine Learning (ML) workflows that the architecture and interfaces enable” – See Abstract and Fig. 4.
Polese, in Fig. 6, teaches that R1 interface is used by the rApp running in the Non-RT RIC, to “obtain access to data management and exposure services, AI/ML functionalities, as well as A1, O1 and O2 interfaces through the internal messaging infrastructure” and that “rApps can support the same control functionalities provided by xApps (e.g., traffic steering, scheduling control, handover management) at large[r] timescale” and “derive control policies that operate at a higher level and affect a larger number of users and network nodes” – See § IV.A, at pages 7-8, first paragraph and Fig. 6. Polese further teaches that “rApps can reach the non-RT RIC through the R1 termination” – See § IV.B, at page 8, second paragraph; and that “O-RAN follows a consumer/producer protocol in which data producers in the SMO/non-RT RIC can advertise and publish data (e.g., performance reports or AI-based prediction of KPMs and network load)” and ”data consumers (e.g., rApps that determine high-level control policies) can discover, subscribe, receive and consume relevant data types from a selected number of nodes in the SMO/non-RT RIC domain” – See id, third paragraph, and Fig. 6.
Polese also teaches an open front haul management plane (FH M-Plane) interface between the E2 node and an open radio unit (O-RU) is used to collect O1-related data and to send instructions from the E2 node to the O-RU to execute (“The O-RAN Fronthaul (FH) interface connects a DU to one or multiple RUs inside the same gNB” – See § V.D, at page 13, col. 1, first paragraph, and Fig. 12; wherein “[t]he M-plane of the O-RAN FH can function as the O1 interface of the RU” and “takes care of several operations related to the life cycle of the RU” such as “the start-up, during which the RU establishes the management with the DU and/or the SMO” and “configuration management, performance and fault monitoring, and file management for bulk transfer of data” – See id, at page 14, col. 2, second and third paragraph).
Regarding AI/ML models, Polese teaches that AI/ML workflow is standardized by O-RAN and “[c]ontinuous operations ensure that models that perform poorly online can be refined and re-trained to improve their functionalities” – See § VI, at page 16, col. 1, last paragraph; see also Fig. 13.
Polese also teaches that models “are published and stored in an AI/ML catalog on the SMO/non-RT RIC” from where they “can be downloaded, deployed and executed,” e.g., by an rApp. Polese further teaches at least one re-trained AI/ML, deploy and activate, by the rApp, one re-trained AI/ML model for inferring data providing O1 configurations required to perform the RF reconfiguration within the O-RAN (“the AI/ML model is downloaded as a standalone file that executes within an inference environment . . . that forwards the inference output of the model to one or more O-RAN applications,” i.e., a rApp, for “taking management and control actions (over the O1 and E2 interfaces, respectively)” – See id, at page 17, col. 1, first and second paragraphs; see also Fig. 14 wherein the AI/ML model is deployed and activated on an inference host also in the non-RT RIC or in the Near-RT RIC).
Thus, Polese and Wang each teaches rApps and an NRT-RIC framework, wherein an rApp collects and monitors O1-related data and sends O1 configuration data to/from a E2 node. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the R1 interface, the FH M-Plane the continuous operations of the AI/ML workflow in Polese could have been added in to the NRT-RIC in Wang because the Wang system is “based on an O-RAN architecture” – See [¶0031]. Furthermore, a person of ordinary skill in the art would have been able to carry out the addition through techniques known in the art. Finally, the addition achieves the predictable result of allowing the energy saving rApp in Wang to integrated in the NRT-RIC framework and the AI/ML workflow following the O-RAN standard for Non-RT RIC architecture, as described or referenced in Polese.
In addition or in the alternative to Wang teaching wherein the O1-related data comprises measurement reports provided from the O-RU, the energy consumption (EC) measurement report indicating energy consumed by the O-RU – See [¶0125], Polese gives insights into the acquisition of the claimed reports.
First, Polese teaches that “one DU can support more than one RU, e.g., to serve carriers of the same cells from different RUs, or to process multiple cells with one DU and multiple RUs” using “the O-RAN FH specifications” whereby “[t]he O-RAN FH protocol includes . . . management plane (M-plane), for the configuration of the RU functionalities from the DU itself [110]” – See § V.D, id., ¶2:col.2, at page 12 (citing to O-RAN.WG4.MP as reference [110]), and “[t]he M-plane of the O-RAN FH can thus function as the O1 interface of the RU. As for O1, the management directives are based on NETCONF” – See id., ¶2:col2, at page 14, thus clarifying that the O-DU and the O-RU are intimately connected through the O-RAN FH interface. Then, Polese gives the key to understanding how the O-DU of an E2 node obtains the from the O-RU, the measurement reports comprising at least one of an energy efficiency (EE) measurement report indicating energy efficiency of the O-RU or an energy consumption (EC) measurement report indicating energy consumed by the O-RU (“the M-Plane . . . . enables software updates, configuration management, performance and fault monitoring, and file management for bulk transfer of data. Among others, the M-plane manages the registration of the RU as PNF” – See § id., ¶3:col2, at page 14 (emphasis added) whereby “[t]he performance metrics are also either based on 3GPP documents [95], vendor specific, or standardized by the different WGs of the O-RAN Alliance” – See § V.B., ¶4, col.1, at page 12; whereby reference [95] is 3GPP TS 28.552 V17.8.0 (2022-09), “Technical Specification Group Services and System Aspects; Management orchestration; 5G performance measurements (Release 17),” published September 23, 2022, requiring Power, Energy and Environmental (PEE) measurements “valid for a 5G Physical Network Function (PNF),” i.e., a registered O-RU, including, for each ManagedElement,, average, minimum, and maximum power during the measurement period, the energy consumed, as well as the PNF temperature, current and voltage, i.e., energy efficiency parameters – See § 5.1.1.19.13, at page 97-100).
Even if neither Wang nor Polese would disclose techniques for collecting energy efficiency or energy consumption reports from the O-RU, O-RAN.WG4.MP technical specification from O-RAN specifically focuses on the O-RU management, including configuration and performance management. O-RAN.WG4.MP requires collection from the O-RU, in any configuration, “epe-stats include[ing] the performance measurement for energy, power and environmental parameters as shown in the following table. An O-RU shall report its supported measurement objects per hardware component class” – See Annex B.5, id.: 179, and whereby the epe-stats are measurements of power, temperature, voltage and current of hardware components such as those in the O-RU, measured “using method specified in clause 5.1.1.19 of 3GPP TS 28.552 [57]” – See Table B.1-1, id.:176; see also § 17.4, id.:150-151 (for performance management, “O-RU (Cascade / FHM) shall monitor epe-stats per hardware component”) and Annex D.3.7, id.:190 (showing epe-stats as part of the o-ran-performance-management.yang module configured to the O-RU)).
Thus, Wang in view of Polese and O-RAN.WG4.MP each teaches O-RU management through the FH M-Plane. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the techniques for performance management reporting and collection of epe-stats by the O-DU disclosed in O-RAN.WG4.MP could be applied to the O-DU in the E2 node managing the O-RU taught in Wang in view of Polese because both references teach O-RU managed by the O-DU/E2 node. Furthermore, a person of ordinary skill in the art would have been able to carry out the addition through techniques known in the art. Finally, the addition achieves the predictable result of allowing a O-RU to report energy efficiency/energy consumption EE/EC measurements using standardized methods as taught in O-RAN.WG4.MP.
In sum, Amended Claim 1 is obvious over Wang in view of Polese and further in view of O-RAN.WG4.MP.
Regarding Amended Claim 4, dependent from Amended Claim 1, Wang teaches wherein the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on comprise at least one of configurations and performance indicators (the embodiment provides “[r]eporting of the KPIs from E2 nodes to Non-RT RIC (e.g., cell throughput, instantaneous energy consumption, number of handovers) through O1 interface” – See [¶0125]; whereby “the E2 nodes. . . could include but not be limited to, eNB, O-CU and O-DU” that control the O-RU – See [¶0099]; and “[t]he rApp 803 . . . makes a decision, according to the parameters obtained from O1 interface, e.g., instantaneous as well as average cell loads and KPIs of the E2 node(s)” – See [¶0130]),
wherein the measurement reports further comprise at least one of a cell load related information and traffic information (“The E2 node(s) report/transmit relevant network parameters, such as updates of the cell loads, to the non-RT RIC and/or Near-RT RIC” – See [¶0116]; and “[t]he rApp 803 uses cell statistics collected from E2 Node(s) 306, such as load statistics” – See [¶0130]).
In addition, § 10, O-RAN.WG4.MP:73-79 discloses the details of configuring and obtaining the measurement reports from the O-RU using NETCONF procedures and YANG subscriptions and/or asynchronous notifications. Furthermore, Annex B.3, O-RAN.WG4.MP: 178-179 specify the traffic statistics measured by the O-RU, whereby the collecting node, e.g., the O-DU/E2 node aggregates multi-carrier O-RUs at cell level, as taught by Polese supra.
Therefore, Amended Claim 4 is obvious over Wang in view of Polese and further in view of O-RAN.WG4.MP.
Regarding Claim 5, dependent from Claim 1, Wang in view of Polese teaches wherein while collecting the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on, as explained in Regarding Claim 1, supra.
Polese further teaches send, by the rApp, an O1-related data collection request via an R1 interface through the NRT-RIC framework and via an O1 interface through the SMO function within the SMO framework to the E2-node (“the non-RT RIC hosts the R1 termination, which allows rApps to interface with the non-RT RIC . . . to obtain access to data management and exposure services . . . as well as A1, O1 and O2 interfaces through the internal messaging infrastructure” – See § IV.A, at page 7, col.2, last paragraph; and the SMO/Non-RT RIC framework providing data services is connected through the O1 interface to the E2-node – See, e.g., Fig. 4, and “[t]he O-RAN specifications also include data management and exposure services pertaining to the SMO/non-RT RIC framework . . . follow[ing] a consumer/producer protocol in which data producers in the SMO/non-RT RIC can advertise and publish data (e.g., performance reports or AI-based prediction of KPMs and network load” while “data consumers (e.g., rApps that determine high-level control policies) can discover, subscribe, receive and consume relevant data types from a selected number of nodes in the SMO/non-RT RIC domain” – See § IV.B, at page 8, col2, third paragraph4; therefore an rApp may request O1-related data collection through the O1 or R1 interfaces and the SMO will send it to the E2-node);
receive, by the E2 node, the O1-related data collection request from the SMO function and collect by the E2 node, the O1-related data providing O1 configurations required to perform a cell and/or carrier switch off/on from the O-RU ( “[t]he O1 interface supports Management Services (MnS), which include the management of the life-cycle of O-RAN components (from startup and configuration to fault tolerance and heartbeat services)”i.e., including carrier or cell switch on/off, connecting “one MnS provider (i.e., generally the node managed by the SMO) to one MnS consumer (i.e., the SMO)” and also supports “Provisioning Management Services [which] allow the SMO to push configurations to the managed nodes, and the reporting of external configuration updates from managed nodes to the SMO” whereby “O1 uses a combination of REST/HTTPS APIs and NETCONF” – See § V.B, at page 12, col.1, first, second and third paragraph)
via an open front haul management plane FH M-Plane interface between the E2 node and the open radio unit O-RU (“[t]he O-RAN Fronthaul (FH) interface connects a DU to one or multiple RUs inside the same gNB,” i.e., the E2 node– See § V.D, at page 13, col. 1; and, through the M-plane of the O-RAN FH which “can function as the O1 interface of the RU . . . takes care of several operations related to the life cycle of the RU” including “configuration management, performance and fault monitoring, and file management for bulk transfer of data” – See id., at page 14, col. 2, second paragraph; e.g., collecting the data providing O1 configurations required to perform cell and/or carrier switch on/off); and
send, by the E2 node, the collected O1-related data providing O1 configurations required to perform a cell and/or carrier switch off/on via the O1 interface through the SMO function and through the NRT-RIC framework within the SMO framework to the rApp via the R1 interface. e.g., Performance Assurance Services available to the SMO at the O1 interface push the collected O1-related data providing O1 configurations required to perform a cell and/or carrier switch off/on via the O1 interface through the SMO function and through the NRT-RIC framework within the SMO framework to the rApp via the R1 interface – See, e.g., Fig. 12; see also Wang, Figs. 7 and 8.
Thus, Claim 5 is obvious over Wang in view of Polese, and further in view of O-RAN.WG4.MP.
Regarding Claim 6, dependent from Claim 1, Wang teaches notify, by the E2 node, the completion of the implementation of the cell and/or carrier switch off/on towards the rApp via an O1 interface through the SMO function and via an R1 interface through the NRT-RIC framework within the SMO framework, e.g., in Fig. 8, and in Fig. 7 at step 707. Furthermore, Polese teaches the M-Plane interface, e.g., in Fig. 12, for NETCONF Network Management Services regarding the lifecycle of the RU. However, Wang in view of Polese does not teach notify, by the O-RU, the completion of the implementation of the cell and/or carrier switch off/on towards the E2 node via the FH M-Plane interface between the E2 node and the O- RU.
O-RAN.WG4.MP teaches a “ NETCONF/YANG based M-Plane” model of the E2 node wherein “NETCONF clients connecting to the O-RU may be of different classes (e.g., O-DU and SMO)”, and “functions like O-RU software management, performance management, configuration management and fault management can be managed directly by the management system(s)” e.g., the SMO, because “[d]irect logical communication between an O-RU and SMO can be enabled via O-RUs being assigned routable IP” – See § 5.1.2 and Figure 5.1.1-1. O-RAN.WG4.MP further teaches that a NETCONF Server in the O-RU can deliver a (pnfRegistration) notifications NETCONF client (such as a O-DU or SMO) to report operational data upon client registration – See id., § 6.2.1 and Figure 6.9.2.1. In addition, the use of YANG models with NETCONF operations “allows O-RU Controllers to configure the O-RU to provide notifications of modifications to its YANG datastore” – See id., § 9.4.2 (e.g., Figure 9.1.3-1 wherein a power-state is changed). Therefore, O-RAN.WG4.MP for open FH M-Plane operations at O-RU level such as the cell and/or carrier switch off/on, teaches notify, by the O-RU, the completion of the implementation of the cell and/or carrier switch off/on towards the E2 node (containing the O-DU) via the FH M-Plane interface between the E2 node and the O- RU.
Therefore, Claim 6 is obvious over Wang in view of Polese, and further in view of O-RAN.WG4.MP.
Regarding Claims 8, and 11-13, as amended, they merely recite the steps executed by the O-RAN system in Claims 1, and 4-6, respectively, as amended, with no other limitations. Because Claims 1, and 4-6, as amended, are obvious over Wang in view of Polese and further in view of O-RAN.WG4.MP, Claims 8, and 11-13, as amended, are also obvious over Wang in view of Polese and further in view of O-RAN.WG4.MP.
Regarding Amended Claim 15, Wang teaches a non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor configured to implement a non-real-time radio intelligent controller (NRT-RIC), an NRT-RIC framework, at least one SMO function and an rApp hosted by the NRT-RIC, to perform a method for implementing an optimization of a carrier and/or cell switch off/on in an open radio access network (0-RAN) by a service management and orchestration (SMO) framework (as shown in Fig. 8 wherein “block[s] of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, may be implemented by computer program instructions . . . stored in a computer usable or computer readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer usable or computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks” – See [¶0052]). Because Wang in view of Polese and further in view of O-RAN.WG4.MP teaches all the other limitations in Amended Claim 15 which are not different from the steps executed by the system in Amended Claim 1, Amended Claim 15 is obvious over Wang in view of Polese and further in view of O-RAN.WG4.MP.
Regarding Claims 18-20, as amended, dependent from Amended Claim 15, they merely recite the steps in Claims 4-6, respectively, as amended, with no other limitations. Because Amended Claim 15 and Claims 4-6, as amended, are obvious over Wang in view of Polese, and further in view of O-RAN.WG4.MP, Claims 18-20, as amended, are obvious over Wang in view of Polese and further in view of O-RAN.WG4.MP.
In sum, Claims 1, 4-6, 8, 11-13, 15, and 18- 20, as amended, are rejected under 35 U.S.C. 103 as obvious over Wang in view of Polese and further in view of O-RAN.WG4.MP.
Claims 2-3, 7, 9-10, 14, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Wang in view of Polose and further in view of O-RAN.WG4.MP as applied to Amended Claim 1, 8 and 15 above, and further in view of O-RAN Working Group 2, “O-RAN Non-RT RIC: Functional Architecture 1.01,” O-RAN.WG2.Non-RT-RIC-ARCH-TR-v01.01 Technical Report, July 2021 (available for download at https://specifications.o-ran.org/specifications) (hereinafter O-RAN.WG2.Non-RT-RIC-ARCH-TR)( Polese reference [21]).
Regarding Claim 2, dependent from Amended Claim 1, Wang further teaches “Machine Learning, ML, models for energy optimization, which may respectively autonomously recognize traffic types, predict throughput and energy consumption under a certain traffic pattern” – See [¶0136]. Polese also teaches that ML models “are published and stored in an AI/ML catalog on the SMO/non-RT RIC” – See § VI, at page 15, col.2, second paragraph; and “AI/ML catalog . . . provide side information on the ideal network conditions (e.g., network load, mobility pattern, size of deployment) under which the specific AI solution delivers the best performance” – See id., third paragraph.
Polese further teaches while re-training of at least one AI/ML model the at least one processor is further configured to:
select, by the rApp, an AI/ML model from a plurality of AI/ML models (“models go through a validation phase to make sure they are reliable,” e.g., “evaluating how well diverse AI solutions perform under diverse traffic patterns and demand, number and distribution of users, available bandwidth and operational frequencies” and “either point out AI solutions that are not performing well and need to be retrained, as well as determine the subset of AI algorithms that can be published to the AI/ML catalog as well as provide side information on the ideal network conditions (e.g., network load, mobility pattern, size of deployment) under which the specific AI solution delivers the best performance” e.g., based on model parameters from the rApp – See id., and Fig. 13); and
sending, by the NRT-RIC framework, the re-trained Al/ML model to the rApp (“the deployment of the model is performed by using the O1 interface” wherein “[i]n the image-based deployment, the AI/ML model executes as a containerized image in the form of an O-RAN application (e.g., xApps and rApps)” and “[t]he file-based deployment, instead, considers the case where the AI/ML model is downloaded as a standalone file that executes within an inference environment—outside the O-RAN application domain—that forwards the inference output of the model to one or more O-RAN applications” – See Polese § VI, at page 16, col.1, first paragraph, and Fig. 13, showing the sending of the model to the execution environment (inference host)).
However, Wang in view of Polese and O-RAN.WG4.MP does not explicitly teach how an rApp interacts with the NRT-RIC framework to send, by the rApp, an initiation request for re-training the AI/ML model to the NRT-RIC framework; re-train the AI/ML model by the NRT-RIC framework; monitor, by the rApp, re-trained AI/ML model parameters and determining, based on the re-trained AI/ML model parameters, the retrieval of the re-trained AI/ML model from the NRT-RIC framework; request, by the rApp, the re-trained AI/ML model from the NRT-RIC framework.
O-RAN.WG2.Non-RT-RIC-ARCH-TR, teaches that “Non-RT RIC framework functions provide services to rApps via the open APIs (also referred to as R1 services)” including “ML Model Repository”, “AI/ML Modeling/Training Functions”; “AI/ML Model Management Functions”; and “AI/ML Monitoring functions” for run-time monitoring of AI/ML models – See § 2.4.1, at page 16; whereby “[a] function is a logical entity that plays the roles of services producer and/or service consumer” and “[t]he services provided by Non-RT RIC framework and SMO framework are discovered by rApps via ‘services registration and discovery function’” – See id, § 2.2, at page 14; see also the service-based architectural approach in § 2.2a.1, at page 15.
O-RAN.WG2.Non-RT-RIC-ARCH-TR teaches that a rApp can select and AI/ML model through the “ML model retrieval service” of the “ML Model Repository” functionality, e.g., by “providing the model identifier and the version number” and also “supplemental information” such as “the performance of the ML model, which helps consumers to select the right model version to be retrieved” – See § 3.3.2, at page 23. It further teaches that a “ML model can be continuously and incrementally updated/re-trained with online information” – See id., therefore an rApp can send an initiation for re-training of at least one AI/ML model. Furthermore, the rApp requests, by the re-trained AI/ML model from the NRT-RIC framework through the same ML model retrieval service.
O-RAN.WG2.Non-RT-RIC-ARCH-TR further teaches:
send, by the rApp, an initiation request for re-training the AI/ML model to the NRT-RIC framework; and re-train the AI/ML model by the NRT-RIC framework (“ML training in the SMO/Non-RT RIC offers offline training” and the “AI/ML Modeling/Training Functions” allow the training of AI/ML models “within the SMO/Non-RT RIC” including “registered data output from rApps over R1 interface” and “[t]he output is a trained, validated, and tested ML model, which is ready to be deployed within an rApp or xApp and which can be stored by the SMO or by the Non-RT RIC Framework using the ML model repository functionality” – See §3.3.1, at page 22-23);
monitor, by the rApp, re-trained Al/ML model parameters and determining, based on the re-trained AI/ML model parameters, the retrieval of the re-trained AI/ML model from the NRT-RIC framework (the “AI/ML Monitoring functions” further “enable run-time monitoring of AI/ML models which are deployed in Non-RT RIC” to “ensure these deployed AI/ML models performing normally as they declared in their agreements” based on types of information in the agreement/contract such as model and data specification, monitoring metrics and feedback mechanism – See id, § 3.3.3, at page 24-26; see also Polese, for off-line training, teaching that “the operator can train a set of Deep Reinforcement Learning (DRL) agents and decision trees and explore different combination and input formats (e.g., the specific subset of KPMs and their amount), different architectures (e.g., depth and width of a DRL agent, number of neurons, among others) . . . to train a large number of AI algorithms and identify which ones are the most suitable to accomplish a specific task” – See § VI, ¶1:col2, at page 15).
Thus, Wang in view of Polese and O-RAN.WG4.MP, and O-RAN.WG2.Non-RT-RIC-ARCH-TR, each teaches an AI/ML workflow in the SMO/Non-RT RIC framework and a rApp requesting at least one AI/ML model to be retrained. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the AI/ML workflow in Wang in view of Polese and O-RAN.WG4.MP could have been improved to offer the functionalities described in O-RAN.WG2.Non-RT-RIC-ARCH-TR because Polese references the O-RAN standards for implementation details. Furthermore, a person of ordinary skill in the art would have been able to carry out the improvement through techniques known in the art. Finally, the improvement achieves the predictable goal of supporting the whole AI/ML lifecycle in the O-RAN, as taught by O-RAN.WG2.Non-RT-RIC-ARCH-TR.
Therefore, Claim 2 is obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR.
Regarding Claim 3, dependent from Amended Claim 1, O-RAN.WG2.Non-RT-RIC-ARCH-TR further teaches that the ML Training functionality allows re-train, by the rApp, an AI/ML model from the plurality of AI/ML models “the option that a 3rd party application (for example, rApp or xApp) performs online learning by itself (e.g., a reinforcement learning application)” – See § 3.3.1 and that an “ML model can be continuously and incrementally updated/re-trained with online information” and “a previously stored ML model, which was proved to be well-performing, can serve as a backup if the running model evolves in the wrong direction” – See id, § 3.3.2)
Therefore, Claim 3 is obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR.
Regarding Claim 7, dependent from Amended Claim 1, Polese further teaches wherein the at least one processor is further configured to:
monitor, by the NRT-RIC, the performance of the re-trained AI/ML model and initiating an AI/ML model update or retraining (the AI/ML workflow, which is part of the SMO/NRT-RIC framework, using the feedback from O1 interface, as shown in Fig.13, has “the ability to monitor and analyze the intelligence deployed throughout the network to verify that the inference outputs of AI/ML models are effective, accurate and do not negatively affect the performance of the network” and “if any anomalies or inefficiencies are detected, it can decide to retrain the AI/ML model embedded in the xApp [or rApp] over new data collected through the O1 and E2 interfaces” – See § VI, at page 16, col. 1, last paragraph5).
However, Wang in view of Polese and O-RAN.WG4.MP does not teach a predetermined performance objective for the AI/ML model.
O-RAN.WG2.Non-RT-RIC-ARCH-TR teaches, as explained in Regarding Claim 2, supra, that the ML Monitoring function of the Non-RT-RIC is there to “ensure these deployed AI/ML models performing normally as they declared in their agreements” based on types of information in the agreement/contract from the ML provider – See § 3.3.3, at page 24. Therefore, based on the ML provider contract/agreement, the Non-RT-RIC can determine that a predetermined performance objective is not achieved based on the collected O1-related data, and initiate an AI/ML model update or retraining (or chose a previous model version from the ML repository).
Therefore, Claim 7 is obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR.
Regarding Claims 9-10, and 14, dependent from Amended Claim 8 obvious over Wang in view of Polese and O-RAN.WG4.MP, they merely recite the steps executed by the O-RAN system in Claims 2-3, and 7, respectively, with no other limitations. Because Claims 2-3 and 7 are obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR, Claims 9-10 and 14 are also obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR.
Regarding Claims 16-17, dependent from Amended Claim 15, obvious over Wang in view of Polese and O-RAN.WG4.MP, they merely recite the steps in Claims 2-3, respectively, with no other limitations, as applied to Amended Claim 15. Because Claims 2-3 and 15 are obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR, Claims 16-17 are obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR.
Therefore, Claims 2-3, 7, 9-10, 14, and 16-17 are rejected under 35 U.S.C. 103 as obvious over Wang in view of Polese and O-RAN.WG4.MP, and further in view of O-RAN.WG2.Non-RT-RIC-ARCH-TR.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Wang et al., U.S. Patent Application Publication No. 2025/0254016 also discloses non-real-time RAN intelligent controller (non-RT RIC) and near-RT RIC and a method of configuring one node with a list of cell IDs representing cells to be activated or deactivated based on a condition in a network;
Kodaypak et al., U.S. Patent Application Publication No. 2023/0362807 discloses data analytics driven metering solution for next-generation mobile networks evolution that can initiate triggers based on rules within the converged domain data analytics function (CDDAF), extract the energy efficiency data from the domain specific slices and network functions within the slice, correlates with the user traffic patterns on a location/time/service scale, and takes actions to conserve energy resources across the networking domains, referencing both 3GPP and O-RAN specification;
Han et al., WIPO Patent Application No. WO2022060923, discloses training, monitoring, pushing and pulling ML models in a Non-RT RIC ML catalog;
Ying et al., WIPO Patent Application Publication No. WO2022155511A1 disclosing data services for RIC applications (Ding, Z.);
Ying et al., U.S. Patent Application Publication No. 2022/0012645 disclosing non real-time (Non-RT) radio access network intelligence controller (RIC) services for machine learning (ML) in an open radio access network (O-RAN) for ML capability query, federated learning session creation, federated learning session deletion, global model download/update, local model upload/update, global model status query, local model status query, global model status notification, and local model status notification;
O-RAN Working Group 2, “O-RAN AI/ML Workflow Description and Requirements 1.03,” O-RAN.WG2.AIML-v01.03 Technical Specification, October 2021 (available for download at https://specifications.o-ran.org/specifications);
O-RAN Working Group 4 (Open Fronthaul Interfaces WG), “Control, User and Synchronization Plane Specification,” O-RAN.WG4.CUS.0-v09.00, July 1, 2022 (available for download at https://specifications.o-ran.org/specifications);
O-RAN Working Group 1, “O-RAN Operations and Maintenance Interface Specification,” O-RAN.WG1.O1-Interface.0-v04.00, July 1, 2022 (available for download at https://specifications.o-ran.org/specifications);
O-RAN Working Group 1, “O-RAN Operations and Maintenance Architecture,” O-RAN.WG1.OAM-Architecture-v04.00, July 1, 2022 (available for download at https://specifications.o-ran.org/specifications);
3GPP TS 28.552 V17.8.0 (2022-09), “Technical Specification Group Services and System Aspects; Management and orchestration; 5G performance measurements (Release 17),” September 23, 2022;
ITRI and PEGATRON: “Non-Real Time Radio Intelligent Controller (Non-RT RIC), Near Real-Time Radio Intelligent Controller (Near-RT RIC), O-CU O-DU flexible deployment” demo at MWC Barcelona, March 2022 (available at https://www.virtualexhibition.o-ran.org/classic/generation/2022/category/intelligent-ran-control-demonstrations/sub/intelligent-control/167) showing an Energy Saving (ES) rApp deployed in the Non-RT RIC platform to monitor the traffic load of the O-RAN gNBs and when the ES rApp detects that the traffic loading is below a threshold, it will decide which gNBs can be powered off to reduce power consumption;
D’Oro et al., "OrchestRAN: Network Automation through Orchestrated Intelligence in the Open RAN," IEEE INFOCOM 2022 - IEEE Conference on Computer Communications, London, United Kingdom, 2022, pp. 270-279, doi: 10.1109/INFOCOM48880.2022.9796744; Date of Conference: 02-05 May 2022; Date Added to IEEE Xplore: 20 June 2022;
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUCIA GHEORGHE GRADINARIU whose telephone number is (571)272-1377. The examiner can normally be reached Monday-Friday 9:00am - 5:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joseph AVELLINO can be reached at (571)272-3905. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/L.G.G./Examiner, Art Unit 2478
/JOSEPH E AVELLINO/Supervisory Patent Examiner, Art Unit 2478
1 In accord with O-RAN.WG4.MP which explains the lower-layer functional split between the O-DU and the O-RU whereby “portions of the PHY processing on the O-DU side of the fronthaul interface, including FEC encode/decode, scrambling, and modulation/demodulation” and “portions of the PHY processing on the O-RU side of the fronthaul interface, including FFT/iFFT, digital beamforming, and PRACH extraction and filtering” and defines “O-RU Controller” like the RIC disclosed in Wang, as a “network function that is permitted to control the configuration of an O-RU. Examples of O-RU controllers include, an O-DU, a classical NMS, an O-RAN Service Management and Orchestration function, or other network automation platforms” – See O-RAN.WG4.MP:12 and Fig. 5.1.1-1, at page 16, showing O-RAN WG4 FH functional split.
2 At the effective filling date, the O-RAN standard specification provided that collecting O-RU data through the O1 interface, as claimed in Amended Claim 1, goes through the E2 node and not directly to the O-RU – See, e.g., § 3.3.3, O-RAN.WG10.OAM-Architecture-v07.00, “O-RAN Operations and Maintenance Architecture,” published July 1, 2022, at page 30-31 (showing in Figure 3.3.2-1 the O-RAN logical architecture with O-DU and O-RU in same color, providing that “[t]he O1 interface . . . is used for OAM functions between the O-RAN Service Management and Orchestration Framework and the O-RAN network functions (with the exception of the O-RU). The Open FH M-plane is used for OAM functions between O-RAN Service Management and Orchestration Framework and O-RU when O-RU is managed using the hybrid management model” and that “[i]n the flat model, all entities/nodes are managed directly by the SMO. This model is not currently supported for the O-RU and is for future study”) (emphasis added).
3 Examiner’s note: the reference O-RAN Alliance Working Group 4 “Management Plane Specification,” O-RAN.WG4.MP.0-v09.00 Technical Specification, July 2022 (available for download at https://specifications.o-ran.org/specifications) (hereinafter O-RAN.WG4.MP) states that at least at the time of filing the present application,” [w]hile ML model implementation in O-RU could be envisaged, it is presently not supported in O-RAN” – See O-RAN.WG4.MP:18 (showing the three control loops in O-RAN architecture in Figure 3-4)
4 Further details on requesting and obtaining data services through the R1 interface are provided in Chapter 3 of O-RAN Working Group 2, “R1 interface: General Aspects and Principles,” O-RAN.WG2.R1GAP-v02.00 Technical Specification, July 2022 (available for download at https://specifications.o-ran.org/specifications).
5 Polese references at [21] O-RAN Working Group 2, “O-RAN AI/ML Workflow Description and Requirements 1.03,” O-RAN.WG2.AIML-v01.03 Technical Specification, October 2021 (available for download at https://specifications.o-ran.org/specifications)(hereinafter O-RAN.WG2.AIML). Figure 5-5 of O-RAN.WG2.AIML shows the sequence containing the step of Model Performance Monitoring based on collected O1 data and of Model Redeploy/Update. Figure 5-5 also shows how an rApp may interact with the SMO framework orchestrator and the collector to request model training, deployment, performance monitoring, or request a model update.
Prosecution Insights