DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
2. Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy INDIA 202141028920 has been filed on 06/28/2021. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55. Examiner notes that the certified copy is in English.
Claim Objections
3. Claims 52, 58-59 and 65 are objected to because of the following informalities:
Claim 52 “a timing-advance command used to effect the switch” should read “a timing-advance command used to affect the switch”.
Claim 58 “the condition of claim 50 is met” should read “the condition of claim 57 is met”
Claim 65 “the condition of claim 50 is met” should read “the condition of claim 64 is met”
Claims 59 and 65 have the same informalities as claim 52, therefore the same objections are applied.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
4. Claims 48-53, 55-60 and 62-66 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 48, 55 and 62:
The applicant claimed “PUCCH transmission is in PUCCH Format 1 and the indication is carried as uplink control information (UCI) bits protected by a cyclic redundancy check (CRC)”. However, the applicant gives no support in the specification regarding the relationship of PUCCH Format 1, UCI and CRC ([0039] the UE may transmit an implicit or explicit indication, to a source cell, e.g., via a MAC control element (CE) or physical (PHY) channel (e.g., PUCCH), that there is no more pending UL MAC and RLC (re)-transmissions to the source cell after the UL switch to the target cell during an ongoing DAPS handover).
Regarding claims 49, 56 and 63:
The applicant claimed “wherein the PDCP SN consists of eighteen bits with modulo-2^18 numbering… computed modulo-2^18”. However, the applicant gives no support in the specification regarding the relationship of PDCP SN consists of 18 bits with modulo-2^18 ([0040] the UE can transmit, to the target cell, information related to the last UL packet successfully transmitted to the source cell. In some embodiments, such information can include an identifier (e.g., an RLC or PDCP sequence number) of the next UL packet that is to be forwarded to a UPF and/or serving gateway).
Regarding claims 50, 57 and 64:
The applicant claimed “verifying that (i) all hybrid automatic repeat request (HARQ) processes toward the source network node are idle and (ii) both MAC and RLC UL buffers toward the source network node are empty”. However, the applicant gives no support in the specification regarding the relationship of HARQ processes and MAC and RLC UL buffers are empty ([0097] in the case there are no pending MAC and RLC (re-)transmissions to the source cell upon, or shortly after, the UL switch. Another benefit of some embodiments is that the source link can be kept by the target cell for a longer time for improved reliability without delaying the transmission of the buffered UL packets to the serving gateway and/or UPF).
Regarding claims 51, 58 and 65:
The applicant claimed “suppresses the PUCCH indication upon expiry of timer T, and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired”. However, the applicant gives no support in the specification regarding the relationship of suppressing and transmitting the PUCCH indication being dependent on the status of expiration of Timer T ([0056] The timer T may be started by the UE when the UL switch to the target cell occurs. The timer T may be stopped if the MAC and RLC (re)-transmissions to the source cell are completed. According to some embodiments, the indication may be sent by the UE to the source cell or target cell. The timer T may expire if the MAC and RLC (re)-transmissions to the source cell are not completed. According to certain embodiments, the indication may not be sent by the UE to the source cell or the target cell).
Regarding claims 52, 59 and 65:
The applicant claimed “the RAR includes an uplink grant and a timing-advance command used to effect the switch”. However, the applicant gives no support in the specification regarding the RAR includes an uplink grant and timing advance command ([0032] When the UE completes the random access successfully to the target cell (e.g., receives a RACH response (RAR) in the case of contention free random access (CFRA), or physical downlink control channel (PDCCH) addressed to a cell radio network temporary identifier (C-RNTI) in case of contention based random access (CBRA)), the UE may switch the uplink (UL) user plane transmission from the source cell to the target cell).
Regarding claims 53, 60 and 66:
The applicant claimed “encodes a one-bit no- pending-retransmissions flag and an eighteen-bit PDCP SN for a total UCI payload of nineteen bits, mapped to a single-slot PUCCH transmission of one symbol duration without repetition”. However, the applicant gives no support in the specification regarding the 18 PDCP SN being encoded with an additional bit for a total of 19 bits mapped to the PUCCH transmission without repetition ([0048] In some cases, the UE may not have any pending (re)-transmissions, and the source node may send the SN status transfer UL as shown at 126 of FIG. 1a).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
5. Claims 47-66 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 47:
Claim 47 recites “after receiving the indication, transmitting, to the source network node via a PUCCH, an indication comprising” is indefinite because it is unclear whether “the indication” is referring to “transmitting, to a source network node via a Physical Uplink Control Channel (PUCCH), an indication comprising” in claim 47 or “receiving, from the source network node, an indication to enable uplink interruption reduction during the handover” in claim 47. For the purpose of examination, “the indication” will be interpreted as ““receiving, from the source network node, an indication to enable uplink interruption reduction during the handover”” in claim 47.
Claim 47 recites “wherein the indication is transmitted only for periodic” is indefinite because it is unclear whether “the indication” is referring to “transmitting, to a source network node via a Physical Uplink Control Channel (PUCCH), an indication comprising” in claim 47 or “after receiving the indication, transmitting, to the source network node via a PUCCH, an indication comprising” in claim 47. For the purpose of examination, “the indication” will be interpreted as “transmitting, to a source network node via a Physical Uplink Control Channel (PUCCH), an indication comprising” in claim 47.
Claims 54 and 61 have similar indefiniteness to claim 47, therefore the examiner applied the same interpretation.
Claims 48, 49, 51, 53, 55, 56, 58, 60, 62, 63, 65 and 66 have similar indefiniteness to claim 47. For the purpose of examination, “the indication” will be interpreted as “transmitting, to a source network node via a Physical Uplink Control Channel (PUCCH), an indication comprising” respectively to their independent claim.
Claim Rejections - 35 USC § 103
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 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
6. Claims 47, 54 and 61 are rejected under 35 U.S.C. 103 as being unpatentable over Wallentin et al. (US-20220361060-A1, hereinafter WALLENTIN) in view of KIM et al. (US-20210136829-A1, hereinafter, KIM) and in view of Conceicao et. al. (US-20240381222-A1, hereinafter, CONCEICAO) and in view of SHAH et. al. (US-20230413340-A1, hereinafter SHAH).
Regarding claim 47, WALLENTIN discloses:
A user equipment (UE) operating in Fifth Generation (5G) New Radio (NR) and participating in a Dual Active Protocol Stack (DAPS) handover (Abstract - the disclosure concerns a method performed by a User Equipment for handling Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) when performing a Dual Active Protocol Stack (DAPS) handover of at least one radio bearer from a source access node to a target access node in a wireless communications network; [0009] To support fast mobility between NR and LTE and avoid change of core network, LTE eNBs can also be connected to the 5G-CN via NG-U/NG-C and support the Xn interface… it should be noted that most of the solutions/features described for LTE and NR in this document also apply to LTE connected to 5GC), the UE comprising:
at least one processor (Fig. 14b – processor 146); and
at least one memory (Fig. 14b – memory 147) including computer-executable instructions (Fig. 14b – computer program 148) that, when executed by the processor, cause the UE to perform the following operations ([0269] In some embodiments, a respective computer program 148, 158 comprises instructions, which when executed by the at least one processor 146, 156, cause the at least one processor 146, 156 of the respective the target access node 112 and UE 120 to perform the actions above):
transmitting, to a source network node (Fig. 4 – Source eNB), an indication (Fig. 4 – Step 401; [0014] An RRC_CONNECTED UE in E-UTRAN or NG-RAN can be configured by the network to perform measurements of serving and neighbor cells and based on the measurement reports sent by the UE, the network may decide to perform a handover of the UE to a neighbor cell) comprising
(i) a Packet Data Convergence Protocol (PDCP) sequence number (SN) of a next uplink packet to be forwarded (Fig. 4 – Step 408; [0045] To avoid packet duplication, the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell) and
(ii) a statement (Fig. 4 – step 408) that there are no pending uplink (UL) Medium Access Control (MAC) and Radio Link Control (RLC) retransmissions to the source network node ([0046] in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell; (PDCP packets travels down the protocol stack, e.g., PDCP, RLC, MAC, etc. in order to be transmitted – see Fig. 5));
Receiving (Fig. 5 – Step 405), from the source network node prior to transmitting the indication that there are no pending transmissions (Fig. 4 – step 408), an enumerated Radio Resource Control (RRC) information element (Fig. 5 – Step 405; RRC Conn reconfig) set to true that enables uplink interruption reduction ([0038] To address the shortcomings of Rel-14 MBB and achieve ˜0 ms interruption time an enhanced version of Make-Before-Break (eMBB) is being discussed for Rel-16 for both LTE and NR. In this enhanced version, it is assumed that the UE is capable of simultaneously transmitting and receiving from the source and target cell. In practice, this may require that the UE is equipped with dual Tx/Rx chains) during the DAPS handover ([0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, (Step 405 RRC Conn reconfig indicates to enable eMBB in the handover command) the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption);
receiving, from the source network node (Fig. 4 – Step 405), an indication to enable uplink interruption reduction during the handover ([0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption);
after receiving the indication, transmitting, to the source network node, an indication ([0215] In some other alternative embodiments, in Action 1206, when the radio connection with the source access node 111 is released implicitly by the UE 120 or the release is triggered by an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111) comprising
(i) a statement that there are no pending UL MAC and RLC retransmissions to the source network node ([0215] the source access node 111 is released implicitly by the UE 120 or the release is triggered by an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111, the PDCP Status Report is sent together with the first transmitted UL data packet to the target access node 112; [0024] The source access node receives an indication from the gateway that indicates the last packet sent to the source access node, a so called “end marker” packet) and
(ii) a PDCP sequence number (SN) of a next UL packet to be forwarded ([0024] the source access node also forwards this indication to the target access node so that the target access node knows when it can start transmission of packets received from the gateway; [0045] the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN… the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell), wherein the transmitting is performed:
after an UL user-plane switch to the target network node that occurs ([0043] Once the connection setup with the target access node is successful, i.e. after sending the Handover Complete message in step 408, the UE maintains two data links, one to the source access node and one to the target access node. After step 408, the UE transmits the UL user plane data on the target access node similar to the regular HO procedure using the target access node security keys and compression context; [0046] The release of the source cell in step 413 can e.g. be triggered by an explicit message from the target access node (not shown in the figure) or by some other event such as the expiry of a release timer) upon receipt of a Random Access procedure (Fig. 4 – Step 407; [0047] the UE has performed random access in the target cell);
after transmission of a RRC reconfiguration complete message to the target network node (Fig. 4 – Step 408: RRC Conn reconfig complete + PDCP status report(s)); and
based on a timer T not expiring, wherein the timer T is started when the UL switch to the target network node occurs in the RRC message that includes the handover command (Fig. 4 – step 407-408; [0209] a timer which typically is started at completion of the random access procedure or at reception of the handover command),
wherein the information element has been set by the target network node and conveyed together with the handover command (Fig. 4 – HO request ACK; [0040] Some highlights in this solution are: [0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption. And after step 408, the UE has the target link available for UL/DL user plane data transmission similar to the regular HO procedure; [0239] Action 1301: The target access node 112 obtains an indication, such as a handover request message from the source access node 111, that an enhanced make-before break handover/SCG change of UE 120 is being performed from a source access node 111 to this node),
WALLENTIN does not explicitly disclose transmitting the indication via a Physical Uplink Control Channel (PUCCH); receipt of a of a Random Access Response (RAR) in a contention-free random access (CFRA) procedure; wherein the timer T has a duration of 10 milliseconds; and wherein the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds.
However, KIM discloses transmitting data via a PUCCH ([0171] when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource) and a receipt a of a Random Access Response (RAR) in a contention-free random access (CFRA) procedure ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10, and if the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message. As another method, it may be determined that the first condition is satisfied if an uplink transmission resource is first received after the RAR is received).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the indication and receipt of the random access procedure of WALLENTIN to include transmitting via the PUCCH and receipt of the RAR in a CFRA procedure as taught by KIM in order to transmit preamble and data to the source and target base stations and perform efficient handover (KIM - [0171] efficient handover method in FIG. 7 may be characterized in that the UE 7-20 stops transmitting/receiving data (transmitting uplink data and receiving downlink data) with the source eNB 7-05 when the UE performs a procedure of random access to the target eNB 7-10… the UE transmits a preamble, or when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource; [0185] the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message).
WALLENTIN and KIM do not explicitly disclose wherein the timer T has a duration of 10 milliseconds.
However, CONCEICAO discloses wherein the timer T has a duration of 10 milliseconds ([0098] Where the definitions and requirements for these times are as follows (min value; max value) or (tuple of possible values): [0099] i. T.sub.RRC_procedure is a maximum RRC procedure delay as specified in clause 12 in TS 38.331 (min Oms; max 10 ms); [0109] i. T.sub.RRC is the is a maximum RRC procedure delay as specified in clause 12 in TS 38.331; [0112] iv. T.sub.CHO_execution is the WTRU execution preparation time for a conditional handover, and starts after the WTRU realizes the condition of CHO is met and identity of the target cell is determined. T.sub.CHO_execution may be up to 10 ms).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the timer T of WALLENTIN and KIM to include the timer T has the duration of 10 miliseconds as taught by CONCEICAO in order to minimize interruption time by giving the UE some time to successfully decode the handover command (CONCEICAO - [0109] i. T.sub.RRC is the is a maximum RRC procedure delay as specified in clause 12 in TS 38.331. [0110] ii. T.sub.Event_DU is the delay uncertainty, which is the time from when the WTRU successfully decodes a conditional handover command until a condition exists at the measurement reference point which will trigger the conditional handover. [0111] iii. T.sub.measure is the measurements time starting from T.sub.Event_DU until the WTRU executes a handover to a target cell and interruption time starts).
WALLENTIN, KIM and CONCEICAO do not explicitly disclose wherein the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds.
However, SHAH discloses wherein an indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic ([0459] The communication apparatus is not limited to be portable or movable, and may also include any kind of apparatus… and any other “things” in a network of an “Internet of Things (IoT)) in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds ([0097] For NR URLLC, further use cases with tighter requirements have been identified such as… The tighter requirements are higher reliability (up to 10.sup.6 level), higher availability, packet sizes of up to 256 bytes, time synchronization down to the order of a few μs where the value can be one or a few μs depending on frequency range and short latency in the order of 0.5 to 1 ms in particular a target user plane latency of 0.5 ms, depending on the use cases).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the indication of WALLENTIN, KIM and CONCEICAO to include the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds as taught by SHAH in order to improve reliability by reducing the user plane latency (SHAH - [0096] As mentioned above, it is expected that the scope of reliability in NR becomes wider. One key requirement to all the cases, and especially necessary for URLLC and mMTC, is high reliability or ultra-reliability. Several mechanisms can be considered to improve the reliability from radio perspective and network perspective; [0097];).
Regarding claim 54, WALLENTIN discloses:
A system (Fig. 1) comprising:
a user equipment (UE) operating in Fifth Generation (5G) New Radio (NR) and participating in a Dual Active Protocol Stack (DAPS) handover (Abstract - the disclosure concerns a method performed by a User Equipment for handling Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) when performing a Dual Active Protocol Stack (DAPS) handover of at least one radio bearer from a source access node to a target access node in a wireless communications network; [0009] To support fast mobility between NR and LTE and avoid change of core network, LTE eNBs can also be connected to the 5G-CN via NG-U/NG-C and support the Xn interface… it should be noted that most of the solutions/features described for LTE and NR in this document also apply to LTE connected to 5GC);
at least one processor (Fig. 14b – processor 146); and
at least one memory (Fig. 14b – memory 147) including computer-executable instructions that (Fig. 14b – computer program 148), when executed by the processor, cause the UE to perform the following operations ([0269] In some embodiments, a respective computer program 148, 158 comprises instructions, which when executed by the at least one processor 146, 156, cause the at least one processor 146, 156 of the respective the target access node 112 and UE 120 to perform the actions above):
transmitting, to a source network node (Fig. 4 – Source eNB), an indication (Fig. 4 – Step 401; [0014] An RRC_CONNECTED UE in E-UTRAN or NG-RAN can be configured by the network to perform measurements of serving and neighbor cells and based on the measurement reports sent by the UE, the network may decide to perform a handover of the UE to a neighbor cell) comprising
(i) a Packet Data Convergence Protocol (PDCP) sequence number (SN) of a next uplink packet to be forwarded (Fig. 4 – Step 408; [0045] To avoid packet duplication, the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell) and
(ii) a statement (Fig. 4 – step 408) that there are no pending uplink (UL) Medium Access Control (MAC) and Radio Link Control (RLC) retransmissions to the source network node ([0046] in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell; (PDCP packets travels down the protocol stack, e.g., PDCP, RLC, MAC, etc. in order to be transmitted – see Fig. 5));
receiving, from the source network node prior to transmitting the indication that there are no pending transmissions (Fig. 4 – step 408), an enumerated Radio Resource Control (RRC) information element (Fig. 5 – Step 405; RRC Conn reconfig) set to true that enables uplink interruption reduction ([0038] To address the shortcomings of Rel-14 MBB and achieve ˜0 ms interruption time an enhanced version of Make-Before-Break (eMBB) is being discussed for Rel-16 for both LTE and NR. In this enhanced version, it is assumed that the UE is capable of simultaneously transmitting and receiving from the source and target cell. In practice, this may require that the UE is equipped with dual Tx/Rx chains) during the DAPS handover ([0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, (Step 405 RRC Conn reconfig indicates to enable eMBB in the handover command) the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption);
receiving, from the source network node (Fig. 4 – Step 405), an indication to enable uplink interruption reduction during the handover ([0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption);
after receiving the indication, transmitting, to the source network node, an indication ([0215] In some other alternative embodiments, in Action 1206, when the radio connection with the source access node 111 is released implicitly by the UE 120 or the release is triggered by an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111) comprising
(i) a statement that there are no pending UL MAC and RLC retransmissions to the source network node ([0215] the source access node 111 is released implicitly by the UE 120 or the release is triggered by an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111, the PDCP Status Report is sent together with the first transmitted UL data packet to the target access node 112; [0024] The source access node receives an indication from the gateway that indicates the last packet sent to the source access node, a so called “end marker” packet) and
(ii) a PDCP sequence number (SN) of a next UL packet to be forwarded ([0024] the source access node also forwards this indication to the target access node so that the target access node knows when it can start transmission of packets received from the gateway; [0045] the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN… the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell), wherein the transmitting is performed:
after an UL user-plane switch to the target network node that occurs ([0043] Once the connection setup with the target access node is successful, i.e. after sending the Handover Complete message in step 408, the UE maintains two data links, one to the source access node and one to the target access node. After step 408, the UE transmits the UL user plane data on the target access node similar to the regular HO procedure using the target access node security keys and compression context; [0046] The release of the source cell in step 413 can e.g. be triggered by an explicit message from the target access node (not shown in the figure) or by some other event such as the expiry of a release timer) upon receipt of a Random Access procedure (Fig. 4 – Step 407; [0047] the UE has performed random access in the target cell);
after transmission of a RRC reconfiguration complete message to the target network node (Fig. 4 – Step 408: RRC Conn reconfig complete + PDCP status report(s)); and
based on a timer T not expiring, wherein the timer T is started when the UL switch to the target network node occurs in the RRC message that includes the handover command (Fig. 4 – step 407-408; [0209] a timer which typically is started at completion of the random access procedure or at reception of the handover command),
wherein the information element has been set by the target network node and conveyed together with the handover command (Fig. 4 – HO request ACK; [0040] Some highlights in this solution are: [0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption. And after step 408, the UE has the target link available for UL/DL user plane data transmission similar to the regular HO procedure; [0239] Action 1301: The target access node 112 obtains an indication, such as a handover request message from the source access node 111, that an enhanced make-before break handover/SCG change of UE 120 is being performed from a source access node 111 to this node),
WALLENTIN does not explicitly disclose transmitting the indication via a Physical Uplink Control Channel (PUCCH); receipt of a of a Random Access Response (RAR) in a contention-free random access (CFRA) procedure after the random access procedure; wherein the timer T has a duration of 10 milliseconds; and wherein the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds.
However, KIM discloses transmitting data via a PUCCH ([0171] when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource) and a receipt a of a Random Access Response (RAR) in a contention-free random access (CFRA) procedure ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10, and if the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message. As another method, it may be determined that the first condition is satisfied if an uplink transmission resource is first received after the RAR is received).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the indication and receipt of the random access procedure of WALLENTIN to include transmitting via the PUCCH and receipt of the RAR in a CFRA procedure as taught by KIM in order to transmit preamble and data to the source and target base stations and perform efficient handover (KIM - [0171] efficient handover method in FIG. 7 may be characterized in that the UE 7-20 stops transmitting/receiving data (transmitting uplink data and receiving downlink data) with the source eNB 7-05 when the UE performs a procedure of random access to the target eNB 7-10… the UE transmits a preamble, or when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource; [0185] the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message).
WALLENTIN and KIM do not explicitly disclose wherein the timer T has a duration of 10 milliseconds.
However, CONCEICAO discloses wherein the timer T has a duration of 10 milliseconds ([0098] Where the definitions and requirements for these times are as follows (min value; max value) or (tuple of possible values): [0099] i. T.sub.RRC_procedure is a maximum RRC procedure delay as specified in clause 12 in TS 38.331 (min Oms; max 10 ms); [0109] i. T.sub.RRC is the is a maximum RRC procedure delay as specified in clause 12 in TS 38.331; [0112] iv. T.sub.CHO_execution is the WTRU execution preparation time for a conditional handover, and starts after the WTRU realizes the condition of CHO is met and identity of the target cell is determined. T.sub.CHO_execution may be up to 10 ms).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the timer T of WALLENTIN and KIM to include the timer T has the duration of 10 miliseconds as taught by CONCEICAO in order to minimize interruption time by giving the UE some time to successfully decode the handover command (CONCEICAO - [0109] i. T.sub.RRC is the is a maximum RRC procedure delay as specified in clause 12 in TS 38.331. [0110] ii. T.sub.Event_DU is the delay uncertainty, which is the time from when the WTRU successfully decodes a conditional handover command until a condition exists at the measurement reference point which will trigger the conditional handover. [0111] iii. T.sub.measure is the measurements time starting from T.sub.Event_DU until the WTRU executes a handover to a target cell and interruption time starts).
WALLENTIN, KIM and CONCEICAO do not explicitly disclose wherein the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds.
However, SHAH discloses wherein an indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic ([0459] The communication apparatus is not limited to be portable or movable, and may also include any kind of apparatus… and any other “things” in a network of an “Internet of Things (IoT)) in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds ([0097] For NR URLLC, further use cases with tighter requirements have been identified such as… The tighter requirements are higher reliability (up to 10.sup.6 level), higher availability, packet sizes of up to 256 bytes, time synchronization down to the order of a few μs where the value can be one or a few μs depending on frequency range and short latency in the order of 0.5 to 1 ms in particular a target user plane latency of 0.5 ms, depending on the use cases).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the indication of WALLENTIN, KIM and CONCEICAO to include the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds as taught by SHAH in order to improve reliability by reducing the user plane latency (SHAH - [0096] As mentioned above, it is expected that the scope of reliability in NR becomes wider. One key requirement to all the cases, and especially necessary for URLLC and mMTC, is high reliability or ultra-reliability. Several mechanisms can be considered to improve the reliability from radio perspective and network perspective; [0097];).
Regarding claim 61, WALLENTIN discloses:
A method performed by a user equipment (UE) operating in Fifth Generation (5G) New Radio (NR) and participating in a Dual Active Protocol Stack (DAPS) handover, the method (Abstract - the disclosure concerns a method performed by a User Equipment for handling Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) when performing a Dual Active Protocol Stack (DAPS) handover of at least one radio bearer from a source access node to a target access node in a wireless communications network; [0009] To support fast mobility between NR and LTE and avoid change of core network, LTE eNBs can also be connected to the 5G-CN via NG-U/NG-C and support the Xn interface… it should be noted that most of the solutions/features described for LTE and NR in this document also apply to LTE connected to 5GC) comprising:
at least one processor (Fig. 14b – processor 146); and
at least one memory (Fig. 14b – memory 147) including computer-executable instructions (Fig. 14b – computer program 148) that, when executed by the processor, cause the UE to perform the following operations ([0269] In some embodiments, a respective computer program 148, 158 comprises instructions, which when executed by the at least one processor 146, 156, cause the at least one processor 146, 156 of the respective the target access node 112 and UE 120 to perform the actions above):
transmitting, to a source network node (Fig. 4 – Source eNB), an indication (Fig. 4 – Step 401; [0014] An RRC_CONNECTED UE in E-UTRAN or NG-RAN can be configured by the network to perform measurements of serving and neighbor cells and based on the measurement reports sent by the UE, the network may decide to perform a handover of the UE to a neighbor cell) comprising
(i) a Packet Data Convergence Protocol (PDCP) sequence number (SN) of a next uplink packet to be forwarded (Fig. 4 – Step 408; [0045] To avoid packet duplication, the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell) and
(ii) a statement (Fig. 4 – step 408) that there are no pending uplink (UL) Medium Access Control (MAC) and Radio Link Control (RLC) retransmissions to the source network node ([0046] in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell; (PDCP packets travels down the protocol stack, e.g., PDCP, RLC, MAC, etc. in order to be transmitted – see Fig. 5));
receiving, from the source network node prior to transmitting the indication that there are no pending transmissions (Fig. 4 – step 408), an enumerated Radio Resource Control (RRC) information element (Fig. 5 – Step 405; RRC Conn reconfig) set to true that enables uplink interruption reduction ([0038] To address the shortcomings of Rel-14 MBB and achieve ˜0 ms interruption time an enhanced version of Make-Before-Break (eMBB) is being discussed for Rel-16 for both LTE and NR. In this enhanced version, it is assumed that the UE is capable of simultaneously transmitting and receiving from the source and target cell. In practice, this may require that the UE is equipped with dual Tx/Rx chains) during the DAPS handover ([0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, (Step 405 RRC Conn reconfig indicates to enable eMBB in the handover command) the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption);
receiving, from the source network node (Fig. 4 – Step 405), an indication to enable uplink interruption reduction during the handover ([0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption);
after receiving the indication, transmitting, to the source network node, an indication ([0215] In some other alternative embodiments, in Action 1206, when the radio connection with the source access node 111 is released implicitly by the UE 120 or the release is triggered by an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111) comprising
(i) a statement that there are no pending UL MAC and RLC retransmissions to the source network node ([0215] the source access node 111 is released implicitly by the UE 120 or the release is triggered by an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111, the PDCP Status Report is sent together with the first transmitted UL data packet to the target access node 112; [0024] The source access node receives an indication from the gateway that indicates the last packet sent to the source access node, a so called “end marker” packet) and
(ii) a PDCP sequence number (SN) of a next UL packet to be forwarded ([0024] the source access node also forwards this indication to the target access node so that the target access node knows when it can start transmission of packets received from the gateway; [0045] the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN… the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell), wherein the transmitting is performed:
after an UL user-plane switch to the target network node that occurs ([0043] Once the connection setup with the target access node is successful, i.e. after sending the Handover Complete message in step 408, the UE maintains two data links, one to the source access node and one to the target access node. After step 408, the UE transmits the UL user plane data on the target access node similar to the regular HO procedure using the target access node security keys and compression context; [0046] The release of the source cell in step 413 can e.g. be triggered by an explicit message from the target access node (not shown in the figure) or by some other event such as the expiry of a release timer) upon receipt of a Random Access procedure (Fig. 4 – Step 407; [0047] the UE has performed random access in the target cell);
after transmission of a RRC reconfiguration complete message to the target network node (Fig. 4 – Step 408: RRC Conn reconfig complete + PDCP status report(s)); and
based on a timer T not expiring, wherein the timer T is started when the UL switch to the target network node occurs in the RRC message that includes the handover command (Fig. 4 – step 407-408; [0209] a timer which typically is started at completion of the random access procedure or at reception of the handover command),
wherein the information element has been set by the target network node and conveyed together with the handover command (Fig. 4 – HO request ACK; [0040] Some highlights in this solution are: [0041] In step 405, upon receiving the “eMBB” indication in the Handover Command, the UE maintains the connection to the source access node while establishing the connection to the target access node. That is, the UE can send and receive DL/UL user plane data via the source access node between step 405-408 without any interruption. And after step 408, the UE has the target link available for UL/DL user plane data transmission similar to the regular HO procedure; [0239] Action 1301: The target access node 112 obtains an indication, such as a handover request message from the source access node 111, that an enhanced make-before break handover/SCG change of UE 120 is being performed from a source access node 111 to this node),
WALLENTIN does not explicitly disclose transmitting the indication via a Physical Uplink Control Channel (PUCCH); receipt of a of a Random Access Response (RAR) in a contention-free random access (CFRA) procedure after the random access procedure; wherein the timer T has a duration of 10 milliseconds; and wherein the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds.
However, KIM discloses transmitting data via a PUCCH ([0171] when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource) and a receipt a of a Random Access Response (RAR) in a contention-free random access (CFRA) procedure ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10, and if the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message. As another method, it may be determined that the first condition is satisfied if an uplink transmission resource is first received after the RAR is received).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the indication and receipt of the random access procedure of WALLENTIN to include transmitting via the PUCCH and receipt of the RAR in a CFRA procedure as taught by KIM in order to transmit preamble and data to the source and target base stations and perform efficient handover (KIM - [0171] efficient handover method in FIG. 7 may be characterized in that the UE 7-20 stops transmitting/receiving data (transmitting uplink data and receiving downlink data) with the source eNB 7-05 when the UE performs a procedure of random access to the target eNB 7-10… the UE transmits a preamble, or when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource; [0185] the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message).
WALLENTIN and KIM do not explicitly disclose wherein the timer T has a duration of 10 milliseconds.
However, CONCEICAO discloses wherein the timer T has a duration of 10 milliseconds ([0098] Where the definitions and requirements for these times are as follows (min value; max value) or (tuple of possible values): [0099] i. T.sub.RRC_procedure is a maximum RRC procedure delay as specified in clause 12 in TS 38.331 (min Oms; max 10 ms); [0109] i. T.sub.RRC is the is a maximum RRC procedure delay as specified in clause 12 in TS 38.331; [0112] iv. T.sub.CHO_execution is the WTRU execution preparation time for a conditional handover, and starts after the WTRU realizes the condition of CHO is met and identity of the target cell is determined. T.sub.CHO_execution may be up to 10 ms).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the timer T of WALLENTIN and KIM to include the timer T has the duration of 10 miliseconds as taught by CONCEICAO in order to minimize interruption time by giving the UE some time to successfully decode the handover command (CONCEICAO - [0109] i. T.sub.RRC is the is a maximum RRC procedure delay as specified in clause 12 in TS 38.331. [0110] ii. T.sub.Event_DU is the delay uncertainty, which is the time from when the WTRU successfully decodes a conditional handover command until a condition exists at the measurement reference point which will trigger the conditional handover. [0111] iii. T.sub.measure is the measurements time starting from T.sub.Event_DU until the WTRU executes a handover to a target cell and interruption time starts).
WALLENTIN, KIM and CONCEICAO do not explicitly disclose wherein the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds.
However, SHAH discloses wherein an indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic ([0459] The communication apparatus is not limited to be portable or movable, and may also include any kind of apparatus… and any other “things” in a network of an “Internet of Things (IoT)) in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds ([0097] For NR URLLC, further use cases with tighter requirements have been identified such as… The tighter requirements are higher reliability (up to 10.sup.6 level), higher availability, packet sizes of up to 256 bytes, time synchronization down to the order of a few μs where the value can be one or a few μs depending on frequency range and short latency in the order of 0.5 to 1 ms in particular a target user plane latency of 0.5 ms, depending on the use cases).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the indication of WALLENTIN, KIM and CONCEICAO to include the indication is transmitted only for periodic deterministic industrial Internet of Things (IIoT) traffic in which each packet has a size of 40 bytes at an inter-arrival period of 0.5 milliseconds as taught by SHAH in order to improve reliability by reducing the user plane latency (SHAH - [0096] As mentioned above, it is expected that the scope of reliability in NR becomes wider. One key requirement to all the cases, and especially necessary for URLLC and mMTC, is high reliability or ultra-reliability. Several mechanisms can be considered to improve the reliability from radio perspective and network perspective; [0097];).
7. Claims 48, 55 and 62 are rejected under 35 U.S.C. 103 as being unpatentable over WALLENTIN in view of KIM and in view of CONCEICAO and in view of SHAH and in view of WONG et al. (US-20220279559-A1, hereinafter WONG).
Regarding claim 48, WALLENTIN, KIM, CONCEICAO and SHAH, as shown in the rejection above, discloses the limitations of claim 47.
WALLENTIN further discloses:
wherein the indication contains a Cell Radio Network Temporary Identifier(C-RNTI) ([0015] The reconfiguration parameters provided by the target access node contains, for example, information needed by the UE to access the target access node, e.g., random access configuration, a new C-RNTI assigned by the target access node and security parameters enabling the UE to calculate new security keys associated to the target access node so the UE can send a Handover Complete message, in LTE an RRConnectionReconfiguratioComplete message and in NR an RRCReconfigurationComplete message, on SRB1 encrypted and integrity protected based on new security keys upon accessing the target access node).
WALLENTIN, KIM, CONCEICAO and SHAH do not explicitly disclose the transmission is in PUCCH Format 1 and the indication is carried as uplink control information (UCI) bits protected by a cyclic redundancy check (CRC).
However, WONG discloses a transmission is in PUCCH Format 1 and an indication is carried as uplink control information (UCI) bits protected by a cyclic redundancy check (CRC) ([0049] A terminal device that wishes to transmit UCI selects a PUCCH Resource Set depending upon the number of UCI bits; [0056] There are five potential PUCCH Formats {0, 1, 2, 3, 4}. PUCCH Format 0 and 1 are sequence based while for PUCCH Formats 2, 3 & 4 the UCI bits are encoded using a Reed-Muller or Polar code with CRC (cyclic redundancy check)).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the transmission and indication of WALLENTIN, KIM, CONCEICAO and SHAH to include the transmission is in PUCCH Format 1 and the indication is carried as UCI bits protected by the CRC as taught by WONG in order to help successful handovers by encrypting and detecting errors in data transmission (WALLENTIN - [0015] a new C-RNTI assigned by the target access node and security parameters enabling the UE to calculate new security keys associated to the target access node so the UE can send a Handover Complete message, in LTE an RRConnectionReconfiguratioComplete message and in NR an RRCReconfigurationComplete message, on SRB1 encrypted and integrity protected based on new security keys upon accessing the target access node; WONG - [0056] There are five potential PUCCH Formats {0, 1, 2, 3, 4}. PUCCH Format 0 and 1 are sequence based while for PUCCH Formats 2, 3 & 4 the UCI bits are encoded using a Reed-Muller or Polar code with CRC (cyclic redundancy check)).
Regarding claim 55, WALLENTIN, KIM, CONCEICAO and SHAH, as shown in the rejection above, discloses the limitations of claim 54.
WALLENTIN further discloses:
wherein the indication contains a Cell Radio Network Temporary Identifier(C-RNTI) ([0015] The reconfiguration parameters provided by the target access node contains, for example, information needed by the UE to access the target access node, e.g., random access configuration, a new C-RNTI assigned by the target access node and security parameters enabling the UE to calculate new security keys associated to the target access node so the UE can send a Handover Complete message, in LTE an RRConnectionReconfiguratioComplete message and in NR an RRCReconfigurationComplete message, on SRB1 encrypted and integrity protected based on new security keys upon accessing the target access node).
WALLENTIN, KIM, CONCEICAO and SHAH do not explicitly disclose the transmission is in PUCCH Format 1 and the indication is carried as uplink control information (UCI) bits protected by a cyclic redundancy check (CRC).
However, WONG discloses a transmission is in PUCCH Format 1 and an indication is carried as uplink control information (UCI) bits protected by a cyclic redundancy check (CRC) ([0049] A terminal device that wishes to transmit UCI selects a PUCCH Resource Set depending upon the number of UCI bits; [0056] There are five potential PUCCH Formats {0, 1, 2, 3, 4}. PUCCH Format 0 and 1 are sequence based while for PUCCH Formats 2, 3 & 4 the UCI bits are encoded using a Reed-Muller or Polar code with CRC (cyclic redundancy check)).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the transmission and indication of WALLENTIN, KIM, CONCEICAO and SHAH to include the transmission is in PUCCH Format 1 and the indication is carried as UCI bits protected by the CRC as taught by WONG in order to help successful handovers by encrypting and detecting errors in data transmission (WALLENTIN - [0015] a new C-RNTI assigned by the target access node and security parameters enabling the UE to calculate new security keys associated to the target access node so the UE can send a Handover Complete message, in LTE an RRConnectionReconfiguratioComplete message and in NR an RRCReconfigurationComplete message, on SRB1 encrypted and integrity protected based on new security keys upon accessing the target access node; WONG - [0056] There are five potential PUCCH Formats {0, 1, 2, 3, 4}. PUCCH Format 0 and 1 are sequence based while for PUCCH Formats 2, 3 & 4 the UCI bits are encoded using a Reed-Muller or Polar code with CRC (cyclic redundancy check)).
Regarding claim 62, WALLENTIN, KIM, CONCEICAO and SHAH, as shown in the rejection above, discloses the limitations of claim 61.
WALLENTIN further discloses:
wherein the indication contains a Cell Radio Network Temporary Identifier(C-RNTI) ([0015] The reconfiguration parameters provided by the target access node contains, for example, information needed by the UE to access the target access node, e.g., random access configuration, a new C-RNTI assigned by the target access node and security parameters enabling the UE to calculate new security keys associated to the target access node so the UE can send a Handover Complete message, in LTE an RRConnectionReconfiguratioComplete message and in NR an RRCReconfigurationComplete message, on SRB1 encrypted and integrity protected based on new security keys upon accessing the target access node).
WALLENTIN, KIM, CONCEICAO and SHAH do not explicitly disclose the transmission is in PUCCH Format 1 and the indication is carried as uplink control information (UCI) bits protected by a cyclic redundancy check (CRC).
However, WONG discloses a transmission is in PUCCH Format 1 and an indication is carried as uplink control information (UCI) bits protected by a cyclic redundancy check (CRC) ([0049] A terminal device that wishes to transmit UCI selects a PUCCH Resource Set depending upon the number of UCI bits; [0056] There are five potential PUCCH Formats {0, 1, 2, 3, 4}. PUCCH Format 0 and 1 are sequence based while for PUCCH Formats 2, 3 & 4 the UCI bits are encoded using a Reed-Muller or Polar code with CRC (cyclic redundancy check)).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the transmission and indication of WALLENTIN, KIM, CONCEICAO and SHAH to include the transmission is in PUCCH Format 1 and the indication is carried as UCI bits protected by the CRC as taught by WONG in order to help successful handovers by encrypting and detecting errors in data transmission (WALLENTIN - [0015] a new C-RNTI assigned by the target access node and security parameters enabling the UE to calculate new security keys associated to the target access node so the UE can send a Handover Complete message, in LTE an RRConnectionReconfiguratioComplete message and in NR an RRCReconfigurationComplete message, on SRB1 encrypted and integrity protected based on new security keys upon accessing the target access node; WONG - [0056] There are five potential PUCCH Formats {0, 1, 2, 3, 4}. PUCCH Format 0 and 1 are sequence based while for PUCCH Formats 2, 3 & 4 the UCI bits are encoded using a Reed-Muller or Polar code with CRC (cyclic redundancy check)).
8. Claims 49-52, 56-59, and 63-65 are rejected under 35 U.S.C. 103 as being unpatentable over WALLENTIN in view of KIM and in view of CONCEICAO and in view of SHAH and in view of WONG and in view of XU et al. (US-20240031065-A1, hereinafter XU).
Regarding claim 49, WALLENTIN, KIM, CONCEICAO, SHAH and WONG as shown in the rejection above, discloses the limitations of claim 48.
WALLENTIN further discloses:
wherein the PDCP SN consists of eighteen bits with modulo-2^18 numbering, and the sequence number included in the indication is the next sequence number after the last PDCP SN successfully transmitted to the source network node, computed modulo-2^18.
wherein the sequence number included in the indication is the next sequence number after the last PDCP SN successfully transmitted to the source network node ([0045] the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN… the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell).
However, KIM discloses a PDCP SN consists of modulo numbering ([0290] 4> The UE may configure, update, or initialize the (1-3).sup.th window parameter to a PDCP sequence number corresponding to the last data (PDCP SDU) delivered to the upper layer device. As another method, the UE may configure, update, or initialize the (1-3).sup.th window parameter to a calculation result value of [((1-2).sup.th window parameter value−1) modulo (first constant value+1)]. As another method, if the PDCP sequence number of data (PDCP SDU) first received after changing or reconfiguring to the structure of the second PDCP layer device is x (or if the x value is not zero), the (1-3).sup.th window parameter may be configured, updated, or initialized to a calculation result value of [x modulo (first constant value+1)].).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the PDCP SN of WALLENTIN, KIM, CONCEICAO, SHAH and WONG to include the PDCP SN consists of modulo numbering as taught by KIM in order to properly manage and deliver PDCP packets after the handover (WALLENTIN - [0045] he target access node can avoid sending duplicate PDCP packets; KIM – [0290] if the PDCP sequence number of data (PDCP SDU) first received after changing or reconfiguring to the structure of the second PDCP layer device).
WALLENTIN, KIM, CONCEICAO, SHAH and WONG do not explicitly disclose wherein the PDCP SN consists of eighteen bits with modulo-2^18 numbering and computed modulo-2^18.
However, XU discloses the PDCP SN consists of eighteen bits with modulo-2^18 numbering and computed modulo-2^18 (in FIG. 10, a binary stream corresponding to 54 is... Because the length of the PDCP SN is 18 bits, it may be determined, based on the value of the COUNT, that the value of the PDCP SN corresponding to the data packet 1 is 54 (in other words, 54 modulo 2.sup.18=54), and that the value of the HFN is 0).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the PDCP SN consists of modulo numbering of WALLENTIN, KIM, CONCEICAO, SHAH and WONG to include the PDCP SN consists of eighteen bits with modulo-2^18 and computed modulo-2^18 as taught by XU in order to help improve handover reliability and stability (XU - [0007] An access network device receives the first indication information from a core network and determines the value of the COUNT of the first data packet based on the value of the COUNT indicated by the first indication information. This can ensure synchronization of values of HFNs and PDCP SNs between different access network devices and help implement normal transmission of a multicast and broadcast service in a handover scenario and improve communication reliability and stability).
Regarding claim 50, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 49.
WALLENTIN further discloses:
wherein determining that there are no pending UL MAC and RLC retransmissions comprises ([0046] in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell; (PDCP packets travels down the protocol stack, e.g., PDCP, RLC, MAC, etc. in order to be transmitted – see Fig. 5)) verifying that (ii) both MAC and RLC UL buffers toward the source network node are empty ([0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission (hence the MAC and RLC buffers of the source node are empty). The target access node 112 receives those forwarded data packets from the source access node 111).
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle.
However, KIM discloses verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle ([0223] Specifically, if the UE 8-20 has received a handover command message, and if a handover corresponding to the second embodiment of the disclosure (for example, DAPS handover method) has been indicated… However, the UE 8-20 may continuously receive downlink data from the source eNB 8-05, and even after uplink transmission switching, the UE 8-20 may continuously transmit an HARQ ACK or HARQ NACK, RLC status report, or PDCP control data (for example, PDCP status report or ROHC feedback information) corresponding to the downlink data. In addition, the UE 8-20 may continuously receive downlink data from the source eNB 8-05 or target eNB 8-10 even if the first condition is satisfied; [0232] the UE 8-20 may determine that the second condition is satisfied if no downlink data is received form the source eNB 8-05 (hence all the HARQ processes toward the source network are idle) for a predetermined time, may determine that the same has disconnected from the source eNB 8-05, and may disconnect therefrom).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the verification of no pending UL MAC and RLC retransmissions of WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU to include verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle as taught by KIM in order to prevent data loss when performing the handover process (KIM – [0222] the UE 8-20 may continue data transmission resulting from HARQ retransmission by the MAC device or resulting from retransmission by the AM-mode RLC layer device, in order to guarantee that there is no data loss to the source eNB 8-05; WALLENTIN - [0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission. The target access node 112 receives those forwarded data packets from the source access node 111).
Regarding claim 51, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 50.
WALLENTIN further discloses:
wherein the UE starts timer T at the UL user-plane switch ([0046] The release of the source cell in step 413 can e.g. be triggered by an explicit message from the target access node (not shown in the figure) or by some other event such as the expiry of a release timer; [0209] The release of the source cell may be triggered by a message received from the source or target access node or from an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111 or that a certain condition in the UE 120 is fulfilled, such as a timer has expired, a timer which typically is started at completion of the random access procedure or at reception of the handover command. The release of the source connection may also be done implicitly by the UE 120, e.g. at expiry of an inactivity timer or at detection of a radio link failure), and the condition of claim 50 is met ([0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission. The target access node 112 receives those forwarded data packets from the source access node 111).
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose wherein stops timer T when the condition is met, suppresses the PUCCH indication upon expiry of the timer T, and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired.
However, KIM discloses wherein stops timer T when a condition is met ([0165] If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50)), suppresses a PUCCH indication upon expiry of the timer T ([0164] if the UE fails to hand over to the target eNB for a predetermined time (for example, if T304 timer has expired), the original configuration of the UE is restored, and the same switches to the RRC idle state… if an efficient handover method has been configured, and if connection with the source eNB is valid, the UE may fall back, report the handover failure to the source eNB, and may reconfigure the connection (UE does not send pucch indication to target UE when the timer expires). The source eNB delivers a sequence number (SN) status regarding up/downlink data to each bearer (for example, RLC UM bearer or RLC AM bearer) and, if downlink data or uplink exists, delivers the same to the target eNB (6-30, 6-35)), and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired ([0165] If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50); [0166] After receiving the RAR, the UE transmits an RRC reconfiguration complete message and receives a downlink transmission resource or uplink transmission resource, thereby starting to transmit/receive data with the target eNB).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the timer T of WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU to include stops timer T when the condition is met, suppresses the PUCCH indication upon expiry of the timer T, and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired as taught by KIM in order to implement an efficient handover process by utilizing the timer (KIM - [0164] the UE stops data transmission/reception with the source eNB according to the configured handover method, or continues to perform the same, and starts a T304 timer. T304 refers to a timer configured such that, if the UE fails to hand over to the target eNB for a predetermined time (for example, if T304 timer has expired), the original configuration of the UE is restored, and the same switches to the RRC idle state; [0171] the efficient handover method in FIG. 7 may be characterized in that the UE 7-20 stops transmitting/receiving data (transmitting uplink data and receiving downlink data) with the source eNB 7-05 when the UE performs a procedure of random access to the target eNB 7-10 according to the handover method indicated by the handover command message in the second step 7-02, when the UE transmits a preamble, or when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource; WALLENTIN - [0209] The release of the source connection may also be done implicitly by the UE 120, e.g. at expiry of an inactivity timer or at detection of a radio link failure).
Regarding claim 52, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 51.
WALLENTIN further discloses:
wherein the UL user-plane switch follows a Random Access Channel (RACH) procedure ([0205] The UE 120 establishes a radio connection with the target access node 112, typically using a random access procedure).
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch.
However, KIM discloses using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10, and if the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message. As another method, it may be determined that the first condition is satisfied if an uplink transmission resource is first received after the RAR is received; [0165] the UE monitors whether or not a random access response (RAR) message is transmitted from the target cell. The monitoring time interval is referred to as a random access response window (RAR window). If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50)).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the RACH procedure of WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU to include using the preconfigured contention-free resource and the dedicated preamble, and the RAR as taught by KIM in order to enhance the handover process by including a RAR message (KIM - ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10; [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message).
Regarding claim 56, WALLENTIN, KIM, CONCEICAO, SHAH and WONG as shown in the rejection above, discloses the limitations of claim 55.
WALLENTIN further discloses:
wherein the PDCP SN consists of eighteen bits with modulo-2^18 numbering, and the sequence number included in the indication is the next sequence number after the last PDCP SN successfully transmitted to the source network node, computed modulo-2^18.
wherein the sequence number included in the indication is the next sequence number after the last PDCP SN successfully transmitted to the source network node ([0045] the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN… the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell).
However, KIM discloses a PDCP SN consists of modulo numbering ([0290] 4> The UE may configure, update, or initialize the (1-3).sup.th window parameter to a PDCP sequence number corresponding to the last data (PDCP SDU) delivered to the upper layer device. As another method, the UE may configure, update, or initialize the (1-3).sup.th window parameter to a calculation result value of [((1-2).sup.th window parameter value−1) modulo (first constant value+1)]. As another method, if the PDCP sequence number of data (PDCP SDU) first received after changing or reconfiguring to the structure of the second PDCP layer device is x (or if the x value is not zero), the (1-3).sup.th window parameter may be configured, updated, or initialized to a calculation result value of [x modulo (first constant value+1)].).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the PDCP SN of WALLENTIN, KIM, CONCEICAO, SHAH and WONG to include the PDCP SN consists of modulo numbering as taught by KIM in order to properly manage and deliver PDCP packets after the handover (WALLENTIN - [0045] he target access node can avoid sending duplicate PDCP packets; KIM – [0290] if the PDCP sequence number of data (PDCP SDU) first received after changing or reconfiguring to the structure of the second PDCP layer device).
WALLENTIN, KIM, CONCEICAO, SHAH and WONG do not explicitly disclose wherein the PDCP SN consists of eighteen bits with modulo-2^18 numbering and computed modulo-2^18.
However, XU discloses the PDCP SN consists of eighteen bits with modulo-2^18 numbering and computed modulo-2^18 (in FIG. 10, a binary stream corresponding to 54 is... Because the length of the PDCP SN is 18 bits, it may be determined, based on the value of the COUNT, that the value of the PDCP SN corresponding to the data packet 1 is 54 (in other words, 54 modulo 2.sup.18=54), and that the value of the HFN is 0).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the PDCP SN consists of modulo numbering of WALLENTIN, KIM, CONCEICAO, SHAH and WONG to include the PDCP SN consists of eighteen bits with modulo-2^18 and computed modulo-2^18 as taught by XU in order to help improve handover reliability and stability (XU - [0007] An access network device receives the first indication information from a core network and determines the value of the COUNT of the first data packet based on the value of the COUNT indicated by the first indication information. This can ensure synchronization of values of HFNs and PDCP SNs between different access network devices and help implement normal transmission of a multicast and broadcast service in a handover scenario and improve communication reliability and stability).
Regarding claim 57, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 56.
WALLENTIN further discloses:
wherein determining that there are no pending UL MAC and RLC retransmissions comprises ([0046] in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell; (PDCP packets travels down the protocol stack, e.g., PDCP, RLC, MAC, etc. in order to be transmitted – see Fig. 5)) verifying that (ii) both MAC and RLC UL buffers toward the source network node are empty ([0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission (hence the MAC and RLC buffers of the source node are empty). The target access node 112 receives those forwarded data packets from the source access node 111).
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle.
However, KIM discloses verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle ([0223] Specifically, if the UE 8-20 has received a handover command message, and if a handover corresponding to the second embodiment of the disclosure (for example, DAPS handover method) has been indicated… However, the UE 8-20 may continuously receive downlink data from the source eNB 8-05, and even after uplink transmission switching, the UE 8-20 may continuously transmit an HARQ ACK or HARQ NACK, RLC status report, or PDCP control data (for example, PDCP status report or ROHC feedback information) corresponding to the downlink data. In addition, the UE 8-20 may continuously receive downlink data from the source eNB 8-05 or target eNB 8-10 even if the first condition is satisfied; [0232] the UE 8-20 may determine that the second condition is satisfied if no downlink data is received form the source eNB 8-05 (hence all the HARQ processes toward the source network are idle) for a predetermined time, may determine that the same has disconnected from the source eNB 8-05, and may disconnect therefrom).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the verification of no pending UL MAC and RLC retransmissions of WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU to include verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle as taught by KIM in order to prevent data loss when performing the handover process (KIM – [0222] the UE 8-20 may continue data transmission resulting from HARQ retransmission by the MAC device or resulting from retransmission by the AM-mode RLC layer device, in order to guarantee that there is no data loss to the source eNB 8-05; WALLENTIN - [0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission. The target access node 112 receives those forwarded data packets from the source access node 111).
Regarding claim 58, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 57.
WALLENTIN further discloses:
wherein the UE starts timer T at the UL user-plane switch ([0046] The release of the source cell in step 413 can e.g. be triggered by an explicit message from the target access node (not shown in the figure) or by some other event such as the expiry of a release timer; [0209] The release of the source cell may be triggered by a message received from the source or target access node or from an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111 or that a certain condition in the UE 120 is fulfilled, such as a timer has expired, a timer which typically is started at completion of the random access procedure or at reception of the handover command. The release of the source connection may also be done implicitly by the UE 120, e.g. at expiry of an inactivity timer or at detection of a radio link failure), and the condition of claim 50 is met ([0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission. The target access node 112 receives those forwarded data packets from the source access node 111).
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose wherein stops timer T when the condition is met, suppresses the PUCCH indication upon expiry of the timer T, and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired.
However, KIM discloses wherein stops timer T when a condition is met ([0165] If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50)), suppresses a PUCCH indication upon expiry of the timer T ([0164] if the UE fails to hand over to the target eNB for a predetermined time (for example, if T304 timer has expired), the original configuration of the UE is restored, and the same switches to the RRC idle state… if an efficient handover method has been configured, and if connection with the source eNB is valid, the UE may fall back, report the handover failure to the source eNB, and may reconfigure the connection (UE does not send pucch indication to target UE when the timer expires). The source eNB delivers a sequence number (SN) status regarding up/downlink data to each bearer (for example, RLC UM bearer or RLC AM bearer) and, if downlink data or uplink exists, delivers the same to the target eNB (6-30, 6-35)), and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired ([0165] If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50); [0166] After receiving the RAR, the UE transmits an RRC reconfiguration complete message and receives a downlink transmission resource or uplink transmission resource, thereby starting to transmit/receive data with the target eNB).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the timer T of refA to include stops timer T when the condition is met, suppresses the PUCCH indication upon expiry of the timer T, and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired as taught by KIM in order to implement an efficient handover process by utilizing the timer (KIM - [0164] the UE stops data transmission/reception with the source eNB according to the configured handover method, or continues to perform the same, and starts a T304 timer. T304 refers to a timer configured such that, if the UE fails to hand over to the target eNB for a predetermined time (for example, if T304 timer has expired), the original configuration of the UE is restored, and the same switches to the RRC idle state; [0171] the efficient handover method in FIG. 7 may be characterized in that the UE 7-20 stops transmitting/receiving data (transmitting uplink data and receiving downlink data) with the source eNB 7-05 when the UE performs a procedure of random access to the target eNB 7-10 according to the handover method indicated by the handover command message in the second step 7-02, when the UE transmits a preamble, or when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource; WALLENTIN - [0209] The release of the source connection may also be done implicitly by the UE 120, e.g. at expiry of an inactivity timer or at detection of a radio link failure).
Regarding claim 59, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 58.
WALLENTIN further discloses:
wherein the UL user-plane switch follows a Random Access Channel (RACH) procedure ([0205] The UE 120 establishes a radio connection with the target access node 112, typically using a random access procedure) using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch.
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch.
However, KIM discloses using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10, and if the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message. As another method, it may be determined that the first condition is satisfied if an uplink transmission resource is first received after the RAR is received; [0165] the UE monitors whether or not a random access response (RAR) message is transmitted from the target cell. The monitoring time interval is referred to as a random access response window (RAR window). If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50)).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the RACH procedure of WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU to include the preconfigured contention-free resource and the dedicated preamble, and the RAR as taught by KIM in order to enhance the handover process by including a RAR message (KIM - ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10; [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message).
Regarding claim 63, WALLENTIN, KIM, CONCEICAO, SHAH and WONG as shown in the rejection above, discloses the limitations of claim 62.
WALLENTIN further discloses:
wherein the PDCP SN consists of eighteen bits with modulo-2^18 numbering, and the sequence number included in the indication is the next sequence number after the last PDCP SN successfully transmitted to the source network node, computed modulo-2^18.
wherein the sequence number included in the indication is the next sequence number after the last PDCP SN successfully transmitted to the source network node ([0045] the UE may send a PDCP status report together with the Handover Complete message in step 408, indicating the last received PDCP SN… the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell).
However, KIM discloses a PDCP SN consists of modulo numbering ([0290] 4> The UE may configure, update, or initialize the (1-3).sup.th window parameter to a PDCP sequence number corresponding to the last data (PDCP SDU) delivered to the upper layer device. As another method, the UE may configure, update, or initialize the (1-3).sup.th window parameter to a calculation result value of [((1-2).sup.th window parameter value−1) modulo (first constant value+1)]. As another method, if the PDCP sequence number of data (PDCP SDU) first received after changing or reconfiguring to the structure of the second PDCP layer device is x (or if the x value is not zero), the (1-3).sup.th window parameter may be configured, updated, or initialized to a calculation result value of [x modulo (first constant value+1)].).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the PDCP SN of WALLENTIN, KIM, CONCEICAO, SHAH and WONG to include the PDCP SN consists of modulo numbering as taught by KIM in order to properly manage and deliver PDCP packets after the handover (WALLENTIN - [0045] he target access node can avoid sending duplicate PDCP packets; KIM – [0290] if the PDCP sequence number of data (PDCP SDU) first received after changing or reconfiguring to the structure of the second PDCP layer device).
WALLENTIN, KIM, CONCEICAO, SHAH and WONG do not explicitly disclose wherein the PDCP SN consists of eighteen bits with modulo-2^18 numbering and computed modulo-2^18.
However, XU discloses the PDCP SN consists of eighteen bits with modulo-2^18 numbering and computed modulo-2^18 (in FIG. 10, a binary stream corresponding to 54 is... Because the length of the PDCP SN is 18 bits, it may be determined, based on the value of the COUNT, that the value of the PDCP SN corresponding to the data packet 1 is 54 (in other words, 54 modulo 2.sup.18=54), and that the value of the HFN is 0).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the PDCP SN consists of modulo numbering of WALLENTIN, KIM, CONCEICAO, SHAH and WONG to include the PDCP SN consists of eighteen bits with modulo-2^18 and computed modulo-2^18 as taught by XU in order to help improve handover reliability and stability (XU - [0007] An access network device receives the first indication information from a core network and determines the value of the COUNT of the first data packet based on the value of the COUNT indicated by the first indication information. This can ensure synchronization of values of HFNs and PDCP SNs between different access network devices and help implement normal transmission of a multicast and broadcast service in a handover scenario and improve communication reliability and stability).
Regarding claim 64, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 63.
WALLENTIN further discloses:
wherein determining that there are no pending UL MAC and RLC retransmissions comprises ([0046] in step 408, indicating the last received PDCP SN. Based on the PDCP status report, the target access node can avoid sending duplicate PDCP packets (i.e. PDCP PDUs with identical sequence numbers) to the UE, i.e. PDCP packets which were already received by the UE in the source cell; (PDCP packets travels down the protocol stack, e.g., PDCP, RLC, MAC, etc. in order to be transmitted – see Fig. 5)) verifying that (ii) both MAC and RLC UL buffers toward the source network node are empty ([0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission (hence the MAC and RLC buffers of the source node are empty). The target access node 112 receives those forwarded data packets from the source access node 111).
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle.
However, KIM discloses verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle ([0223] Specifically, if the UE 8-20 has received a handover command message, and if a handover corresponding to the second embodiment of the disclosure (for example, DAPS handover method) has been indicated… However, the UE 8-20 may continuously receive downlink data from the source eNB 8-05, and even after uplink transmission switching, the UE 8-20 may continuously transmit an HARQ ACK or HARQ NACK, RLC status report, or PDCP control data (for example, PDCP status report or ROHC feedback information) corresponding to the downlink data. In addition, the UE 8-20 may continuously receive downlink data from the source eNB 8-05 or target eNB 8-10 even if the first condition is satisfied; [0232] the UE 8-20 may determine that the second condition is satisfied if no downlink data is received form the source eNB 8-05 (hence all the HARQ processes toward the source network are idle) for a predetermined time, may determine that the same has disconnected from the source eNB 8-05, and may disconnect therefrom).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the verification of no pending UL MAC and RLC retransmissions of WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU to include verifying that all hybrid automatic repeat request (HARQ) processes toward the source network node are idle as taught by KIM in order to prevent data loss when performing the handover process (KIM – [0222] the UE 8-20 may continue data transmission resulting from HARQ retransmission by the MAC device or resulting from retransmission by the AM-mode RLC layer device, in order to guarantee that there is no data loss to the source eNB 8-05; WALLENTIN - [0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission. The target access node 112 receives those forwarded data packets from the source access node 111).
Regarding claim 65, WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU, as shown in the rejection above, discloses the limitations of claim 64.
WALLENTIN further discloses:
wherein the UE starts timer T at the UL user- plane switch ([0046] The release of the source cell in step 413 can e.g. be triggered by an explicit message from the target access node (not shown in the figure) or by some other event such as the expiry of a release timer; [0209] The release of the source cell may be triggered by a message received from the source or target access node or from an in-band indicator, e.g. a PDCP “end marker” packet, received from the source access node 111 or that a certain condition in the UE 120 is fulfilled, such as a timer has expired, a timer which typically is started at completion of the random access procedure or at reception of the handover command. The release of the source connection may also be done implicitly by the UE 120, e.g. at expiry of an inactivity timer or at detection of a radio link failure), the condition of claim 50 is met ([0240] In order to ensure lossless handover in the DL, the source access node 111 forwards the DL PDCP SDUs stored in the retransmission buffer as well as fresh DL PDCP SDUs received from the gateway to the target access node 112 for (re-) transmission. The target access node 112 receives those forwarded data packets from the source access node 111), and wherein the UL user-plane switch follows a Random Access Channel (RACH) procedure ([0205] The UE 120 establishes a radio connection with the target access node 112, typically using a random access procedure) using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch.
WALLENTIN, CONCEICAO, SHAH, WONG and XU do not explicitly disclose wherein stops timer T when the condition is met, suppresses the PUCCH indication upon expiry of the timer T, and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired and using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch.
However, KIM discloses wherein stops timer T when a condition is met ([0165] If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50)), suppresses a PUCCH indication upon expiry of the timer T ([0164] if the UE fails to hand over to the target eNB for a predetermined time (for example, if T304 timer has expired), the original configuration of the UE is restored, and the same switches to the RRC idle state… if an efficient handover method has been configured, and if connection with the source eNB is valid, the UE may fall back, report the handover failure to the source eNB, and may reconfigure the connection (UE does not send pucch indication to target UE when the timer expires). The source eNB delivers a sequence number (SN) status regarding up/downlink data to each bearer (for example, RLC UM bearer or RLC AM bearer) and, if downlink data or uplink exists, delivers the same to the target eNB (6-30, 6-35)), and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired ([0165] If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50); [0166] After receiving the RAR, the UE transmits an RRC reconfiguration complete message and receives a downlink transmission resource or uplink transmission resource, thereby starting to transmit/receive data with the target eNB) and using a preconfigured contention-free resource and a dedicated preamble, and the RAR includes an uplink grant and a timing-advance command used to effect the switch ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10, and if the instructed random access is a contention-free random access (CFRA) (for example, if a predesignated preamble or a UE cell identifier (for example, cell radio network temporary identifier (C-RNTI) has been assigned thereto); [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message. As another method, it may be determined that the first condition is satisfied if an uplink transmission resource is first received after the RAR is received; [0165] the UE monitors whether or not a random access response (RAR) message is transmitted from the target cell. The monitoring time interval is referred to as a random access response window (RAR window). If an RAR is received during the specific time (6-45), the UE transmits an HO complete message, as an RRC reconfiguration complete message, to the target eNB (6-55). If the RAR is successfully received from the target eNB in this manner, the UE ends the T304 timer (6-50)).
It would have been obvious to a person of ordinary skill in the art at the time of the invention was filed to modify the timer T and the RACH procedure of WALLENTIN, KIM, CONCEICAO, SHAH, WONG and XU to include stops timer T when the condition is met, suppresses the PUCCH indication upon expiry of the timer T, and transmits the PUCCH indication immediately upon stopping timer T if timer T has not expired and using the preconfigured contention-free resource and the dedicated preamble, and the RAR as taught by KIM in order to implement an efficient handover process by utilizing the timer (KIM - [0164] the UE stops data transmission/reception with the source eNB according to the configured handover method, or continues to perform the same, and starts a T304 timer. T304 refers to a timer configured such that, if the UE fails to hand over to the target eNB for a predetermined time (for example, if T304 timer has expired), the original configuration of the UE is restored, and the same switches to the RRC idle state; [0171] the efficient handover method in FIG. 7 may be characterized in that the UE 7-20 stops transmitting/receiving data (transmitting uplink data and receiving downlink data) with the source eNB 7-05 when the UE performs a procedure of random access to the target eNB 7-10 according to the handover method indicated by the handover command message in the second step 7-02, when the UE transmits a preamble, or when the UE first transmits data with an uplink transmission resource by using a physical uplink control channel (PUCCH) or physical uplink shared channel (PUSCH) transmission resource; WALLENTIN - [0209] The release of the source connection may also be done implicitly by the UE 120, e.g. at expiry of an inactivity timer or at detection of a radio link failure) and enhance the handover process by including a RAR message (KIM - ([0185] if the UE 8-20 has received a handover command message from the source eNB 8-05, if the UE 8-20 has been instructed to make a random access to the target eNB 8-10; [0186] It may be considered that the random access procedure has been successfully completed when the UE 8-20 has transmitted a predesignated preamble to a cell of the target eNB 8-10 and has received an RAR message. Therefore, it may be determined that the first condition is satisfied if the UE 8-20 has received the first uplink transmission resource assigned, included, or indicated by the RAR message).
Conclusion
9. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. PTO-892 form.
MolavianJazi et al. (US-20220385381-A1) teaches DAPS handover wherein in response to a PRACH transmission, a UE attempts to detect a DCI format 1_0 with cyclic redundancy check (CRC) scrambled by a corresponding RA-RNTI during a window.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THERESA NGUYEN whose telephone number is (571)272-2386. The examiner can normally be reached Monday - Friday 9AM - 5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, MOO JEONG can be reached at (571)272-9617. 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.
/THERESA NGUYEN/Examiner, Art Unit 2418
/Moo Jeong/Supervisory Patent Examiner, Art Unit 2418