Managing control plane delays for integrated access and backhaul

Abstract

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

Description

[0001] This application is a divisional application of the invention patent application with the application date of September 25, 2019, application number 201980060986.2, and invention name “Managing control plane delay for integrated access and backhaul”.

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 62 / 736,761, filed on September 26, 2018, which is incorporated herein by reference 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 Art

[0004] Due to the increase in the number and type of user equipment (UE) using network resources and the increase in the amount of data and bandwidth used by various applications such as video streaming operating on these UEs, the use of various types of systems has increased. Bandwidth, latency and data rate improvements can release the 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 become a unified framework designed to meet very different and sometimes conflicting performance standards and services. In general, NR will evolve based on 3GPP Advanced LTE technology and additional enhanced radio access technology (RAT) to achieve seamless wireless connectivity solutions. However, the use of complex IAB networks and IAB nodes may encounter lower performance levels than non-IAB networks. These reduced performance levels can be attributed to, for example, the hopping mode used in the IAB network. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the drawings, which are not necessarily drawn to scale, like numbers may describe similar components in different views. Like numbers with different letter suffixes may represent different instances of similar components. The accompanying drawings generally illustrate various aspects described in this document by way of example and not by way of limitation.

[0006] Figure 1 A combined communication system according to some embodiments is shown.

[0007] Figure 2 A block diagram of a communication device according to some embodiments is shown.

[0008] Figure 3 An example of an IAB network according to some embodiments is shown, where the UE is in standalone mode.

[0009] Figure 4 An example of a user plane protocol architecture for a multi-hop IAB network is shown according to some embodiments.

[0010] Figure 5 An example of a multi-hop transmission according to some embodiments is shown.

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

[0012] Figure 7 An example of random access channel (RACH) processing for multi-hop IAB network transmissions is shown in accordance with some embodiments.

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

[0014] Fig. 9 An exemplary multi-hop transmission using CB-PUSCH and activation is shown in accordance with some embodiments. DETAILED DESCRIPTION

[0015] The following description and accompanying drawings sufficiently illustrate specific aspects to enable those skilled in the art to practice these aspects. Other aspects may incorporate structural changes, logical changes, electrical changes, process changes, and other changes. Portions and features of some aspects may be included in or replace portions and features of other aspects. Aspects set forth in the claims encompass all available equivalents in those claims.

[0016] Figure 1 A combined communication system according to some embodiments is shown. System 100 includes 3GPP LTE / 4G and NG network functions. The network functions may 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).

[0017] The Evolved Packet Core (EPC) of the LTE / 4G network contains protocols and reference points defined for each entity. These core network (CN) entities may include a Mobility Management Entity (MME) 122, a Serving Gateway (S-GW) 124, and a Paging Gateway (P-GW) 126.

[0018] In NG networks, the control plane and the user plane may be separate, which may allow independent resizing and allocation of resources for each plane. The UE 102 may be connected to an access network or random access network (RAN) 110 and / or may be connected to an NG-RAN 130 (gNB) or an access and mobility function (AMF) 142. The RAN 110 may 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 may include multiple network functions in addition to the AMF 112. The UE 102 may generate, encode, and possibly encrypt uplink transmissions to the RAN 110 and / or gNB 130, and decode (and decrypt) downlink transmissions from the RAN 110 and / or gNB 130 (where the reverse is true for the RAN 110 / gNB 130).

[0019] The network functions may 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 NG reference point connection shown.

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

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

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

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

[0024] Figure 2 A block diagram of a communication device according to some embodiments is shown. In some embodiments, the communication device may 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 may be a dedicated computer, a personal or laptop computer (PC), a tablet, a mobile phone, a smart phone, a network router, a switch or a bridge, or any machine capable of (sequentially or otherwise) executing instructions specifying actions to be taken by the machine. In some embodiments, the communication device 200 may be embedded in other non-communication-based devices such as vehicles and appliances.

