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 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 26- 56 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Wang et al. (US 12666335 B2).
Regarding claims 29, 38, 42, Wang discloses
A method performed by a user equipment (UE) for handling communication in a wireless communication network, (Column 7, lines 29-42; target network device 130 may fetch the information in the successful handover report via a UE Information Request and Response mechanism.);
the method comprising transmitting a successful handover report (SHR) to a radio network node, wherein the SHR comprises an indicator indicating whether or not the UdE has experienced a listen before talk (LBT) failure and/or a random access problem before successfully accessing a target cell in a handover (HO) procedure; (Column 10, lines 1-10; Column 16, lines 12-51; the set of triggering conditions 125 may include a radio problem towards the source cell being detected prior to handover triggering, a RACH delay during handover procedure being detected, a quality change threshold being reached, an absolute quality threshold for the main measurement moments being reached, the handover being initiated during running of the timer T310/T312 as defined in the related 3GPP specifications, RRCReconfiguration being executed, and so on. In some embodiments, it would be desirable for the set of triggering conditions 125 to be more inclusive and comprehensive, so that the source network device 110 and/or the target network device 130 of the handover can obtain more useful information for improving future handovers. For example, one or more of the set of triggering conditions 125 may be designed in consideration of various new features introduced by Rel-16.
In some embodiments, the first type of information can include an indication of a consistent LBT failure. Therefore, upon receiving the successful handover report provided by the terminal device 120, the source network device 110 can obtain the indication of the consistent LBT failure from the successful handover report. Accordingly, the source network device 110 may optimize a future handover of a terminal device initiated in the cell 115 to avoid a consistent LBT failure related to the terminal device 121; in some embodiments, the first type of information may comprise at least one of the following: an indication of a consistent LBT failure, information on one or more BWPs in which the consistent LBT failure is triggered, BWPs in sequence in which a consistent LBT failure recovery has been performed, a value of a counter for counting the number of LBT failures, and a value of a timer for consistent LBT failure detection.)
Regarding claim 30, 43, Yan discloses
comprising detecting, during the HO procedure from a first radio network node to a second network node, one or more LBT failures and/or a random access problem.
(Column 10, lines 65-67 through Column 10, lines 1-4; the first type of triggering conditions related to the LBT process may be any suitable triggering condition indicating a LBT process that may need to be improved. In some embodiments, the first type of triggering conditions may be related to LBT failure related information. In other words, the LBT failure related information can be considered as a triggering condition for a successful handover report.)
Regarding claims 31, 44, Wang discloses
further comprising, upon successfully completing the handover procedure before a handover related timer expires, storing a first information indicating whether or not the UE has experienced LBT failure and/or a random access problem, wherein the indicator comprised in the transmitted SHR indicates the first information. (Column 17, lines 5-20; Additionally or alternatively, the first type of information can include a value of a timer for consistent LBT failure detection. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can obtain the value of the timer from the successful handover report. Accordingly, the network device 110 can determine the severity of the LBT failures when the handover is performed, for example, how long has it been since the last LBT failure, and thus can evaluate the degree of congestion in the unlicensed bands. On this basis, the network device 110 can optimize the use of the licensed bands, for example, allocating to a terminal device less BWPs in which LBT failures occurred. In some embodiments, the timer may be lbt-FailureDetectionTimer as defined in related 3GPP specifications.)
Regarding claims 32, 33, 39, 45, 46, Wang discloses
one or more uplink LBT failures experienced while the handover related timer was running; consistent uplink (UL) LBT failures detected in one or more UL bandwidth parts (BWP) configured with physical random access channel (PRACH) resources; and a random access problem experienced while the handover related timer was running. (Column 4, lines 34-46; As used herein, an uplink (UL) transmission/reception is a scheme in which data is transmitted from user equipment to a base station. Alternatively, a downlink (DL) transmission/reception is a scheme in which data is transmitted from the base station to the user equipment.;
Column 17 lines 5-35; Additionally or alternatively, the first type of information may include a value of a counter for counting the number of LBT failures. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can determine the value of the counter from the successful handover report. Accordingly, the network device 110 can determine the severity of the LBT failures when the handover is performed, for example, how many times the LBT has failed, and thus can evaluate the degree of congestion in the unlicensed bands. On this basis, the network device 110 can optimize the use of the licensed bands, for example, allocating to a terminal device less BWPs in which LBT failures occurred. In some embodiments, the counter for counting the number of LBT failures may be the LBT_COUNTER as defined in related 3GPP specifications.
Additionally or alternatively, the first type of information can include a value of a timer for consistent LBT failure detection. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can obtain the value of the timer from the successful handover report. Accordingly, the network device 110 can determine the severity of the LBT failures when the handover is performed, for example, how long has it been since the last LBT failure, and thus can evaluate the degree of congestion in the unlicensed bands. On this basis, the network device 110 can optimize the use of the licensed bands, for example, allocating to a terminal device less BWPs in which LBT failures occurred. In some embodiments, the timer may be lbt-FailureDetectionTimer as defined in related 3GPP specifications.)
Regarding claims 34, 47, Wang discloses
wherein the indicator is only included in the SHR when the UE has experienced a number of uplink (UL) LBT failures greater than a certain threshold, in one or more UL bandwidth parts (BWP) where physical random access channel (PRACH) resources are configured.
(Column 11, lines 57-67 through Column 12, lines 1-3; As another example, a triggering condition of the first type may be that a LBT counter for counting the number of LBT failures in the LBT process is greater than a predetermined threshold. The number of LBT failures higher than the predetermined threshold can imply that there is one or more LBT failures occur in the LBT process performed by the terminal device 120 before or during the handover, and thus the handover process is suboptimal and can be improved by optimizing the handover related parameters. Therefore, through such a triggering condition regarding the LBT counter, the terminal device 120 can be triggered to collect the information related to the handover and report the collected information to the source network device 110 via the target network device 120 or another serving network device of the terminal device 120. In this way, the source network device 110 can optimize a future handover procedure based on the successful handover report triggered by the triggering condition regarding the LBT counter, and thereby avoiding one or more of LBT failures related to a terminal device in the cell 115 before the future handover..)
Regarding claims 35, 36, 48, 49, Wang discloses
the indicator indicates a number of times the UE has received the LBT failure while trying to perform a random access procedure.
(Column 11, lines 57-67 through Column 12, lines 1-3; As another example, a triggering condition of the first type may be that a LBT counter for counting the number of LBT failures in the LBT process is greater than a predetermined threshold. The number of LBT failures higher than the predetermined threshold can imply that there is one or more LBT failures occur in the LBT process performed by the terminal device 120 before or during the handover, and thus the handover process is suboptimal and can be improved by optimizing the handover related parameters. Therefore, through such a triggering condition regarding the LBT counter, the terminal device 120 can be triggered to collect the information related to the handover and report the collected information to the source network device 110 via the target network device 120 or another serving network device of the terminal device 120. In this way, the source network device 110 can optimize a future handover procedure based on the successful handover report triggered by the triggering condition regarding the LBT counter, and thereby avoiding one or more of LBT failures related to a terminal device in the cell 115 before the future handover.)
Regarding claims 37, 50, Wang discloses
the SHR further comprises a duration indication indicating a duration for which the UE experienced LBT issues while performing the handover procedure.
(Column 17, lines 65-67 through Column 18, lines 1-9; In some embodiments, the second type of information can include the duration since an MCG RLF is detected until the handover is completed, namely, the time elapsed since the MCG connection failure until the handover succeeded, which may represent the interruption time of the on-going service of MCG. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can obtain the duration from the successful handover report. Accordingly, the network device 110 may analyze the performance of the fast MCG recovery through handover and determine if any optimization on the fast MCG recovery is needed.)
Regarding claims 40, 41, Wang discloses
performing radio optimization taking the indicator in the SHR into account.
(Column 16, lines 62-67 through Column 17, lines 1-4; Additionally or alternatively, the first type of information can include BWPs in sequence in which a consistent LBT failure recovery has been performed. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can determine the ordered BWPs related to the consistent LBT failure recovery from the successful handover report. Accordingly, the network device 110 may optimize a future handover of a terminal device initiated in the cell 115 to avoid a consistent LBT failure in these BWPs.)
Regarding claim 51, Wang discloses
a radio network node for handling communication in a wireless communication network, wherein the radio network node comprises: processing circuitry configured to receive a successful handover report (SHR) from a UE, wherein the SHR comprises an indicator indicating whether or not the UE has experienced a listen before talk (LBT) failure and/or a random access problem before successfully accessing a target cell in a handover procedure.
(Column 4, lines 5-23; … the circuitry may be a combination of analog and/or digital hardware circuits with software/firmware. As a further example, the circuitry may be any portions of hardware processors with software including digital signal processor(s), software, and memory (memories) that work together to cause an apparatus, such as a terminal device or a network device, to perform various functions…;
Column 15, lines 63 through Column 16, lines 1-42; In general, the successful handover report generated by the terminal device 120 can include any information that can be helpful for the source network device 110 or the target network device 130 to improve the performance of future handovers. For example, the information collected (240) by the terminal device 120 and to be contained in the successful handover report may include RLM related information, BFD related information, and handover related information, or the like. In some embodiments, it would be desirable for the content of the successful handover report to be more inclusive and comprehensive. Therefore, after receiving the informative successful handover report, the source network device 110 or the target network device 130 can obtain more useful information related to various aspects of the handover, so as to improve the performance of the future handovers more effectively and efficiently.
As an example, for the purpose of generating the successful handover report, the terminal device 120 can collect a first type of information related to a LBT process performed by the terminal device 120. In general, the first type of information may be any suitable information of the LBT process that can reflect problems in the LBT process. For example, LBT failure related information can be stored by the terminal device 120 as the content of the successful handover report and reported to the source network device 110. In this way, after receiving the successful handover report including the information related to the LBT process performed by the terminal device 120 before the handover, the source network device 110 can improve a future LBT process performed by a terminal device related to a handover initiated in the cell 115 by optimizing the configurations of the handover.)
Regarding claim 52, Wang discloses
the indicator indicates at least one of the following: one or more LBT failures while a handover related timer is running; consistent uplink (UL) LBT failures in one or more UL bandwidth parts (BWP) where physical random access channel (PRACH) resources are configured; and a random access problem in a medium access control (MAC) layer while a handover related timer is running.
(Column 16, lines 53-67; Column 17, lines 1-4; Additionally or alternatively, the first type of information may include information on one or more bandwidth parts (BWP) in which the consistent LBT failure is triggered. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can obtain the BWP information related to the consistent LBT failure from the successful handover report. Accordingly, the network device 110 may optimize a future handover of a terminal device initiated in the cell 115 to avoid a consistent LBT failure in these BWPs.
Additionally or alternatively, the first type of information can include BWPs in sequence in which a consistent LBT failure recovery has been performed. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can determine the ordered BWPs related to the consistent LBT failure recovery from the successful handover report. Accordingly, the network device 110 may optimize a future handover of a terminal device initiated in the cell 115 to avoid a consistent LBT failure in these BWPs.)
Regarding claim 53, Wang discloses
the processing circuitry is further configured to perform radio optimization taking the indicator in the SHR into account.
( (Column 16, lines 53-67; Column 17, lines 1-4; Additionally or alternatively, the first type of information can include BWPs in sequence in which a consistent LBT failure recovery has been performed. Therefore, upon receiving the successful handover report provided by the terminal device 120, the network device 110 can determine the ordered BWPs related to the consistent LBT failure recovery from the successful handover report. Accordingly, the network device 110 may optimize a future handover of a terminal device initiated in the cell 115 to avoid a consistent LBT failure in these BWPs.)
Regarding claims 54, 55, 56, Wang discloses
the processing circuitry is further configured to provide information to another radio network node for performing radio optimization based on the indicator,
(Column 7, lines 29-42; In some embodiments, the terminal device 120 can generate a successful handover report if the handover from the source cell 115 to the target cell 135 is successful. The availability of the successful handover report may be indicated by a message (for example, a Handover Complete message, such as RRCReconfigurationComplete) transmitted from the terminal device 120 to the target network device 130 over radio resource control (RRC) layer. The target network device 130 may fetch the information in the successful handover report via a UE Information Request and Response mechanism. In addition, the target network device 130 may then forward the successful handover report to the source network device 110 to indicate failures experienced during a successful handover event.)
Response to Arguments
Applicant’s arguments with respect to claim(s) 26-54 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Krishnan (US 12160764 B2), discloses methods, systems, devices, and apparatuses with techniques, which leverage minimization of drive testing (MDT) procedures to improve MBS-based communications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVETTA W GOINS whose telephone number is (571)272-2957. The examiner can normally be reached Monday thru Friday; 7:30 AM to 5:30 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
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.
/DAVETTA W GOINS/Supervisory Patent Examiner, Art Unit 2689
Prosecution Insights