DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The abstract of the disclosure is objected to because it exceeds 150 words. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
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 factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-30 are rejected under 35 U.S.C. 103 as being unpatentable over TR38.821 (“Solutions for NR to support non-terrestrial networks (NTN)”), hereinafter “TR38.821”, in view of TS38.401 (“Architecture description”), hereinafter “TS38.401”.
Per claim 1 and 17:
Regarding claim 17, TR38.821 teaches ‘A network node for wireless communication’ (TR38.821: [Page 26: Figure 5.2.2-2]: “NTN Gateway”), ‘comprising: one or more memories’ (existence of memory for NTN Gateway is implied); ‘one or more processors’ (existence of processor for NTN Gateway is implied), ‘coupled to the one or more memories, configured to cause the network node to’ (these are implied);
‘establish a network interface link with a centralized unit (CU)’ (TR38.821: [Page 26: Figure 5.2.2-3]: “NTN Gateway” <-> “gNB-CU”: “L1”, “L2”, “F1-U”; [Page 27: Figure 5.2.2-4]: “NTN Gateway” <-> “gNB-CU”: “L1”, “L2”, “F1-C”; [Page 127]: “When the connection between the new gNB-CU and the gNB-DU is established through the target NTN GW”; would establish a network interface link with a CU);
‘establish a set of one or more network interface links with a set of one or more distributed units (DUs)’ (TR38.821: [Page 22]: “SRI (Satellite Radio Interface) is a transport link between NTN GW and satellite”; [Page 26: Figure 5.2.2-2]: “NTN Gateway” <-> “Satellite with on-board gNB-DU”: “SRI”, network interface link with DU; [Page 25]: “DU on board different satellites may be connected to the same CU on ground. If the satellite hosts more than one DU, the same SRI will transport all the corresponding F1 interface instances”; [Page 127]: “the connection between the new gNB-CU and the gNB-DU is established through the target NTN GW … Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-DU mobility”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; would establish SRI with a set of one or more DUs; [Page 113: Table 8.3-1]: “NG-RAN procedures versus NTN hand-over scenarios”, “Intra-gNB-CU Mobility/ Inter-gNB-DU Mobility or Inter-gNB-CU handover (See clause 8.2.1.1 in TS 38.401)”);
‘receive a first communication via the network interface link’ (TR38.821: [Page 26: Figure 5.2.2-3]: “UPF” <-> “UE”: “PDU”, PDU data between UPF and UE via NTN gateway and current serving gNB-DU; [Page 26]: “The User PDUs are transported over GTP-U tunnels between the gNB-CU and the on board gNB-DU via the NTN Gateway”; implicitly teach that NTN gateway would receive DL PDU for UE (an end node) from gNB-CU and forward PDU to current serving gNB-DU (source gNB-DU) over SRI interface before handover or move to a new gNB-DU);
‘transmit the first communication to an end node via a first network interface link of the set of one or more network interface links’ (discussed in element above);
‘receive a second communication via the network interface link’ (TS38.821: [Page 114]: “Intra-gNB/Inter-DU Mobility”; [Page 127]: “Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-DU mobility”; [Page 26: Figure 5.2.2-3]: “UPF” <-> “UE”: “PDU”, PDU data between UPF and UE via NTN gateway and current serving gNB-DU; [Page 113: Table 8.3-1]: “NG-RAN procedures versus NTN hand-over scenarios”, “Intra-gNB-CU Mobility/ Inter-gNB-DU Mobility or Inter-gNB-CU handover (See clause 8.2.1.1 in TS 38.401)”; implicitly teach that when NTN Gateway receives new DL PDU for UE from the same gNB-CU after intra gNB-CU and inter-gNB-DU mobility, NTN Gateway would forward new DL PDU to new gNB-DU (the target gNB-DU which is the current serving gNB-DU now) over the SRI associated with the new gNB-DU);
‘transmit, after transmitting the first communication via the first network interface link, the second communication to the end node via a second network interface link’ (discussed in element above).
Although the limitations of sending DL data to UE via source gNB-DU before handover and via target gNB-DU after handover are implicitly taught in TR38.821, the reference does not explicitly teach sending DL data to UE via source gNB-DU before handover and via target gNB-DU after handover.
Nevertheless, TS38.401 in the same field of endeavor teaches the detail procedures for intra-gNB-CU and inter-gNB-DU mobility about gNB-CU sending DL data to UE via source gNB-DU before handover and via target gNB-DU after handover (TS38.401: [Page 28: Figure 8.2.1.1-1]: “gNB-CU” -> “Source gNB-DU” -> “UE”: “Downlink User Data” before step 1, “gNB-CU” -> “Target gNB-DU” -> “UE”: “Downlink User Data” after step 9).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine TS38.401’s teaching with that of TR38.821 in order to conform to 3GPP procedures for promotion of corroboration and inter-operation.
Regarding claim 1, claim 1 recites the method implemented by the network node of claim 17 (see rejection of claim 17 above).
Per claim 2 and 18:
Regarding claim 18, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
TR38.821 teaches ‘wherein the set of one or more network interface links comprises the second network interface link’ (TR38.821: [Page 127]: “Having two gNB-DUs with individual feeder link connections”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites);
‘wherein the second network interface link is established after the set of one or more network interface links is established’ (this is optional).
Regarding claim 2, claim 2 recites the method implemented by the network node of claim 18 (see rejection of claim 18 above).
Per claim 3 and 19:
Regarding claim 19, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
TR38.821 teaches ‘transmit the second communication to the second DU via the second network interface link based at least in part on one or more of movement or availability of the first DU associated with the first network interface link, availability of the first network interface link’ (this is optional);
‘movement or availability of the second DU associated with the second network interface link, or availability of the second network interface link’ (TS38.821: [Page 115]: “the UE mobility (hand-over) is due to the change of the interface, for example, when the satellite moves out of the coverage of current radio network node on the ground”; [Page 26: Figure 5.2.2-3]: “Satellite with on-board gNB-DU”; [Page 127]: “Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-DU mobility”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; could be due to satellite (gNB-DU) movement caused mobility to another DU).
Regarding claim 3, claim 3 recites the method implemented by the network node of claim 19 (see rejection of claim 19 above).
Per claim 4 and 20:
Regarding claim 20, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
TR38.821 teaches ‘release, suspend, or resume the first network interface link after the first communication is transmitted, wherein the first network interface link is released, suspended, or resumed based at least in part on a connection availability between the network node and the first DU independent from the network interface link with the CU’ (TR38.821: [Page 129]: “the satellite/gNB-DU and gNB-CU may suspend the F1 interface and keep the application level configuration data when the satellite/gNB-DU leaves, then resume the F1 interface when the satellite/gNB-DU connects to the same gNB-CU later”; [Page 127]: “Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-DU mobility”; [Page 115]: “the UE mobility (hand-over) is due to the change of the interface, for example, when the satellite moves out of the coverage of current radio network node on the ground”; [Page 26: Figure 5.2.2-3]: “Satellite with on-board gNB-DU”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; [Page 113: Table 8.3-1]: “NG-RAN procedures versus NTN hand-over scenarios”, “Intra-gNB-CU Mobility/ Inter-gNB-DU Mobility or Inter-gNB-CU handover (See clause 8.2.1.1 in TS 38.401)”; would suspend or resume the F1 interface based on the movement of satellite independent from the network interface link between NTN-Gateway and gNB-CU (intra-gNB-CU)).
Regarding claim 4, claim 4 recites the method implemented by the network node of claim 20 (see rejection of claim 20 above).
Per claim 5 and 21:
Regarding claim 21, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
TR38.821 teaches ‘perform a network interface link setup associated with the second network interface link before transmitting the second communication, wherein the network interface link setup associated with the second network interface link is independent from the network interface link with the CU’ (TS38.821: [Page 115]: “the UE mobility (hand-over) is due to the change of the interface, for example, when the satellite moves out of the coverage of current radio network node on the ground”; [Page 26: Figure 5.2.2-3]: “Satellite with on-board gNB-DU”, “SRI”, “UPF” <-> “UE”: “PDU”; [Page 127]: “Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-DU mobility”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; [Page 113: Table 8.3-1]: “NG-RAN procedures versus NTN hand-over scenarios”, “Intra-gNB-CU Mobility/ Inter-gNB-DU Mobility or Inter-gNB-CU handover (See clause 8.2.1.1 in TS 38.401)”; would perform SRI setup associated with the new DU during mobility before transmitting the new DL PDU to new DU independent from the network interface link between NTN-Gateway and gNB-CU (intra-gNB-CU)).
Regarding claim 5, claim 5 recites the method implemented by the network node of claim 21 (see rejection of claim 21 above).
Per claim 6 and 22:
Regarding claim 22, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
Combination of TR38.821 and TS38.401 teaches ‘receive, from the CU, an indication of an intra-DU handover from the first DU associated with the first network interface link to the second DU associated with the second network interface link’ (TR38.821: [Page 27: Figure 5.2.2-4]: “gNB-CU” <-> “NTN Gateway”: “F1-C”; [Page 127]: “Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-DU mobility”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; [Page 115]: “the UE mobility (hand-over) is due to the change of the interface, for example, when the satellite moves out of the coverage of current radio network node on the ground”; [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”; [Page 113: Table 8.3-1]: “NG-RAN procedures versus NTN hand-over scenarios”, “Intra-gNB-CU Mobility/ Inter-gNB-DU Mobility or Inter-gNB-CU handover (See clause 8.2.1.1 in TS 38.401)”. TS38.401: [Page 28: Figure 8.2.1.1-1]: “Inter-gNB-DU Mobility for intra-NR”, step 2a: “gNB-CU” -> “Source gNB-DU”: “UE CONTEXT MODIFICATION REQUEST”; NTN Gateway would receive an indication of handover from gNB-CU and forward to target gNB-DU);
‘perform an inter-DU handover from the first DU to the second DU’ (TR38.821: [Page 127]: “perform intra-gNB-CU inter-gNB-DU mobility”. TS38.401: [Page 28: Figure 8.2.1.1-1], [Page 29]: performance handover from source DU to target DU).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine TS38.401’s teaching of inter-gNB-DU handover procedures with that of TR38.821 in order to conform to 3GPP procedures for promotion of corroboration and inter-operation.
Regarding claim 6, claim 6 recites the method implemented by the network node of claim 22 (see rejection of claim 22 above).
Per claim 7 and 23:
Regarding claim 23, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
Combination of TR38.821 and TS38.401 teaches ‘receive, from the first DU, first configuration information associated with a first link between the first DU and the destination node’ (TR38.821: [Page 27: Figure 5.2.2-4]: “gNB-DU” <-> “NTN Gateway”: “F1-C”, “SRI”; [Page 127]: “Having two gNB-DUs with individual feeder link connections entails the UEs may perform intra-gNB-CU inter-gNB-DU mobility”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”; [Page 113: Table 8.3-1]: “NG-RAN procedures versus NTN hand-over scenarios”, “Intra-gNB-CU Mobility/ Inter-gNB-DU Mobility or Inter-gNB-CU handover (See clause 8.2.1.1 in TS 38.401)”. TS38.401: [Page 28: Figure 8.2.1.1-1]: step 2b: “Source gNB-DU” -> “gNB-CU”: “UE CONTEXT MODIFICATION RESPONSE”; [Page 29]: “The source gNB-DU responds with an UE CONTEXT MODIFICATION RESPONSE message that includes full configuration information”. NTN Gateway would receive the configuration from source DU and forward to CU);
‘transmit, to the second DU, second configuration information, based at least in part on the first configuration information, associated with establishing a second link between the second DU and the destination node’ (TR38.821: [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”. TS38.401: [Page 28: Figure 8.2.1.1-1]: step 3: “gNB-CU” -> “Target gNB-DU”: “UE CONTEXT SETUP REQUEST”; [Page 29]: “The gNB-CU sends an UE CONTEXT SETUP REQUEST message to the target gNB-DU to create an UE context and setup one or more data bearers. The UE CONTEXT SETUP REQUEST message includes a HandoverPreparationInformation”. NTN Gateway would receive configuration for handover from CU and forward to target DU).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine TS38.401’s teaching of inter-gNB-DU handover procedures with that of TR38.821 in order to conform to 3GPP procedures for promotion of corroboration and inter-operation.
Regarding claim 7, claim 7 recites the method implemented by the network node of claim 23 (see rejection of claim 23 above).
Regarding claim 8, combination of TR38.821 and TS38.401 teaches the method of claim 1 (discussed above).
TR38.821 teaches ‘wherein the network node comprises a gateway node’ (TR38.821: [Page 26: Figure 5.2.2-2]: “NTN Gateway”).
Per claim 9 and 24:
Regarding claim 24, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
TR38.821 teaches ‘wherein the set of one or more DUs comprises a set of one or more non-terrestrial network (NTN) DUs’ (TR38.821: [Page 26: Figure 5.2.2-3]: “Satellite with on-board gNB-DU”; [Page 15: Figure 4.1-2]: “Gateway” connected to two satellites).
Regarding claim 9, claim 9 recites the method implemented by the network node of claim 24 (see rejection of claim 24 above).
Per claim 10 and 25:
Regarding claim 25, combination of TR38.821 and TS38.401 teaches the network node of claim 17 (discussed above).
TR38.821 teaches ‘wherein the network interface link and the one or more network interface links comprise F1 interface links’ (TR38.821: [Page 26: Figure 5.2.2-3]: “NTN Gateway” -<-> “gNB-CU”: “F1-U”, “NTN Gateway” <-> “gNB-DU”: “F1-U”; [Page 27: Figure 5.2.2-4]: “NTN Gateway” <-> “gNB-CU”: ““F1-C”, “NTN Gateway” <-> “gNB-DU”: “F1-C”).
Regarding claim 10, claim 10 recites the method implemented by the network node of claim 25 (see rejection of claim 25 above).
Per claim 11 and 26:
Regarding claim 26, TR38.821 teaches ‘A network node for wireless communication’ (TR38.821: [Page 26: Figure 5.2.2-2]: “NTN Gateway”); ‘comprising: one or more memories’ (existence of memory for NTN Gateway is implied); ‘one or more processors’ (existence of processor for NTN Gateway is implied); ‘coupled to the one or more memories, configured to cause the network node to’ (these are implied);
‘communicate with a centralized unit (CU)’ (TR38.821: [Page 26: Figure 5.2.2-3]: “NTN Gateway” <-> “gNB-CU”: “F1-U”; [Page 27: Figure 5.2.2-4]: “NTN Gateway” <-> “gNB-CU”: “F1-C”; [Page 127]: “When the connection between the new gNB-CU and the gNB-DU is established through the target NTN GW”; would communicate with a CU);
‘communicate with a set of one or more distributed units (DUs)’ (TR38.821: [Page 22]: “SRI (Satellite Radio Interface) is a transport link between NTN GW and satellite”; [Page 26: Figure 5.2.2-2]: “NTN Gateway” <-> “Satellite with on-board gNB-DU”: “SRI”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; would communicate with a set of one or more DUs);
‘receive, from the CU, an indication of a handover from a first cell associated with a first DU to a second cell associated with a second DU’ (TR38.821: [Page 27: Figure 5.2.2-4]: “NTN Gateway” <-> “gNB-CU”: “F1-C”, “NTN Gateway” <-> “gNB-DU”: “F1-C”; [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”; [Page 94: Figure 7.3.2.1.1-1]: “Handover procedure”, step 1: “Source gNB” -> “Target gNB”: “Handover REQUEST”; step 3: “Source gNB” -> “UE”: “RRCReconfiguration”; [Page [Page 113: Table 8.3-1]: “NG-RAN procedures versus NTN hand-over scenarios”, “Inter-gNB-CU handover (See clause 8.2.1.1 in TS 38.401)”). However, TR38.821 fails to expressly teach an indication of a handover from a first cell associated with a first DU to a second cell associated with a second DU.
However, TS38.401 teaches inter-gNB handover procedures from a source gNB-CU associated with a source gNB-DU to a target gNB-CU with a target gNB-DU (TS48.401: [Page 63: Figure 8.9.4-1]: source cell (source gNB-CU) = (“Source gNB-CU-CP, Source gNB-CU-UP} associated with “Source gNB-DU”, target cell (Target gNB-CU) = {“Target gNB-CU-CP, Target gNB-CU-UP} associated with “Target gNB-DU”, step 1: “Source gNB-CU-CP” -> “Target gNB-CU-CP”: “HANDOVER REQUEST”, step 6: “Source gNB-CU-CP” -> “Source gNB-DU”: “F1 UE Context Modification Procedure”; [Page 63]: “The F1 UE Context Modification procedure is performed to send the handover command to the UE”, an indication of handover).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine TS38.401’s teaching with that of TR38.821 for NTN Gateway to receive from CU an indication of a handover from a first cell associated with a first DU to a second cell associated with a second DU in order to conform to 3GPP procedures for promotion of corroboration and inter-operation.
Combination of TR38.821 and TS38.401 teaches ‘transmit, to the first DU, an indication of a user equipment (UE) context modification request associated with the first cell’ (TR38.821: [Page 27: Figure 5.2.2-4]: “NTN Gateway” <-> “gNB-CU”: “F1-C”, “NTN Gateway” <-> “gNB-DU”: “F1-C”; [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”. TS48.401: [Page 63: Figure 8.9.4-1]: source cell (source gNB-CU) = (“Source gNB-CU-CP, Source gNB-CU-UP} associated with “Source gNB-DU”, target cell (Target gNB-CU) = {“Target gNB-CU-CP, Target gNB-CU-UP} associated with “Target gNB-DU”; step 6: “Source gNB-CU-CP” <-> “Source gNB-DU”: “F1 UE Context Modification Procedure”; [Page 63]: “The F1 UE Context Modification procedure is performed to send the handover command to the UE”; [Page 115]: “gNB-CU sends the UE CONTEXT MODIFICATION REQUEST message by including the RRCReconfiguration message to the source gNB-DU”; NTN Gateway would forward UE context modification request to source gNB-DU associated with source ell);
‘receive, from the first DU, an indication of a UE context modification response’ (TR38.821: [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”. TS48.401: [Page 63: Figure 8.9.4-1]: step 6: “Source gNB-CU-CP” <-> “Source gNB-DU”: “F1 UE Context Modification Procedure”; [Page 115]: “The source gNB-DU sends the UE CONTEXT MODIFICATION RESPONSE message to the gNB-CU”, NTN Gateway would receive UE context modification response from source gNB-DU);
‘transmit, to the second DU, an indication of a UE context setup request associated with the second cell’ (TR38.821: [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”. TS48.401: [Page 91: Figure 8.15.2.1-1]: step 7: “Target gNB-CU-CP” -> “Target gNB-DU”: “UE CONTEXT SETUP REQUEST”; NTN Gateway would forward UE context setup request received from target cell to target gNB-DU);
‘receive, from the second DU, an indication of a UE context setup response’ (TR38.821: [Page 27]: “The RRC PDUs are transported over PDCP over the F1-C protocols stack between the gNB-CU and the on board gNB-DU, via the NTN Gateway”. TS48.401: [Page 91: Figure 8.15.2.1-1]: step 8: “Target gNB-DU” -> “Target gNB-CU-CP”: “UE CONTEXT SETUP RESPONSE”; NTN Gateway would forward UE context setup response received from target gNB-DU to target cell).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine TS38.401’s teaching of inter-gNB handover procedures with that of TR38.821 in order to conform to 3GPP procedures for promotion of corroboration and inter-operation.
Regarding claim 11, claim 11 recites the method implemented by the network node of claim 26 (see rejection of claim 26 above).
Per claim 12 and 27:
Regarding claim 27, combination of TR38.821 and TS38.401 teaches the network node of claim 26 (discussed above).
TR38.821 teaches ‘establish network interfaces with the CU and with the one or more DUs’ (TR38.821: [Page 26: Figure 5.2.2-3]: “NTN Gateway” <-> “gNB-CU”: “L1”, “L2”, “F1-U”, “NTN Gateway” <-> “Satellite with on-board gNB-DU”: “SRI”, “F1-U”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites; [Page 127]: “When the connection between the new gNB-CU and the gNB-DU is established through the target NTN GW”; NTN Gateway would establish network interfaces with CU and one or more DUs).
Regarding claim 12, claim 12 recites the method implemented by the network node of claim 27 (see rejection of claim 27 above).
Regarding claim 13, combination of TR38.821 and TS38.401 teaches the method of claim 12 (discussed above).
TR38.821 teaches ‘wherein the network interfaces comprise an F1 interface’ (TR38.821: [Page 26: Figure 5.2.2-3]: “NTN Gateway” <-> “gNB-CU”: “L1”, “L2”, “F1-U”; [Page 27: Figure 5.2.2-4]: “NTN Gateway” <-> “gNB-CU”: “L1”, “L2”, “F1-C”).
Per claim 14 and 28:
Regarding claim 28, combination of TR38.821 and TS38.401 teaches the network node of claim 26 (discussed above).
Combination of TR38.821 and TS38.401 teaches ‘receive a configuration for mapping the CU to the one or more DUs’ (TR38.821: [Page 26: Figure 5.2.2-3]; [Page 27: Figure 5.2.2-4]; [Page 29]: “IP packets are transported over SRI protocols stack, at the SRI and over any L2/L1 layers at gNB-CU – NTN Gateway interface”; [Page 39]: “cell associated with the corresponding beam centers”; [Page 89: Figure 7.3-1]: “PCI mapping into satellite beams”; [Page 89]: “A satellite beam can consist of one or more SSB beams. One cell (PCI) can have maximum of L SSB beams”; [Page 15: Figure 4.1-2]: “Gateway” with two feeder links to two satellites. TS38.401: [Page 52: Figure 8.5-1]: “F1 startup and cell activation”, step 0: “gNB-CU” <-> “gNB-DU”: “Pre-operational state”, step 3: “gNB-CU” -> “gNB-DU”: “F1 SETUP RESPONSE”, step 4: “gNB-CU” -> “gNB-DU”: “gNB-CU CONFIGURATION UPDATE”; [Page 52]: “The gNB-DU and its cells are configured by OAM in the F1 pre-operational state”; NTN Gateway would receive configuration for mapping of the CU to one or more DUs).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine TS38.401’s teaching of F1 startup with that of TS38.401 for NTN Gateway to receive configuration for mapping of the CU to one or more DUs in order to conform to 3GPP procedures for promotion of corroboration and inter-operation.
Regarding claim 14, claim 14 recites the method implemented by the network node of claim 28 (see rejection of claim 28 above).
Per claim 15 and 29:
Regarding claim 29, combination of TR38.821 and TS38.401 teaches the network node of claim 26 (discussed above).
TR38.821 teaches ‘based at least in part on a connection availability between the network node and a DU of the one or more DUs, one or more of: establish a connection with the DU’ (TS38.821: [Page 26: Figure 5.2.2-2]: “NTN Gateway” <-> “Satellite with on-board gNB-DU”: “SRI”, “F1-U”; [Page 127]: “When the connection between the new gNB-CU and the gNB-DU is established through the target NTN GW”; [Page 129]: “the satellite moves into a coverage of a new gNB-CU. The satellite/gNB-DU need to setup the new F1 with the new gNB-CU”); ‘release the connection with the DU; suspend the connection with the DU; or resume the connection with the DU’ (these are optional).
Regarding claim 15, claim 15 recites the method implemented by the network node of claim 29 (see rejection of claim 29 above).
Per claim 16 and 30:
Regarding claim 30, combination of TR38.821 and TS38.401 teaches the network node of claim 29 (discussed above).
TR38.821 teaches ‘wherein the connection availability between the network node and the DU is based at least in part on movement of the DU’ (TS38.821: [Page 26: Figure 5.2.2-2]: “NTN Gateway” <-> “Satellite with on-board gNB-DU”: “SRI”; [Page 115]: “the UE mobility (hand-over) is due to the change of the interface, for example, when the satellite moves out of the coverage of current radio network node on the ground”; [Page 26: Figure 5.2.2-3]: “Satellite with on-board gNB-DU”; [Page 129]: “the satellite moves into a coverage of a new gNB-CU. The satellite/gNB-DU need to setup the new F1 with the new gNB-CU”).
Regarding claim 16, claim 16 recites the method implemented by the network node of claim 30 (see rejection of claim 30 above).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20250080214 A1 see [FIG.14], [0137]-[0147];
US 20220078733 A1 see [0087]-[0090];
US 20240031984 A1 see [FIG.4], [FIG.6A], [FIG.7A], [0192], [0265];
US 20220046501 A1 see [FIG.3], [FIG.12]-[FIG.13], [FIG.19], [0008];
US 20220141891 A1 see [FIG.5], [FIG.10], [0002]-[0017];
US 20210314060 A1 see [FIG.1], [FIG.2C], [FIG.5]-[FIG.7], [0033]-[0046].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GUOXING FAN whose telephone number is (703)756-1310. The examiner can normally be reached Monday - Friday 8:30am - 5:30pm.
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, Yemane Mesfin can be reached at (571)272-3927. 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.
/G.F./Examiner, Art Unit 2462
/YEMANE MESFIN/Supervisory Patent Examiner, Art Unit 2462