[0025] Examples as described herein may include a logical component or multiple components, modules or mechanisms, or may operate on a logical component or multiple components, modules or mechanisms. Modules and components are tangible entities (e.g., hardware) that can perform specified operations and can be configured or arranged in some way. In one example, a circuit may be arranged as a module in a specified manner (e.g., internally or relative to an external entity such as other circuits). In one example, all or part of one or more computer systems (e.g., independent computer systems, client computer systems, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application parts, or applications) to operate to perform a specified operation of the module. In one example, the software may reside on a machine-readable medium. In one example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operation.

[0026] Thus, the term "module" (and "component") should be understood to encompass a tangible entity, i.e., an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transiently) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operations described herein. Considering an example where a module is temporarily configured, each module need not be instantiated at any one time. For example, if a module includes a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as corresponding different modules at different times. The software may configure the hardware processor accordingly, for example, to constitute a particular module at one instance in time and to constitute a different module at a different instance in time.

[0027] The computing device 200 may 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 may communicate with each other via an interconnection link (e.g., a bus) 208. The main memory 204 may include any or all of a removable storage device and a non-removable storage device, a volatile memory, or a non-volatile memory. The communication device 200 may also include a display unit 210 (such as a video display), a mixed digital and 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, the input device 212, and the UI navigation device 214 may be a touch screen display. The communication device 200 may additionally include a storage device (e.g., a drive unit) 216, a signal generating 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, a compass, an accelerometer, or other sensors. The communication device 200 may also include an output controller, such as a serial (e.g., Universal Serial Bus (USB)) connection, a parallel connection, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

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

[0029] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by the communication device 200 and causing the communication device 200 to perform any one or more of the techniques of the present disclosure, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory, and optical and magnetic media. Specific examples of machine-readable media may 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.

