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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/27/2026 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/21/2025 was filed after the mailing date of the Final Office Action on 10/27/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 02/27/2026 complies with the requirements of 37 CFR 1.121(c) and has been entered. Claims 1, 5-6, 8, 11-13, 15, and 18-20 are amended.
Response to Arguments
Applicant's Arguments/Remarks filed 02/27/2026 (hereinafter Resp.) revolve around the concept of “carrier” and “cell” in wireless communications, whereby the Applicant distinguishes these two concepts, stating that “[t]he specification of the instant application describes a plurality of carriers of a same cell” – See Resp., 2:¶3, citing to [¶0010] of the Specification. The issue with Applicant’s distinction is that the cited paragraph states “switching off . . . one or more carriers or entire cells” (emphasis added). There is no place in the Specification supporting “a plurality of carriers of a same cell,” and the issues is clarified by Wannstrom (for 3GPP), “Carrier Aggregation explained,” June 2013 (available online at https://www.3gpp.org/technologies/101-carrier-aggregation-explained) showing in Figure 3, reproduced below, multiple component carriers used in multi-carrier communications (i.e., Carrier Aggregation) wherein “Each component carrier corresponds to a [i.e., one] serving cell. The different serving cells may have different coverage.”
PNG
media_image1.png
489
886
media_image1.png
Greyscale
Multi-carrier communication is specified in §4.5, 3GPP TS 38.211 V17.3.0 (2022-09), “Technical Specification Group Radio Access Network; NR; Physical channels and modulation (Release 17),” at page 16, explaining carrier aggregation, i.e., use of multiple carriers by one device, as “Transmissions in multiple cells can be aggregated,” i.e., one carrier per cell, and “For carrier aggregation of cells with unaligned frame boundaries, the slot offset
N
slot, offset
CA
between a PCell/PScell and an SCell is determined by higher-layer parameter ca-SlotOffset for the SCell.”
Therefore, a carrier or a cell represents the same managed object in a network management framework and the Specification is correct when it states that one carrier (or cell) or “entire cells,” i.e., all available carriers at a base station/RU can be switched on/off. However, the limitation “not all carriers, of a cell” is not supported by the Specification and inconsistent with the understanding of a person of ordinary skills in the art.
Examiner Note: Lin et al., “Embracing AI in 5G-Advanced Towards 6G: A Joint 3GPP and O-RAN Perspective,” 12 September, 2022, arXiv:2209.04987 (hereinafter Lin) summarizes, at page 4, col.2, the network energy saving problem as “a complicated problem involving multiple layers of the network and the need to balance with other key performance indicators (KPIs) and QoS requirements” and states:
“Conventional network energy saving mechanisms rely on rule-based configuration, e.g., switching on/off cells based on different thresholds of cell load. Such rule-based techniques are reactive, inflexible, and difficult for achieving globally optimized system performance and energy efficiency. AI algorithms can leverage the RAN data to optimize network energy saving, e.g., predicting energy efficiency and load in future states to enable proactive, adaptive actions of traffic offloading, coverage modification, and cell activation/ deactivation”
Therefore, the novel aspect in ML/AI network energy solutions rests in performing case-specific predictions requiring case-specific actions. For example, Yeh, US 2022/0014963 infra, uses “a deep contextual bandit RL architecture for multi-access traffic management” – See [¶0125] in order “to learn the best/optimal strategy for traffic management by interacting with the environment and collecting runtime statistics without relying on optimization models or predefined policies” – See [¶0124].
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.
Claims 1-5, 7-12 and 14-19, as amended, are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-5, 7-12 and 14-19, respectively, of copending Application No. U.S. Patent Application Publication 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 by 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. All other provisionally rejected claims follow the same rationale as in Claims 1 and 4 analyses. This is a provisional nonstatutory double patenting rejection.
Cl.
18/016,814
Cl.
18/018,399
1
A system for implementing an optimization of a carrier 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 (O-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 O1 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 . . . , energy consumption, power consumed by hardware component, transmit power, load statistics per cell and per carrier, . . . 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, 5, 7, 9-10, 12, 14, 16-17, and 19 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, 11, 15, and 18.
Therefore, Claim 1-5, 7-12 and 14-19 are provisionally rejected on the ground of nonstatutory double patenting over Claims 1-5, 7-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 § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 8, 15 and their dependent claims are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, regards as the invention.
Where applicant acts as his or her own lexicographer to specifically define a term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999).
The term “but not all carriers, of a cell” in claims 1, 8 and 15 is used by the claim language to mean “some carriers are switched off but the specific cell each of them covers is still active ,” while the accepted meaning is “when a carrier is switched off, its cell coverage area is also switched off, i.e., coverage/service disappears.” The term is indefinite because the specification does not clearly redefine the term. Here, the Specification states “switching off... one or more carriers or entire cells” – See [¶0010] that is, by the understanding of a person of ordinary skills in the art, that when a carrier is switched off the cell covered by each carrier is also switched off leading to “entire cells” being switched off. The concept of cell vs. carrier is explained in the Figured referenced in Response to Arguments supra.
For these reasons, Claims 1, 8, 15 and their dependents are rejected under 35 U.S.C. 112(b) for indefiniteness.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Yeh et al., U.S. Patent Application Publication No 2022/0014963 and O-RAN and 3GPP specifications referenced therein (hereinafter Yeh) in view of Wang et al., U.S. Patent Application Publication No 2025/0254016 (hereinafter Wang).
Regarding Claim 1, Yeh teaches a system for implementing an optimization of a carrier switch off/on (a “scalable artificial intelligence (AI)/machine learning (ML) architecture embodiments and implementations for multi-access traffic management . . . by interacting with the environment and collecting the runtime statistics” – See [¶0031])
in an open radio access network (O-RAN) by a service management and orchestration (SMO) framework (“The O-RAN architecture 2000 includes four O-RAN defined interfaces-namely, the Al interface, the O1 interface, the O2 interface, and the Open Fronthaul Management (M)-plane interface-which connect the Service Management and Orchestration framework (SMO) 2002 to O-RAN network functions (NFs) 2004 and the O-Cloud 2006” – See [¶0277] and FIG. 20, whereby “[t]he O1 interface is an interface between orchestration & management entities (Orchestration/NMS) and O-RAN managed elements, for operation and management, by which FCAPS management, Software management, File management and other similar functions shall be achieved (see e.g., O-RAN Alliance Working Group (WG) 1, "O-RAN Architecture Description" v04.00 (March 2021) ("[O-RAN.WG 1.O-RAN-Architecture-Description-v04.00]")” – See [¶0278], referencing O-RAN WG 1, O-RAN.WG1.O-RAN-Architecture-Description-v06.00, “O-RAN Architecture Description 6.0,” July 2022, (hereinafter O-RAN.WG1.O-RAN-Architecture-Description) showing, at page 18, in Figure 4.3-1, the SMO Framework, rApps and interfaces of the 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 (“FIG. 21 illustrates a logical architecture 2100 of the O-RAN system architecture 2000 of FIG. 20” – See [¶0280] and FIGs. 20-22 showing the NRT-RIC whereby, as shown in FIG. 26, the “compute node 2600 may be embodied as any type of engine, device, or collection of devices capable of performing various compute functions” including the “SMO 2002, O-RAN NFs 2004, O-Cloud 2006, NG-Core 2008, external system 2010, Non-RT RIC 2012, Near-RT RIC 2014, O-RU 2016 of FIG. 20; UE 2101, SMO 2102, O-cloud 2106, O-e/gNB 2110, Non-RT RIC 2112, Near-RT RIC 2114, O-DU 2115, O-RU 2116, O-CU-CP 2121, O-CU-UP 2122 and/or FIG. 21; E2 nodes of FIG. 22” – See [¶0409] ;and as shown in Fig. 21, “the Service Management and Orchestration Framework” used for “operation and management, by which FCAPS management, Software management, File management and other similar functions shall be achieved (see e.g., O-RAN Alliance Working Group (WG) 1, "O-RAN Architecture Description" v04.00 (March 2021) ("[O-RAN.WG 1.O-RAN-Architecture-Description-v04.00]")” – See [¶0278], i.e., SMO functions, e.g., in a “management architecture of flat mode O-RAN Alliance WG1, "O-RAN Operations and Maintenance Architecture Specification" v04.00 (November 2020) ("[O-RAN.WG1.OAM-Architecture-v04.00]") and its relation to the O1 interface for the O-RU” – See [¶0279] wherein O-RAN.WG1.OAM-Architecture-v04.00, O-RAN Working Group 1, “O-RAN Operations and Maintenance Architecture,” July 1, 2022 (hereinafter O-RAN.WG1.OAM-Architecture) specifies, at page 31, that “[i]n the flat model, all entities/nodes are managed directly by the SMO” albeit the model is for further study, and referencing, at page 28, the OAM O1 Interface specification for definition of supported management services and their APIs for SMO functions such as “Instantiation and Termination of a Virtualized Network Function (VNF)” managing, controlling, and routing traffic across component carriers, in accord with Yeh:[¶0279] stating that “O-RAN NFs 2004 can be VNFs such as VMs or containers, sitting above the O-Cloud 2006 and/or Physical Network Functions (PNFs) utilizing customized hardware. All O-RAN NFs 2004 are expected to support the O1 interface when interfacing the SMO 2002”; see also O-RAN WG 1, O-RAN.WG1.O-RAN-Architecture-Description-v06.00, “O-RAN Architecture Description 6.0,” July 2022, (hereinafter O-RAN.WG1.O-RAN-Architecture-Description) showing, at page 18, in Figure 4.3-1, the SMO Framework, rApps and interfaces, referencing O-RAN.WG2. Non-RT-RIC-TS-v02.00, O-RAN Working Group 2, “Non-RT RIC Architecture,” July 2022, (hereinafter O-RAN.WG2.Non-RT-RIC-ARCH) specifying, at page 12, in Figure 4-1, the Non-RT RIC Reference Architecture), and
an rApp hosted by the NRT-RIC (“In O-RAN framework. . ., the traffic distributor control plane that calculates traffic distribution rules can be part of the RAN intelligence controller (RIC)” whereby “data-driven machine learning (ML) techniques can be used to develop advanced multi-access traffic distribution strategies” – See [¶0093], e.g., an “agent can be implemented as a single xApp” or “can be implemented as multiple xApps where the four performance assurance mechanisms [of the SMO] communicate with each other and the RL inference model via xApp APIs” – See [¶0102] and FIG. 5 showing an Agent 501 running an ML model, whereby “pre-trained ML algorithms may be implemented as a separate microservices (e.g., xApp(s) in O-RAN)” and a real-time “agent 501 can subscribe those services to obtain recommended traffic distribution actions . . . shared via APIs” – See [¶0108] e.g., a “threshold linked to one of the performance metrics can be provided to the EW 507 via A1-policy from non-RT RIC or via xApp API from near-RT RIC management module or another xApp” – See [¶0116] and FIG. 5, whereby a person of ordinary skills in the art would appreciate that an agent in the non-RT RIC may be an rApp1 as per O-RAN specifications – See, e.g., O-RAN.WG2.Non-RT-RIC-ARCH-TR-v01.01, O-RAN Working Group 2, “Non-RT RIC: Functional Architecture,” July 2022 (hereinafter O-RAN.WG2.Non-RT-RIC-ARCH-TR) describing, at page 13, in Figure 2.2-1 reproduced below, the functional view of the SMO and the NRT-RIC, including the APIs/interfaces, e.g., R1 the rApp and the NRT-RIC, the SMO internal interface between the NRT-RIC and the SMO framework and the O1 interface to E2 nodes)
PNG
media_image2.png
200
400
media_image2.png
Greyscale
Figure 2.2-1: Non-RT RIC architecture functional view diagram (O-RAN.WG2.Non-RT-RIC-ARCH-TR)
the at least one processor configured to execute the instructions to: collect, by an rApp, O1-related data2 providing O1 configurations3 required to perform the carrier switch off/on via the R1 interface through the NRT-RIC framework and via an O1 interface through a SMO function within the SMO framework (“All O-RAN NFs 2004 are expected to support the O1 interface when interfacing the SMO 2002 . . . (see e.g., O-RAN Alliance WG1, "O-RAN Operations and Maintenance Interface Specification" v04.00 (November 2020) ("[O-RAN.WG1.O1-Interface. 0-v04.00]"))”” – See [¶0279] and Fig. 20, whereby the “O1 interface is an interface between orchestration & management entities (Orchestration/NMS) and O-RAN managed elements, for operation and management, by . . . FCAPS management” – See [¶0278], e.g., “for gathering radio network information from the radio base station . . . thus enabling the execution of suitable radio-aware traffic management algorithms” – See [¶0266] and also “the Near-RT RIC 2214 and other RAN nodes have O1 interfaces as defined in [O-RAN.WG1.OAM-Architecture-v04.00]” – See [¶0302]; see also O-RAN.WG1.OAM-Architecture defining, at page 21, the O-RU as a “O-RAN Managed Element” comprising one or more “Managed Functions (MF)” in accordance with “3GPP TS 28.622 [3] section 4.3.3” ; see O-RAN.WG10.OAM-Architecture-v07.00, O-RAN Operations and Maintenance Architecture, July 2022 (hereinafter O-RAN.WG10.OAM-Architecture) describing in Appendix C.5, at page 58-60, the lifecycle of an rApp in the NRT-RIC, whereby “rApp deployment is instantiated on Non-RT RIC, resulting in enhanced capabilities. Configuration and communication between rApp and SMO is mediated by the Non-RT RIC via the R1 interface” after the “rApp registers with the Non-RT RIC via the R1 interface,” then “the Non-RT RIC . . . detect[s] when rApp is requesting data that is anchored in the SMO and initiate a request for that data,” e.g., the measurement data from the O-RU/ME required to perform carrier switch on/off, and further describing in Annex A, at page 61, Figure A-1, SMO and Non-RT RIC mapping with 3GPP management system, stating that “O1 interface reflects the 3GPP traditional FCAPS management services,” i.e., O1 configurations required to perform the carrier switch off/on, a Configuration Management SMO function, are obtained by the rApp through the R1 interface to the NRT-RIC and through the O1 interface to the SMO as explained, e.g., in O-RAN.WG2.Non-RT-RIC-ARCH, at page 12, stating that “Data Consumers (e.g., rApps) communicate information about the data types that they want to discover. Data Consumers subscribe/request data from the SMO/Non-RT RIC framework for consumption with specific data type, periodicity, and delivery (or reporting) method, scope, etc.”)
from an E2 node (as shown in Figure 21, “E2 nodes include the O-e/gNB 2110,” i.e., base stations; see also Figure 22, showing that the “Near-RT RIC 2214 can be connected to multiple E2 Nodes (e.g., multiple O-CU-CPs 2221, O-CU-UPs 2222, O-DUs 2215, and O-e/gNBs 2210)” through E2 interfaces, and, “[i]n addition, the Near-RT RIC 2214 and other RAN nodes have O1 interfaces” – See [¶0302] e.g., to communicate with the SMO as a NETCONF/NMS client as shown infra),
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) (“The Open Fronthaul M-plane interface between the SMO 2002 and the O-RAN Radio Unit (O-RU) 2016 supports the O-RU 2016 management in the O-RAN hybrid model as specified in O-RAN Alliance WG4, O-RAN Fronthaul Management Plane Specification, version 2.0 (July 2019) ("[ORAN-WG4.MP.0-v02.00.00]")” – See [¶0279] and Fig. 21 showing the Open FH interface between the SMO and the O-RU in an E2 node, whereby “the O-RU 2116 terminates the OF M-Plane interface towards the O-DU 2115 and optionally towards the SMO 2102 as specified in [ORAN-WG4.MP.0-v02.00.00]” – See [¶0287]; see also O-RAN Alliance Working Group 4, “Management Plane Specification,” ORAN.WG4.MP.0-v09.00 Technical Specification, July 2022 (hereinafter ORAN.WG4.MP), defining, at page 13, the “O-RU: O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer functional split. This is similar to 3GPP’s ‘TRP’ or ‘RRH’” and an “O-RU Controller: 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”; further specifying the architecture for the Open fronthaul functional split at page 17, Figure 5.1.1-1 showing in detail the M-Plane between a O-DU/E2 node and an O-RU, also that the SMO/NMS has access to the M-Plane to extract O1-related/FCAPS data because the “NETCONF/YANG based M-Plane is used for supporting the management features including "start up" installation, software management, configuration management, performance management, fault management and file management towards the O-RU” whereby “NETCONF/YANG is used as the network element management protocol [3] and data modelling language”; and at page 156, in Figure 17-2-1 the NETCONF client that may be implemented by the SMO)
PNG
media_image3.png
200
400
media_image3.png
Greyscale
Figure 17.2-1: M-Plane Connection
based on the collected O1-related data, by the SMO, re-train at least one artificial intelligence/machine learning (AI/ML) model (“the non-RT RIC 2112 may request or trigger ML model training in the training hosts regardless of where the model is deployed and executed” and “can be an ML training host to host the training of one or more ML models’ whereby “ML training can be performed offline using data collected from the RIC, O-DU 2115 and O-RU 2116,” e.g., O1-related data/FCAPS data from the O-RU and “[f]or supervised learning, non-RT RIC 2112 is part of the SMO 2102, and the ML training host and/or ML model host/actor can be part of the non-RT RIC 2112 and/or the near-RT RIC 2114” – See [¶0296] and Fig. 21 whereby “[t]he non-RT RIC 2112 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations” – See [¶0298]);
among the at least one re-trained AI/ML (“ML models may be trained and not currently deployed” – See [¶0296]; “the non-RT RIC 2112 provides a query-able catalog for an ML designer/developer to publish/install trained ML models (e.g., executable software components)” and “the non-RT RIC 2112 may provide discovery mechanism if a particular ML model can be executed in a target ML inference host (MF), and what number and type of ML models can be executed in the MF” – See [¶0297], i.e., an rApp in the NRT-RIC may query and retrieve and AI/ML model through the R1 interface),
deploy and activate, by the rApp, one re-trained AI/ML model for inferring data providing O1 configurations required to perform the carrier switch off/on within the O-RAN (“The non-RT RIC 2112 may also implement policies to switch and activate ML model instances under different operating conditions” – See [¶0297]; see also O-RAN.WG1.O-RAN-Architecture-Description, specifying, at page 19, that “The Non-RT RIC is comprised of two sub-functions: Non-RT RIC Framework” and “Non-RT RIC Applications (rApps) – Modular applications that leverage the functionality exposed by the Non-RT RIC Framework to perform RAN optimization and other functions. Services exposed to rApps via the R1 interface enable rApps to obtain information and trigger actions (e.g., policies, re-configuration) through the A1, O1, O2 and Open FH M-Plane related services”);
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 O1-related data providing O1 configurations required to perform the carrier switch off/on, wherein the O1-related data comprises measurement reports provided from the O-RU (e.g., O-RAN.WG2.Non-RT-RIC-ARCH supra further references O-RAN.WG2.R1GAP-v02.00, “O-RAN Working Group 2; R1 interface: General Aspects and Principles,” July 2022, (hereinafter O-RAN.WG2.R1GAP) for details on data consumption by rApps, whereby O-RAN.WG2.R1GAP, at page 11, specifies that an rApp “Service Consumer provides information on the data that it intends to consume based on the data type information and specifies additional characteristics of the data instance to obtain” including “data type identifier, start time and stop time for the collection of data instances, time interval (for the data instance), periodicity of collection and delivery (how often data instances are to be collected and delivered), scope (i.e., filter on the data), target (i.e., filter on the managed objects that the data is associated with)” as part of R1 Services, similar to the MEC Service at the Mp1 interface in Figures 18-19 of Yeh, and furthermore like the Near-RT RIC exposing the “REPORT Service RIC Action Definition IE [which] contains measurement types that Near-RT RIC is requesting to subscribe followed by a list of categories or subcounters to be measured for each measurement type, and a granularity period indicating collection interval of those measurements. The IE may also contain a cell identifier to point to a specific cell for collecting measurements within the E2 Node” – See [¶0337], i.e., measurements may be per carrier/cell4)
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 RAN function handling reporting of the cell-level performance measurements for 5G networks [is] defined in 3GPP TS 28.552 v17.3.1 (2021-06-24) ("[TS28552]") . . . hereby incorporated by reference in their entireties, and their possible adaptation of UE-level or QoS flow-level measurements. The RAN function Key Performance Measurement (KPM) is used to provide RIC Service exposure of the performance measurement logical function of the E2 Nodes” – See [¶0329], e.g., a data reporting RIC Service “subscribes to the measurements defined in [TS28552] and [TS32425]” – See [¶0336], whereby, “[t]he conversion of the measurements' definitions provided in [TS2S552] and [TS532425] is performed according to the rules in Table 9” – See [¶0347] and Table 9 showing “Data volume” and “PEE related”; see also 3GPP TS 28.552 V17.8.0 (2022-09), “Technical Specification Group Services and System Aspects; Management orchestration; 5G performance measurements (Release 17),” (hereinafter 3GPP TS 28.552) indicating, at page 25-26, “The list of families currently used in the present document”, including “CARR (measurements related to Carrier),” and “PEE (measurements related to Power, Energy and Environment)” e.g., at page 41, “Average DL UE throughput in gNB,” comprising “the total volume scheduled for each UE regardless if using only primary- or also supplemental aggregated carriers,” and in § 5.1.1.19, at page 99-11, specifies measured and reported KPI/KPMs for the RU, e.g., required Power, Energy and Environmental (PEE) measurements “valid for a 5G Physical Network Function (PNF),” including “PNF Energy consumption,” “the average power consumed over the measurement period” and “the minimum power consumed during the measurement period”; Annex B.5, ORAN.WG4.MP, specifying, at page 207, that “epe-stats include 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”);
evaluate, by the rApp, the O1-related data providing O1 configurations required to perform the carrier switch off/on (“a DU (e.g., O-DU 2115) can use E2SM KPM RIC style message(s) to convey, to an RIC (e.g., Near-RT RIC 2114 and/or Non-RT RIC 2112), per UE throughput (e.g., average and/or distribution of UE throughput in NAN (e.g., gNB); see e.g., [TS28552] § 5.1.1.3)” – See [¶0350] because “[t]he RNI may be provided at the relevant granularity (e.g., per UE 1820, per cell, per period of time)” – See [¶0242], whereby the Non-RT RIC may provide the O1-related data through the R1 Service Consumer interface to the rApp, i.e., the inference host for the AI/ML model, for “[t]he pre-trained ML algorithms to generate a suggested set of actions to be chosen for exploration,” i.e., evaluation, or “pre-trained ML algorithms can also be an action prediction model trained through supervised learning” – See [¶0107] e.g., a policy change regarding carriers switch on/off at certain times);
determine, by the rApp, to generate O1 configuration data to prepare and execute the carrier switch off/on (“The recommended traffic distribution actions can be shared via APIs” – See [¶0108], e.g., as further explained in O-RAN.WG2.R1GAP regarding the R1 interface services, at page 12, “[t]he push data service allows the Service Consumer to push data to the Service Producer” and “the Data management and exposure functions in the SMO/Non-RT RIC framework consume this service”; in addition, as explained at page 13, “[t]he A1 Policy management service is an R1 service that enables an rApp (the consumer of that service)” to “create, update and delete an A1 policy,” e.g., configuration data to prepare and execute the carrier switch off/on based on certain conditions as predicted by the AI/ML model inference in the rApp);
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 carrier switch off/on to the least one E2 node (“The O-RAN Non-Real Time (RT) RAN Intelligent Controller (RIC) 2112 is a logical function within the SMO 2002, 2102 that enables non-real-time control and optimization of RAN elements and resources” using “AI/machine learning (ML) workflow(s) including model training, inferences, and updates” – See [¶0294] e.g., as described in § 15, ORAN.WG4.MP, at page 112, a “NETCONF Client creates tx-array-carrier(s) and rx-array-carrier(s)” that “can be configured with type set to LTE, NR or DSS-LTE-NR” whereby the NETCONF Client implements one of the SMO FCAPS functions, e.g., Configuration and Change Management, as shown in Figure 17.2-1: M-Plane Connection supra, and further “performs activation by setting the value of the parameter "active" at tx-array-carrier element / rxarray-carrier element to "ACTIVE"” and “deactivation by setting the value of the parameter "active" at tx-array-carrier element /rx-array-carrier element to "INACTIVE"” as explained at page 114, effectively switching on/off a carrier)
wherein the carrier switch off/on is a switch off/on of at least one carrier, but not all carriers, of [a] all cells (e.g., as described in § 16.3.2, ORAN.WG4.MP, at page 155, describing the case of Licensed-assisted access (LAA) carrier-aggregation (CA), wherein “[t]o start radio transmission and reception with a new centre frequency, for every component carrier (CC) that needs to be re-configured with a new centre frequency, the O-DU shall first deactivate the TX carrier, delete it, then create a new TX carrier”; in this case, it would be obvious for a person of ordinary skills in the art that the primary carrier, the PCell would not be switched off, at least not until a secondary carrier/cell is made primary and the UEs are HO-ed to the new PCell/primary carrier5).
Although Yeh describes in detail Carrier Aggregation (CA) Control, used to control operations of Carrier Aggregation (CA) at the E2 node and the O-RU – See, e.g., [¶0367] and Table 12, showing the supported CONTROL Service Style Types, including CA, for each action “the RAN parameters [are] to be controlled by Near-RT RIC pertaining to the given control action” through the E2 interface – See [¶0368], Yeh does not teach implement, by the E2 node and the O-RU, the carrier switch off/on 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 carrier switch off/on and instruct, by the E2 node, the O-RU to execute the carrier switch off/on.
Wang teaches in Figs. 2 and 8 “a method and apparatus for RAN energy saving in a wireless communication system using O-RAN” – See [¶0010] whereby “a network entity in wireless communication system using an open-radio access network (O-RAN) is provided, the network entity including at least one of a non-real-time RAN intelligent controller (non-RT RIC) and near-RT RIC, the network entity comprises a transceiver, and a processor configured to configure at least one node with a list of cell IDs representing cells to be activated or deactivated based on a condition in a network, and transmit, to the at least one node via the transceiver, information including the list of cell IDs” – See [¶0016].
Like Yeh, Wang teaches “the Service Management and Orchestration (SMO) 301 (including non-RT RIC 301a) can perform one or more” management functions – See [¶0134] and Fig. 8, including “Retrieve necessary performance, configuration, and load statistics of the cells, and other data for defining and updating policies to guide the behavior of energy saving” – See [¶0135] and “Support communication of measurement configuration parameters to RAN nodes” – See [¶0138] whereby “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]. Also, like Yeh, Wang teaches “[t]raining of potential Machine Learing, ML, models” here, specifically “for energy optimization” that similarly “autonomously recognize traffic types, predict throughput and energy consumption under a certain traffic pattern” – See [¶0136].
Wang specifically teaches an energy saving rApp in the NRT-RIC (“New enabler within Non-RT RIC for RAN energy saving by semi-dynamically turning cells on/off. This includes a new rApp, namely the energy saving rApp, at Non-RT RIC” – See [¶0122]) sending 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 (“The optimal energy saving configuration parameters can be calculated in the analytics rApp from the non-RT RIC 101, according to analytics of the cell load data through the extended period. The new thresholds parameters can then be configured through the O1 interface to eNB, or through open fronthaul to O-RU. The cells are then activated or deactivated, once the cell load is lower than the specified thresholds. The thresholds can be updated periodically” – See [¶0120] whereby the rApp “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), decides a list of cells to be activated and/or deactivated” – See [¶0130]).
Wang further teaches implement, by the E2 node and the O-RU, the carrier switch off/on within the O-RAN (“Energy Saving RAN function that control Cell Activation and De-Activation at the E2 nodes. The configuration of cell activation and cell deactivation can also be configured at the O-RU” – See [¶0123]). 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 carrier switch off/on and instruct, by the E2 node, the O-RU to execute the carrier switch off/on (“New 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] including “Reporting of cell activation and deactivation status from E2 nodes to Non-RT RIC, through O1 interfaces” – See [¶0126] that inherently requires conversion by the E2 node of the O1 configuration parameters to prepare and execute the carrier switch off/on and instruct, by the E2 node, the O-RU to execute the carrier switch off/on as shown in Fig. 8).
Thus, Yeh and Wang each teaches an rApp or xApp as an inference host in the O-RAN environment (NRT-RIC or RT-RIC and SMO framework) for a trained AI/ML model, trained using measurement data collected from the wireless network nodes per cell id to predict traffic patterns in view of RAN resources utilization optimization actions from the rApp or xApp to the E2node and the O-RU using the O1 interface of the SMO and the Open FH M-Plane between the O-RU and the E2 node/O-DU. A person of ordinary skill in the art before the effective filing date of the claimed invention would have understood that the new rApp for energy saving by switching on/off cells/carriers when certain conditions are predicted to occur, as taught in Wang, could have been combined with the O-RAN environment and procedures taught in Yeh because both use similarly trained AI/ML models using the same measurements data collected from the O-RUs and these models are hosted in RAN-optimization related r/xApps that trigger actions at O-RU level in an E2 node through the same type of O-RAN standardized interfaces and procedures.
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 NRT-RIC based rApp to switch on/off one or more carriers/cells for O-RAN energy savings, as taught in Wang, while not switching off all cells/carriers available to a UE, as taught in O-RAN references cited by Yeh to still provide the QoS to the UE, as taught in Yeh.
Therefore, Amended Claim 1 is obvious over Yeh in view of Wang.
Regarding Claim 2, dependent from Amended Claim 1, Yeh further teaches the system as claimed in claim 1, wherein 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 (“the non-RT RIC 2112 provides a query-able catalog for an ML designer/developer to publish/install trained ML models (e.g., executable software components)” and “may provide discovery mechanism if a particular ML model can be executed in a target ML inference host (MF), and what number and type of ML models can be executed in the MF” – See [¶0297], therefore an rApp in the NRT-RIC may select a suitable ML model);
send, by the rApp, an initiation request for re-training the AI/ML model to the NRT-RIC framework (“[i]n a multi-access network, the number UEs 101 with active transmission(s) and/or the number of traffic flows for different QoS requirements can vary over time . . . the neural network will have to be retrained with complete different size” – See [¶0047] and, because the rApp receives real-time measurements of the traffic flows, as explained in Regarding Amended Claim 1 supra, e.g., “[a]fter performing the traffic steering/splitting strategy recommended by the agent 140 [i.e., the rApp], new observation can be collected from the environment l00x and a reward r can be calculated according to an engineered reward function” for reinforced learning (RL) – See [¶0095]);
re-train the AI/ML model by the NRT-RIC framework (whereby “[i]n O-RAN framework implementations . . . [m]odel training is located at non-RT RIC for off-line RL” – See [¶0102], i.e., the rApp requests re-training the AI/ML model to 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 (“an early warning mechanism (e.g., EW 507) is implemented together with online RL in order to detect whether the model generated by RL is drifting towards sub-optimal solutions” wherein, in “addition to traditional AI/ML model monitoring metrics,” the rApp may monitor the performance of the re-trained AI/ML model through techniques disclosed in Regarding Amended Claim 1 supra, “using performance measurements reflecting wireless network conditions can provide more insightful indication for model effectiveness” whereby “metrics can be used to monitor the performance of the AI/ML model generated by RL to trigger early warning” – See [¶0116] and Fig. 5, or using Guided Exploration – See [¶¶0103-6] and Enforce Safety Action Space – See [¶¶0109-13]);
request, by the rApp, the re-trained AI/ML model from the NRT-RIC framework; and sending, by the NRT-RIC framework, the re-trained AI/ML model to the rApp (“The RL training agent 501 keeps at least one copy of at least one previously trained AI/ML model that provided reasonably good performance as back-up (e.g., back-up models 511 in model store 510)” or “can keep the last K versions of one or more AI/ML models created during online training. Once the metrics for performance monitoring violates (or exceeds) a corresponding threshold, the RL training agent 501 can replace current model 503 with one of the past trained (back-up) AI/ML models 511 providing satisfactory performance guarantee and restart online RL from that model 511” – See [¶0117] and Fig. 5 showing the library of AI/ML models and the re-training environment, and Fig. 6 showing the re-trained model deployment environment).
Therefore, Claim 2 is obvious over Yeh in view of Wang.
Regarding Claim 3, dependent from Amended Claim 1, Yeh further teaches the system as claimed in claim 1, wherein while re-training of at least one AI/ML model the at least one processor is further configured to: re-train, by the rApp, an AI/ML model from the plurality of AI/ML models – See, e.g., Fig. 5, wherein the Agent 501 is the rApp and “[t]he RL training agent 501 keeps at least one copy of at least one previously trained AI/ML model that provided reasonably good performance as back-up (e.g., back-up models 511 in model store 510)” – See [¶0117].
Therefore, Claim 3 is obvious over Yeh in view of Wang.
Regarding Amended Claim 4, dependent from Amended Claim 1, Yeh further teaches the system as claimed in claim 1, wherein the O1-related data providing O1 configurations required to perform the carrier switch off/on comprise at least one of configurations and performance indicators (“The O1 interface is an interface between orchestration & management entities (Orchestration/NMS) and O-RAN managed elements, for operation and management, by which FCAPS management . . . and other similar functions shall be achieved (see e.g., O-RAN Alliance Working Group (WG) 1, "O-RAN Architecture Description" v04.00 (March 2021) ("[O-RAN.WG 1.O-RAN-Architecture-Description-v04.00]"),”– See [¶0278] i.e., Performance Management and Configuration Management data is available at the O1 interface, and for “SMO 2002 (see e.g., O-RAN Alliance WG1, "O-RAN Operations and Maintenance Interface Specification" v04.00 (November 2020) ("[O-RAN.WG1.01-Interface.0-v04.00]")” – See [¶0279]; see also O-RAN.WG1.O-RAN-Architecture-Description describing the rApps at page 9 as “functionality within the Non-RT RIC enables non-real-time control and optimization of RAN elements and resources and policy-based guidance,” e.g., “recommending values and actions that may be subsequently applied over the O1/O2 interface” referencing [21] O-RAN.WG2.Non-RT-RIC-ARCH-TS specifying, at page 16 that “O1-related services produced by the SMO/Non-RT RIC framework enable rApps” to “obtain performance information related to the network,” “obtain the current configuration of the network” or “provision changes of the configuration of the network” such as carrier switch on/off)
wherein the measurement reports further comprise at least one of a cell load related information and traffic information (“performance measurements reflecting wireless network conditions can provide more insightful indication for model effectiveness,” e.g., traffic information such as “average value of one way or e2e delay for one or more data flow(s); delay variation trends; buffer (e.g., queue 410) accumulation; CQI variation trends; MCS distribution trends; and/or the like” – See [¶0116]).
To be sure Wang also teaches “[t]he rApp 803 uses cell statistics collected from E2 Node(s) 306, such as load statistics” – See [¶0130].
Therefore, Amended Claim 4 is obvious over Yeh in view of Wang.
Regarding Amended Claim 5, dependent from Amended Claim 1, Yeh further teaches the system as claimed in claim 1, wherein while collecting the O1-related data providing O1 configurations required to perform the carrier switch off/on, the at least one processor is configured to:
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 (O-RAN.WG1.O-RAN-Architecture-Description discussing the O1 interface at [¶0278] references O-RAN.WG2.Non-RT-RIC-ARCH-TS specifying in § 6.2, at page 18, “R1 service management and exposure functions” including “data management and exposure functions are logical functions that produce the data registration, data discovery, data subscription, data request, data delivery and optional data processing services specified in Clause 5.4” whereby “the data management and exposure functions identify a valid Data Producer, which can be . . . Data Producers in the Non-RT RIC framework /SMO (e.g., O1-related functions),” such as E2 node data related to SMO’s FCAPS functions, as explained in Regarding Amended Claim 1 supra, whereby the “data management and exposure functions optionally provide data processing functionality on collected data (e.g., quantization, normalization, correlation, labelling, etc.)” and, as stated in § 5.4, at page 14, “Data Consumers (e.g., rApps) communicate information about the data types that they want to discover. Data Consumers subscribe/request data from the SMO/Non-RT RIC framework for consumption with specific data type, periodicity, and delivery (or reporting) method, scope, etc.”);
receive, by the E2 node, the O1-related data collection request from the SMO function (“the O-RU 2116 terminates the OF M-Plane interface . . . towards the SMO 2102 as specified in [ORAN-WG4.MP.0-v02.00.00]” – See [¶0287] whereby ORAN.WG4.MP supra, specifies, in § 10, at page 81, Performance Management that “consists of 2 functions. One is for the measurement activation and the other is the collection of measurement results” whereby “performance measurement is defined as o-ran-performance-management YANG module” and, “only one NETCONF client shall activate/deactivate the measurements in the O-RU,” whereby an SMO through the Performance Management function of the O1 interface as defined in Yeh:[¶0278] supra is a NETCONF client) and
collect, by the E2 node, the O1-related data providing O1 configurations required to perform 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 (ORAN.WG4.MP supra, specifies, in § 10.3, at page 82-87, there “scenarios used to collect measurement results” including one for “those O-RUs that support the optional NON-PERSISTENT-MPLANE feature” using “configured subscription from O-RU as Event-Producer to Event-Collector,” whereby “the O-RU shall report the same notification-based measurement results to all subscribed NETCONF clients/Event-Collectors” and the event-collector may be an entity different from the NETCONF client, e.g., a O-DU acting as a O-RU Controller, “as described in clause 18,” e.g., in Figure 18.3-1 at page 173, using HTTP/ger RPC specific to the M-Plane subscriptions – See, e.g., id., at page 20, Figure 5.2-1: M-plane protocol stack); and
send, by the E2 node, the collected O1-related data providing O1 configurations required to perform the 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 (“The non-RT RIC 2112 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations” whereby “operating statistics it produces can also be sent to the non-RT RIC 2112 over O1” – See [¶0298]; see also Figure 3.4-1: R1 interface as a collection of services between the Non-RT RIC Framework and rApps, O-RAN.WG2.Non-RT-RIC-ARCH-TR, at page 27, reproduced hereinafter).
PNG
media_image4.png
571
941
media_image4.png
Greyscale
Wang also teaches send, by the E2 node, the collected O1-related data providing O1 configurations required to perform the carrier switch off/on (“The E2 node(s) report/transmit relevant network parameters, such as updates of the cell loads, to the non-RT RIC” – See [¶0116] and “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]).
Therefore, Amended Claim 5 is obvious over Yeh in view of Wang.
Regarding Amended Claim 6, dependent from Amended Claim 1, although Yeh teaches notifications by the O-RU towards the E2 node via the FH M-Plane interface between the E2 node and the O-RU (“FIGS. 20 and 21 also show that the O-RU 2116 terminates the OF M-Plane interface towards the O-DU 2115 and optionally towards the SMO 2102 as specified in [ORAN-WG4.MP.0-v02.00.00]” whereby the O-DU is part of the E2 node as shown in Figure 21 – See [¶0287] and O-RAN.WG4.MP further specifies, in § 5.2, at page 19 that “The M-Plane interface is defined between the O-RU Controller and the O-RU” whereby “O-RU controllers include, an O-DU, a classical NMS, an O-RAN Service Management and Orchestration function,” and “the O-RU may support the capability to support asynchronous notifications to be sent using HTTPS . . . when the O-RU Controller corresponds to the SMO which is operating with a non-persistent NETCONF session to the O-RU,” and at page 79, and “an optional O-RU capability which allows O-RU Controllers to configure the O-RU to provide notifications of modifications to its YANG datastore,” i.e., their configuration datastore, including carrier switch on/off state, e.g., as specified in § 15.3.2, at page 125 and Figure 15.3.2-1 regarding carrier configuration, activation, deactivation and sleep), Yeh does not teach the system as claimed in claim 1 instructing the O-RU to execute the carrier switch off/on via the open FH M-Plane.
However, Yeh in view of Wang teaches instructing the O-RU to execute the carrier switch off/on via the open FH M-Plane as explained in Regarding Amended Claim 1 supra, and that the at least one processor, is further configured to:
notify, by the O-RU, the completion of the implementation of the carrier switch off/on towards the E2 node via the FH M-Plane interface between the E2 node and the O-RU, as explained in Yeh supra; and
notify, by the E2 node, the completion of the implementation of the 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 (“Reporting of cell activation and deactivation status from E2 nodes to Non-RT RIC, through O1 interfaces” – See Wang:[¶0126]).
Therefore, Amended Claim 6 is obvious over Yeh in view of Wang.
Regarding Claim 7, dependent from Amended Claim 1, Yeh further teaches the system as claimed in claim 1, wherein the at least one processor is further configured to:
monitor, by the NRT-RIC, the performance of the re-trained AI/ML model (“an early warning mechanism (e.g., EW 507) is implemented together with online RL in order to detect whether the model generated by RL is drifting towards sub-optimal solutions. In addition to traditional AI/ML model monitoring metrics, performance measurements reflecting wireless network conditions can provide more insightful indication for model effectiveness” – See [¶0116], e.g., “The non-RT RIC 2112 is be able to access feedback data (e.g., FM and PM statistics) over the O1 interface on ML model performance and perform necessary evaluations” – See [¶0298]);
determine that a predetermined performance objective is not achieved based on the collected O1-related data (“If the ML model fails during runtime, an alarm can be generated as feedback to the non-RT RIC 2112. How well the ML model is performing in terms of prediction accuracy or other operating statistics it produces can also be sent to the non-RT RIC 2112 over O1” – See id.); and
initiate a fallback mechanism and/or initiating an AI/ML model update or retraining (“The RL training agent 501 keeps at least one copy of at least one previously trained AI/ML model that provided reasonably good performance as back-up (e.g., back-up models 511 in model store 510)” – See [¶0117] and Fig. 5).
Therefore, Claim 7 is obvious over Yeh in view of Wang.
Regarding Claims 8-14, as amended, they merely recite the steps executed by the O-RAN system in Claims 1-7, respectively, as amended, with no other limitations. Because Claims 1-7, as amended, are obvious over Yeh in view of Wang, Claims 8-14, as amended, are obvious over Yeh in view of Wang.
Regarding Amended Claim 15, Yeh further teaches in Figure 27 (“computing node 2750 for implementing the techniques (e.g., operations, processes, methods, and methodologies) described” – See [¶0419]), a non-transitory computer-readable recording medium having recorded thereon instructions executable by at least one processor (“storage 2758 may include instructions 2782 in the form of software, firmware, or hardware commands to implement the techniques described” – See [¶0444] whereby “the instructions 2782 provided via the memory 2754, the storage 2758, or the processor 2752 may be embodied as a non-transitory, machine-readable medium 2760 including code to direct the processor 2752 to perform electronic operations in the edge computing node” – See [¶0445]) 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, i.e., the system of Amended Claim 1;
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, i.e., the method of Amended Claim 8.
Because Amended Claims 1 and 8 are obvious over Yeh in view of Wang, Amended Claim 15 is obvious over Yeh in view of Wang.
Regarding Claims 16-20, as amended, dependent from Amended Claim 15, they merely recite the steps in Claims 2-6, respectively, as amended, with no other limitations. Because Amended Claim 15 and Claims 2-6, as amended, are obvious over Yeh in view of Wang, Claims 16-20, as amended, are obvious over Yeh in view of Wang.
In sum, Claims 1-20, as amended, are rejected under 35 U.S.C. §103 as obvious over Yeh in view of Wang.
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. 2022/0407664 as applied in previous Office actions;
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;
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;
Ying et al., U.S. Patent Application Publication No. 20240214272discloses O-RAN environment wherein modify one or more A1 policies associated with an A1 interface connecting a non-real-time (non-RT) RAN intelligence controller (RIC) and a near-real-time (near-RT) RIC to resolve the conflict and notify the two or more rApps of the modification of the one or more A1 policies;
Tsai et al., U.S. Patent Application Publication No. 2022/0150723 discloses a resource management method, a resource management system, and a workload scheduling apparatus for network slicing implemented in O-RAN non-RT RIC;
Khan, U.S. Patent Application Publication No. 2023/0062393 discloses a machine learning or artificial intelligence model or process (ML/AI), that can be updatable, and can be used to predicting congestion;
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.);
O-RAN WG 1, O-RAN.WG1.O-RAN-Architecture-Description-v06.00, “O-RAN Architecture Description 6.0,” July 2022 (available for download at https://specifications.o-ran.org/specifications);
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);
O-RAN.WG3.E2SM-RC-v01.02, “O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller E2 Service Model (E2SM), RAN Control,” July 2022 (available for download at https://specifications.o-ran.org/specifications);
O-RAN.WG2. Non-RT-RIC-TS-v02.00, O-RAN Working Group 2, “Non-RT RIC Architecture,” July 2022 (available for download at https://specifications.o-ran.org/specifications);
O-RAN.WG2.Non-RT-RIC-ARCH-TR-v01.01, O-RAN Working Group 2, “Non-RT RIC: Functional Architecture,” July 2022 (available for download at https://specifications.o-ran.org/specifications);
O-RAN.WG10.OAM-Architecture-v07.00, O-RAN Operations and Maintenance Architecture, July 2022 (available for download at https://specifications.o-ran.org/specifications);
O-RAN.WG2.R1GAP-v02.00, “O-RAN Working Group 2; R1 interface: General Aspects and Principles,” July 2022 (available for download at https://specifications.o-ran.org/specifications);
3GPP TS 28.622 V18.0.0 (2022-09) “Technical Specification Group Services and System Aspects; Telecommunication management; Generic Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS) (Release 18)”;
3GPP TS 38.211 V17.3.0 (2022-09), “Technical Specification Group Radio Access Network; NR; Physical channels and modulation (Release 17)”;
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;
Polese et al., “Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges”; arXiv: 2202.01032v2; 1 August 2022;
Lin et al., “Embracing AI in 5G-Advanced Towards 6G: A Joint 3GPP and O-RAN Perspective,” 12 September, 2022, arXiv:2209.04987 (available online at https://arxiv.org/pdf/2209.04987);
Wannstrom, “Carrier Aggregation explained,” June 2013 (available online at https://www.3gpp.org/technologies/101-carrier-aggregation-explained)
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 See, e.g., Polese et al., “Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges”; arXiv: 2202.01032v2; 1 August 2022 (hereinafter Polese), describing, in §IV(A) the non-RT RIC, stating, at page 6, col.1: “It is worth mentioning that although rApps can support the same control functionalities provided by xApps (e.g., traffic steering, scheduling control, handover management) at larges timescales, they have been standardized to derive control policies that operate at a higher level and affect a larger number of users and network nodes.”
2 Fault, Configuration, Accounting, Performance, Security (FCAPS). Throughout the Office Action it would be understood that O1-related data is FCAPS related data because the Specification defines “the O1-related data providing O1 configurations required to perform the cell and/or carrier switch off/on may be input data, for example, measurement data, used in the AI/ML model training and inference” – See [¶0118] (emphasis added); here, there are two distinctions to be made: (1) measurement data, related to Performance Management, is distinguishable from configurations, related to Provisioning and Configuration Management, although both types may be obtained through the FCAPS functions of the SMO; and (2) the rApp may obtain such data over the R1 interface to the NRT-RIC and the NRT-RIC may obtain the data from the SMO but could also obtain some data through the interface with the RT-RIC which in turn obtains it from the E2 nodes through the E2 interface. The Specification only refers to “the O1-related data . . . collected via an open front haul management plane (FH M-Plane) interface between the E2 node and an open radio unit (O-RU)” – See [¶0113].
3 Although configurations are different from measurements, as explained supra, the O1 interface may also configure Managed Elements such as O-RUs specifically for carrier switch on/off – See , e.g., ORAN.WG4.MP infra specifying in § 16, at page 140-144, management of RUs working in Licensed-assisted access (LAA) that “leverages the carrier-aggregation (CA) functionality” wherein, as described at page 144, “the NETCONF client configures the O-RU with the new channel(s), if needed,” whereby the NETCONF Client may be the SMO performing Configuration Management “[t]o start radio transmission and reception with a new centre frequency, for every component carrier (CC) that needs to be re-configured . . . deactivate the TX carrier, delete it, then create a new TX carrier (using the new centre carrier frequency as well as any other new configurations), and then activate the TX carrier again to start OTA operation. The procedure for deactivating/deleting/creating/activating the carrier is explained in clause 15.3: Carrier Configuration,” specifying carrier Carrier creation, activation and deactivation, whereby such reconfiguration may be triggered by the AI/ML model inference in the rApp, based on the measurements data collected.
4 Annex A, O-RAN.WG2.Non-RT-RIC-ARCH-TR, describes in detail, starting at page 32, an example similar to the MEC environment in Figures 18-19 of Yeh, specifying the interaction between 3 predicting rApps based on monitoring RF signal, cell utilization and QoE, including how data is produced and consumed by the rApps at the R1 interface and the O1 interface of the SMO.
5 See, e.g., ORAN.WG3.E2SM-RC-v01.02, “O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller E2 Service Model (E2SM), RAN Control,” July 2022, specifying RAN CONTROL service at the E2 node, including CONTROL Service Style 6: Carrier Aggregation Control, described in § 7.6.7, at page 43, whereby only a secondary cell/carrier can be changed/activated/deactivated through the control command.
Prosecution Insights