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 .
Response to Arguments
Applicant’s arguments, see Appeal Brief, filed July 14, 2025, with respect to the rejection(s) of claim(s) 1,4, 6, 7, 9, 12 and 14-15 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn, in view of pre-appeal conference held on July 22, 2025 with Gary Mui and Ian Moore. However, upon further consideration, a new ground(s) of rejection is made in view of Huawei (QoS Management of IAB nodes, R2-1810692, 2 - 6 July, 2018) and 3GPP (Study on integrated Access and Backhaul, 3GPP TR 38.874 V0.3.2 (2018-06)).
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 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.
Claims 1, 4, 6-7, 9, 12, 14-15, and 18-21 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 pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 has been amended to recites, " ... adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information”. Neither the claim nor the specification further describe, “… adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information”. Paragraph 0230 of instant application disclose, “Some fields may be included in the common header of the ADAP layer entity, and some fields may be included in the dedicated header of the ADAP layer entity. For example, the ADAP layer entity may concatenate data by including the QoS information in the common header and including the UE-specific ID or the UE-bearer-specific ID in the dedicated header. Also, the ADAP layer entity may concatenate data by including the QoS information and the radio node address or the route ID in the common header….” The claims and the specification of the instant application does not describe the method/step, “... adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information.” Therefore claim 1 is rejected under 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement
The subject matter was not described in the specification (see paragraph 0230) in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and /or use the invention.
Claim 9 is also rejected for the same reason as set forth above for claim 1.
Claims 4, 6, 7, 12, 14-15, and 18-21 are also rejected since they are dependent on the rejected independent claims 1 and 9, respectfully, as set forth above.
Claims 1, 4, 6-7, 9, 12, 14-15, and 18-21 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 pre-AIA the applicant regards as the invention.
Claim 1 recite in line 3, “establishing a signaling radio bearer (SRB)” - (step A), in lines 4-7, “ … adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information” – (step B), in lines 8-9, “mapping, by the backhaul ADAP layer entity, an RLC channel to the group of data, transmitting the group of data to a second IAB node based on the mapped RLC channel”, (step C) and in lines 10-11, “wherein the SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity”. In view of step C, mapping, by the backhaul ADAP layer entity … and
transmitting the group of data to a second IAB node based on the mapped RLC channel, it is unclear whether the “wherein the SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity”, since clearly the mapping is done by the “backhaul ADAP layer entity” and transmitted (by ADAP layer) the group of data to a second IAB node. Thus the claim is indefinite.
It is unclear the relationship between “establishing a signaling radio bearer (SRB)” and the remaining steps of the claims. It is also unclear whether “establishing a signaling radio bearer (SRB)” is via/interface “the backhaul ADAP layer entity” or the relationship to/with “a second IAB node”.
It is unclear whether /how transmitting the group of data to a second IAB node is done? Is the transmitting being done using the established “signaling radio bearer”? How does the “backhaul adaptation (ADAP) layer entity” interface the “signaling radio bearer”, when the last limitation recites, “wherein the SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity”?
Claim 9 is also rejected for the same reason as set forth above for claim 1.
Claims 4, 6, 7, 12, 14-15, and 18-21 are also rejected since they are dependent on the rejected independent claims 1 and 9, respectfully, as set forth above.
For purpose of examination, the examiner interprets the limitation as best understood.
Notice re prior art available under both pre-AIA and AIA
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 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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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.
Claims 1, 6-7, 9 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over CATT (CATT: "Control Plane Considerations for L2 IAB Architectures"; 3GPP DRAFT, R2-1809819; Montreal, Canada; 22 June 2018 (2018-06-22)), in view Teyeb (US Pub. No.: 2021/0274381, us prov. 62688231, 20180621) and further in view Huawei (QoS Management of IAB nodes, R2-1810692, 2 - 6 July, 2018).
As per claim 1, CATT disclose A method of a first integrated access backhaul (IAB) node in a wireless communication system (see Fig. 8.3.4.1, processing method in access IAB node), the method comprising:
establishing a signaling radio bearer (SRB) (see Fig. 8.3.4.1, section 2, UE's RRC is carried over UE's SRB /established/establishing);
establishing a backhaul adaptation (ADAP) layer entity as an upper layer entity of a radio link control (RLC) entity (see Fig. 8.3.4.1, section 2, the UEs RRC is treated like normal data to be carried an RLC channel with adaption layer in access IAB's access link, see Fig. 8.3.4-3, page 5, on the wireless backhaul links, the PDCP of the Fl -AP's SRB is carried over RLC-channels with adaptation layer. The adaptation layer placement in the RLC channel is the same for C-plane as for U- plane. The information carried on the adaptation layer is different for SRB than for DRB);
mapping, by the backhaul ADAP entity, an RLC channel to a group of data (see Fig. 8.3.4.1, section 2, the RLC channel have higher priority than DRB 's related channels to guarantee signaling prioritized transmission, see Fig. 8.3.4.1, section 2, the RLC channel have higher priority than DRB 's related channels to guarantee signaling prioritized transmission, the UE's and the MT's RRC are carried over SRB, on the UE's or MT's access link, the SRB uses an RLC-channel, clearly the group of data is mapped and carried over the SRB, also, in access lAB node, for Alt I and Alt 3, UE's RRC is treated like normal data is carried an RLC channel with adaption layer in access IAB's access link. This RLC channel may have higher priority than DRBs related channels to guarantee signaling prioritized transmission. For Alt 2, UEs RRC is encapsulated into a DU"s Fl-AP message of its access node, is aligned with current F1 interface procedure, clearly a group of data are mapped since, On the wireless backhaul. the SRB 's PDCP layer is carried over RLC-channels with adaptation layer. The adaptation layer placemat in the RLC channel is the same for C-p1ane as for U-plane. The information carried on the adaptation layer may be different for SRB than for DRB); and
transmitting the group of data to a second IAB node based on the mapped RLC channel (see Fig. 8.3.4.1, section 2, on the UEs access link, the SRB uses the RLS channel to transmit data to a second IAB node),
wherein the SRB is directly connected to a packet data convergence protocol (PDCP) entity (see Fig. 8.3.4.1, section 2, on the wireless backhaul links, the SRB's PDCP layer is carried over RLC-channels with adaptation layer, the adaptation layer placement in the RLC channel is the same for C-p1ane as for U-plane, the information carried on the adaptation layer is different for SRB than for DR).
Although CATT discloses mapping, by the backhaul ADAP layer entity, an RLC channel to the group of data;
CATT however does not explicitly disclose adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information;
Teyeb however disclose a method comprising adding, by a backhaul adaptation entity, a header to a group of data (see Fig.5e, Fig.9d, para. 0170-0171, an IP header is part of the adaptation layer or carried on top of the adaptation layer, as shown in FIG. 5e, the IAB-donor DU holds an IP routing function to extend the IP-routing plane of the fronthaul to the IP-layer carried by adapt on the wireless backhaul. This allows native F1-U to be established end-to-end, i.e. between IAB-node DUs and IAB-donor CU-UP. The scenario implies that each IAB-node holds an IP-address, which is routable from the fronthaul via the IAB-donor DU, the IAB-nodes' IP addresses is used for routing on the wireless backhaul / a header to a group of data) wherein the header includes a route identifier (ID) for routing and IAB node address information (see para. 0160-0163, Information to be carried on the adaptation layer includes, but is not limited to: UE-bearer-specific Id, UE-specific Id, Route Id, IAB-node or IAB-donor address, see also para. 0170-0174, see FIG. 5e, an IP header is part of the adaptation layer or carried on top of the adaptation layer, and as shown in Fig.5e, the IAB-donor DU holds an IP routing function {a routing identifier (ID)} to extend the IP-routing plane of the fronthaul to the IP-layer carried by adapt on the wireless backhaul. This allows native F1-U to be established end-to-end, i.e. between IAB-node DUs and IAB-donor CU-UP. The scenario implies that each IAB-node holds an IP-address { a routing identifier (ID)}, which is routable from the fronthaul via the IAB-donor DU. The IAB-nodes' IP addresses is further used for routing on the wireless backhaul / IAB node address information to a group of data, also per para. 0174, both adaptation layer placements supports aggregated routing (e.g. by inserting an IAB-node address into the adaptation header) and both adaptation layer placements support per-UE-bearer QoS for a large number of UE-bearers / including IAB node address information to a group of data. For above-RLC adaptation layer, the LCID space has to be enhanced since each UE-bearer is mapped to an independent logical channel. For above-MAC adaptation layer, UE-bearer-related info has to be carried on the adaptation header, also per para. 0175, both adaptation layer placements can support aggregated QoS handling e.g. by inserting an aggregated QoS Id into the adaptation header, see also para. 0179-0180, the GTP-U protocol over UDP over IP serves as the TNL for data streams on the F1 interface. The transport bearer is identified by the GTP-U tunnel endpoint ID (TEID) and the IP address (source TEID, destination TEID, source IP address, destination IP address). The F1-U protocol uses the services of the TNL in order to allow flow control of user data packets transferred from the node hosting NR PDCP (CU-UP in the case of CU-DU split) to the corresponding node (DU), see para. 0174, both adaptation layer placements can support aggregated routing (e.g. by inserting an IAB-node address {dedicated header} into the adaptation header {common header}) and both adaptation layer placements can support per-UE-bearer QoS for a large number of UE-bearers. For above-RLC adaptation layer, the LCID space has to be enhanced since each UE-bearer is mapped to an independent logical channel. For above-MAC adaptation layer, UE-bearer-related info has to be carried on the adaptation header).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information to including a routing identifier (ID) including IAB node address, as taught by Teyeb, in the system of CATT, so as to prevent or mitigate packet loss in Integrated Access Backhaul systems, see Teyeb, paragraphs 1-12.
Although the combination of CATT and Teyeb disclose the method of a first integrated access backhaul (IAB) node in a wireless communication system as set forth above;
The combination of CATT and Teyeb however does not explicitly disclose wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity.
Huawei however disclose wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity (see Fig. 2, section 2.3, Bearer Mappings, Solution 2.1: Per-lAB bearer mapping, As shown in the Figure 2, the intermediate IAB nodes performs IAB bearer mapping, e.g. the mapping between IAB1 RLC channel and IAB2 RLC channel based on QoS information of IAB RLC channel directly without distinguishing UEs and the mapping between IAB2 RLC channel /IAB1 RLC channel and UE DRB based on QoS information of UE DRBs, clearly directly connected to PDCP without being connected to the backhaul ADAP layer entity).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity, as taught by Huawei, in the system of CATT and Teyeb, so as to map between IAB1 RLC channel and IAB2 RLC channel based on QoS information of IAB RLC channel directly, see Huawei, page 4, Solution 2.
As per claim 6, the combination of CATT, Teyeb and Huawei disclosed the method of claim 1.
Teyeb further disclose receiving the group of data from a third IAB node via a RLC channel or from a user equipment (UE) (see Fig.9-Fig.10, para. 0167-0176, for RLC AM, ARQ is conducted hop-by-hop along access and backhaul links (FIG. 9c-e and FIG. 10). It is also possible to support ARQ end-to-end between UE and IAB-donor (FIG. 9a-b) / a third IAB node via a RLC channel or from a user equipment (UE), see also Fig.3-Fig.4, , para. 0130-0137, each IAB node 302 holds a DU 306 and an MT 308. Via the MT 308, the IAB-node connects to an upstream IAB-node or the IAB-donor 304. Via the DU 306, the IAB-node establishes RLC-channels to UEs 310 and to MTs 308 of downstream IAB-nodes 302).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of receiving the group of data from a third IAB node via a RLC channel or from a user equipment (UE), as taught by Teyeb, in the system of CATT, so as to prevent or mitigate packet loss in Integrated Access Backhaul systems, see Teyeb, paragraphs 1-12.
As per claim 7, the combination of CATT, Teyeb and Huawei disclose the method of claim 6.
Teyeb further disclose wherein the second IAB node is a parent IAB node of the first IAB node and the third IAB node is a child IAB node of the first IAB node (see Fig.9-Fig.10, para. 0167-0176, for RLC AM, ARQ can be conducted hop-by-hop along access and backhaul links (FIG. 9c-e and FIG. 10). It is also possible to support ARQ end-to-end between UE and IAB-donor (FIG. 9a-b) / the second IAB node is a parent IAB node of the first IAB node and the third IAB node is a child IAB node of the first IAB node, see also Fig.3-Fig.4, , para. 0130-0137, the IAB Donor 304 also includes a DU 312 to support UEs and MTs of downstream IAB nodes. The IAB-donor holds a CU 314 for the DUs of all IAB-nodes and for its own DU. It is FFS if different CUs can serve the DUs of the IAB-nodes. Each DU on an IAB-node connects to the CU in the IAB-donor using a modified form of F1, which is referred to as F1*. F1*-U runs over RLC channels on the wireless backhaul between the MT on the serving IAB-node and the DU on the donor).
As per claim 9, CATT disclose A first integrated access backhaul (IAB) node in a wireless communication system (see Fig. 8.3.4.1, processing method in access IAB node / first integrated access backhaul (IAB) node), the first IAB node configured to:
establish a signaling radio bearer (SRB) (see Fig. 8.3.4.1, section 2, UE's RRC is carried over UE's SRB /establish);
establish a backhaul adaptation (ADAP) entity as an upper layer entity of a radio link control (RLC) entity (see Fig. 8.3.4.1, section 2, the UEs RRC is treated like normal data to be carried an RLC channel with adaption layer in access IAB's access link);
map, by the backhaul ADAP entity, a RLC channel to a group of data (see Fig. 8.3.4.1, section 2, the RLC channel have higher priority than DRB 's related channels to guarantee signaling prioritized transmission); and
transmit the data to a second IAB node based on the mapped RLC channel (see Fig. 8.3.4.1, section 2, on the UEs access link, the SRB uses the RLS channel to transmit data to a second IAB node),
wherein the SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity (see Fig. 8.3.4.1, section 2, on the wireless backhaul links, the SRB's PDCP layer is carried over RLC-channels with adaptation layer, the adaptation layer placement in the RLC channel is the same for C-p1ane as for U-plane, the information carried on the adaptation layer is different for SRB than for DRB / a signaling radio bearer (SRB) e.g. a UE's SRB is configured for communication at a packet data convergence protocol (PDCP) but not for the backhaul adaptation entity i.e. not at the IAB node).
CATT however does not explicitly disclose add, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information.
Teyeb however disclose A first integrated access backhaul (IAB) node (see Fig.14, network nodes 1460, see para. 0250) in a wireless communication system (see Fig.14, a wireless network), the first IAB node comprising:
a communicator (see Fig.14, one or more of radio frequency (RF) transceiver circuitry 1472);
and at least one controller (see Fig.14, processing circuitry 1470) connected to the communicator (see para. 0249, processing circuitry 1470 include one or more of radio frequency (RF) transceiver circuitry 1472 and baseband processing circuitry 1474);
add, by the backhaul ADAP layer entity, a header to a group of data (see Fig.5e, Fig.9d, para. 0170-0171, an IP header is part of the adaptation layer or carried on top of the adaptation layer, as shown in FIG. 5e, the IAB-donor DU holds an IP routing function to extend the IP-routing plane of the fronthaul to the IP-layer carried by adapt on the wireless backhaul. This allows native F1-U to be established end-to-end, i.e. between IAB-node DUs and IAB-donor CU-UP. The scenario implies that each IAB-node holds an IP-address, which is routable from the fronthaul via the IAB-donor DU, the IAB-nodes' IP addresses is used for routing on the wireless backhaul / a header to the data) wherein the header includes a route identifier (ID) for routing and IAB node address information (see para. 0160-0163, Information to be carried on the adaptation layer includes, but is not limited to: UE-bearer-specific Id, UE-specific Id, Route Id, IAB-node or IAB-donor address, see also para. 0170-0174, see FIG. 5e, an IP header is part of the adaptation layer or carried on top of the adaptation layer, and as shown in Fig.5e, the IAB-donor DU holds an IP routing function {a routing identifier (ID)} to extend the IP-routing plane of the fronthaul to the IP-layer carried by adapt on the wireless backhaul. This allows native F1-U to be established end-to-end, i.e. between IAB-node DUs and IAB-donor CU-UP. The scenario implies that each IAB-node holds an IP-address { a routing identifier (ID)}, which is routable from the fronthaul via the IAB-donor DU. The IAB-nodes' IP addresses is further used for routing on the wireless backhaul / IAB node address information to a group of data, also per para. 0174, both adaptation layer placements supports aggregated routing (e.g. by inserting an IAB-node address into the adaptation header) and both adaptation layer placements support per-UE-bearer QoS for a large number of UE-bearers / including IAB node address information to a group of data. For above-RLC adaptation layer, the LCID space has to be enhanced since each UE-bearer is mapped to an independent logical channel. For above-MAC adaptation layer, UE-bearer-related info has to be carried on the adaptation header, also per para. 0175, both adaptation layer placements can support aggregated QoS handling e.g. by inserting an aggregated QoS Id into the adaptation header, see also para. 0179-0180, the GTP-U protocol over UDP over IP serves as the TNL for data streams on the F1 interface. The transport bearer is identified by the GTP-U tunnel endpoint ID (TEID) and the IP address (source TEID, destination TEID, source IP address, destination IP address). The F1-U protocol uses the services of the TNL in order to allow flow control of user data packets transferred from the node hosting NR PDCP (CU-UP in the case of CU-DU split) to the corresponding node (DU), see para. 0174, both adaptation layer placements can support aggregated routing (e.g. by inserting an IAB-node address {dedicated header} into the adaptation header {common header}) and both adaptation layer placements can support per-UE-bearer QoS for a large number of UE-bearers. For above-RLC adaptation layer, the LCID space has to be enhanced since each UE-bearer is mapped to an independent logical channel. For above-MAC adaptation layer, UE-bearer-related info has to be carried on the adaptation header).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality to add, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information, as taught by Teyeb, in the system of CATT, so as to prevent or mitigate packet loss in Integrated Access Backhaul systems, see Teyeb, paragraphs 1-12.
Although the combination of CATT and Teyeb disclose the method of a first integrated access backhaul (IAB) node in a wireless communication system as set forth above;
The combination of CATT and Teyeb however does not explicitly disclose wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity.
Huawei however disclose wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity (see Fig. 2, section 2.3, Bearer Mappings, Solution 2.1: Per-lAB bearer mapping, As shown in the Figure 2, the intermediate IAB nodes performs IAB bearer mapping, e.g. the mapping between IAB1 RLC channel and IAB2 RLC channel based on QoS information of IAB RLC channel directly without distinguishing UEs and the mapping between IAB2 RLC channel /IAB1 RLC channel and UE DRB based on QoS information of UE DRBs, clearly directly connected to PDCP without being connected to the backhaul ADAP layer entity).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity, as taught by Huawei, in the system of CATT and Teyeb, so as to map between IAB1 RLC channel and IAB2 RLC channel based on QoS information of IAB RLC channel directly, see Huawei, page 4, Solution 2.
As per claim 13, claim 13 is rejected the same way as claim 5.
As per claim 14, claim 14 is rejected the same way as claim 6.
As per claim 15, claim 15 is rejected the same way as claim 7.
Claims 4 are rejected under 35 U.S.C. 103 as being unpatentable over CATT (CATT: "Control Plane Considerations for L2 IAB Architectures"; 3GPP DRAFT, R2-1809819; Montreal, Canada; 22 June 2018 (2018-06-22), in view of Teyeb (US Pub. No.: 2021/0274381), in view Huawei (QoS Management of IAB nodes, R2-1810692, 2 - 6 July, 2018) and further in view of Zhu et al (US Pub. No.: 2019/0159277).
As per claim 4, the combination of CATT, Teyeb and Huawei disclose the method of claim 1.
The combination of CATT, Teyeb and Huawei however does not explicitly disclose further comprising performing, by the PDCP entity, at least one of ciphering, deciphering, integrity protection, or integrity verification corresponding to the established SRB.
Zhu however disclose comprising performing, by a PDCP entity, at least one of ciphering, deciphering, integrity protection, or integrity verification corresponding to the established SRB (see 0085, 0156, The PDCP layer 1504 executes header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of performing, by a PDCP entity, at least one of ciphering, deciphering, integrity protection, or integrity verification corresponding to the established SRB, as taught by Zhu, in the system of CATT, Teyeb and Huawei, so as to improve wireless connectivity solutions, see Zhu, paragraph 0004.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over CATT (CATT: "Control Plane Considerations for L2 IAB Architectures"; 3GPP DRAFT, R2-1809819; Montreal, Canada; 22 June 2018 (2018-06-22), in view of Teyeb (US Pub. No.: 2021/0274381), in view Huawei (QoS Management of IAB nodes, R2-1810692, 2 - 6 July, 2018) and further in view of Zhu et al (US Pub. No.: 2019/0159277).
As per claim 12, the combination of CATT, Teyeb and Huawei disclose the first IAB node of claim 9.
The combination of CATT, Teyeb and Huawei however does not explicitly disclose performing, by the PDCP entity, at least one of ciphering, deciphering, integrity protection, or integrity verification corresponding to the established SRB.
Zhu however disclose comprising performing, by a PDCP entity, at least one of ciphering, deciphering, integrity protection, or integrity verification corresponding to the established SRB (see 0085, 0156, The PDCP layer 1504 may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of performing, by a PDCP entity, at least one of ciphering, deciphering, integrity protection, or integrity verification corresponding to the established SRB, as taught by Zhu, in the system of CATT, Teyeb and Huawei, so as to improve wireless connectivity solutions, see Zhu, paragraph 0004.
As per claim 18, the combination of CATT, Teyeb and Huawei disclosed the first IAB node of claim 9.
Teyeb further disclose wherein the at least one controller is further configured to map, by the backhaul ADAP layer entity, the RLC channel to the group of data based on quality of service (QoS) information (see Fig.9, Fig.10, para. 0144-0145, architecture group 1 (i.e., architectures 1a and 1b) including placement of an adaptation layer, functions supported by the adaptation layer, support of multi-hop RLC, impacts on scheduler and QoS / mapping based on QoS, and para. 0149-0154, 1a, information carried on the adaptation layer supports the following functions: [0150] Identification of the UE-bearer for the PDU, [0151] Routing across the wireless backhaul topology, [0152] QoS-enforcement {this will be based on the quality of service (OoS) mapping information} by the scheduler on DL and UL on the wireless backhaul link, [0153] Mapping of UE user-plane PDUs to backhaul RLC channels / mapping, an RLC channel “based on QoS information”, see also para. 0155-0160, In architecture 1b, information carried on the adaptation layer supports the following functions: [0157] QoS-enforcement by the scheduler on DL and UL on the wireless backhaul link, and para. 0164, Information to be carried on the adaptation layer includes QoS information / data “based on quality of service (QoS) information, see also para. 0174-0175, 0210, 0225, the IAB node is configured to apply this behaviour to all UEs that it is serving, to a subset of UEs that it is serving (e.g., indicated when a UE gets connected to an IAB node), or even only to certain bearers of a particular UE or a particular QoS requirement (e.g., as part of the UE bearer setup and the corresponding RLC entity setup for that bearer at the IAB node), an RLC channel corresponding to the group of data “based on quality of service (QoS) information).
As per claim 20, claim 20 is rejected the same way as claim 18.
Claims 19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over CATT (CATT: "Control Plane Considerations for L2 IAB Architectures"; 3GPP DRAFT, R2-1809819; Montreal, Canada; 22 June 2018 (2018-06-22)), in view of Teyeb (US Pub. No.: 2021/0274381) in view Huawei (QoS Management of IAB nodes, R2-1810692, 2 - 6 July, 2018) and further in view of Li (WO 2019233465A1).
As per claim 19, the combination of CATT, Teyeb and Huawei disclosed the first IAB node of claim 9.
The combination of CATT, Teyeb and Huawei however does not explicitly disclosed wherein the header is divided into a common header and a dedicated header, where the common header is for data concatenated in the backhaul ADAP layer entity, and the dedicated header includes header specific fields.
Li however disclose wherein a header is divided into a common header and a dedicated header, where the common header is for data concatenated in the backhaul ADAP layer entity, and the dedicated header includes header specific fields (see Fig.8, pages 21-22, the downlink data sent by DgNB carries two types of information: one is path information, such as the path identifier or destination node identifier (RN2). The role of the path information is Data can be sent to RN2 {a dedicated header including one or more header specific fields / a header including a routing identifier (ID) including IAB node address information to a group of data}; the other is the DRB identification of the terminal device, such as the ID of the terminal device and the ID of the DRB of the terminal device {a common header including one or more concatenated data fields}. The ID of the DRB of the terminal device is used by RN2 to send the data through the DRB of the appropriate terminal device Send to the corresponding terminal device. The above two types of information are carried in the Adaptation Layer PDU, such as the header of the PDU, Also, the terminal device completes the QoS management and puts QoS Flow into the DRB of the terminal device according to the configured QoS mapping criteria / an RLC channel to the group of data based on “quality of service (QoS) information, see also pages 16-17 Fig. 6 and Fig.7).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of wherein a header is divided into a common header and a dedicated header, where the common header is for data concatenated in the backhaul ADAP layer entity, and the dedicated header includes header specific fields, as taught by Li, in the system of CATT, Teyeb and Huawei, so as to reduce signaling overhead and complexity of path selection, see Li, page 2.
As per claim 21, claim 21 is rejected the same way as claim 19.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Second Rejection:
Claims 1 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over CATT (CATT: "Control Plane Considerations for L2 IAB Architectures"; 3GPP DRAFT, R2-1809819; Montreal, Canada; 22 June 2018 (2018-06-22)), in view 3GPP (Study on integrated Access and Backhaul, 3GPP TR 38.874 V0.3.2 (2018-06)).
As per claim 1, CATT disclose A method of a first integrated access backhaul (IAB) node in a wireless communication system (see Fig. 8.3.4.1, processing method in access IAB node), the method comprising:
establishing a signaling radio bearer (SRB) (see Fig. 8.3.4.1, section 2, UE's RRC is carried over UE's SRB /established/establishing);
establishing a backhaul adaptation (ADAP) layer entity as an upper layer entity of a radio link control (RLC) entity (see Fig. 8.3.4.1, section 2, the UEs RRC is treated like normal data to be carried an RLC channel with adaption layer in access IAB's access link, see Fig. 8.3.4-3, page 5, on the wireless backhaul links, the PDCP of the Fl -AP's SRB is carried over RLC-channels with adaptation layer. The adaptation layer placement in the RLC channel is the same for C-plane as for U¬ plane. The information carried on the adaptation layer is different for SRB than for DRB);
mapping, by the backhaul ADAP entity, an RLC channel to a group of data (see Fig. 8.3.4.1, section 2, the RLC channel have higher priority than DRB 's related channels to guarantee signaling prioritized transmission, see Fig. 8.3.4.1, section 2, the RLC channel have higher priority than DRB 's related channels to guarantee signaling prioritized transmission, the UE's and the MT's RRC are carried over SRB, on the UE's or MT's access link, the SRB uses an RLC-channel, clearly the group of data is mapped and carried over the SRB, also, in access lAB node, for Alt I and Alt 3, UE's RRC is treated like normal data is carried an RLC channel with adaption layer in access IAB's access link. This RLC channel may have higher priority than DRBs related channels to guarantee signaling prioritized transmission. For Alt 2, UEs RRC is encapsulated into a DU"s Fl-AP message of its access node, is aligned with current F1 interface procedure, clearly a group of data are mapped since, On the wireless backhaul. the SRB 's PDCP layer is carried over RLC-channels with adaptation layer. The adaptation layer placemat in the RLC channel is the same for C-p1ane as for U-plane. The information carried on the adaptation layer may be different for SRB than for DRB); and
transmitting the group of data to a second IAB node based on the mapped RLC channel (see Fig. 8.3.4.1, section 2, on the UEs access link, the SRB uses the RLS channel to transmit data to a second IAB node),
wherein the SRB is directly connected to a packet data convergence protocol (PDCP) entity (see Fig. 8.3.4.1, section 2, on the wireless backhaul links, the SRB's PDCP layer is carried over RLC-channels with adaptation layer, the adaptation layer placement in the RLC channel is the same for C-p1ane as for U-plane, the information carried on the adaptation layer is different for SRB than for DR).
Although CATT discloses mapping, by the backhaul ADAP layer entity, an RLC channel to the group of data;
CATT however does not explicitly disclose adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information; and wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity;
3GPP however disclose adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information (see Fig. 8.2.2-2, pages 21-22, Content added and carried on the adaptation layer header, includes - UE-bearer-specific ld
- UE-specific Id, - Roule ld, IAB-node and IAB-donor address), and wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity (see Fig. 8.3.5-1, page 29-30, Figure 8.3.5 - 1 shows protocol stacks for UE's RRC, MT's RRC and DU's Fl-AP for architecture lb. In these examples, the adaptation layer carrying the DRB's PDCP resides on top of RLC. On the IAB-node's access link, the adaptation layer
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to provide the functionality of adding, by the backhaul ADAP layer entity, a header to a group of data, wherein the header includes a route identifier (ID) for routing and IAB node address information; and wherein a SRB is directly connected to a packet data convergence protocol (PDCP) entity without being connected to the backhaul ADAP layer entity, as taught by 3GPP, in the system of CATT, so as to support architecture 1b, so that when the UE's or MT's RRC is carried over SR.B. On the wireless backhaul, this SRB's PDCP is carried over native F1-C, see 3GPP, page 30 lines 1-6.
As per claim 9, claim 9 is rejected the same way as claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hampel (US Pub. No.:2017/0006499) – see para. 0046, “The IAB network 226 may be addressed by a network address prefix (e.g., Prefix A), which it advertises to the main backhaul network 204. To route packets to/from the UE 220, the IAB node 216 utilizes a tunnel endpoint address, which includes the network address prefix. For example, the tunnel endpoint address for the UE 220 may be “A6.” Downstream packets for the UE 220 would then carry “A6” as the destination address in the packet header when traveling via the tunnel 224 through the main backhaul network 204 and the IAB network 226. Upon receiving the downstream packets, the IAB 216 may remove the tunnel header and deliver the packets to the UE 220 over the wireless link”.
ZHU (US Pub. No.:2019/0159277) – see para. 0052, “As shown by FIG. 6, the adaptation layer (e.g., MHRP) is placed on top of RLC. On the IAB-node's access link, the adaptation layer may or may not be included. In the embodiment depicted by FIG. 6, the UE's and the MT's (e.g., RN (DU)) RRC are carried over SRB. On the UE's and/or the MT's (e.g., RN (DU)) access link, the SRB uses an RLC channel. On the wireless backhaul links, the SRB's PDCP layer is carried over RLC channels with the adaptation layer. The adaptation layer placement in the RLC channel is the same for the control plane as for the user plane. The information carried on the adaptation layer may be different for SRBs than for DRBs. The DU's (e.g., dgNB DU) F1-AP is encapsulated in the RRC of a collocated MT. This allows the F1-AP to be protected by the PDCP of the underlying SRB. Within the IAB-donor (e.g., dgNB CU), the baseline is to use native F1-C stack. Moreover, various control plane functions are supported such as reliable transport via RLC over the wireless backhaul, in-order delivery via PDCP, security via PDCP”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAKERAM JANGBAHADUR whose telephone number is (571)272-1335. The examiner can normally be reached M-F 7 am - 4 pm.
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, Ian Moore can be reached at 571-272-3085. 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.
/LAKERAM JANGBAHADUR/Primary Examiner, Art Unit 2469