[0030] The instructions 224 may also be transmitted or received in a communication network via the network interface device 220 using a transmission medium 226, the transmission or reception being performed using any of a plurality of transmission protocols (e.g., frame relay, Internet Protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Exemplary communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile phone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network. Communications over the network may include one or more different protocols, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards (referred to as Wi-Fi), the IEEE 802.16 family of standards (referred to as WiMax), the IEEE 802.15.4 family of standards, the Long Term Evolution (LTE) family of standards, the Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, NG / NR standards, and the like. In one example, the network interface device 220 may include one or more physical jacks (eg, Ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the transmission medium 226 .

[0031] The communication device 200 may 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 may be connected via Figure 1The eNB or gNB shown communicates with the core network. The communication device 200 may be an autonomous or semi-autonomous 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 may be limited by memory, size, or functionality, allowing a larger number of devices to be deployed at a similar cost to a smaller number of larger devices. In some embodiments, the communication device 200 may be a virtual device, such as an application on a smartphone or other computing device.

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

[0033] Figure 3 An example of an IAB network according to some embodiments is shown, wherein the UE is in standalone mode. 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 UE 308 and other IAB nodes and backhauls access traffic. Backhaul can be a part of the network responsible for transmitting communication data between a baseband unit (BBU) and a core network (CN) and connecting a smaller remote network to the CN. It should be noted that, as used herein, the downstream IAB node is more hops away from the IAB donor node than the upstream (or parent) IAB node. However, as shown in the figure, the IAB node 306 may lack a fully functional base station (gNB) capability. The IAB network 300 can utilize a central unit-distributed unit (CU-DU) split architecture present in a 5G architecture. The IAB donor node 304 may include one or more CU control planes (CPs) 304a and one or more DUs 304c, as well as providing other functions 304b. The RRC function may exist in the CU-CP 304a of the IAB donor node 304, and each IAB node 306 functions as a DU. The IAB node 306 may be controlled by the IAB donor 304 in a manner similar to the way the CU controls the DU. Specifically, the F1 control plane protocol between the CU and the DU may be modified to support transmission over multiple hops; the modified F1 protocol enables the IAB donor 304 to control the IAB node 306.

[0034] One consequence of the centralized placement of the RRC functionality (ie in the CU of the donor IAB node) is that RRC messages from the UE may be routed over multiple hops.If the UE is operating in standalone mode, the RRC messages may be transmitted over multiple hops. Figure 4 An example of a protocol architecture for a multi-hop IAB network is shown according to some embodiments. Figure 4 Various protocol layers are shown, including Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), IP Security (IPSec), and User Plane GPRS Tunneling Protocol (GTP-U). Figure 4 As shown, each IAB node 404a, 404b operates as a combination of a DU and a mobile terminal (MT). The DU can serve the next hop and ultimately the UE 402. The MT can provide connectivity with a parent node, which can be an IAB donor node 406. The MT of the IAB nodes 404a, 404b embodies UE functionality for enabling connectivity with the parent node. Figure 4 The RRC messages traversing multiple hops shown may cause delays and air interface delays associated with standard UE operations at each node. Delays may affect key functions. For example, it may take significantly longer to transmit measurement reports from UE 402 to IAB donor 404b, resulting in a higher proportion of handover failures and radio link failures. RRC connection establishment, re-establishment, and RRC connection recovery may take longer, which may result in significantly lower levels of performance compared to non-IAB networks. It is desirable to minimize such additional delays caused by multi-hop transmission of RRC messages, and in other embodiments, minimize such additional delays for other protocols (such as PDCP).

[0035] Figure 5 An exemplary multi-hop transmission is shown in accordance with some embodiments. As described above, RRC signaling may start from the UE 502 and traverse multiple IAB nodes 504a, 504b, 504c before reaching the IAB donor node 506. Figure 5 An example of an RRC protocol architecture assuming that UE 502 is in standalone mode is shown. RRC messages from UE 502 traverse multiple hops, as shown. Message transmission may cause delays at each IAB node 504a, 504b, 504c. As described above, each IAB node 504a, 504b, 504c may include a DU and a MT. Note that the UL grant may 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 may be included in the SR or may be a separate transmission. The BSR may be initiated under various conditions and may be referred to as a regular BSR, a filler BSR, or a periodic BSR.

[0036] Consider the RRC connection establishment situation, such as Figure 5 As shown. UE 502 may transmit an RRC setup request message to the DU of IAB node 3504c. The DU of IAB node 3 may 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 may treat the incoming RLC PDU as an uplink data arrival event. If no resources are available for uplink transmission, UE 502 may request uplink resources. If configured, the request may be a scheduling request; otherwise, a RACH request may be used. Resources may then be allocated for uplink transmission. Considering that most services typically exist downstream, there may be no uplink data in the MT's buffer at a given moment. In this case, the MT may not have requested uplink resources, and the state may have already allocated uplink resources for the transmission of the RLC PDU.

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

[0038] Figure 6 An example of a multi-hop transmission utilizing pre-allocation according to some embodiments is shown. Figure 5 ,exist Figure 6 In , RRC signaling may start from UE 602 and traverse multiple (intermediate or relay) IAB nodes 604a, 604b, 604c before reaching IAB donor node 606. Figure 6 In the example, special scheduling request (SR) resources may be allocated to each IAB node 604a, 604b, 604c by its serving parent node. Continuous control plane SR may be used to allocate resources to predictively allocate resources for uplink transmissions on multiple links.

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

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

[0041] IAB Node 3 604c may simultaneously use the uplink resources signaled in the uplink grant to transmit the RLC PDU to the DU of IAB Node 2 604b. When the RLC PDU is received by IAB Node 2 604b and submitted to the MT for transmission, the MT already has the uplink resources to transmit the RLC PDU. Therefore, the RLC PDU can be transmitted without delay.

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

[0043] Control plane SR triggering

[0044] When the DU of the serving IAB node of the UE receives an RRC message, the serving IAB node may determine that the transmission is an RRC message. Considering that the IAB node does not usually process RRC messages, the DU may 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 may be mapped to a common control channel (CCCH) logical channel or a dedicated control channel (DCCH) logical channel. Specifically, if the RLC PDU is received in an uplink resource allocated via the RAR, the DU of the IAB node 3 may 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 may indicate to the MT that the RRC message is expected. In response, the MT may transmit a control plane SR.

[0045] The intermediate IAB node may also indicate in its corresponding MAC subheader whether the PDU is for CCCH or DCCH. Depending on the selected protocol architecture, the RRC message from the UE may be carried directly through the RLC in the intermediate link or through the F1 interface.

[0046] Control Plane SR Details

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

[0048] Timing of RLC PDU arrival and uplink grant validity at IAB nodes

[0049] The RLC PDUs arriving at the IAB nodes 704a, 704b, 704c may not match the availability of uplink resources at the MTs of the IAB nodes 704a, 704b, 704c. For example, the RLC PDUs transmitted from the IAB node 3 704c to the IAB node 2 704b may use more than one HARQ transmission. Therefore, the DUs of the IAB node 2 704b may receive the RLC PDUs after the time applicable to the UL grant received by the MTs of the IAB node 2 704b.

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

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

[0052] Discontinuous transmission (DTX) of uplink transmission: To address the above-mentioned timing uncertainty, if the RLC PDU is not available when the UL grant is applicable, the MT may DTX its uplink transmission. To achieve this, the MT of the IAB node may transmit a control plane SR as described above. The DU of the parent IAB node may receive the control plane SR and signal the MT of the UL grant. Considering that the RLC PDU is not available when the UL grant is applicable, the MT may not transmit any signal in the resources corresponding to 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 may signal the MT of a second UL grant. At the same time, the MT may receive the RLC PDU. The DU may then transmit the RLC PDU in the resources indicated in the second UL grant.

[0053] SR indicates the time slot of UL grant: The SR from the MT may indicate the time slot in which UL resources should be provided. This enables the IAB node to consider the radio conditions between itself and the downstream node when requesting UL resources. That is, the MT may conservatively request UL resources for a time slot later than the normal time slot via the SR. For example, if the link between the UE and the IAB node 3 is such that HARQ retransmission of an RRC message may be required, the MT may request UL grant in a time slot later than the normal time slot. Information about the duration from the SR to the UL resource may be carried in the modified PUCCH signal.

[0054] Further delay reduction by optimizing random access channel (RACH) processing

[0055] Figure 7 An example of RACH processing for multi-hop IAB network transmissions according to some embodiments is shown. Figure 5 and Figure 6 ,exist Figure 7 In the embodiment of the present invention, RRC signaling may start from UE 702 and traverse multiple IAB nodes 704a, 704b, 704c before reaching IAB donor node 706. Further reduction in latency may be achieved by initiating a control plane SR at the MT serving the IAB node in response to a RACH transmission from UE 702. For procedures where the network expects UE 702 to perform RACH, the network may allocate a RACH preamble. For UE-initiated RRC procedures (e.g., connection establishment, connection reestablishment), UE 702 may use a contention-based RACH procedure. That is, UE 702 may randomly select a RACH preamble.

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

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

[0058] High priority uplink data arrival: If the UE 702 has high priority (urgent) data to transmit, then the observation about multi-hop scheduling delay is maintained. The above-mentioned techniques can be used to alleviate the delay in this case. The intermediate node can be configured with a high priority SR. When the DU serving the IAB node 704c receives a PDU with an LCID corresponding to a high priority logical channel, the DU can transmit a high priority SR. Resource allocation and transmission of the PDU are performed as discussed above for the RRC message.

[0059] Use contention-based transmission to reduce latency

[0060] Figure 8 An example of multi-hop transmission using a contention-based physical uplink shared channel (CBPUSCH) is shown in accordance with some embodiments. Figures 5 to 7 ,exist Figure 8, RRC signaling may start from UE 802 and traverse multiple IAB nodes 804a, 804b, 804c before reaching IAB donor node 806.

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

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

[0063] IAB nodes 1 804a and 2 804b may 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 MT may transmit the PDU using the next available CB PUSCH resource. IAB nodes 804a, 804b, 804c may be in connected mode and maintain uplink time alignment. Thus, an additional uplink time alignment step may be avoided prior to CB-PUSCH transmission.

[0064] In order to minimize the delay before transmission, a large amount of time-frequency resources may be reserved for CB-PUSCH transmission. Considering that the resources are not frequently used, this may represent a large amount of unused / wasted resources that may have been allocated for transmissions from other IAB nodes or UEs. To address this issue, when the time-frequency resources for CB-PUSCH are configured as above, the CB-PUSCH resources may 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 selected by the UE, or based on the received RACH preamble being in a set reserved for the RRC process), the DU of the serving IAB node 804c may indicate the expected arrival of the RRC PDU to the MT. The MT may then transmit an "activate CB PUSCH" command to the DU of the parent IAB node 804b.

