Apparatus of a first iab node in a network, iab nodes in a network and method of operating a first iab node in a network

Abstract

The present disclosure relates to managing control plane latency for integrated access and backhaul. Systems and methods are described that reduce control plane latency in 5G IAB networks. An SR transmitted between nodes indicates that a control plane PDU is to be transmitted. The SR uses periodic resources or OCCs reserved for control plane signaling and is initiated by an RRC message or RACH from a UE. The SR is initiated if a LCID field in a MAC subheader of the RRC message indicates a CCCH logical channel or a DCCH logical channel. If the PDU is available after the original resources, resources provided via another grant are used, which are provided periodically or initiated automatically due to a failure to transmit on the original grant. The SR or RRC message can also specify a latency slot for the grant. For a contention-based procedure, a RACH preamble is randomly selected or selected from a set of RACH preambles allocated for RRC procedures.

Description

[0001] This application is a divisional application of the application patent application entitled "Managing Control Plane Latency for Integrated Access and Backhaul" having application number 201980060986.2 and filing date September 25, 2019.

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 736,761, filed September 26, 2018, which is incorporated by reference herein in its entirety. TECHNICAL FIELD

[0003] Embodiments relate to radio access networks (RANs). Some embodiments relate to cellular networks, including Third Generation Partnership Project (3GPP) Long Term Evolution (LTE), 4th Generation (4G), and 5th Generation (5G) New Radio (NR) (or Next Generation (NG)) networks. Some embodiments relate to Integrated Access Backhaul (IAB) nodes in 5G systems. BACKGROUND

[0004] The use of various types of systems has increased due to an increase in both the number and types of user equipment (UEs) using network resources and the amount of data and bandwidth used by various applications operating on these UEs, such as video streaming. Bandwidth, latency, and data rate improvements can free up the ever-increasing demand for network resources. The next generation of wireless communication systems, 5G or NR, will provide ubiquitous connectivity and access to information by various users and applications, as well as the ability to share data. NR is expected to be a unified framework designed to meet vastly different performance criteria and services that are sometimes mutually contradictory. Generally, NR will evolve based on 3GPP LTE-Advanced technology and additional enhanced Radio Access Technologies (RATs) to enable seamless wireless connectivity solutions. However, using complex IAB networks and IAB nodes can encounter lower performance levels than non-IAB networks. These reduced performance levels can be attributed to, for example, hop patterns used in IAB networks. SUMMARY

[0005] According to an aspect of the disclosure, an apparatus of a first integrated access backhaul, IAB, node in a network is provided, the apparatus comprising: a memory device; and a processing circuit coupled to the memory device, the processing circuit configured to: determine that a first indication has been received from a second IAB node, wherein the second IAB node has fewer hops to a user equipment, UE, than the first IAB node, wherein the first indication indicates a request associated with uplink data for transmission; and based at least in part on receiving the first indication, encode a second indication for transmission to a parent IAB node, wherein the parent IAB node has more hops to the UE than the first IAB node and the second IAB node, wherein the second indication provides prediction information about data expected to arrive at the first IAB node.

[0006] According to another aspect of the disclosure, a first integrated access backhaul, IAB, node in a network is provided, the first IAB comprising: a non-transitory computer readable storage medium; and a processing circuit configured to: determine that a first indication has been received from a second IAB node, wherein the second IAB node has fewer hops to a user equipment, UE, than the first IAB node, the first indication indicating that uplink data is to be transmitted; and in response to receiving the first indication, encode a second indication for transmission to a parent IAB node, wherein the parent IAB node has more hops to the UE than the first IAB node and the second IAB node, wherein the second indication provides prediction information about data expected to arrive at the first IAB node, and wherein the non-transitory computer readable storage medium is configured to store the first indication.

[0007] According to yet another aspect of the disclosure, a method for operating a first integrated access backhaul, IAB, node in a network is provided, the method comprising: decoding, based at least in part on reception from a second IAB node, a first indication for indicating an amount of uplink data for transmission; and encoding, based on the first indication, a second indication for indicating prediction information about data expected to arrive at the first IAB node. BRIEF DESCRIPTION OF DRAWINGS

[0008] In the drawings, which are not necessarily drawn to scale, like numerals can describe similar components in different views. Like numerals having different letter suffixes can represent different instances of similar components. The drawings illustrate generally, by way of example, various aspects described herein in the figures.

[0009] Figure 1 A combined communication system is shown in accordance with some embodiments.

[0010] Figure 2 A block diagram illustrating a communication device, in accordance with some embodiments, is shown.

[0011] Figure 3 An example of an IAB network in which a UE is in standalone mode, in accordance with some embodiments, is shown.

[0012] Figure 4 An example of a user plane protocol architecture for a multi-hop IAB network, in accordance with some embodiments, is shown.

