DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 03/08/2024, 10/03/2024 and 06/12/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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 are objected to under 37 CFR 1.83(a) because they fail to clearly show the details of figures 16 and 24 as described in the specification. Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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, 14-16 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 buffer spaces to radio link control (RLC) queues in the DU.
Johansson teaches buffer spaces to 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]).
Please not that while Gupta does not explicitly say increasing the buffer size. 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 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.
Reason for allowing claims 4 and 5 is as follows:
Kazmi further teaches additional UEs becoming active during the time window of W number of TTIs ([0060]-“Based on this example, an optimized legacy scheduler may schedule UE-1 during a first slot. Before a second slot UE-3 may move to beam-1. Then the optimized legacy scheduler may schedule UE-2 in the second slot.”).
However, neither Kazmi nor any other of the references cited teach in the case more UEs become active and W is less than a specified minimum threshold, computing scheduling metrics of the additional UEs in the subsequent time window.
Additionally, none of the references cited teach in the case more UEs become active and the number of additional UEs is less than a specified threshold, computing scheduling metrics of the additional UEs in remaining TTIs within the time window.
In other words, none of the reference teach that in the event more UEs become active in a TTI and another criteria pertinent to either a threshold time value or a threshold number of additional users, calculating the scheduling metric for the new UEs either in the subsequent time window or the current time window, respectively.
Reason for allowing claims 16 is as follows:
The claim recites i) in the case the 5G DU is overloaded, the CU-UP implements the overload control action by increasing the data transmission rate over the 4G leg in comparison to the data transmission rate over the 5G leg; and ii) in the case the 4G DU is overloaded, the CU-UP implements the overload control action by increasing the data transmission rate over the 5G leg in comparison to the data transmission rate over the 4G leg.
The closest prior art, Dhanapal, teaches switching between from 4G to 5G RAT based on a perceived congestion level of the RAT at the UE exceeding a pre-defined threshold level ([0068]- “While communicating with the network, UE 110 may monitor a level of congestion in the network and determine whether the level of congestion exceeds a pre-defined threshold for congestion. At some point, application circuitry 402 may determine that a level of network congestion (e.g., a bottleneck) exceeds the pre-designated or pre-defined threshold for a level of acceptable congestion for 4G (or LTE) communication with the network (at 720)”; Fig. 7). However, Dhanapal does not explicitly teach that a CU-UP adjusts the data transmission for either the 4G path or the 5G path, as required by the claim.
Conclusion
The following references were cited but not relief upon:
US 2016/0105834 A1, US 20140098778 A1, and US 20180368109 A1
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDUL AZIZ SANTARISI whose telephone number is (703)756-4586. The examiner can normally be reached Monday - Friday 8 AM - 5:00 PM ET. 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, Ayman Abaza can be reached on (571)270-0422. 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.
/ABDUL AZIZ SANTARISI/Examiner, Art Unit 2465
/John Pezzlo/
Primary Examiner, AU 2465B
11 March 2026