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 .
Response to Amendment
Acknowledgement is made of amendment filed on 06/15/2026. The amendments of Applicant are entered and have been considered by Examiner. Claims 1-20 were previously pending. Claims 21 and 22 have been added. Claims 1-22 are currently pending.
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in India on 03/15/2023. It is noted, however, that applicant has not filed a certified copy of the IN 202321017243 application as required by 37 CFR 1.55.
Drawings
The drawings were received on 06/15/2026. These drawings are acceptable.
Response to Arguments
Applicant's arguments filed 06/15/2026 have been fully considered but they are not persuasive.
Applicant argues on Page 11 of applicants remarks:
The Office relies on Gupta for the general idea of implementing overload control using an E2 node including a DU and/or CU-UP, and relies on Johansson for the alleged teaching of buffer spaces to radio link control (RLC) queues in the DU. The Office then concludes that it would have been obvious to combine Johansson with Gupta because doing so "would enhance packet management" (Office Action § 6, claim 1 analysis). Applicant respectfully submits that reasoning does not support the combination advanced in the rejection.
Claim 1 is not directed merely to generic congestion control or generic packet management. Rather, claim 1 is directed to detecting an overload condition at the E2 node and performing an overload-control action utilizing the E2 node, including, as relevant here, dynamically allocating increased buffer spaces to corresponding RLC queues in the DU. The Office Action itself acknowledges that Gupta "does not explicitly teach buffer spaces to radio link control (RLC) queues in the DU" (Office Action § 6, claim 1 analysis). Thus, the rejection depends on Johansson to supply that feature.
However, Johansson's cited disclosure does not support the Examiner's proposed modification. As quoted in the Office Action, Johansson states that "[t]o keep queues low at the DUs 30, 40, L4S marking may be implemented in the DUs 30, 40 e.g. to prevent queue build-up on the RLC layer" (Johansson [0098], as quoted in the Office Action § 6). The surrounding Johansson passages cited by the Office, namely [0096]-[0098], are consistently directed to keeping queues low and preventing queue build-up in the DU. In other words, Johansson's design objective is to avoid queue growth in the DU RLC layer through marking and control mechanisms, not to respond to overload by dynamically increasing DURLC queue space.
That teaching is directly contrary to the modification required by the rejection. The Office relies on Johansson to support a claim feature requiring dynamically allocating increased buffer space to RLC queues in the DU, but Johansson affirmatively teaches preventing queue build-up and keeping DU queues low. A person of ordinary skill in the art would understand Johansson as discouraging the use of larger DU RLC queues as the remedy as suggested by the Office. Thus, Johansson does not merely fail to disclose the claimed modification; Johansson teaches directly away from it.
This teach-away is significant because it undermines the stated rationale to combine. The Office's rationale that the combination would "enhance packet management" is too general and conclusory to bridge the absolute contradiction between Gupta and Johansson. Under MPEP § 2141 and KSR, there must be articulated reasoning with rational underpinning for combining the references in the manner claimed. Here, the rejection does not explain why a person of ordinary skill would have modified Gupta's system to dynamically allocate increased DU RLC queue space using a reference that expressly teaches the desirability of keeping those DU queues low and preventing RLC queue build-up.
Gupta does not cure the deficiency in Johansson. As cited in the Office Action, Gupta discusses a "buffer control algorithm" and states that congestion control decisions may be based on "packet drop rates, RTT (round trip time), or a congestion marker" and that queueing and scheduling policy may be adjusted, for example by "changing buffer size, pro-actively dropping packets, or changing ECN marking threshold" (Gupta [0030], [0052]-[0053], [0062], [0065], as cited in the Office Action § 6). But Gupta's teachings are directed generally to congestion-control optimization and application performance. Gupta does not teach the particular DU-side RLC queue buffering feature the Office imports from Johansson. Nor does Gupta provide any reason to adopt Johansson's low-queue, anti- build-up philosophy and at the same time modify the combined system to use increased RLC queue space in the DU.
Accordingly, it is respectfully submitted that the proposed Gupta-Johansson combination is internally inconsistent. Johansson's own teachings would have led a skilled artisan away from the specific modification required to meet claim 1. Because claims 2 and 9 depend from the same deficient base combination, the rejection of claims 2 and 9 should also be withdrawn.
Examiner respectfully disagrees. As indicated in the previous office action, the examiner had indicated that Gupta teaches dynamically adjusting queuing and scheduling policy at the enB (e.g., changing buffers size), but does not explicitly teach “dynamically allocating increased buffer spaces”. However, Gupta is directed to flexible buffer management that optimize congestion control. Examiner argues that flexible buffer management that includes changing the buffer size includes both the ability to increase buffer sizes and decrease buffer sizes in order to optimize congestion control. As known in the art, congestion is a state in which the network has a load that exceeds its capacity. Changing buffer size in order to alleviate congestion is not performed by decreasing the buffer size, but rather increasing the buffer size, such that by increasing the buffer capacity, the eNB is capable of handling the load. Furthermore, Gupta further describes in [0030], the RIC monitoring any bursts in traffic and ensure low latency. As known in the art, a burst is a sudden and temporary increase in traffic. Performing buffer management by changing the buffer size would require increasing the buffer size in order to handle bursty traffic. As such, Gupta teaches increasing buffer spaces.
As summarized above, Gupta teaches “dynamically allocating increased buffer spaces to queues in the DU”, but does not teach RLC queues in the DU. Johansson is introduced to teach the deficiency of RLC queues in the DU. The concept of L4S marking for preventing queue buildup in the RLC layer is not relied on nor required for teaching the concept of a DU having RLC queues. In other words, a DU can have RLC queues without performing L4S marking. As such, by using only the concept of a DU having RLC queues to modify the teachings of Gupta, the combination of Gupta in view of Johansson teaches on the claim element “dynamically allocating increased buffer spaces to RLC queues in the DU”.
Applicants arguments in pages 12-17 for dependent claims under independent claim 1 all recite the same arguments as presented for claim 1. Examiner refers applicant to the response to arguments above.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148
USPQ 459 (1966), that are applied 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 non-obviousness.
Claims 1, 2, 9 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20210029580) hereinafter Gupta in view of Johansson (US 20230344772 A1) hereinafter Johansson.
Regarding claim 1,
Gupta teaches a method of implementing at least one of downlink (DL) and uplink (UL) data traffic overload control ([0052]-“buffer control algorithm 400 that can facilitate optimizing congestion control”; also refer to [0052]-[0053] and [0065]; Figs. 4 and 6) utilizing an E2 node comprising at least one of a distributed unit (DU) and a centralized unit (CU) ([0050]-“ In some embodiments, a distributed unit (DU) 314 and a central unit user plane (CU-UP) 318 has been specified by 3GPP. The DU 314 is communicatively connected to CU-UP) 318 via an application data link 316. The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size)….”; also refer to [0049]-[0051]; Fig. 3) for at least one of 1) a stand-alone (SA) 4G architecture or a SA 5G architecture wireless network ([0043]- “In various embodiments, system 100 can be configured to provide and employ 5G wireless networking features and functionalities….”; [0043]; Fig. 1), and 2) a non-stand-alone (NSA) architecture wireless network serving user equipments (UEs), comprising: detecting, by utilizing at least the E2 node, an overload condition at the E2 node ([0030]-“An eNB/gNB buffer management xApp running on the RIC will monitor the RAN and the flow performance and dynamically tune the available policies through the E2 interface”; also refer to [0030] and [0062]); and performing an overload control action utilizing at least the E2 node ([0062]-“…In some embodiments, the eNB/gNB buffer management xApp running on the RIC will monitor the RAN and the flow performance and dynamically tune the available policies through the E2 interface. In some embodiments, the flow performance can be measured by packet drop rates, RTT (round trip time), or a congestion marker to make control decisions….”; also refer to [0030] and [0062]), wherein the overload control action comprises at least one of: i) reducing a number of UEs for which corresponding scheduling metric is computed in each transmission time interval (TTI); ii) reducing a number of UEs for which UL grant is given; iii) reducing a size of UL grant given to each UE; (iv) reducing the amount of radio resource the E2 node provides to each cell of the wireless network; (v) dynamically allocating buffer spaces ([0030]-“ …Dynamically adjusting the queueing and scheduling policy at the eNB (e.g., changing buffer size, pro-actively dropping packets, or changing ECN marking threshold) can have a big impact on application performance….”; also refer to [0030] and [0032]);
(vi) reducing an activity factor for selected data radio bearers (DRBs); (vii) changing scheduling metrics for delay-sensitive applications; and (viii) in the case of the NSA architecture wireless network, adjusting relative data transmission rates between a 4G leg of data transmission and a 5G leg of data transmission to a served UE.
Gupta does not explicitly teach increased buffer spaces.
However Gupta is directed to flexible buffer management that optimize congestion control (see [0030]). Flexible buffer management that includes changing the buffer size includes both the ability to increase buffer sizes and decrease buffer sizes in order to optimize congestion control. As known in the art, congestion is a state in which the network has a load that exceeds its capacity. Changing buffer size in order to alleviate congestion is not performed by decreasing the buffer size, but rather increasing the buffer size, such that by increasing the buffer capacity, the eNB is capable of handling the load. Furthermore, Gupta further describes the RIC monitoring any bursts in traffic and ensure low latency (see [0030]). As known in the art, a burst is a sudden and temporary increase in traffic. Performing buffer management by changing the buffer size would require increasing the buffer size in order to handle bursty traffic.
It would have been obvious to one having ordinary skill in the art before the effective filing date to modify the teachings of Gupta to include “increased buffer spaces”. One would have been motivated to do so, in order to optimize congestion control as indicated in [0030] of Gupta.
Gupta does not explicitly teach radio link control (RLC) queues in the DU.
Johansson teaches b radio link control (RLC) queues in the DU ([0098]-“To keep queues low at the DUs 30, 40, L4S marking may be implemented in the DUs 30, 40 e.g. to prevent queue build-up on the RLC layer similar to action 703 above”; also refer to [0096]-[0098]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Johansson to the teachings of Gupta. One would have been motivated to do so, with a reasonable expectation of success, because it would enhance packet management (Johansson [0001]).
Regarding claim 2,
Gupta and Johansson teach all the features of claim 1, as outlined above.
Gupta further teaches the overload control utilizes at least the DU ([0050]-“…The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312….” ; [0050]; Fig. 3).
Regarding claim 9,
Gupta and Johansson teach all the features of claim 1, as outlined above.
Gupta further teaches wherein the overload control utilizes at least a centralized unit user plane (CU-UP) ([0050]-“…The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312….” ; [0050]; Fig. 3).
Claims 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Johansson in further view of Dhanapal et al. (US 20230076738 A1) hereinafter Dhanpal in further view of in further view of Itaba (US 20210377779 A1) hereinafter Itaba.
Regarding claim 14,
Gupta and Johansson teach all the features of claim 2, as outlined above, where Gupta teaches a distributed DU and CU-UP architecture ([0050]-“ In some embodiments, a distributed unit (DU) 314 and a central unit user plane (CU-UP) 318 has been specified by 3GPP. The DU 314 is communicatively connected to CU-UP) 318 via an application data link 316. The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size). Each individual functional entities DU and CU-UP may be placed at different physical locations according to operator requirements.”)
Gupta and Johansson do not explicitly teach the overload control is performed in the non-stand-alone (NSA) architecture wireless network; an overload condition is detected by one of a 4G node or a 5G node of the NSA architecture wireless network based on utilization of central processing unit (CPU) of the one the 4G node or the 5G node exceeding a specified threshold.
Dhanpal teaches the overload control is performed in the non-stand-alone (NSA) architecture wireless network ([0023]-“Techniques, described herein, may enable a UE to select optimal RATs and radio resources (e.g., BWPs) when communicating with the network. As described below, this may be based on factors, such as whether the UE is currently using 4G RAT or 5G RAT, a BWP being used by the UE, whether an application or network service being used by the UE requires a certain throughput, a level of congestion in a 4G RAN or 5G RAN, a mode of operation of the UE (e.g., idle or active), and so on.”; also refer to [0022]-[0026]); an overload condition is detected by one of a 4G node or a 5G node of the NSA architecture wireless network based on utilization exceeding a specified threshold ([0056]-“…Later, UE 110 may reprioritize 5G SA connections, relative to 4G connections and switch to a 5G connection if/when UE 110 determines that a level of congestion for the 4G connection has exceeded a pre-determine congestion threshold for 4G connections (at 330)….”; also refer to [0068]; Figs. 3 and 7).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Dhanpal to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would allow optimal selection based on congestion (Dhanpal [0023]).
Gupta and Johansson and Dhanpal do not explicitly teach utilization of central processing unit (CPU) of the one the 4G node or the 5G node exceeding a specified threshold.
Itaba teaches utilization of central processing unit (CPU) of the one the 4G node or the 5G node ([0170]-“… As the state of the DU 72, the DU 72 may monitor, for example, the processing load on the DU 72…”; [0170]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Itaba to the teachings of Gupta and Johansson and Dhanpal. One would have been motivated to do so, with a reasonable expectation of success, because it would enable flow control in dual connectivity (Itaba [0008]-[0009]).
Regarding claim 15,
Gupta and Johansson and Dhanpal and Itaba teach all the features of claim 14, as outlined above, where Gupta teaches a distributed DU and CU-UP architecture ([0050]-“ In some embodiments, a distributed unit (DU) 314 and a central unit user plane (CU-UP) 318 has been specified by 3GPP. The DU 314 is communicatively connected to CU-UP) 318 via an application data link 316. The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size). Each individual functional entities DU and CU-UP may be placed at different physical locations according to operator requirements.”) and Dhanpal teaches a split 4G and 5G NSA architecture ([0023]-“Techniques, described herein, may enable a UE to select optimal RATs and radio resources (e.g., BWPs) when communicating with the network. As described below, this may be based on factors, such as whether the UE is currently using 4G RAT or 5G RAT, a BWP being used by the UE, whether an application or network service being used by the UE requires a certain throughput, a level of congestion in a 4G RAN or 5G RAN, a mode of operation of the UE (e.g., idle or active), and so on.”; also refer to [0022]-[0026]).
Gupta and Johansson and Dhanpal do not explicitly teach the DU indicates the overload condition to a CU-UP in the wireless network by sending an enhanced DL Data Delivery Status (DDDS) message including a DU overload extension field, Itaba discloses ([0167]-“…Further, the CU 71 receives a DDDS message, which is a message notifying about a DL data communication status, from each of the MeNB 40 and the DU 72.…”; refer also to [0167]-[0170] ; Fig. 4) for a DRB ([0167]-“… Each of the MeNB 40 and the DU 72 may transmit the DDDS message per user (per DRB) or per group…”).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Itaba to the teachings of Gupta and Johansson and Dhanpal. One would have been motivated to do so, with a reasonable expectation of success, because it would enable flow control in dual connectivity (Itaba [0008]-[0009]).
Claims 3 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta in view of Johansson in further view of Kazmi (US 20230422232 A1) hereinafter hereinafter Kazmi in further view of Annamalai et al. (US 20220201699 A1) hereinafter Annamalai.
Regarding claim 3,
Gupta and Johansson teach all the features of claim 2, as outlined above.
Gupta does not explicitly teach the overload control action comprises: computing scheduling metrics for only a subset of UEs among active UEs in each TTI within a time window of W number of TTIs, wherein W > 1, and wherein the scheduling metric for each active UE is computed only once within the time window of W number of TTIs.
Kazmi teaches the overload control action comprises: computing scheduling metrics for only a subset of UEs among active UEs in each TTI within a time window of W number of TTIs ([0055]- “For each user x in a ranked beam Branked(j), the BUB scheduling weight can be calculated (or updated) by P_ADDing the BUB beam weight (Wbub_beam(j)) to user's scheduling Wb(x).“; refer also to [0055]-[0062]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Kazmi to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would enhance resource efficiency (Kazmi [0009]).
Gupta and Johansson and Kazmi do not explicitly teach wherein W > 1, and wherein the scheduling metric for each active UE is computed only once within the time window of W number of TTIs.
Annamalai teaches wherein W > 1, and wherein the scheduling metric for each active UE is computed only once within the time window of W number of TTIs ([0120]-“…base station 102 calculates a new adjacency matrix B in accordance with the aspects discussed above every TTI…”; [0120]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Annamalai to the teachings of Gupta and Johansson and Kazmi. One would have been motivated to do so, with a reasonable expectation of success, because it would reduce computational load at the base station (Annamalai [0120]).
Claims 6 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20210029580) hereinafter Gupta in view of Johansson in further view of Itaba.
Regarding claim 6,
Gupta and Johansson teach all the features of claim 2, as outlined above.
Gupta further teaches the overload control further utilizes a near-real-time radio intelligent controller (near-RT RIC) ([0030]-“According an embodiments, an intelligent buffer management through the RIC is used to influence the behavior of congestion control algorithms….” And [0050]-“…The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size).…”; also refer to [0030] and [0050]); and the RIC utilizes measurement parameters sent by the DU to detect the overload condition ([0050]-“ …The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management…”; [0050]; Fig. 3).
Gupta and Johansson do not explicitly teach DU processing load, the number of active UEs, physical resource block (PRB) utilization, and the number of packets per TTI.
Itaba teaches DU processing load, the number of active UEs, physical resource block (PRB) utilization, and the number of packets per TTI ([0170]-“… As the state of the DU 72, the DU 72 may monitor, for example, the processing load on the DU 72…”; [0170]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Itaba to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would enable flow control in dual connectivity (Itaba [0008]-[0009]).
Regarding claim 17,
Gupta and Johansson teach all the features of claim 2, as outlined above, where Gupta teaches a centralized unit user plane (CU-UP) ([0050]-“ The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP…”; [0050]; Fig. 3).
Gupta further teaches implementing, by the DU, a DL overload control action comprising a change in at least one of a desired buffer size (DBS) ([0050]-“In some embodiments, a distributed unit (DU) 314 and a central unit user plane (CU-UP) 318 has been specified by 3GPP. The DU 314 is communicatively connected to CU-UP) 318 via an application data link 316. The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size). Each individual functional entities DU and CU-UP may be placed at different physical locations according to operator requirements….”; [0050]; Fig. 3), sending to to a centralized unit user plane (CU-UP) (…The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size)….).
Gupta and Johansson do not explicitly teach DL overload condition is detected based on one of processing load or DL packet rate at the DU exceeding a specified threshold ; and implementing, by the DU, a DL overload control action which is sent as part of DL Data Delivery Status (DDDS) message from the DU to a centralized unit user plane (CU-UP) for each selected DRB.
Itaba teaches DL overload condition is detected based on one of processing load ([0170]-“…As the state of the DU 72, the DU 72 may monitor, for example, the processing load on the DU 72 or the remaining amount of a buffer of the DU 72. The DU 72 monitors at least one of the state of the DU 72 and the radio state between the DU 72 and the UE 30, and if the DU 72 determines that it is necessary to perform control because, for example, the processing load is high, the DU 72 determines a group to be controlled and the control content….”; [0170]) or DL packet rate at the DU exceeding a specified threshold ([0170]-“… The DU 72 monitors at least one of the state of the DU 72 and the radio state between the DU 72 and the UE 30, and if the DU 72 determines that it is necessary to perform control because, for example, the processing load is high, the DU 72 determines a group to be controlled and the control content….”; [0170]); and implementing, by the DU, a DL overload control action which is sent as part of DL Data Delivery Status (DDDS) message from the DU to a centralized unit ([0167]-“…Further, the CU 71 receives a DDDS message, which is a message notifying about a DL data communication status, from each of the MeNB 40 and the DU 72.…”; refer also to [0167]-[0170] ; Fig. 4) for each selected DRB ([0167]-“… Each of the MeNB 40 and the DU 72 may transmit the DDDS message per user (per DRB) or per group…”).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Itaba to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would enable flow control in dual connectivity (Itaba [0008]-[0009]).
Please not that while Itaba does not explicitly say the processing load at the DU exceeding a specified threshold. It would have been obvious to one having ordinary level of skill in the art, before the effective filing date, to use the teachings of Itaba to implement a thresholding mechanism for detecting high processing load.
Regarding claim 18,
Gupta and Johansson and Itaba teach all the features of claim 17, as outlined above, where Gupta teaches a centralized unit user plane (CU-UP) ([0050]-“ The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP…”; [0050]; Fig. 3).
Gupta further teaches a reduced DBS ([0050]-“In some embodiments, a distributed unit (DU) 314 and a central unit user plane (CU-UP) 318 has been specified by 3GPP. The DU 314 is communicatively connected to CU-UP) 318 via an application data link 316. The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size). Each individual functional entities DU and CU-UP may be placed at different physical locations according to operator requirements….”; [0050]; Fig. 3), sending to a centralized unit user plane (CU-UP) (…The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size)….).
Gupta and Johansson do not explicitly teach value is sent as part of the DDDS message.
Itaba teaches a value is sent as part of the DDDS message ([0167]-“…Further, the CU 71 receives a DDDS message, which is a message notifying about a DL data communication status, from each of the MeNB 40 and the DU 72.…”; refer also to [0167]-[0170] ; Fig. 4) for each selected DRB from the DU ([0167]-“… Each of the MeNB 40 and the DU 72 may transmit the DDDS message per user (per DRB) or per group…”).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Itaba to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would enable flow control in dual connectivity (Itaba [0008]-[0009]).
Please not that while Gupta does not explicitly say a reduced DBS. It would have been obvious to one having ordinary level of skill in the art, before the effective filing date, to use the teachings of Gupta to dynamically increase or decrease the buffer size.
Claims 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20210029580) hereinafter Gupta in view of Johansson in further view Itaba in further view of Sartori et al. (US 20220217046 A1) hereinafter Sartori.
Regarding claim 7,
Gupta and Johansson and Itaba teach all the features of claim 6, as outlined above.
Gupta and Johansson and Itaba do not explicitly teach requesting, by the near-RT RIC to the DU, to compute scheduling metrics for only a subset of active UEs in every TTI within a transmission window.
Sartori teaches requesting, by the near-RT RIC to the DU, to compute scheduling metrics ([0101]-“…To compute the average throughput, the RIC/CU-CP may request the necessary metrics from, for example, one or more DUs….”; refer also to [0100]-[0103]) for only a subset of active UEs in every TTI within a transmission window ([0068]-“ A criterion may relate to a type of requested information, a level of detail of requested information, a validity of requested information or any other criterion. The at least one criterion may comprise a criterion relating to a time scale of the requested information.”; refer also to [0050]-[0070]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Sartori to the teachings of Gupta and Johansson and Itaba. One would have been motivated to do so, with a reasonable expectation of success, because it would enhance network optimization (Sartori [0009]).
Regarding claim 8,
Gupta and Johansson and Itaba teach all the features of claim 6, as outlined above.
Gupta and Johansson and Itaba do not explicitly teach sending, by the near-RT RIC to the DU, at least one policy to enable the DU to identify a subset of active UEs for which scheduling metrics need to be computed in a given TTI within a transmission window.
Sartori teaches sending, by the near-RT RIC to the DU, at least one policy to enable the DU to identify a subset of active UEs for which scheduling metrics need to be computed in a given TTI within a transmission window ([0068]-“ A criterion may relate to a type of requested information, a level of detail of requested information, a validity of requested information or any other criterion. The at least one criterion may comprise a criterion relating to a time scale of the requested information.”; [0050]-[0070]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Sartori to the teachings of Gupta and Johansson and Itaba. One would have been motivated to do so, with a reasonable expectation of success, because it would enhance network optimization (Sartori [0009]).
Please note that “criterion” in Sartori equates to “policy” as claimed.
Claims 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20210029580) hereinafter Gupta in view of Johansson in further view of Skarve et al. (US 20240007905 A1) hereinafter Skarve.
Regarding claim 10,
Gupta and Johansson teach all the features of claim 9, as outlined above.
Gupta and Johansson do not explicitly teach the CU-UP detects the overload condition based on at least one of the following parameters:
1) the number of data radio bearers (DRBs) for which the CU-UP is carrying traffic;
2) DL and UL processing load at the CU-UP;
3) Packet Data Convergence Protocol (PDCP) service data unit (SDU) or Protocol Data Unit (PDU) drops in PDCP queues at the CU-UP due to non-availability of buffer space in corresponding Radio Link Control (RLC) queues in a DU;
4) identity of DRBs for which PDCP SDUs or PDUs are being dropped at the CU-UP due to non-availability of space in CU-UP queues; and
5) available buffer space in PDCP queues at the CU-UP.
Skarve teaches the CU-UP detects the overload condition based on at least one of the following parameters:
1) the number of data radio bearers (DRBs) for which the CU-UP is carrying traffic;
2) DL and UL processing load at the CU-UP ([0082]-“Load condition—reaching a preconfigured load level for CU-UP processing or F1-U interface…”; [0082]-[0083]);
3) Packet Data Convergence Protocol (PDCP) service data unit (SDU) or Protocol Data Unit (PDU) drops in PDCP queues at the CU-UP due to non-availability of buffer space in corresponding Radio Link Control (RLC) queues in a DU;
4) identity of DRBs for which PDCP SDUs or PDUs are being dropped at the CU-UP due to non-availability of space in CU-UP queues; and
5) available buffer space in PDCP queues at the CU-UP.
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Skarve to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would minimize latency (Skarve [0008]).
Regarding claim 12,
Gupta and Johansson teach all the features of claim 9, as outlined above.
Gupta teaches the overload control further utilizes a near-real-time radio intelligent controller (near-RT RIC) ([0030]-“According an embodiments, an intelligent buffer management through the RIC is used to influence the behavior of congestion control algorithms….” And [0050]-“…The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size).…”; [0030] and [0050]); and the near-RT RIC utilizes measurement parameters sent by the CU-UP to detect the overload condition ([0050]- “In some embodiments, a distributed unit (DU) 314 and a central unit user plane (CU-UP) 318 has been specified by 3GPP. The DU 314 is communicatively connected to CU-UP) 318 via an application data link 316. The buffers for DU and CU-UP can be controlled by the RIC 302 via a E2 interface 312. The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP (e.g., to request adjustments to buffer size). Each individual functional entities DU and CU-UP may be placed at different physical locations according to operator requirements.”; [0050]; Fig. 3)
Gupta and Johansson do not explicitly teach the measurement parameters being at least one of the following:
1) the number of data radio bearers (DRBs) for which the CU-UP is carrying traffic;
2) DL and UL processing load at the CU-UP;
3) Packet Data Convergence Protocol (PDCP) service data unit (SDU) or Protocol Data Unit (PDU) drops in PDCP queues at the CU-UP due to non-availability of buffer space in corresponding Radio Link Control (RLC) queues in a DU;
4) identity of DRBs for which PDCP SDUs or PDUs are being dropped at the CU-UP due to non-availability of space in CU-UP queues; and
5) available buffer space in PDCP queues at the CU-UP.
Skarve teaches the measurement parameters being at least one of the following:
1) the number of data radio bearers (DRBs) for which the CU-UP is carrying traffic;
2) DL and UL processing load at the CU-UP ([0082]-“Load condition—reaching a preconfigured load level for CU-UP processing or F1-U interface…”; [0082]-[0083]);
3) Packet Data Convergence Protocol (PDCP) service data unit (SDU) or Protocol Data Unit (PDU) drops in PDCP queues at the CU-UP due to non-availability of buffer space in corresponding Radio Link Control (RLC) queues in a DU;
4) identity of DRBs for which PDCP SDUs or PDUs are being dropped at the CU-UP due to non-availability of space in CU-UP queues; and
5) available buffer space in PDCP queues at the CU-UP.
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Skarve to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would minimize latency (Skarve [0008]).
Regarding claim 13,
Gupta and Johansson and Skarve teach all the features of claim 12, as outlined above.
Gupta further teaches wherein the overload control action comprises: instructing, by the near-RT RIC to the DU ([0050]-“ The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP”; [0050]; Fig. 3), to one of i) dynamically allocate buffer space to the corresponding RLC queues in the DU ([0030]-“…Dynamically adjusting the queueing and scheduling policy at the eNB (e.g., changing buffer size, pro-actively dropping packets, or changing ECN marking threshold) can have a big impact on application performance….”; [0030] and [0032]), or ii) adjust scheduler weights to give higher preference to the corresponding DRBs.
Please not that while Gupta does not explicitly say dynamically allocating more buffer space. It would have been obvious to one having ordinary level of skill in the art, before the effective filing date, to use the teachings of Gupta for increasing the buffer size.
Regarding claim 11,
Gupta and Johansson and Skarve teach all the features of claim 10, as outlined above.
Gupta teach dynamically allocate buffer space to the corresponding RLC queues in the DU ([0030]-“…Dynamically adjusting the queueing and scheduling policy at the eNB (e.g., changing buffer size, pro-actively dropping packets, or changing ECN marking threshold) can have a big impact on application performance….”; [0030] and [0032]).
Gupta and Johansson do not explicitly teach the overload control action comprises: instructing, by the CU-UP to the DU.
Skarve teaches the overload control action comprises: instructing, by the CU-UP to the DU ([0087]-“ If a decision has been made to switch states, affected node(s) (leg(s)) for the FC configuration change. This configuration is performed by signaling from the triggering node to the other node(s). There is a set of different alternatives available as: [0088] user plane signaling (e.g., step 402-3, 502-2) [0089] from CU-UP to DU” and [0088]-“user plane signaling (e.g., step 402-3, 502-2) [0089] from CU-UP to DU”; [0087]-[0093]).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Skarve to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would enhance buffer management in DU-CU architecture (Skarve [0008]).
Please not that while Gupta does not explicitly say dynamically allocating more buffer space. It would have been obvious to one having ordinary level of skill in the art, before the effective filing date, to use the teachings of Gupta for increasing the buffer size.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20210029580) hereinafter Gupta in view of Johansson in further view of Itaba in further view of Kollar et al. (US 20220311712 A1) hereinafter Kollar.
Regarding claim 19,
Gupta and Johansson and Itaba teach all the features of claim 17, as outlined above, where Gupta teaches a centralized unit user plane (CU-UP) ([0050]-“ The E2 interface 312 feeds data, including various RAN measurements, to the RIC 302 to facilitate radio resource management, it is also the interface through which the RIC near-RT 302 may initiate configuration commands directly to DU and CU-UP…”; [0050]; Fig. 3) and Itaba teaches transmission of the DDDS ([0167]-“…Further, the CU 71 receives a DDDS message, which is a message notifying about a DL data communication status, from each of the MeNB 40 and the DU 72.…”; refer also to [0167]-[0170] ; Fig. 4) including information for each DBR ([0167]-“… Each of the MeNB 40 and the DU 72 may transmit the DDDS message per user (per DRB) or per group…”).
Gupta and Johansson and Itaba do not explicitly teach a reduced DDR is sent as part of the DDDS message.
Kollar teaches a DDR is sent as part of the DDDS message ([0027]-“…and DDR is the latest Desired Data Rate reported within the DL DATA DELIVERY STATUS (DDDS)…).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Kollar to the teachings of Gupta and Johansson and Itaba. One would have been motivated to do so, with a reasonable expectation of success, because it would enhance latency measurement (Kollar [0001]).
Please not that while Kollar does not explicitly say dynamically a reduced DDR, buffer space, it would have been obvious to one having ordinary level of skill in the art, before the effective filing date, to use the teachings of Kollar for indicating a reduced desired data rate.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US 20210029580) hereinafter Gupta in view of Johansson in further of Nasralla (“A Hybrid Downlink Scheduling Approach for Multi-Traffic Classes in LTE Wireless Systems”, IEEE Access, vol. 8, pp. 82173-82168, 2020) hereinafter Nasralla.
Regarding claim 20,
Gupta and Johansson teach all the features of claim 2, as outlined above, where Johansson teaches radio link control (RLC) packets in the DU’s RLC queues ([0098]-“To keep queues low at the DUs 30, 40, L4S marking may be implemented in the DUs 30, 40 e.g. to prevent queue build-up on the RLC layer similar to action 703 above”; also refer to [0096]-[0098]).
Gupta and Johansson do not explicitly teach the overload control action comprises, in a given TTI, changing scheduling metrics for delay-sensitive applications whose queues for longer duration compared to UEs in a subsequent TTI.
Nasralla the overload control action comprises, in a given TTI, changing scheduling metrics for delay-sensitive applications whose queues for longer duration compared to UEs in a subsequent TTI (“The purpose of the EXP/PF scheduler is to exponentially raise the priority of RT flows w.r.t NRT ones when their HoL packet delays are close to the target delay. For RT flows, parameters sensitive to delay and the PF rule are used to formulate the EXP/PF scheduler. This will prioritize the delay parameters over the flow channel conditions, which results in greater support for RT flows. However, the PF rule is used on its own to schedule packets among NRT users. The below equation illustrates the metric employed to represent the EXP/PF scheduler:
PNG
media_image1.png
131
630
media_image1.png
Greyscale
“ ; section III B 1; pages 82177-82178).
It would have been obvious to one having ordinary skill in the art before the effective filing date to add the teachings of Nasralla to the teachings of Gupta and Johansson. One would have been motivated to do so, with a reasonable expectation of success, because it would prioritize delay over channel conditions (Narsalla page 82178).
Allowable subject matter
Claims 4, 5 and 16, are objected to for being dependent on rejected base claims. However, the claims contain allowable subject matter and are patentable if written in independent form.
Claims 21, 22 allowed.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2025/0106922 A1 to Chandrashekar et al., directed to adjusting scheduling grants based on DU buffer status.
US 2024/0276205 A1 to Song et al., directed to a Near-RT RIC receiving overload status information and performing overload reduction.
US 2023/0362658 A1 to Shetty et al., directed to an RIC configured to detect overload of the NSA and SA users.
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 JENKEY VAN whose telephone number is (571)270-7160. The examiner can normally be reached Monday - Friday 9am - 5pm.
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, Chirag Shah can be reached at (571)272-3144. 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.
/JENKEY VAN/Primary Examiner, Art Unit 2477
Prosecution Insights