[0013] Figure 5 An example of multi-hop transmission, in accordance with some embodiments, is shown.

[0014] Figure 6 An example of multi-hop transmission with pre-allocation, in accordance with some embodiments, is shown.

[0015] Figure 7 An example of random access channel (RACH) handling for multi-hop IAB network transmission, in accordance with some embodiments, is shown.

[0016] Figure 8 An example of multi-hop transmission using contention-based physical uplink shared channel (CB-PUSCH), in accordance with some embodiments, is shown.

[0017] Figure 9 An example of exemplary multi-hop transmission using CB-PUSCH and activation, in accordance with some embodiments, is shown. DETAILED DESCRIPTION

[0018] The following description and drawings are illustrative of the specific aspects and are not intended to be limiting. Other aspects can incorporate structural, logical, electrical, process, and other changes. Portions and features of some aspects can be included in, or substituted for, those of other aspects, or they can be excluded from other aspects. Aspects set forth in the claims are intended to encompass all use equivalents of the claims. Various aspects can comprise different steps or techniques.

[0019] Figure 1 A combined communication system, in accordance with some embodiments, is shown. The system 100 includes 3GPP LTE / 4G and NG network functions. The network functions can be implemented as discrete network elements on dedicated hardware, as software instances running on dedicated hardware, or as virtualized functions instantiated on an appropriate platform (e.g., dedicated hardware or cloud infrastructure).

[0020] The evolved packet core (EPC) of LTE / 4G networks contains protocols and reference points defined for each entity. These core network (CN) entities can include a mobility management entity (MME) 122, a serving gateway (S-GW) 124, and a paging gateway (P-GW) 126.

[0021] In NG networks, the control plane and the user plane can be separated, which can allow independent scaling and allocation of resources for each plane. The UE 102 can connect to an access network or a random access network (RAN) 110 and / or can connect to an NG-RAN 130 (gNB) or an access and mobility function (AMF) 142. The RAN 110 can be an eNB or a general non-3GPP access point, such as an eNB or a general non-3GPP access point for Wi-Fi. The NG core network can contain multiple network functions in addition to the AMF 112. The UE 102 can generate, encode, and possibly encrypt uplink transmissions to the RAN 110 and / or the gNB 130, and decode (and decrypt) downlink transmissions from the RAN 110 and / or the gNB 130 (with the RAN 110 / gNB 130 case being reversed).

[0022] The network functions can include a user plane function (UPF) 146, a session management function (SMF) 144, a policy control function (PCF) 132, an application function (AF) 148, an authentication server function (AUSF) 152, and a user data management (UDM) 128. The various elements are connected by Figure 1 The NG reference points shown are connected.

[0023] The AMF 142 can provide UE-based authentication, authorization, mobility management, etc. The AMF 142 can be independent of the access technology. The SMF 144 can be responsible for session management and IP address allocation for the UE 102. The SMF 144 can also select and control the UPF 146 for data transmission. The SMF 144 can be associated with a single session of the UE 102 or multiple sessions of the UE 102. That is, the UE 102 can have multiple 5G sessions. Different SMFs can be assigned to each session. Using different SMFs can allow each session to be managed separately. Thus, the functions of each session can be independent of each other. The UPF 126 can be connected with a data network, and the UE 102 can communicate with the data network, the UE 102 transmitting uplink data to the data network or receiving downlink data from the data network.

[0024] AF 148 can provide information about packet flows to PCF 132, which is responsible for policy control to support desired QoS. PCF 132 can set mobility and session management policies for UE 102. To do so, PCF 132 can use the packet flow information to determine appropriate policies for correct operation of AMF 142 and SMF 144. AUSF 152 can store data for UE authentication. UDM 128 can similarly store UE subscription data.

[0025] The gNBs 130 can be standalone gNBs or non-standalone gNBs, for example, operating in a dual connectivity (DC) mode as a booster controlled by eNB 110 over an X2 or Xn interface. At least some of the functions of the EPC and the NG CN can be shared (or, separate components can be used for each of the combined components shown). The eNB 110 can connect with the MME 122 of the EPC over an S1 interface and with the SGW 124 of the EPC 120 over an S1-U interface. The MME 122 can connect with the HSS 128 over an S6a interface, while the UDM connects to the AMF 142 over an N8 interface. The SGW 124 can connect with the PGW 126 over an S5 interface (with a control plane PGW-C over S5-C and a user plane PGW-U over S5-U). The PGW 126 can serve as an IP anchor for data over the Internet.

[0026] The NG CN as described above can include, among other things, AMF 142, SMF 144, and UPF 146. The eNB 110 and gNB 130 can communicate data with the SGW 124 of the EPC 120 and the UPF 146 of the NG CN. If an N26 interface is supported by the EPC 120, the MME 122 and the AMF 142 can connect via the N26 interface to provide control information between the MME 122 and the AMF 142. In some embodiments, when the gNB 130 is a standalone gNB, the 5G CN and the EPC 120 can connect via the N26 interface.