[0065] Once the "Activate CB PUSCH" command is transmitted (or at a fixed time offset after the transmission), the MT may assume that the CB-PUSCH resources are available for transmission and use the CB-PUSCH resources to transmit the received RLC PDU containing the RRC message. Upon receiving the "Activate CB PUSCH" command, the next IAB nodes 804b, 804a may transmit the "Activate CB PUSCH" command upstream respectively until the IAB donor 806 is reached. This ensures that the CB-PUSCH resources are activated on each hop and the PDU containing the RRC message can be transmitted without delay. In addition, the CB-PUSCH resources may be activated only when needed (i.e., explicitly activated), otherwise allowing these resources to be available to other UEs and IAB nodes.

[0066] When the RLC PDU is successfully transmitted, the CB-PUSCH resources may be implicitly deactivated. Alternatively, the CB-PUSCH resources may be implicitly deactivated for a fixed duration after activation.

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

[0068] Fig. 9 An exemplary multi-hop transmission using CB-PUSCH and activation is shown in accordance with some embodiments. Figures 5 to 8 ,exist Fig. 9 In , RRC signaling may start from UE 902 and traverse multiple IAB nodes 904a, 904b, 904c before reaching IAB donor node 906. Fig. 9 In , the "Activate CB-PUSCH" command can be used to indicate the expected arrival of the RRC PDU, similar to Figure 5 .

