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 .
Claim Objections
Claim 1 objected to because of the following informalities: Claim 1 line 2 reads determine, based on the other independent claims and the complete disclosure, it appears as if this should read determiner. Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 35-54 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Charipadi (US 20200389806 A1) hereafter Charipadi.
Regarding Claim 35:
Charipadi discloses:
A method of determining packet loss in a fronthaul link between a baseband node and a radio node of a radio access network, the method being performed in a packet loss determine, ([¶0013] the present systems and methods may implement a variety of metrics called fronthaul operational measurements (OMs), updated at least every measurement interval, in a distributed RAN in order to monitor the fronthaul network. ) the method comprising: detecting at least one empty input data slot of a plurality of input data slots of a communication chain operation in a first time period, wherein the communication chain operation is one in a sequence of communication chain operations in a device on a receiving end of the fronthaul link;([¶0003] The baseband controller is also configured to determine, for each of the plurality of RPs, a number of packet losses (reflecting dropped and/or delayed packets), for the wireless channel and during the measurement interval, based on the number of successfully received packets.) determining that data was intended to be provided to the at least one empty input data slot; and determining that a packet loss has occurred in the fronthaul link, based on the detecting the at least one empty input data slot and the determining that data was intended to be provided. ([¶0095] For example, the baseband controller 104 may send a command scheduling the RP 106 to send PUSCH data in a certain TTI. But if that command doesn't go through, the RP 106 won't send any data. However, if a fronthaul OM 118 is implemented for the command itself, the RP 106 would inform baseband controller 104 that it hasn't received any commands. The baseband controller 104 could also determine that it didn't send any commands in the first place so there wasn't any packet loss. In contrast, if the baseband controller 104 sends such a scheduling command and the command is dropped or delayed and not processed, this could indicate some problem in the baseband-controller-to-RP path that needs to be addressed. A separate fronthaul OM 118 may be implemented for scheduling commands from the baseband controller 104 to the RP 106 relating to each uplink channel for which an auditable record is desired.)
Regarding Claim 36:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
further comprising determining an aggregate metric of fronthaul loss, based on at least one occurrence of the determining that a packet loss has occurred. ([¶0043] The baseband controller 104 may also determine a cumulative OM 120 indicating the number of packets lost or delayed (for a particular downlink channel during a measurement interval) by summing the packet loss RP-specific OMs 122 for a measurement interval (each indicating the number of packet losses for a particular RP 106 and channel) across multiple RPs 106. The baseband controller 104 may also determine a cumulative OM 120 indicating the number of successfully received (and processed) packets by summing the successfully-received-and-processed RP-specific OMs 122 for a measurement interval (each indicating the number of successfully received and processed packets for a particular RP 106 and channel) across multiple RPs 106.)
Regarding Claim 37:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
further comprising providing a metric signal, based on the aggregate metric, to a link adaptation module. ([¶0044] Similarly, for each uplink channel for which fronthaul OMs 118 are maintained, each RP 106 will peg (maintain) a counter indicating the number of packets transmitted from the RP 106 (during a measurement interval) to the baseband controller 104. Each RP 106 may transmit its respective counter(s) to the baseband controller 104 periodically, e.g., every aggregation interval in a heartbeat message.)
Regarding Claim 38:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
wherein the metric signal is used by the link adaptation module to determine when to disregard user equipment (UE) feedback in a subsequent link adaptation. ([¶0049] The fronthaul OMs 118 may be used to identify and/or correct performance problems in the C-RAN 100. In some configurations, the operator can first determine whether cumulative OMs 120 stored at the baseband controller 104 (and indicating packet loss and successfully received packets across all RPs 106 for a particular channel and measurement interval) are showing a value in an unexpected range, e.g., high total packet loss and/or low successfully received packets. If so, the operator may examine the RP-specific OMs 122 (indicating packet loss or successfully received packets for individual RPs 106) for a particular channel and measurement interval. Using the cumulative OMs 120 and/or the RP-specific OMs 122, the operator may determine if KPI degradations (e.g., throughput degradation, high BLER, connection drop rates, etc.) are caused by (or exacerbated by) issues in the fronthaul network 116, e.g., switch configurations, link bandwidth limitations, etc.)
Regarding Claim 39:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
further comprising: comparing the aggregate metric against a threshold; and providing a fronthaul loss signal to a link adaptation module when the aggregate metric indicates a fronthaul loss that is greater than the threshold. ([¶0049] The fronthaul OMs 118 may be used to identify and/or correct performance problems in the C-RAN 100. In some configurations, the operator can first determine whether cumulative OMs 120 stored at the baseband controller 104 (and indicating packet loss and successfully received packets across all RPs 106 for a particular channel and measurement interval) are showing a value in an unexpected range, e.g., high total packet loss and/or low successfully received packets. If so, the operator may examine the RP-specific OMs 122 (indicating packet loss or successfully received packets for individual RPs 106) for a particular channel and measurement interval. Using the cumulative OMs 120 and/or the RP-specific OMs 122, the operator may determine if KPI degradations (e.g., throughput degradation, high BLER, connection drop rates, etc.) are caused by (or exacerbated by) issues in the fronthaul network 116, e.g., switch configurations, link bandwidth limitations, etc.)
Regarding Claim 40:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
further comprising determining, in the baseband node, the threshold based on a code rate of a data set encompassing data of the plurality of input data slots in the first time period. ([¶0012] Service providers have obligations to provide a certain level of wireless service to its customers. These obligations may be described in service level agreements (SLAs), which impose requirements on the wireless service in terms of key performance indicators (KPIs), e.g., throughput, block error rate (BLER), connection drop rates, etc. [¶0013] As described below, the present systems and methods may implement a variety of metrics called fronthaul operational measurements (OMs), updated at least every measurement interval, in a distributed RAN in order to monitor the fronthaul network. This ability to monitor the operation of the fronthaul network enables service providers the ability to meet their obligations outlined in service level agreements (SLAs).[¶0014] As described herein, an aggregation interval may be a unit of time (e.g., 100 radio frames of 10 msec each=1 second) during which downlink packets received by an RP, as well as the uplink packets transmitted by the RP, are accumulated at the RP and transmitted to the baseband controller as a set of counters, one for each wireless channel for which fronthaul OMs are maintained (e.g., PRACH, PUCCH, PUSCH, SRS, PDCCH, and PDSCH), in a heartbeat message in the subsequent aggregation interval. This process continues every aggregation interval. When the baseband controller receives the heartbeat message during aggregation interval N+1, it will add the counts (relating to aggregation interval N) for each channel and each RP to the running counts maintained for each channel and each RP during the present measurement interval. At the boundary of the measurement interval (e.g., 15 minutes) the loss count and success count for each channel and each RP is determined and recorded as a loss RP-specific OM and a success RP-specific OM for the just-completed measurement interval, which can be stored and/or displayed to a user. This process is repeated in the baseband controller every measurement interval for multiple (e.g., all) RPs and for one or more wireless channels. The length of the measurement interval may be configurable, e.g., by a user of the baseband controller. Cumulative OMs may be determined for each channel and each measurement interval, by summing the corresponding RP-specific OMs across all RPs during the measurement interval.)
Regarding Claim 41:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
wherein: the method is applied for downlink communication; the communication chain operation is orthogonal frequency domain multiplexing (OFDM); and each one of the plurality of input data slots is configured to contain at least one modulated symbol. ([¶0026] In some configurations, a baseband signal can be pre-processed at a source RP 106 and converted to frequency domain signals (after removing guard-band/cyclic-prefix data, etc.) in order to effectively manage the fronthaul rates, before being sent to the baseband controller 104. The RP 106 can further reduce the data rates by quantizing such frequency domain signals and reducing the number of bits used to carry such signals and sending the data. In a further simplification, certain symbol data/channel data may be fully processed in the source RP 106 itself and only the resultant information is passed to the baseband controller 104.)
Regarding Claim 42:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
wherein: the method is applied for downlink communication; the communication chain operation is precoding; and each one of the plurality of input data slots is configured to contain at least one modulated symbol. ([¶0026] In some configurations, a baseband signal can be pre-processed at a source RP 106 and converted to frequency domain signals (after removing guard-band/cyclic-prefix data, etc.) in order to effectively manage the fronthaul rates, before being sent to the baseband controller 104. The RP 106 can further reduce the data rates by quantizing such frequency domain signals and reducing the number of bits used to carry such signals and sending the data. In a further simplification, certain symbol data/channel data may be fully processed in the source RP 106 itself and only the resultant information is passed to the baseband controller 104.)
Regarding Claim 43:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
wherein: the method is applied for downlink communication; the communication chain operation is modulation; and each one of the plurality of input data slots is configured to contain at least one binary word. ([¶0026] In some configurations, a baseband signal can be pre-processed at a source RP 106 and converted to frequency domain signals (after removing guard-band/cyclic-prefix data, etc.) in order to effectively manage the fronthaul rates, before being sent to the baseband controller 104. The RP 106 can further reduce the data rates by quantizing such frequency domain signals and reducing the number of bits used to carry such signals and sending the data. In a further simplification, certain symbol data/channel data may be fully processed in the source RP 106 itself and only the resultant information is passed to the baseband controller 104.)
Regarding Claim 44:
Charipadi discloses the limitations of parent claims.
Charipadi discloses:
wherein: the method is applied for uplink communication; the communication chain operation is equalization; and each one of the plurality of input data slots is configured to contain at least one complex value. ([¶0051] As described above, an RP-specific OM 122 may track the number of packets successfully received (e.g., in the expected SFN and SF) or lost for a particular uplink or downlink channel during a measurement interval, which may span multiple aggregation intervals, e.g., 15 minutes. RP-specific OMs 122 indicate counts for a specific RP 106 across a measurement interval. Cumulative OMs 120 indicate counts across multiple (e.g., all) connected RPs 106 across a measurement interval. The following are examples of fronthaul OMs 118 that may be maintained for a C-RAN 100. However, it is understood, that different derived fronthaul OMs could alternatively or additionally be maintained for a C-RAN 100, e.g., for derived uplink and/or downlink channels. Additionally, the RP-specific OMs 122 may be implemented using any suitable data structure (e.g., 64-bit datatype) in order to prevent unintended rollover from happening within a single measurement interval. The various fronthaul OMs 118 may be stored in performance logs for the baseband controller 104 and/or the RPs 106.)
Regarding Claim 45:
Charipadi discloses:
A packet loss determiner for determining packet loss in a fronthaul link between a baseband node and a radio node of a radio access network, the packet loss determiner comprising: a processor;([¶0123] The methods and techniques described here may be implemented in digital electronic circuitry, or with a programmable processor) and a memory storing instructions that, when executed by the processor,([¶0123] Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory.) cause the packet loss determiner to: detect at least one empty input data slot of a plurality of input data slots of a communication chain operation in a first time period, wherein the communication chain operation is one in a sequence of communication chain operations in a device on a receiving end of the fronthaul link;([¶0003] The baseband controller is also configured to determine, for each of the plurality of RPs, a number of packet losses (reflecting dropped and/or delayed packets), for the wireless channel and during the measurement interval, based on the number of successfully received packets.) determine that data was intended to be provided to the at least one empty input data slot; and determine that a packet loss has occurred in the fronthaul link, based on the detecting the at least one empty input data slot and the determining that data was intended to be provided. ([¶0095] For example, the baseband controller 104 may send a command scheduling the RP 106 to send PUSCH data in a certain TTI. But if that command doesn't go through, the RP 106 won't send any data. However, if a fronthaul OM 118 is implemented for the command itself, the RP 106 would inform baseband controller 104 that it hasn't received any commands. The baseband controller 104 could also determine that it didn't send any commands in the first place so there wasn't any packet loss. In contrast, if the baseband controller 104 sends such a scheduling command and the command is dropped or delayed and not processed, this could indicate some problem in the baseband-controller-to-RP path that needs to be addressed. A separate fronthaul OM 118 may be implemented for scheduling commands from the baseband controller 104 to the RP 106 relating to each uplink channel for which an auditable record is desired.)
Regarding Claim 54:
Charipadi discloses:
A non-transitory computer-readable medium storing a computer program product for controlling a packet loss determiner, the computer program product comprising software instructions that, when run on the packet loss determiner, cause the packet loss determiner ([¶0123] The techniques may advantageously be implemented in one or more programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and DVD disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed application-specific integrated circuits (ASICs).) to: detect at least one empty input data slot of a plurality of input data slots of a communication chain operation in a first time period, wherein the communication chain operation is one in a sequence of communication chain operations in a device on a receiving end of the fronthaul link;([¶0003] The baseband controller is also configured to determine, for each of the plurality of RPs, a number of packet losses (reflecting dropped and/or delayed packets), for the wireless channel and during the measurement interval, based on the number of successfully received packets.) determine that data was intended to be provided to the at least one empty input data slot; and determine that a packet loss has occurred in the fronthaul link, based on the detecting the at least one empty input data slot and the determining that data was intended to be provided. ([¶0095] For example, the baseband controller 104 may send a command scheduling the RP 106 to send PUSCH data in a certain TTI. But if that command doesn't go through, the RP 106 won't send any data. However, if a fronthaul OM 118 is implemented for the command itself, the RP 106 would inform baseband controller 104 that it hasn't received any commands. The baseband controller 104 could also determine that it didn't send any commands in the first place so there wasn't any packet loss. In contrast, if the baseband controller 104 sends such a scheduling command and the command is dropped or delayed and not processed, this could indicate some problem in the baseband-controller-to-RP path that needs to be addressed. A separate fronthaul OM 118 may be implemented for scheduling commands from the baseband controller 104 to the RP 106 relating to each uplink channel for which an auditable record is desired.)
Dependent claims 46-54 are functionally equivalent to dependent claims 36-44 and are hereby rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUGH MARK ASHLEY whose telephone number is (571)272-0199. The examiner can normally be reached M-F 8-430.
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, Asad Nawaz can be reached at (571) 272-3988. 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.
/HUGH MARK ASHLEY/Examiner, Art Unit 2463
/ASAD M NAWAZ/Supervisory Patent Examiner, Art Unit 2463
Prosecution Insights