[0027] Figure 2 A block diagram of a communication device in accordance with some embodiments is shown. In some embodiments, the communication device can be a UE (including IoT devices and NB-IoT devices), an eNB, a gNB, or other equipment used in a network environment. For example, the communication device 200 can be a special-purpose computer, a personal or laptop computer (PC), a tablet, a mobile phone, a smart phone, a network router, switch, or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. In some embodiments, the communication device 200 can be embedded in other non-communication-based devices such as vehicles and appliances.

[0028] Examples, as described herein, can include, or can operate on, logic or a number of components, modules, or mechanisms. Modules and components are tangible entities (e.g., hardware) capable of performing specified operations and can be configured or arranged in a certain manner. In an example, circuits can be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors can be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside on a machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

[0029] Accordingly, the term“module” (and“component”) is intended to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor can be configured as respective different modules at different times. Software can accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

[0030] The computing device 200 can include a hardware processor 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204 and a static memory 206, some or all of which can communicate with one another via an interlink (e.g., bus) 208. The main memory 204 can contain any of, or all of, a removable storage device and a non-removable storage device, volatile memory or non-volatile memory. The computing device 200 can also include a display unit 210 (such as a video display), an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In one example, the display unit 210, input device 212 and UI navigation device 214 are a touch screen display. The computing device 200 can additionally include a storage device (e.g., drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors 221, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The computing device 200 can further include an output controller, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

[0031] The storage device 216 can include a non-transitory machine-readable medium 222 (hereinafter simply referred to as machine-readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 224 can also reside, successfully or at least partially, within the main memory 204, static memory 206, and / or hardware processor 202 during execution thereof by the computing device 200. While the machine-readable medium 222 is illustrated as single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store the one or more instructions 224.

[0032] The term "machine-readable medium" can include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 200 and that cause the communication device 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine-readable medium examples can include solid-state memories, and optical and magnetic media. Specific examples of machine-readable media can include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks.

[0033] The instructions 224 can further be transmitted or received using a transmission medium 226 via the network interface device 220 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks can include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks. Communications over the networks can include one or more different protocols, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi, IEEE 802.16 family of standards known as WiMax, IEEE 802.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, a peer-to-peer (P2P) network, an NG / NR standard, etc. In an example, the network interface device 220 can include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the transmission medium 226.

[0034] The communication device 200 can be an IoT device (also referred to as a "machine type communication device" or "MTC device"), a narrowband IoT (NB-IoT) device, or a non-IoT device (e.g., a smartphone, a vehicle UE), any of which can communicate via a cellular or cellular-like communications network, a Bluetooth® network, a Zigbee® network, a Wi-Fi® network, a peer-to-peer (P2P) network, an NG / NR network, etc. Figure 1The illustrated eNB or gNB communicates with a core network. The communication device 200 can be a standalone or semi-standalone device that communicates with other communication devices and a wider network (e.g., the Internet) to perform functions such as sensing or control. If the communication device 200 is an IoT device, in some embodiments, the communication device 200 can be constrained with respect to memory, size, or functionality, thereby allowing a larger number of devices to be deployed at a similar cost as a smaller number of larger devices. In some embodiments, the communication device 200 can be a virtual device, such as an application on a smartphone or other computing device.

[0035] As described above, 5G systems can support multiple IAB networks and nodes. Due to the increase in bandwidth associated with NR compared to LTE (e.g., use of millimeter wave spectrum), as well as use of massive MIMO and multi-beam systems, IAB networks were developed. In IAB networks, the operation of links between different IAB nodes of the IAB network can be on the same frequency or different frequencies.

[0036] Figure 3 An example of an IAB network is shown, in which a UE is in standalone mode, in accordance with some embodiments. The network 300 includes a core network 302, an IAB donor 304, and multiple IAB nodes 306. Each IAB node 306 can be a RAN node that supports wireless access to UEs 308 and other IAB nodes as well as backhauling of access traffic. Backhauling can be a part of a network responsible for transporting communication data between a baseband unit (BBU) and a core network (CN) and connecting smaller, remote networks with the CN. Note that, as used herein, a downstream IAB node is further away from the IAB donor node by a larger number of hops than an upstream (or parent) IAB node. However, as shown, the IAB nodes 306 can lack full-function base station (gNB) capabilities. The IAB network 300 can utilize the central unit-distributed unit (CU-DU) split architecture that exists in 5G architecture. The IAB donor node 304 can include both one or more CU control plane (CP) 304a and one or more DUs 304c, as well as provide other functions 304b. RRC functionality can exist in the CU-CP 304a of the IAB donor node 304, while each IAB node 306 functions as a DU. The IAB nodes 306 can be controlled by the IAB donor 304 in a similar manner to a CU controlling a DU. Specifically, the Fl control plane protocol between the CU and the DU can be modified to support transmission over multiple hops; the modified Fl protocol enables the IAB donor 304 to control the IAB nodes 306.

[0037] One consequence of the centralized placement of RRC functionality (i.e., in the CU of the donor IAB node) is that RRC messages from the UE can be routed via multiple hops. If the UE is operating in standalone mode, RRC messages can also be transmitted via multiple hops. Figure 4 An example of a protocol architecture for a multi-hop IAB network is shown, according to some implementation schemes. Figure 4 Various protocol layers are shown, including Service Data Adaptive Protocol (SDAP), Packet Data Convergence Protocol (PDCP), IP Security (IPSec), and User Plane GPRS Tunneling Protocol (GTP-U). For example... Figure 4 As shown, each IAB node 404a, 404b operates as a combination of a DU and a mobile terminal (MT). The DU serves the next hop and ultimately the UE 402. The MT provides connectivity to a parent node, which can be the IAB donor node 406. The MT of IAB nodes 404a, 404b embodies the UE functionality used to enable connectivity to the parent node. Figure 4 The multi-hop RRC messages illustrated can introduce latency and air interface latency associated with standard UE operation at each node. This latency can impact critical functionality. For example, transmitting a measurement report from UE 402 to IAB donor 404b can take significantly longer, resulting in a higher proportion of handover failures and radio link failures. RRC connection establishment, re-establishment, and RRC connection recovery can also take longer, leading to significantly lower performance compared to non-IAB networks. It is desirable to minimize such additional latency caused by multi-hop transmission of RRC messages, and in other implementations, to minimize such additional latency for other protocols such as PDCP.

[0038] Figure 5 An exemplary multi-hop transport according to some implementation schemes is shown. As described above, RRC signaling may start from UE 502 and traverse multiple IAB nodes 504a, 504b, 504c before reaching IAB donor node 506. Figure 5 An example of the RRC protocol architecture is shown, assuming UE502 is in standalone mode. RRC messages from UE502 traverse multiple hops, as illustrated. Message transmission can cause delays at each IAB node 504a, 504b, and 504c. As mentioned above, each IAB node 504a, 504b, and 504c can contain a DU and a MT. Note that UL authorization can provide resources based on a Buffer Status Report (BSR), which indicates how much data is stored in the UE for transmission to the IAB donor node. The BSR can be included in the SR or can be a separate transmission. BSRs can be initiated under various conditions and can be referred to as regular BSRs, padding BSRs, or periodic BSRs.

[0039] Considering the RRC connection establishment scenario, such as Figure 5 As shown. UE 502 can transmit an RRC setup request message to the DU of IAB node 3504c. The DU of IAB node 3 can receive a Radio Link Control (RLC) Packet Data Unit (PDU) containing the RRC setup request and (after an appropriate routing decision) submit the RRC setup request to its MT RLC entity for transmission. The MT of IAB node 3 can treat the incoming RLC PDU as an uplink data arrival event. If no resources are available for uplink transmission, UE 502 can request uplink resources. If configured, this request can be a scheduling request; otherwise, a RACH request can be used. Resources can then be allocated for uplink transmission. Considering that most services typically reside downstream, it is likely that uplink data is not present in the MT's buffer at a given time. In this case, the MT may not have requested uplink resources, and it is also possible that uplink resources have already been allocated for the transmission of the RLC PDU.

[0040] The MT of IAB node 3 504c can transmit the RLC PDU to the DU of IAB node 2 504b. IAB node 2 506c can repeat the same action as IAB node 3 504c, including the MT of IAB node 2 504b transmitting the RLC PDU to the DU of IAB node 1 504a. Similarly, IAB node 1 506a can repeat the same action as IAB node 3 504c and IAB node 2 504b, including the MT of IAB node 1 504a transmitting the RLC PDU to the DU of IAB donor 506. The DU of IAB donor 506 can then deliver the RLC PDU to the CU of IAB donor 506. Therefore, each hop adds an additional delay. The actual value of this additional delay may depend on the configuration at each link.

[0041] Figure 6 An example of utilizing pre-allocated multi-hop transport is shown according to some implementation schemes. Similar to... Figure 5 ,exist Figure 6 In this context, RRC signaling can start from UE 602 and traverse multiple (intermediate or relay) IAB nodes 604a, 604b, and 604c before reaching the IAB donor node 606. However, in Figure 6 In this context, Special Scheduling Request (SR) resources can be allocated to each IAB node 604a, 604b, and 604c by its serving parent node. Continuous control plane SRs can be used to allocate resources predictively for uplink transmissions on multiple links.

[0042] IAB node 3 604c can receive a control plane PDU from UE 602 (e.g., an RRC message transmitted using uplink resources allocated in a random access response (RAR)). IAB node 3 604c can then indicate to the MT of IAB node 3 604c that a control plane PDU was received. In response, the MT can trigger transmission of the control plane SR to IAB node 2 604b using previously configured control plane SR resources (indicated by SR* in FIG. 6B). Figure 6

[0043] In response to the control plane SR, the DU of IAB node 2 604b can allocate resources (an UL grant) to the MT of IAB node 3 604c for transmission of the control plane PDU. The DU can indicate to the MT of IAB node 2 604b of the expected arrival of the control plane PDU. In response, the MT of IAB node 2 604b can trigger transmission of the control plane SR to IAB node 1 604a using previously configured control plane SR resources. In some embodiments (as in other embodiments described herein), UE 602 can or can not send a buffer status report (BSR). Instead, IAB nodes 604a, 604b, 604c can estimate UL grant resources, e.g., based on a historical amount of uplink data from UE 502.

[0044] IAB node 3 604c can simultaneously transmit an RLC PDU to the DU of IAB node 2 604b using the uplink resources signaled in the uplink grant. When the RLC PDU is received by IAB node 2 604b and submitted to the MT for transmission, the MT already has uplink resources to transmit the RLC PDU. Thus, the RLC PDU can be transmitted without delay.

[0045] Similarly, IAB node 1 604a can receive a control plane SR, allocate resources for transmission from IAB node 2 604b, and also trigger transmission of the control plane SR to the DU of IAB donor 606. In response, the IAB donor DU can allocate resources for transmission from IAB node 1 604a. IAB node 2 604b can simultaneously transmit an RLC PDU to IAB node 1 604a. However, the MT of IAB node 1 can already have uplink resources to transmit the RLC PDU. Thus, the RLC PDU can be transmitted without delay.

[0046] Triggering of control plane SR

[0047] ​When the DU of a UE’s serving IAB node receives an RRC message, the serving IAB node can determine that the transmission is an RRC message. Given that IAB nodes typically do not process RRC messages, the DU can use the logical channel ID (LCID) field in the medium access control (MAC) subheader to determine whether the received RLC PDU contains an RRC message. The RRC message can be mapped to a common control channel (CCCH) logical channel or a dedicated control channel (DCCH) logical channel. Specifically, if a RLC PDU is received in an uplink resource allocated via a RAR, the DU of the IAB node 3 can determine whether the LCID field in the MAC subheader indicates a CCCH logical channel or a DCCH logical channel. If a CCCH logical channel or a DCCH logical channel is indicated, the DU can indicate to the MT that an RRC message is expected. In response, the MT can transmit a control plane SR.

[0048] An intermediate IAB node can also indicate in its respective MAC subheader whether the PDU is for a CCCH or a DCCH. Depending on the selected protocol architecture, the RRC message from the UE can be carried directly through RLC in the intermediate link or through the Fl interface.

[0049] Control plane SR details

[0050] The control plane SR can be distinguished from regular SRs. This can be done by using separate periodic resources configured by the CU for control plane SR transmission. Alternatively, the control plane SR can use the same resources as regular SRs, but can instead assign a different cover code for the control plane SR transmission containing the PUCCH. That is, the network can then configure SRs with orthogonal cover codes at the IAB nodes along the route. An orthogonal cover code can be reserved for control plane SR. If the MT of an IAB node receives an RRC message as described above, the MT can transmit a SR with the reserved orthogonal cover code.

[0051] Timing of RLC PDU arrival at IAB node and uplink grant validity

[0052] The RLC PDU arriving at the IAB node 704a, 704b, 704c can not match the availability of uplink resources at the MT of the IAB node 704a, 704b, 704c. For example, the RLC PDU transmission from the IAB node 3 704c to the IAB node 2 704b can use more than one HARQ transmission. Thus, the DU of the IAB node 2 704b can receive the RLC PDU after the time at which the UL grant received by the MT of the IAB node 2 704b is applicable.

[0053] To still be able to transmit RLC PDUs on the next hop, the parent IAB node (IAB node 1 in this example) can allocate semi-persistent uplink resources in the uplink grant. For example, the uplink resources indicated in the UL grant can be valid for a maximum number of occasions at periodic intervals. If the MT uses the UL grant to transmit a RLC PDU in one of these occasions, the allocated resources can be implicitly released. In some embodiments, the semi-persistent resources are established in response to transmitting the indication to the parent IAB node.

[0054] Configured resources for uplink transmission: The network can use configured grants to allocate resources for control plane message transmission across the backhaul link. The network can configure semi-persistent resources for uplink transmission at the DU of each IAB node. The MT of a child IAB node can be aware of this semi-persistent resources via its respective RRC link to the IAB donor. The semi-persistent resources can be activated in response to receiving a control plane SR from the MT. The MT can transmit a control plane SR as described above. In response to the control plane SR, the DU can transmit a PDCCH to the MT to indicate the activation (and availability) of the semi-persistent resources. The MT can then use the semi-persistent resources to transmit RRC messages.

[0055] Discontinuous transmission (DTX) of uplink transmission: To address the timing uncertainty described above, the MT can DTX its uplink transmission if a RLC PDU is not available at the time the UL grant is applicable. To achieve this, the MT of an IAB node can transmit a control plane SR as described above. The DU of the parent IAB node can receive the control plane SR and signal the UL grant to the MT. Given that a RLC PDU is not available at the time the UL grant is applicable, the MT can not transmit any signal in the resources indicated in the UL grant. In response to having received the control plane SR, and observing that no transmission is received in the resources indicated in the UL grant, the DU can signal a second UL grant to the MT. Meanwhile, the MT can receive a RLC PDU. The DU can then transmit the RLC PDU in the resources indicated in the second UL grant.

[0056] SR indicates time slot of UL grant: The SR from the MT can indicate the time slot in which UL resources should be provided. This enables the IAB node to take into account the radio conditions between itself and the downstream nodes when requesting UL resources. That is, the MT can conservatively request UL resources in a time slot later than the normal time slot via the SR. For example, if the link between the UE and IAB node 3 makes it likely that a HARQ retransmission of a RRC message is needed, the MT can request the UL grant in a time slot later than the normal time slot. Information about the duration from the SR to the UL resources can be carried in a modified PUCCH signal.

[0057] Further reducing latency by optimizing random access channel (RACH) handling

[0058] Figure 7 An example of RACH handling for multi-hop IAB network transmission is shown in accordance with some embodiments. Similar to Figure 5 and Figure 6 In Figure 7 , RRC signaling can start from the UE 702 and traverse multiple IAB nodes 704a, 704b, 704c, and then reach the IAB donor node 706. Further reduction in latency can be achieved by initiating a control plane SR at the MT of the serving IAB node in response to a RACH transmission from the UE 702. For procedures where the network expects the UE 702 to perform RACH, the network can assign a RACH preamble. For UE initiated RRC procedures (e.g., connection establishment, connection re-establishment), the UE 702 can use a contention based RACH procedure. That is, the UE 702 can randomly select a RACH preamble.

[0059] If a contention based RACH is received, i.e., a preamble that is not explicitly assigned by the serving IAB node 702c or the network, the serving IAB node 702c can assume that the RRC message is expected. In response, the serving IAB node 702c can initiate a control plane SR (SR*) transmission as shown in Figure 7 .

[0060] Alternatively, the network can configure one or more RACH preambles for RRC procedures. However, this is not backward compatible with 3GPP Release 15. The configured preambles can be indicated to the IAB nodes 704a, 704b, 704c. If the serving IAB node 704c receives a RACH preamble reserved for RRC procedures, the serving IAB node 704c can initiate a control plane SR transmission.

[0061] High priority uplink data arrival: If the UE 702 has high priority (emergency) data to transmit, the observations regarding multi-hop scheduling latency hold. The techniques described above can be used to mitigate latency in this case. The intermediate nodes can be configured with a high priority SR. When the DU of the serving IAB node 704c receives a PDU with an LCID corresponding to a high priority logical channel, the DU can transmit a high priority SR. The resource allocation and transmission of the PDU is as discussed above for RRC messages.

[0062] Reducing latency using contention-based transmission

[0063] Figure 8 An example of multi-hop transmission using contention based physical uplink shared channel (CB-PUSCH) is shown in accordance with some embodiments. Similar to Figure 5 to Figure 7 , in Figure 8In this case, RRC signaling can start from the UE 802 and traverse multiple IAB nodes 804a, 804b, 804c, and then reach the IAB donor node 806.

[0064] Time-frequency resources for CB PUSCH transmission can be configured at the IAB nodes 804a, 804b, 804c for uplink transmission of PDU containing RRC messages. CB PUSCH resource allocation can include periodically available resources for transmission without explicit resource allocation. These resources can be subject to contention (i.e., two or more UEs can transmit their PDU in the same time-frequency resources). The probability of contention can be minimized by allocating a resource pool of sufficient size.

[0065] As mentioned above, the DU of the serving IAB node 804c can use the LCID field to determine that the received RLC PDU contains an RRC message. The DU can then submit the PDU to the MT for transmission via the associated RLC entity based on the routing decision. The DU can also indicate to the MT that the PDU contains an RRC message. The MT of the IAB node 3 804c can transmit the PDU using the next available CB PUSCH resource.

[0066] The IAB nodes 1 804a and 2 804b can similarly determine that the received PDU contains an RRC message and transmit the PDU to their respective MTs along with an indication that the received PDU contains an RRC message. The MTs can transmit the PDU using the next available CB PUSCH resource. The IAB nodes 804a, 804b, 804c can be in connected mode and maintain uplink time alignment. Thus, additional uplink time alignment steps can be avoided prior to CB-PUSCH transmission.

[0067] To minimize the delay prior to transmission, a large amount of time-frequency resources can be reserved for CB-PUSCH transmission. This can represent a large amount of unused / wasted resources given that the resources are not used frequently, which can have been allocated to transmissions from other IAB nodes or UEs. To address this issue, when time-frequency resources are configured for CB-PUSCH as above, CB-PUSCH resources can not always be available for CB-PUSCH transmission. When the serving IAB node 804c receives a RACH indicating that the UE 802 will transmit an RRC message in response to the RAR (e.g., based on the received RACH preamble being UE-selected, or based on the received RACH preamble being in a set reserved for RRC procedures), the DU of the serving IAB node 804c can indicate to the MT the expected arrival of the RRC PDU. The MT can then transmit an “Activate CB PUSCH” command to the DU of the parent IAB node 804b.

[0068] Once the "Activate CB PUSCH" command is transmitted (or at a fixed time offset after transmission), the MT can assume that the CB-PUSCH resource is available for transmission and use the CB-PUSCH resource to transmit the received RLCPDU containing the RRC message. Upon receiving the "Activate CB PUSCH" command, subsequent IAB nodes 804b and 804a can transmit the "Activate CB PUSCH" command upstream, up to the IAB donor 806. This ensures that the CB-PUSCH resource is activated on each hop and that the PDU containing the RRC message can be transmitted without delay. Furthermore, the CB-PUSCH resource can be activated only when needed (i.e., explicitly activated), otherwise allowing these resources to be used by other UEs and IAB nodes.

[0069] The CB-PUSCH resource can be implicitly deactivated when the RLC PDU is successfully transmitted. Alternatively, the CB-PUSCH resource can be implicitly deactivated for a fixed duration after activation.

[0070] Details of the "Activate CB-PUSCH" command

[0071] Figure 9 Exemplary multi-hop transport using CB-PUSCH and activation is shown according to some implementation schemes. Similar to Figure 5 to Figure 8 ,exist Figure 9 In this process, RRC signaling can start from UE 902 and traverse multiple IAB nodes 904a, 904b, and 904c before reaching the IAB donor node 906. Figure 9 In this context, the "Activate CB-PUSCH" command can be used to indicate the expected arrival of an RRC PDU, similar to... Figure 5 .

[0072] The "Activate CB-PUSCH" command is a physical layer instruction from the MT to the parent node's DU. The "Activate CB-PUSCH" command can also be an instruction from the UE to the network. The "Activate CB-PUSCH" command can be defined via one of the existing signals in the NR physical layer specification. For example, as... Figure 9 As shown, in response to receiving an RRC message (e.g., an RRC setup request) or a RACH signal indicating the start of an RRC procedure, an SR configuration can be used as an "Activate CB-PUSCH" command. Alternatively, a dedicated RACH preamble can be used, such that the transmission of the dedicated RACH preamble by the MT is interpreted as a request for CB PUSCH activation by the DU of the parent IAB node. Alternatively or otherwise, the "Activate CB-PUSCH" command can be a separate physical layer indication.

[0073] While one aspect has been described with reference to the specific example for illustration, it will be readily apparent to those skilled in the art that various changes and modifications can be made thereto without departing from the broader scope of the disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than restrictive sense. The accompanying drawings, which are incorporated herein as part of the specification, illustrate various aspects of the subject matter. The aspects shown are intended to explain the principles of the present disclosure and to enable others skilled in the art to most benefit from the teachings herein. Further aspects can be utilized and structural and logical substitutions can be made without departing from the scope of the present disclosure. Accordingly, the detailed description is to be regarded as merely illustrative and not restrictive, and the scope of the aspects are to be determined by the appended claims and equivalents thereof, along with the full scope of equivalents to which such claims are entitled.

[0074] The Abstract is provided to comply with 37 C.F.R. § 1.72(b) requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or the meaning of the claims. In addition, in the above it can be seen that a variety of features are collectively disclosed in individual aspects for the purpose of simplifying the disclosure. The disclosed aspects are not to be interpreted to reflect an intention that the claimed aspects require more features than are explicitly recited in each claim. Rather, the inventiveness resides in less than all features of the disclosed aspects. Accordingly, the claims are hereby incorporated into the as if each claim was individually recited in the .

Claims

1. An apparatus of a first integrated access backhaul, IAB, node in a network, the apparatus comprising: a memory device; and a processing circuit coupled to the memory device, the processing circuit configured to: determine that a first indication has been received from a second IAB node, wherein the second IAB node has fewer hops to a user equipment, UE, than the first IAB node, wherein the first indication indicates a request associated with uplink data for transmission; and based at least in part on receiving the first indication, encode a second indication for transmission to a parent IAB node, wherein the parent IAB node has more hops to the UE than the first IAB node and the second IAB node, wherein the second indication provides prediction information about data expected to arrive at the first IAB node.

2. The apparatus of claim 1, wherein the first indication comprises a buffer status report associated with the uplink data.

3. The apparatus of claim 1, wherein the processing circuit is further configured to: decode, from the parent IAB node, a grant of a parent resource for transmission of the uplink data from the first IAB node to the parent IAB node in response to the second indication being transmitted to the parent IAB node, wherein the parent resource is a physical uplink shared channel, PUSCH, resource based on a contention-free PUSCH resource; decode the uplink data from the second IAB node after the second indication is transmitted to the parent IAB node; and encode the uplink data for transmission to the parent IAB node in response to receiving the uplink data.

4. The apparatus of claim 1, wherein at least one of the first indication or the second indication is included in a resource request message, and wherein a logical channel identifier, LCID, field in a medium access control, MAC, subheader of the uplink data indicates a common control channel, CCCH, logical channel or a dedicated control channel, DCCH, logical channel.

5. The apparatus of claim 4, wherein the resource request message is a physical layer scheduling request or a buffer status report.

6. The apparatus of claim 1, wherein: at least one of the first indication or the second indication is included in a resource request message, and wherein the processing circuit is further configured to transmit the at least one of the first indication or the second indication using resources reserved for the at least one of the first indication or the second indication.

7. The apparatus of claim 1, wherein at least one of the first indication or the second indication is included in a scheduling request, SR, and wherein the processing circuit is further configured to transmit the SR using an orthogonal cover code reserved for control plane SRs.

8. The apparatus of claim 1, wherein: at least one of the first indication or the second indication is included in a scheduling request, SR, and the SR is initiated based on a radio resource control, RRC, setup request.

9. A first integrated access backhaul, IAB, node in a network, the first IAB comprising: a non-transitory computer readable storage medium; and processing circuitry configured to: determine that a first indication has been received from a second IAB node, wherein the second IAB node has fewer hops to a user equipment, UE, than the first IAB node, the first indication indicating that uplink data is to be transmitted; and in response to receiving the first indication, encode a second indication for transmission to a parent IAB node, wherein the parent IAB node has more hops to the UE than the first IAB node and the second IAB node, wherein the second indication provides prediction information about data expected to arrive at the first IAB node, and wherein the non-transitory computer readable storage medium is configured to store the first indication.

10. The first IAB of claim 9, wherein the first indication comprises a buffer status report.

11. The first IAB node of claim 9, wherein the processing circuitry is further configured to: in response to the second indication being transmitted to the parent IAB node, decode a grant of a parent resource from the parent IAB node for transmission of the uplink data from the first IAB node to the parent IAB node when the parent resource is a physical uplink shared channel, PUSCH, resource, wherein the parent resource is a contention-free PUSCH resource; decode the uplink data from the second IAB node after the second indication is transmitted to the parent IAB node; and in response to receiving the uplink data, encode the uplink data for transmission to the parent IAB node.

12. The first IAB node of claim 9, wherein the processing circuitry is further configured to: in response to receiving the first indication from the second IAB node, allocate a resource for transmission of the uplink data from the second IAB node to the first IAB node; and encode a grant of the resource for transmission to the second IAB node before transmitting the uplink data to the parent IAB node.

13. The first IAB node of claim 9, wherein at least one of the first indication or the second indication is included in a resource request message, and wherein the resource request message is a physical layer scheduling request or a buffer status report, and wherein a logical channel identifier, LCID, field in a medium access control, MAC, subheader of the uplink data indicates a common control channel, CCCH, logical channel or a dedicated control channel, DCCH, logical channel.

14. The first IAB node of claim 9, wherein: at least one of the first indication or the second indication is included in a resource request message, and wherein the processing circuitry is further configured to transmit the at least one of the first indication or the second indication using resources reserved for the at least one of the first indication or the second indication.

15. A method for operating a first integrated access backhaul, IAB, node in a network, the method comprising: decoding, based at least in part on reception from a second IAB node, a first indication, the first indication to indicate an amount of uplink data for transmission; and encoding, based on the first indication, a second indication, the second indication to indicate prediction information about data expected to arrive at the first IAB node.

16. The method of claim 15, wherein the second IAB node has fewer hops to a user equipment, UE, than the first IAB node, wherein the parent IAB node has more hops to the UE than the first IAB node and the second IAB node, and wherein the uplink data is associated with the UE.

17. The method of claim 15, wherein the second indication is for transmission to the parent IAB node.

18. The method of claim 15, wherein the first indication comprises a buffer status report.

Images