[0069] The "Activate CB-PUSCH" command is a physical layer indication from the MT to the DU of the parent node. The "Activate CB-PUSCH" command can be an indication 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, Fig. 9 As shown, in response to receiving an RRC message (e.g., RRC setup request) or a RACH signal indicating the start of an RRC process, an SR configuration may be used as an "activate CB-PUSCH" command. Alternatively, a dedicated RACH preamble may be used so that the transmission of a dedicated RACH preamble by the MT is interpreted as a request for activation of the CB PUSCH by the DU of the parent IAB node. Alternatively or in addition, the "activate CB-PUSCH" command may be a separate physical layer indication.

[0070] Although an aspect has been described with reference to specific exemplary aspects, it is apparent that various modifications and changes may be made to these aspects without departing from the broader scope of the present disclosure. Accordingly, the specification and the drawings should be regarded as having illustrative rather than restrictive meanings. The drawings forming part of this document illustrate specific aspects of the practicable subject matter in an illustrative rather than restrictive manner. The aspects shown are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other aspects may be utilized and derived from the present disclosure, so that structural substitutions and logical substitutions and changes may be made without departing from the scope of the present disclosure. Therefore, this specific embodiment is not restrictive, and the scope of each aspect is limited only by the appended claims and the full scope of equivalents to which such claims are authorized.

[0071] The abstract of the specification is provided to comply with 37 CFR §1.72(b), which requires an abstract that enables the reader to quickly ascertain the essence of the technical disclosure. The abstract of the specification is provided with the understanding that the technical disclosure will not be used to interpret or limit the scope or meaning of the claims. In addition, in the above detailed description, it can be seen that various features are concentrated in a single aspect for the purpose of simplifying the disclosure. The disclosed method should not be interpreted as reflecting an intention that the claimed aspects require more features than those expressly recited in each claim. On the contrary, as reflected in the following claims, the inventive subject matter lies in less than all the features of a single disclosed aspect. Therefore, the following claims are hereby incorporated into the detailed description, with each claim existing independently as a separate aspect.

Claims

1. An apparatus of a first integrated access backhaul (IAB) node in a network, the apparatus comprising: A processing circuit, the processing circuit being configured to: determining that a first indication has been received from a second IAB node, wherein the first IAB node is wirelessly associated with a user equipment (UE) via the second IAB node, wherein the first indication indicates a request associated with uplink data for transmission; and encoding a second indication for transmission to a parent IAB node based at least in part on receiving the first indication, wherein the parent IAB node is wirelessly associated with the UE via the first IAB node and the second IAB node, Wherein the second indication provides predictive information about a data transmission based at least in part on the first indication.

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 second indication comprises a predicted buffer status report associated with the uplink data.

4. The apparatus of claim 1 , wherein the processing circuit is further configured to: In response to the second indication being transmitted to the parent IAB node, when the parent resource is a physical uplink shared channel (PUSCH) resource, decoding from the parent IAB node a grant of the parent resource for transmitting the uplink data from the first IAB node to the parent IAB node, wherein the parent resource is a non-contention based PUSCH resource; After the second indication is transmitted to the parent IAB node, decoding the uplink data from the second IAB node; and In response to receiving the uplink data, the uplink data is encoded for transmission to the parent IAB node.

5. The device according to claim 1, wherein at least one of the first indication or the second indication is included in a resource request message, and 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. The apparatus according to claim 5 , wherein the resource request message is a physical layer scheduling request or a buffer status report.

7. The device according to 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 indication using resources reserved for at least one of the first indication or the second indication.

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

9. The device according to 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.

10. A first integrated access backhaul (IAB) node in a network, the first IAB comprising: a non-transitory computer-readable storage medium; and A processing circuit, the processing circuit being configured to: determining that a first indication has been received from a second IAB node, wherein the first IAB node is in wireless communication with a user equipment (UE) via the second IAB node, the first indication indicating that uplink data is to be transmitted; as well as In response to receiving the first indication, encoding a second indication for transmission to a parent IAB node, wherein the parent IAB node wirelessly communicates with the UE via the first IAB node and the second IAB node, wherein the second indication provides predictive information about the data indicated by the first indication, and Wherein the non-transitory computer-readable storage medium is configured to store the first indication.

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

12. The first IAB of claim 10, wherein the second indication comprises a predicted buffer status report associated with the uplink data.

13. The first IAB node according to claim 10, wherein the processing circuit is further configured to: In response to the second indication being transmitted to the parent IAB node, when the parent resource is a physical uplink shared channel (PUSCH) resource, decoding from the parent IAB node a grant of the parent resource for transmitting the uplink data from the first IAB node to the parent IAB node, wherein the parent resource is a non-contention based PUSCH resource; After the second indication is transmitted to the parent IAB node, decoding the uplink data from the second IAB node; and In response to receiving the uplink data, the uplink data is encoded for transmission to the parent IAB node.

14. The first IAB node according to claim 10, wherein the processing circuit is further configured to: In response to receiving the first indication from the second IAB node, allocating resources for transmitting the uplink data from the second IAB node to the first IAB node; and Prior to transmitting the uplink data to the parent IAB node, the grant of the resources is encoded for transmission to the second IAB node.

15. The first IAB node according to claim 10, 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 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.

16. The first IAB node according to claim 10, 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 indication using resources reserved for at least one of the first indication or the second indication.

17. 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 indicating an amount of uplink data for transmission; as well as A second indication is encoded based on the first indication, the second indication being used to indicate a predicted amount of uplink data for data transmission from the first IAB node to a parent IAB node.

18. The method according to claim 17, wherein the first IAB is wirelessly associated with a user equipment (UE) via the second IAB node, wherein the parent IAB node is wirelessly associated with the UE via the first IAB node and the second IAB node, and The uplink data is associated with the UE.

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

20. The method according to claim 17, wherein the first indication comprises a buffer status report, and Wherein the second indication comprises a predicted buffer status report associated with the uplink data.

Images