Resource configuration in integrated access and backhaul networks

Abstract

The present invention discloses methods, systems, apparatus, and computer programs for communicating a new link availability configuration for a node in an integrated access and backhaul (IAB) network. In one aspect, the method includes receiving a radio resource control (RRC) message from an IAB node; determining a new resource availability configuration for backhaul resources associated with the IAB node based on the RRC message; and, in response to determining the new resource availability configuration, conditionally communicating with the IAB node via the backhaul resources according to the new resource availability configuration.

Description

[0001] Priority claim

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 849,681, filed May 17, 2019, entitled “METHODS FOR RESOURCE CONFIGURATIONS IN RELAY NETWORK,” which is incorporated herein by reference in its entirety. Background Art

[0003] User Equipment (UE) can transmit data wirelessly using a wireless communication network. To transmit data wirelessly, the UE connects to a node of a Radio Access Network (RAN) and synchronizes with the network. Summary of the Invention

[0004] The present disclosure relates to methods, systems, apparatuses, computer programs, or combinations thereof for communicating new resource availability configurations to an integrated access and backhaul (IAB) node.

[0005] According to one aspect of the present disclosure, a method in an integrated access and backhaul (IAB) network includes receiving a radio resource control (RRC) message from an IAB node; determining a new resource availability configuration for backhaul resources associated with the IAB node based on the RRC message; and, in response to determining the new resource availability configuration, conditionally communicating with the IAB node via the backhaul resources according to the new resource availability configuration.

[0006] Other versions include corresponding systems, apparatus, and computer programs for performing the actions of the method defined by the instructions encoded on the computer-readable storage device.These and other versions may optionally include one or more of the following features.

[0007] In some implementations, the new resource availability configuration defines the backhaul resource as hard available, and wherein communicating with the IAB node via the backhaul resource according to the new resource availability configuration includes making the backhaul resource unconditionally available for transmitting backhaul data.

[0008] In some implementations, the new resource availability configuration defines the backhaul resource as softly available, and wherein communicating with the IAB node via the backhaul resource according to the new resource availability configuration includes making the backhaul resource conditionally available for transmitting backhaul data.

[0009] In some implementations, the new resource availability configuration defines the backhaul resource as softly available, and wherein communicating with the IAB node via the backhaul resource according to the new resource availability configuration includes making the backhaul resource unavailable for transmitting backhaul data.

[0010] In some implementations, the new resource availability configuration includes a hard resource availability bitmap having one or more bits and a soft resource availability bitmap having one or more bits, wherein each bit in the hard resource availability bitmap and the soft resource availability bitmap corresponds to a different backhaul resource associated with the IAB node.

[0011] In some implementations, a value of 1 in a bit in the hard resource availability bitmap indicates that the corresponding resource is unconditionally available for transmitting backhaul data, and a value of 1 in a bit in the soft resource availability bitmap indicates that the corresponding resource is conditionally available for transmitting backhaul data.

[0012] In some implementations, a value of 0 in a bit in both the hard resource availability bitmap and the soft resource availability bitmap indicates that the corresponding resource is not available for transmitting backhaul data. In some implementations, the backhaul resources include one or more of the following: an uplink symbol, a downlink symbol, an uplink time slot, or a downlink time slot.

[0013] According to another aspect of the present disclosure, in an integrated access and backhaul (IAB) network including an IAB node, a method includes determining a new resource availability configuration for backhaul resources associated with the IAB node; generating a message including the new resource availability configuration for the backhaul resources in response to the new resource availability configuration; and transmitting an RRC message to the IAB node.

[0014] Other versions include corresponding systems, apparatus, and computer programs for performing the actions of the method defined by the instructions encoded on the computer-readable storage device.These and other versions may optionally include one or more of the following features.

[0015] In some implementations, the new resource availability configuration defines the backhaul resources as hard available, and wherein the new resource availability configuration directs the IAB node to make the backhaul resources unconditionally available for transmitting backhaul data.

[0016] In some implementations, the new resource availability configuration defines the backhaul resources as softly available, and wherein the new resource availability configuration directs the IAB node to make the backhaul resources conditionally available for transmitting backhaul data.

[0017] In some implementations, the new resource availability configuration defines the backhaul resources as unavailable, and wherein the new resource availability configuration directs the IAB node to make the backhaul resources unavailable for transmitting backhaul data.

[0018] In some implementations, the new resource availability configuration includes a hard resource availability bitmap having one or more bits and a soft resource availability bitmap having one or more bits, wherein each bit in the hard resource availability bitmap and the soft resource availability bitmap corresponds to a different backhaul resource associated with the IAB node.

[0019] In some implementations, a value of 1 in a bit in the hard resource availability bitmap indicates that the corresponding resource is unconditionally available for transmitting backhaul data, and a value of 1 in a bit in the soft resource availability bitmap indicates that the corresponding resource is conditionally available for transmitting backhaul data.

[0020] In some implementations, a value of 0 in a bit in both the hard resource availability bitmap and the soft resource availability bitmap indicates that the corresponding resource is not available for transmitting backhaul data.

[0021] In some implementations, the backhaul resources include one or more of: uplink symbols, downlink symbols, uplink time slots, or downlink time slots. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 is an exemplary integrated access and backhaul (IAB) network according to some implementations of the present disclosure.

[0023] Figure 2A and Figure 2B Each shows an exemplary method according to some specific implementations of the present disclosure.

[0024] Figure 3 is an exemplary architecture of a network system according to some specific implementations of the present disclosure.

[0025] Figure 4 An exemplary architecture of a system including a CN according to some specific implementations of the present disclosure is shown.

[0026] Figure 5 is a block diagram of an example of infrastructure equipment according to some implementations of the present disclosure.

[0027] Figure 6 is a block diagram of various protocol functions that may be implemented in a wireless communication device according to some implementations of the present disclosure.

[0028] Figure 7 is a block diagram illustrating components capable of reading instructions from a machine-readable medium or computer-readable medium (eg, a non-transitory machine-readable storage medium) and performing any one or more of the methods described herein, according to some implementations of the present disclosure.

[0029] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0030] The present disclosure relates to an integrated access and backhaul (IAB) network, which is a feature that implements multi-hop routing of data (e.g., as described in 3GPP Release 16 (Rel-16)). The architecture of an IAB network generally includes an IAB donor that serves multiple IAB nodes that operate as relays. An IAB donor is a network node (e.g., a base station) that terminates a new generation (NG) interface. Specifically, the IAB donor can serve as an interface from user equipment (UE) to the core network and / or can provide wireless backhaul functionality to multiple IAB nodes. Multiple IAB nodes can act as access nodes to the UE and can provide backhaul links to other IAB nodes.

[0031] The IAB network architecture implements a central unit-distributed unit (CU-DU) split. In this architecture, multiple IAB nodes terminate the DU function, and the IAB donor terminates the CU function. In addition, each IAB node can include a mobile terminal (MT) function. The IAB node can use the MT function to connect to the parent IAB node and / or the IAB donor. In addition, the IAB node can use the DU function to communicate with the MT of the UE and / or child IAB node. The signaling between the MT or UE of the IAB node and the CU of the IAB donor can use the radio resource control (RRC) protocol. The signaling between the DU of the IAB node and the CU of the IAB donor can use the F1-AP protocol.

[0032] In an IAB network, an IAB node can be aware of the semi-static distributed unit (DU) resource configuration (e.g., downlink (DL), uplink (UL), flexible) for all of its child IAB nodes. If the complete DU resource configuration information for its child IAB nodes is not necessary, only the necessary configuration information can be signaled to the IAB node. Therefore, the semi-static resource allocation for IAB DU resource configuration can be centrally configured by the IAB CU (Central Unit). In addition to DU DL, UL, and flexible modes, hard, soft, and unavailable (H / S / NA) DU configurations are provided, further indicating the availability of configured DL / UL / flexible resources as unconditionally available, conditionally available, or unavailable. Furthermore, a parent node can use explicit indication of soft resource availability to make resources available to child nodes, regardless of any implicit determination of availability by the child node. Therefore, the parent node does not need to be aware of the implicit determination of DU soft resource availability at the child node.

[0033] Since each of the D / U / F resource types may span more than one time slot in the "DUF" configuration sequence mode, different signaling options for H / S / NA with different overheads result in different tradeoffs between coordination flexibility and signaling overhead.

[0034] This disclosure describes enhancements to the Radio Resource Control (RRC) signaling protocol to enable an IAB-CU to flexibly configure coordinated resource availability (e.g., H / S / NA) for child IAB-DUs in an IAB network. The techniques enable the IAB-CU to configure resources for IAB-DUs in the network and communicate the configuration in a data-efficient manner.

[0035] Figure 1 FIG. 1 shows an exemplary IAB network 100 according to some implementations. Figure 1 As shown, the IAB network 100 includes an IAB-CU node 102 and IAB-DU nodes 110 and 120. In the network 100, the IAB-CU node 102 is a central unit (CU) that controls the operation of one or more distributed units (DUs), such as the IAB-DU nodes 110 and 120. For example, the IAB-CU node 102 can utilize the radio resource control (RRC) protocol to control the operation of the IAB-DU nodes 110 and 120. The IAB-CU node 102 is the parent node of the IAB-DU nodes 110 and 120. Conversely, the IAB-DU nodes 110 and 120 are child nodes of the IAB-CU node 102.

[0036] In the IAB network 100, IAB-DU nodes 110 and 120 can communicate with the IAB-CU node 102 using backhaul (BH) resources 112 and 122. The BH resources 112 and 122 can be radio frequency (RF) resources used for data communication between nodes. In some implementations, the IAB-DU nodes 110 and 120 can communicate directly with each other or other IAB-DU nodes via additional BH resources.

[0037] In the IAB network 100, each of the BH resources 112 and 122 between the IAB-DU nodes 110 and 120 and the IAB-CU node 102 is associated with a resource availability (e.g., hard, soft, or unavailable). For example, if the BH resource 112 has a resource availability of "hard" (H), the resource is unconditionally available for backhaul data between the IAB-DU node 110 and the IAB-CU node 102. If the BH resource 112 has a resource availability of "soft" (S), the resource is conditionally available for backhaul data between the IAB node 110 and the IAB-CU node 102. If the BH resource 112 has a resource availability of "not available" (NA), the resource is unavailable for backhaul data between the IAB node 110 and the IAB-CU node 102. In some implementations, the resource availability of the resources 112 and 122 in the IAB network 100 can be configured by the IAB-CU node 102. For example, the IAB-CU node 102 may send a specific RRC information element (IE) including resource configuration to the IAB-DU nodes 110 , 120 to configure the availability of the BH resources 112 , 122 .

[0038] The present invention discloses methods and systems for communicating resource availability configurations to IAB nodes in an IAB network (e.g., IAB network 100). This technology enables an IAB-CU (e.g., 102) to flexibly configure coordinated time resources for all child IAB-DUs (e.g., 110, 120) in the IAB network 100, which can enable the IAB network 100 to achieve higher data efficiency and better performance (e.g., data throughput).

[0039] In one embodiment, resource availability configuration (e.g., hard, soft, or unavailable (H / S / NA), which defines resources as unconditionally available, conditionally available, and unavailable to IAB-DU, respectively) can be configured and signaled at a slot-level granularity. This can be achieved by adding new parameters hardResourceSlotSet and softResourceSlotSet to the TDD-UL-DL-Pattern information element, which is to be signaled from the IAB-CU to the IAB-DU via F1-AP signaling. The description of the information element showing these new parameters is shown in Table 1, and the description of the parameters is shown in Table 2.

[0040] Table 1

[0041]

[0042] Table 2

[0043]

[0044]

[0045] In one embodiment, resource availability configuration can be configured and signaled at symbol-level granularity. This can be achieved by adding new parameters hardResourceSymbolSet and softResourceSymbolSet to the TDD-UL-DL-Pattern information element, which is to be signaled from the IAB-CU to the IAB-DU via F1-AP signaling.

[0046] Descriptions of the information elements showing these new parameters are shown in Table 3, and descriptions of the parameters are shown in Table 4.

[0047] Table 3

[0048]

[0049] Table 4

[0050]

[0051]

[0052] In one embodiment, resource availability configuration can be configured and signaled using resource granularity. For example, resource granularity can be slot, symbol, transmission direction, and transmission direction per slot. This can be achieved by adding a new parameter resourceConfigGranularity to TDD-UL-DL-ConfigCommon and new parameters hardResourceSet and softResourceSet to the TDD-UL-DL-Pattern information element (IE), which is to be signaled from the IAB-CU to the IAB-DU via F1-AP signaling.

[0053] Descriptions of these information elements and parameters are shown in Tables 5 to 8.

[0054] Table 5

[0055]

[0056] Table 6

[0057]

[0058]

[0059] Table 7

[0060]

[0061] Table 8

[0062]

[0063] Figure 2A and Figure 2B Flowcharts illustrating exemplary processes according to some specific implementations of the present disclosure are shown. For clarity of presentation, the following description generally describes processes in the context of other figures in this specification. For example, process 200 may be performed by Figure 1 2. For example, the process 210 may be performed by the base station (e.g., IAB donor) shown in FIG. Figure 1 . However, it should be understood that these processes may be performed by any suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, the steps of the process may be executed in parallel, in combination, in a loop, or in any order.

[0064] Figure 2A 2 is a flow chart of an exemplary process 200 for communicating a new resource availability configuration to an integrated access and backhaul (IAB) node. At step 202, the process involves receiving a radio resource control (RRC) message from the IAB node. In some implementations, the RRC message is received by an IAB-DU node (e.g., Figure 1 At step 204, the process involves determining a new resource availability configuration for backhaul resources associated with the IAB node based on the RRC message. At step 206, the process involves, in response to determining the new resource availability configuration, conditionally communicating with the IAB node via the backhaul resources according to the new resource availability configuration.

[0065] In some implementations, the new resource availability configuration defines the backhaul resource as hard available, and wherein communicating with the IAB node via the backhaul resource according to the new resource availability configuration includes making the backhaul resource unconditionally available for transmitting backhaul data.

[0066] In some implementations, the new resource availability configuration defines the backhaul resource as softly available, and wherein communicating with the IAB node via the backhaul resource according to the new resource availability configuration includes making the backhaul resource conditionally available for transmitting backhaul data.

[0067] In some implementations, the new resource availability configuration defines the backhaul resource as softly available, and wherein communicating with the IAB node via the backhaul resource according to the new resource availability configuration includes making the backhaul resource unavailable for transmitting backhaul data.

[0068] In some implementations, the new resource availability configuration includes a hard resource availability bitmap having one or more bits and a soft resource availability bitmap having one or more bits, wherein each bit in the hard resource availability bitmap and the soft resource availability bitmap corresponds to a different backhaul resource associated with the IAB node.

[0069] In some implementations, a value of 1 in a bit in the hard resource availability bitmap indicates that the corresponding resource is unconditionally available for transmitting backhaul data, and a value of 1 in a bit in the soft resource availability bitmap indicates that the corresponding resource is conditionally available for transmitting backhaul data.

[0070] In some implementations, a value of 0 in a bit in both the hard resource availability bitmap and the soft resource availability bitmap indicates that the corresponding resource is not available for transmitting backhaul data. In some implementations, the backhaul resources include one or more of the following: an uplink symbol, a downlink symbol, an uplink time slot, or a downlink time slot.

[0071] Figure 2B 2 is a flow chart of an exemplary process 210. At step 212, the process involves determining a new resource availability configuration for a backhaul resource associated with an IAB node. At step 214, the process involves generating a message including the new resource availability configuration for the backhaul resource in response to the new resource availability configuration. At step 216, the process involves transmitting the message to the IAB node. In some implementations, steps 212 to 216 are performed by an IAB-CU node (e.g., Figure 1 102) is executed, and the message is transmitted to the IAB-DU node (e.g., 110).

[0072] In some implementations, the new resource availability configuration defines the backhaul resources as hard available, and wherein the new resource availability configuration directs the IAB node to make the backhaul resources unconditionally available for transmitting backhaul data.

[0073] In some implementations, the new resource availability configuration defines the backhaul resources as softly available, and wherein the new resource availability configuration directs the IAB node to make the backhaul resources conditionally available for transmitting backhaul data.

[0074] In some implementations, the new resource availability configuration defines the backhaul resources as unavailable, and wherein the new resource availability configuration directs the IAB node to make the backhaul resources unavailable for transmitting backhaul data.

[0075] In some implementations, the new resource availability configuration includes a hard resource availability bitmap having one or more bits and a soft resource availability bitmap having one or more bits, wherein each bit in the hard resource availability bitmap and the soft resource availability bitmap corresponds to a different backhaul resource associated with the IAB node.

[0076] In some implementations, a value of 1 in a bit in the hard resource availability bitmap indicates that the corresponding resource is unconditionally available for transmitting backhaul data, and a value of 1 in a bit in the soft resource availability bitmap indicates that the corresponding resource is conditionally available for transmitting backhaul data.

[0077] In some implementations, a value of 0 in a bit in both the hard resource availability bitmap and the soft resource availability bitmap indicates that the corresponding resource is not available for transmitting backhaul data.

[0078] In some implementations, the backhaul resources include one or more of: uplink symbols, downlink symbols, uplink time slots, or downlink time slots.

[0079] Figure 2A and 2B The exemplary processes shown in can be modified or reconfigured to include additional, fewer, or different steps ( Figure 2A and Figure 2B ), these steps may be performed in the order shown or in a different order.

[0080] Figure 3 An exemplary architecture of a system 300 of a network according to various embodiments is shown. The following description is provided for an exemplary system 300 operating in conjunction with LTE system standards and 5G or NR system standards provided by 3GPP technical specifications. However, the exemplary embodiments are not limited in this regard and may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems (e.g., sixth generation (6G) systems), IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), and the like.

[0081] like Figure 3As shown, system 300 includes UE 301a and UE 301b (collectively referred to as "UE 301" or "UE 301"). In this example, multiple UEs 301 are shown as smart phones (e.g., handheld touch screen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing devices, such as consumer electronic devices, mobile phones, smart phones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, instrument clusters (ICs), head-up display (HUD) devices, on-board diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), electronic engine management systems (EEMS), electronic / engine electronic control units (ECUs), electronic / engine electronic control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), connected or "smart" appliances, MTC devices, M2M, IoT devices, etc.

[0082] In some embodiments, any of the UEs 301 may be an IoT UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. The IoT UE may utilize technologies such as M2M or MTC to exchange data with an MTC server or device via a PLMN, ProSe or D2D communications, a sensor network, or an IoT network. M2M or MTC data exchanges may be machine-initiated data exchanges. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-term connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0083] UE 301 may be configured, for example, to be communicatively coupled to RAN 310. In an embodiment, RAN 310 may be an NG RAN or 5G RAN, E-UTRAN, or a legacy RAN such as UTRAN or GERAN. As used herein, the term "NG RAN," etc., may refer to RAN 310 operating in an NR or 5G system 300, while the term "E-UTRAN," etc., may refer to RAN 310 operating in an LTE or 4G system 300. UE 301 utilizes connections (or channels) 303 and 304, respectively, each of which includes a physical communication interface or layer (discussed in further detail below).

[0084] In this example, connections 303 and 304 are shown as air interfaces to achieve communication coupling and may be consistent with a cellular communication protocol, such as a GSM protocol, a CDMA network protocol, a PTT protocol, a POC protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, a NR protocol, and / or any other communication protocol discussed herein. In an embodiment, the UE 301 may directly exchange communication data via a ProSe interface 305. The ProSe interface 305 may alternatively be referred to as an SL interface 305 and may include one or more logical channels, including but not limited to a PSCCH, a PSSCH, a PSDCH, and a PSBCH.

[0085] UE 301b is shown as being configured to access AP 306 (also referred to as "WLAN node 306," "WLAN 306," "WLAN terminal 306," "WT 306," etc.) via connection 307. Connection 307 may comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein AP 306 would include Wireless Fidelity. Router. In this example, AP 306 is shown connected to the Internet without being connected to the core network of the wireless system (described in further detail below). In various embodiments, UE 301b, RAN 310, and AP 306 can be configured to utilize LWA operation and / or LWIP operation. LWA operation can involve RAN nodes 311a-b configuring UE 301b in the RRC_CONNECTED state to utilize radio resources of LTE and WLAN. LWIP operation can involve UE 301b using WLAN radio resources (e.g., connection 307) via an IPsec protocol tunnel to authenticate and encrypt packets (e.g., IP packets) sent over connection 307. IPsec tunneling can include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0086] RAN 310 may include one or more AN nodes or RAN nodes 311a and 311b (collectively referred to as "RAN node 311" or "RAN node 311") that enable connections 303 and 304. As used herein, the terms "access node," "access point," and the like may describe equipment that provides radio baseband functionality for data and / or voice connections between a network and one or more users. These access nodes may be referred to as BSs, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs, or TRPs, and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node" and the like may refer to RAN nodes 311 (e.g., gNBs) operating in NR or 5G systems 300, while the terms "E-UTRAN node" and the like may refer to RAN nodes 311 (e.g., eNBs) operating in LTE or 4G systems 300. According to various embodiments, the RAN node 311 may be implemented as one or more dedicated physical devices such as a macrocell base station and / or a low power (LP) base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell.

[0087] In some embodiments, all or part of the multiple RAN nodes 311 may be implemented as one or more software entities running on a server computer as part of a virtual network that may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP). In these embodiments, the CRAN or vBBUP may implement a RAN functional split, such as a PDCP split, where the RRC and PDCP layers are operated by the CRAN / vBBUP, while other L2 protocol entities are operated by individual RAN nodes 311; a MAC / PHY split, where the RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP, and the PHY layer is operated by individual RAN nodes 311; or a "lower PHY" split, where the RRC, PDCP, RLC, MAC layers, and upper portions of the PHY layers are operated by the CRAN / vBBUP, while the lower portions of the PHY layers are operated by individual RAN nodes 311. This virtualization framework allows idle processor cores of the RAN nodes 311 to execute other virtualized applications. In some implementations, a separate RAN node 311 may represent a separate RAN node 311 connected to the RAN via a separate F1 interface ( Figure 3 In these implementations, the gNB-DU may include one or more remote radio heads or RFEMs (see, e.g., Figure 5), and the gNB-CU may be operated by a server (not shown) located in the RAN 310 or by a server pool in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more of the plurality of RAN nodes 311 may be a next-generation eNB (ng-eNB), which is a RAN node that provides E-UTRA user plane and control plane protocol terminations to the plurality of UEs 301 and is connected to the 5GC via an NG interface (discussed below).

[0088] In a V2X scenario, one or more of the RAN nodes 311 may be or function as an RSU. The term "roadside unit" or "RSU" may refer to any traffic infrastructure entity used for V2X communication. The RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a "UE-type RSU," an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU," an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU," and so on. In one example, an RSU is a computing device coupled to RF circuitry located on the roadside that provides connectivity support to passing vehicle UEs 301 (vUEs 301). The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9 GHz Direct Short Range Communication (DSRC) band to provide extremely low latency communications required for high-speed events, such as collision avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low latency communications as well as other cellular communication services. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communications. Some or all of the computing device and the RSU's RF circuitry may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller and / or backhaul network.

[0089] Any of the RAN nodes 311 may terminate the air interface protocol and may be the first point of contact for the UE 301. In some embodiments, any of the RAN nodes 311 may fulfill various logical functions of the RAN 310, including but not limited to the functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0090] In an embodiment, multiple UEs 301 may be configured to communicate with each other or with any of multiple RAN nodes 311 using OFDM communication signals over a multi-carrier communication channel according to various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communication) or SC-FDMA communication techniques (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiments is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0091] In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 311 to the UE 301, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink in each time slot. This type of time-frequency plane representation is common for OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes multiple resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block includes a collection of resource elements; in the frequency domain, this can represent the minimum amount of resources that can currently be allocated. Such resource blocks are used to transmit several different physical downlink channels.

[0092] According to various embodiments, the UE 301 and the RAN node 311 communicate data (e.g., transmit data and receive data) over a licensed medium (also referred to as a "licensed spectrum" and / or a "licensed band") and an unlicensed shared medium (also referred to as an "unlicensed spectrum" and / or an "unlicensed band"). The licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, while the unlicensed spectrum may include a 5 GHz band.

[0093] To operate in the unlicensed spectrum, the UE 301 and the RAN node 311 may operate using LAA, eLAA, and / or feLAA mechanisms. In these implementations, the UE 301 and the RAN node 311 may perform one or more known medium sensing operations and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed according to a listen-before-talk (LBT) protocol.

[0094] LBT is a mechanism for equipment (e.g., UE 301, RAN node 311, etc.) to sense the medium (e.g., a channel or carrier frequency) and transmit when the medium is sensed to be idle (or when a particular channel in the medium is sensed to be unoccupied). The medium sensing operation may include CCA, which utilizes at least ED to determine whether other signals are present on the channel to determine whether the channel is occupied or idle. The LBT mechanism allows cellular / LAA networks to coexist with existing systems in unlicensed spectrum and with other LAA networks. ED may include sensing RF energy over a period of time on an intended transmission band and comparing the sensed RF energy to a predefined or configured threshold.

[0095] Typically, existing systems in the 5 GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism known as CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as UE 301, AP 306, etc.) intends to transmit, the WLAN node may first perform CCA before transmitting. In addition, in the event that more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. The backoff mechanism may be a counter randomly introduced within the CWS that increases exponentially when a collision occurs and is reset to a minimum value when the transmission is successful. The LBT mechanism designed for LAA is somewhat similar to CSMA / CA for WLAN. In some implementations, the LBT process for a DL or UL transmission burst (including PDSCH or PUSCH transmission) may have an LAA contention window of variable length between X and Y ECCA slots, where X and Y are the minimum and maximum values ​​of the CWS for LAA. In one example, the minimum CWS for LAA transmissions may be 9 microseconds (μs); however, the size of the CWS and MCOT (eg, transmission burst) may be based on government regulatory requirements.

[0096] The LAA mechanism is built on the Carrier Adaptation (CA) technology of the LTE-Advanced system. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and up to five CCs can be aggregated, resulting in a maximum aggregate bandwidth of 100 MHz. In an FDD system, the number of aggregated carriers can be different for DL ​​and UL, where the number of UL CCs is equal to or lower than the number of DL component carriers. In some cases, each CC can have a different bandwidth than other CCs. In a TDD system, the number of CCs and the bandwidth of each CC are generally the same for DL ​​and UL.

[0097] CA also includes individual serving cells to provide individual CCs. The coverage of the serving cells may be different, for example, because CCs on different frequency bands will experience different path losses. The primary serving cell or PCell may provide the PCC for both UL and DL and may handle activities related to RRC and NAS. The other serving cells are called SCells, and each SCell may provide individual SCCs for both UL and DL. SCCs may be added and removed as needed, and changing the PCC may require the UE 301 to undergo a handover. In LAA, eLAA, and feLAA, some or all of the SCells may operate in unlicensed spectrum (referred to as "LAA SCells"), and the LAA SCells are assisted by the PCells operating in the licensed spectrum. When a UE is configured with more than one LAA SCell, the UE may receive UL grants on the configured LAA SCells indicating different PUSCH starting positions within the same subframe.

[0098] The PDSCH carries user data and higher layer signaling to the UE 301. The PDCCH carries, among other information, information about the transport format and resource allocation associated with the PDSCH channel. It can also inform the UE 301 about the transport format, resource allocation, and HARQ information associated with the uplink shared channel. Typically, downlink scheduling (allocation of control and shared channel resource blocks to UEs 301b within a cell) can be performed on any of the multiple RAN nodes 311 based on channel quality information fed back from any of the multiple UEs 301. Downlink resource allocation information can be sent on the PDCCH for (e.g., allocated to) each of the UEs 301.

[0099] PDCCH uses CCE to transmit control information. Before being mapped to resource elements, the PDCCH complex-valued symbols can first be organized into quadruples, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets of four physical resource elements, respectively, called REGs. Four quadrature phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the DCI and the channel conditions, one or more CCEs can be used to transmit the PDCCH. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, or 8).

[0100] Some embodiments may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some embodiments may utilize EPDCCH that uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similar to the above, each ECCE may correspond to a set of nine physical resource elements, called EREGs, including four physical resource elements. In some cases, an ECCE may have other numbers of EREGs.

[0101] RAN nodes 311 may be configured to communicate with each other via interface 312. In embodiments where system 300 is an LTE system (eg, when CN 320 is a Figure 4 4 ), the interface 312 may be an X2 interface 312. The X2 interface may be defined between two or more RAN nodes 311 (e.g., two or more eNBs, etc.) connected to the EPC 320, and / or between two eNBs connected to the EPC 320. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user packets transmitted over the X2 interface and may be used to convey information regarding the delivery of user data between eNBs. For example, the X2-U may provide specific sequence number information regarding user data transmitted from the MeNB to the SeNB; information regarding successful in-sequence delivery of PDCP PDUs for user data from the SeNB to the UE 301; information regarding PDCP PDUs that were not delivered to the UE 301; information regarding the current minimum expected buffer size at the SeNB for transmitting user data to the UE; and the like. X2-C can provide intra-LTE access mobility functions, including context transfer from the source eNB to the target eNB, user plane transmission control, etc.; load management functions; and inter-cell interference coordination functions.

[0102] In embodiments where system 300 is a 5G or NR system, interface 312 may be an Xn interface 312. The Xn interface is defined between two or more RAN nodes 311 (e.g., two or more gNBs, etc.) connected to a 5GC 320, between a RAN node 311 (e.g., a gNB) and an eNB connected to a 5GC 320, and / or between two eNBs connected to a 5GC 320. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U interface may provide non-guaranteed delivery of user plane PDUs and support / provide data forwarding and flow control functions. The Xn-C interface may provide management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 301 in connected mode (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected mode between one or more RAN nodes 311. This mobility support may include context transfer from the old (source) serving RAN node 311 to the new (target) serving RAN node 311; and control of the user plane tunnel between the old (source) serving RAN node 311 and the new (target) serving RAN node 311. The Xn-U protocol stack may include a transport network layer built on the Internet Protocol (IP) transport layer, and a GTP-U layer built on top of the UDP and / or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on SCTP. SCTP may be built on top of the IP layer and may provide guaranteed delivery of application layer messages. Within the transport IP layer, signaling PDUs are delivered using point-to-point transport. In other implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0103] RAN 310 is shown as being communicatively coupled to a core network—in this embodiment, core network (CN) 320. CN 320 may include multiple network elements 322 configured to provide various data and telecommunication services to customers / subscribers (e.g., users of UE 301) connected to CN 320 via RAN 310. Components of CN 320 may be implemented in one physical node or separate physical nodes, including components for reading and executing instructions from machine-readable media or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, NFV may be used to virtualize any or all of the aforementioned network node functions (described in further detail below) via executable instructions stored in one or more computer-readable storage media. A logical instance of CN 320 may be referred to as a network slice, and a logical instance of a portion of CN 320 may be referred to as a network sub-slice. NFV architecture and infrastructure may be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches (alternatively, performed by proprietary hardware). In other words, the NFV system can be used to perform virtual or reconfigurable implementations of one or more EPC components / functions.

[0104] Generally speaking, the application server 330 may be an element that provides applications that use IP bearer resources with the core network (e.g., UMTS PS domain, LTE PS data services, etc.). The application server 330 may also be configured to support one or more communication services for the UE 301 via the EPC 320 (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.).

[0105] In an embodiment, CN 320 may be a 5GC (referred to as "5GC 320" or the like), and RAN 310 may be connected to CN 320 via an NG interface 313. In an embodiment, NG interface 313 may be divided into two parts: an NG user plane (NG-U) interface 314, which carries traffic data between RAN node 311 and UPF; and an S1 control plane (NG-C) interface 315, which is a signaling interface between RAN node 311 and AMF.

[0106] In an embodiment, CN 320 may be a 5G CN (referred to as "5GC 320," etc.), while in other embodiments, CN 320 may be an EPC. In the case where CN 320 is an EPC (referred to as "EPC 320," etc.), RAN 310 may be connected to CN 320 via an S1 interface 313. In an embodiment, S1 interface 313 may be divided into two parts: an S1 user plane (S1-U) interface 314, which carries traffic data between RAN node 311 and S-GW; and an S1-MME interface 315, which is a signaling interface between RAN node 311 and MME.

[0107] Figure 4 FIG. 4 shows an exemplary architecture of a system 400 including a first CN 420 according to various embodiments. In this example, the system 400 may implement the LTE standard, wherein the CN 420 is a Figure 3 In addition, UE 401 can communicate with Figure 3 The UE 301 is the same as or similar to the UE 301, and the E-UTRAN 410 can be Figure 3 The CN 420 may be the same as or similar to the RAN 310 of the mobile network, and may include the RAN node 311 discussed previously. The CN 420 may include an MME 421, an S-GW 422, a P-GW 423, an HSS 424, and an SGSN 425.

[0108] MME 421 can be functionally similar to the control plane of a traditional SGSN and can implement MM functionality to keep track of the current location of UE 401. MME 421 can perform various MM procedures to manage mobility aspects of access, such as gateway selection and tracking area list management. MM (also known as "EPS MM" or "EMM" in E-UTRAN systems) can refer to all applicable procedures, methods, data stores, etc. used to maintain knowledge of the current location of UE 401, provide user identity confidentiality to users / subscribers, and / or perform other similar services. Each UE 401 and MME 421 can include an MM or EMM sublayer, and upon successful completion of the attach procedure, an MM context can be established in both UE 401 and MME 421. An MM context can be a data structure or database object that stores MM-related information for UE 401. MME 421 can be coupled to HSS 424 via the S6a reference point, to SGSN 425 via the S3 reference point, and to S-GW 422 via the S11 reference point.

[0109] SGSN 425 may be a node that serves UE 401 by tracking the location of individual UE 401 and performing security functions. Furthermore, SGSN 425 may perform inter-EPC node signaling for mobility between 2G / 3G and E-UTRAN 3GPP access networks; PDN and S-GW selection as specified by MME 421; handling of UE 401 time zone capabilities as specified by MME 421; and MME selection for handover to E-UTRAN 3GPP access networks. The S3 reference point between MME 421 and SGSN 425 may enable user and bearer information exchange for inter-3GPP access network mobility in idle and / or active states.

[0110] HSS 424 may include a database for network users, including subscription-related information used to support network entities handling communication sessions. EPC 420 may include one or several HSSs 424, depending on the number of mobile subscribers, device capabilities, network organization, and the like. For example, HSS 424 may provide support for routing / roaming, authentication, authorization, naming / addressing solutions, location dependencies, and the like. The S6a reference point between HSS 424 and MME 421 may enable the transfer of subscription and authentication data for authenticating / authorizing users to access EPC 420 between HSS 424 and MME 421.

[0111] The S-GW 422 may terminate the S1 interface 313 towards the RAN 410 (at Figure 4 The S-GW 422 is a RAN-based mobile gateway ("S1-U") and routes data packets between the RAN 410 and the EPC 420. Additionally, the S-GW 422 can be the local mobility anchor for inter-RAN node handovers and can also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and enforcing certain policies. The S11 reference point between the S-GW 422 and the MME 421 can provide the control plane between the MME 421 and the S-GW 422. The S-GW 422 can be coupled to the P-GW 423 via the S5 reference point.

[0112] The P-GW 423 may terminate the SGi interface towards the PDN 430. The P-GW 423 may communicate with the PDN 430 via the IP interface 325 (see, e.g., Figure 3 ) routes data packets between EPC 420 and external networks such as a network including application server 330 (alternatively referred to as "AF"). In an embodiment, P-GW 423 can communicate via IP communication interface 325 (see, e.g., Figure 3 ) is communicatively coupled to an application server ( Figure 3 Application server 330 or Figure 4430). The S5 reference point between the P-GW 423 and the S-GW 422 may provide user plane tunneling and tunnel management between the P-GW 423 and the S-GW 422. The S5 reference point may also be used for S-GW 422 relocation due to the mobility of the UE 401 and whether the S-GW 422 needs to connect to a non-collocated P-GW 423 for the required PDN connectivity. The P-GW 423 may also include nodes for policy enforcement and charging data collection, such as a PCEF (not shown). Additionally, the SGi reference point between the P-GW 423 and the packet data network (PDN) 430 may be an operator external public, private PDN, or an intra-operator packet data network, for example, for providing IMS services. The P-GW 423 may be coupled to the PCRF 426 via a Gx reference point.

[0113] PCRF 426 is the policy and charging control element of EPC 420. In a non-roaming scenario, a single PCRF 426 may exist in the Home Public Land Mobile Network (HPLMN) associated with UE 401's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local traffic breakout, two PCRFs may be associated with UE 401's IP-CAN session: a Home PCRF (H-PCRF) in the HPLMN and a Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). PCRF 426 may be communicatively coupled to application server 430 via P-GW 423. Application server 430 may signal PCRF 426 to indicate a new service flow and select appropriate QoS and charging parameters. PCRF 426 may configure the rules to a PCEF (not shown) with the appropriate TFT and QCI, which initiates QoS and charging as specified by application server 430. The Gx reference point between PCRF 426 and P-GW 423 may allow for the transfer of QoS policies and charging rules from PCRF 426 to PCEF in P-GW 423. The Rx reference point may reside between PDN 430 (or "AF 430") and PCRF 426.

[0114] Figure 5 An example of infrastructure equipment 500 according to various embodiments is shown. Infrastructure equipment 500 (or "system 500") can be implemented as a base station, a radio head, a RAN node (such as the RAN node 311 and / or AP 306 shown and described previously), an application server 330, and / or any other element / device discussed herein. In other examples, system 500 can be implemented in or by a UE.

[0115] System 500 includes application circuitry 505, baseband circuitry 510, one or more radio front-end modules (RFEMs) 515, memory circuitry 520, a power management integrated circuit (PMIC) 525, power tee circuitry 530, network controller circuitry 535, a network interface connector 540, satellite positioning circuitry 545, and a user interface 550. In some embodiments, device 500 may include additional components such as, for example, memory / storage, a display, a camera, sensors, or input / output (I / O) interfaces. In other embodiments, the components described below may be included in more than one device. For example, the circuitry described may be separately included in more than one device for a CRAN, vBBU, or other similar implementation.

[0116] The application circuit 505 includes circuits such as, but not limited to, one or more processors (or processor cores), cache memory, and one or more of the following: a low dropout voltage regulator (LDO), an interrupt controller, a serial interface such as SPI, I2C, or a general-purpose programmable serial interface module, a real-time clock (RTC), a timer-counter including an interval timer and a watchdog timer, general-purpose input / output (I / O or IO), a memory card controller such as a Secure Digital (SD) Multimedia Card (MMC) or similar product, a Universal Serial Bus (USB) interface, a Mobile Industry Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. The processor (or core) of the application circuit 505 may be coupled to or include a memory / storage element and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on the system 500. In some implementations, the memory / storage element can be an on-chip memory circuit that can include any suitable volatile and / or non-volatile memory, such as DRAM, SRAM, EPROM, EEPROM, flash memory, solid-state memory, and / or any other type of memory device technology, such as those discussed herein.

[0117] The processor of the application circuit 505 may include, for example, one or more processor cores (CPUs), one or more application processors, one or more graphics processing units (GPUs), one or more reduced instruction set computing (RISC) processors, one or more Acorn RISC Machine (ARM) processors, one or more complex instruction set computing (CISC) processors, one or more digital signal processors (DSPs), one or more FPGAs, one or more PLDs, one or more ASICs, one or more microprocessors or controllers, or any suitable combination thereof. In some embodiments, the application circuit 505 may include or may be a dedicated processor / controller for operating in accordance with various embodiments herein. As an example, the processor of the application circuit 505 may include one or more Apple A series processors, Intel or Processor; Advanced Micro Devices (AMD) Processor, Accelerated Processing Unit (APU), or processors; ARM Holdings, Ltd. licensed ARM-based processors, such as the ARM Cortex-A series processors provided by Cavium (TM), Inc. and MIPS-based designs from MIPS Technologies, Inc., such as the MIPS Warrior P-class processor; etc. In some embodiments, system 500 may not utilize application circuitry 505 and instead may include a dedicated processor / controller to process IP data received, for example, from an EPC or 5GC.

[0118] In some implementations, the application circuit 505 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices, and the like. The one or more hardware accelerators may include, for example, computer vision (CV) and / or deep learning (DL) accelerators. For example, the programmable processing device may be one or more field programmable devices (FPDs), such as field programmable gate arrays (FPGAs); programmable logic devices (PLDs), such as complex PLDs (CPLDs) and high-capacity PLDs (HCPLDs); ASICs, such as structured ASICs; programmable SoCs (PSoCs); and the like. In such embodiments, the circuitry of the application circuit 505 may include logic blocks or logic structures, as well as other interconnected resources that can be programmed to perform various functions, such as the processes, methods, functions, and the like of the various embodiments discussed herein. In such embodiments, the circuitry of the application circuit 505 may include memory cells (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, static memory (e.g., static random access memory (SRAM), antifuse), and the like) for storing the logic blocks, logic structures, data, and the like in a lookup table (LUT) or the like.

[0119] Baseband circuit 510 may be implemented, for example, as a solder-in substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board, or a multi-chip module containing two or more integrated circuits.

[0120] The user interface circuitry 550 may include one or more user interfaces designed to enable a user to interact with the system 500 or a peripheral component interface designed to enable a peripheral component to interact with the system 500. The user interface may include, but is not limited to, one or more physical or virtual buttons (e.g., a reset button), one or more indicators (e.g., light emitting diodes (LEDs)), a physical keyboard or keypad, a mouse, a touchpad, a touch screen, a speaker or other audio emitting device, a microphone, a printer, a scanner, a headset, a display screen or display device, etc. The peripheral component interface may include, but is not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power port, etc.

[0121] The radio front-end module (RFEM) 515 may include a millimeter-wave (mmWave) RFEM and one or more sub-millimeter-wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter-wave RFICs may be physically separate from the mmWave RFEM. The RFIC may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both mmWave and sub-millimeter-wave radio functionality may be implemented in the same physical RFEM 515, incorporating both mmWave antennas and sub-millimeter-wave antennas.

[0122] The memory circuit 520 may include one or more of the following: a volatile memory including a dynamic random access memory (DRAM) and / or a synchronous dynamic random access memory (SDRAM), and a non-volatile memory (NVM) including a high-speed electrically erasable memory (commonly referred to as a "flash memory"), a phase change random access memory (PRAM), a magnetoresistive random access memory (MRAM), etc., and may be combined with and The memory circuit 520 may be implemented as one or more of the following: a solder-in package integrated circuit, a socket memory module, and a plug-in memory card.

[0123] The PMIC 525 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources, such as batteries or capacitors. The power alarm detection circuit may detect one or more of a brownout (undervoltage) and a surge (overvoltage) condition. The power tee circuit 530 may provide power drawn from the network cable to provide both power and data connectivity for the infrastructure equipment 500 using a single cable.

[0124] The network controller circuit 535 can provide connectivity to the network using a standard network interface protocol such as Ethernet, Ethernet based on a GRE tunnel, Ethernet based on Multi-Protocol Label Switching (MPLS), or some other suitable protocol. Network connectivity can be provided to / from the infrastructure equipment 500 via the network interface connector 540 using a physical connection, which can be an electrical connection (commonly referred to as a "copper interconnect"), an optical connection, or a wireless connection. The network controller circuit 535 may include one or more dedicated processors and / or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the network controller circuit 535 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0125] The positioning circuit 545 includes circuits for receiving and decoding signals transmitted / broadcasted by the positioning network of the global satellite navigation system (GNSS). Examples of navigation satellite constellations (or GNSS) include the United States' Global Positioning System (GPS), Russia's Global Navigation System (GLONASS), the European Union's Galileo system, China's BeiDou Navigation Satellite System, regional navigation systems or GNSS augmentation systems (e.g., navigation using the Indian constellation (NAVIC), Japan's Quasi-Zenith Satellite System (QZSS), France's Doppler Orbit Chart and Satellite Integrated Radio Positioning (DORIS), etc.). The positioning circuit 545 includes various hardware elements (e.g., including hardware devices such as switches, filters, amplifiers, antenna elements, etc. for facilitating OTA communication) to communicate with components of the positioning network such as navigation satellite constellation nodes. In some embodiments, the positioning circuit 545 may include a micro technology (micro PNT) IC for positioning, navigation, and timing that uses a master timing clock to perform position tracking / estimation without GNSS assistance. The positioning circuit 545 may also be part of or interact with the baseband circuit 510 and / or RFEM 515 to communicate with nodes and components of the positioning network. The positioning circuit 545 may also provide location data and / or time data to the application circuit 505, which may use the data to synchronize operations with various infrastructure (e.g., RAN node 311, etc.).

[0126] Figure 5 The components shown can communicate with each other using interface circuitry that can include any number of bus and / or interconnect (IX) technologies, such as Industry Standard Architecture (ISA), Extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI express (PCIe), or any number of other technologies. The bus / IX can be a proprietary bus, such as used in SoC-based systems. Other bus / IX systems can be included, such as an I2C interface, an SPI interface, a point-to-point interface, and a power bus, among others.

[0127] Figure 6 1 shows various protocol functions that may be implemented in a wireless communication device according to some embodiments. Specifically, Figure 6 The present invention includes an arrangement 600 showing the interconnection between various protocol layers / entities. The present invention provides various protocol layers / entities for operating in conjunction with the 5G / NR system standard and the LTE system standard. Figure 6 The following description, but Figure 6 Some or all aspects of the present invention may also be applicable to other wireless communication network systems.

[0128] In addition to other higher layer functionality not shown, the protocol layers of arrangement 600 may include one or more of PHY 610, MAC 620, RLC 630, PDCP 640, SDAP 647, RRC 655, and NAS layer 657. These protocol layers may include one or more service access points (e.g., Figure 6 Items 659, 656, 650, 649, 645, 635, 625, and 615).

[0129] PHY 610 can send and receive physical layer signals 605, which can be received from or sent to one or more other communication devices. Physical layer signals 605 may include one or more physical channels, such as those discussed herein. PHY 610 may also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes) and other measurements used by higher layers (e.g., RRC 655). PHY 610 may further perform error detection on transport channels, forward error correction (FEC) encoding / decoding of transport channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping to physical channels, and MIMO antenna processing. In an embodiment, an instance of PHY 610 may process a request from an instance of MAC 620 via one or more PHY-SAP 615 and provide an indication thereto. According to some embodiments, the request and indication transmitted via PHY-SAP 615 may include one or more transport channels.

[0130] Instances of MAC 620 may process requests from instances of RLC 630 via one or more MAC-SAPs 625 and provide instructions thereto. These requests and instructions transmitted via MAC-SAP 625 may include one or more logical channels. MAC 620 may perform mapping between logical channels and transport channels, multiplexing MAC SDUs from one or more logical channels onto TBs to be delivered to PHY 610 via transport channels, demultiplexing MAC SDUs from TBs delivered from PHY 610 via transport channels onto one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction via HARQ, and logical channel prioritization.

[0131] Instances of RLC 630 may process requests from instances of PDCP 640 and provide indications thereto via one or more Radio Link Control Service Access Points (RLC-SAPs) 635. These requests and indications conveyed via RLC-SAPs 635 may include one or more logical channels. RLC 630 may operate in multiple modes of operation, including Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). RLC 630 may perform transmission of upper layer protocol data units (PDUs), error correction via Automatic Repeat Request (ARQ) for AM data transmission, and concatenation, segmentation, and reassembly of RLC SDUs for UM and AM data transmission. RLC 630 may also resegment RLC data PDUs for AM data transmission, reorder RLC data PDUs for UM and AM data transmission, detect duplicate data for UM and AM data transmission, discard RLC SDUs for UM and AM data transmission, detect protocol errors for AM data transmission, and perform RLC re-establishment.

[0132] An instance of PDCP 640 may process requests from an instance of RRC 655 and / or an instance of SDAP 647 via one or more Packet Data Convergence Protocol Service Points (PDCP-SAPs) 645 and provide instructions thereto. These requests and instructions conveyed via PDCP-SAP 645 may include one or more radio bearers. PDCP 640 may perform header compression and decompression of IP data, maintain PDCP sequence numbers (SNs), enforce in-sequence delivery of upper layer PDUs upon lower layer reestablishment, eliminate duplication of lower layer SDUs upon lower layer reestablishment for radio bearers mapped on RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification on control plane data, control timer-based data discard, and perform security operations (e.g., encrypting, decrypting, integrity protection, integrity verification, etc.).

[0133] An instance of SDAP 647 can process requests from one or more higher layer protocol entities via one or more SDAP-SAPs 649 and provide instructions thereto. These requests and instructions transmitted via SDAP-SAP 649 may include one or more QoS flows. SDAP 647 can map QoS flows to DRBs and vice versa, and can also mark the QFI in DL packets and UL packets. A single SDAP entity 647 can be configured for a separate PDU session. In the UL direction, NG-RAN 310 can control the mapping of QoS flows to DRBs in two different ways: reflective mapping or explicit mapping. For reflective mapping, the SDAP 647 of UE 301 can monitor the QFI of the DL packets of each DRB and apply the same mapping to packets flowing in the UL direction. For a DRB, the SDAP 647 of UE 301 can map the UL packets belonging to a QoS flow that corresponds to the QoS flow ID and PDU session observed in the DL packets of that DRB. To implement reflective mapping, the NG-RAN may tag DL packets with a QoS flow ID over the Uu interface. Explicit mapping may involve RRC 655 configuring SDAP 647 with explicit mapping rules for QoS flows to DRBs, which may be stored and followed by SDAP 647. In an embodiment, SDAP 647 may only be used in NR implementations and may not be used in LTE implementations.

[0134] The RRC 655 may configure aspects of one or more protocol layers, which may include one or more instances of the PHY 610, MAC 620, RLC 630, PDCP 640, and SDAP 647, via one or more Management Service Access Points (M-SAPs). In an embodiment, instances of the RRC 655 may process requests from one or more NAS entities 657 and provide instructions thereto via one or more RRC-SAPs 656. Primary services and functions of the RRC 655 may include broadcasting of system information (e.g., included in a MIB or SIB related to the NAS), broadcasting of system information related to the access stratum (AS), paging, establishment, maintenance, and release of the RRC connection between the UE 301 and the RAN 310 (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, inter-RAT mobility, and measurement configuration for UE measurement reporting. These MIBs and SIBs may include one or more IEs, each of which may include a separate data field or data structure.

[0135] NAS 657 may form the highest layer of the control plane between UE 301 and AMF. NAS 657 may support the mobility and session management procedures of UE 301 to establish and maintain an IP connection between UE 301 and P-GW in the LTE system.

[0136] According to various embodiments, one or more protocol entities of arrangement 600 may be implemented in a UE 301, a RAN node 311, an AMF in a NR implementation or an MME 421 in an LTE implementation, a UPF in a NR implementation or an S-GW 422 and P-GW 423 in an LTE implementation, etc., for use in a control plane or user plane communication protocol stack between the aforementioned devices. In such embodiments, one or more protocol entities implemented in one or more of the UE 301, the gNB 311, the AMF, etc. may communicate with corresponding peer protocol entities implemented in or on another device (using the services of corresponding lower layer protocol entities to perform such communication). In some embodiments, the gNB-CU of the gNB 311 may host the RRC 655, SDAP 647, and PDCP 640 of the gNB that controls the operation of one or more gNB-DUs, and the gNB-DUs of the gNB 311 may each host the RLC 630, MAC 620, and PHY 610 of the gNB 311.

[0137] In a first example, the control plane protocol stack may include, in order from highest layer to lowest layer, NAS 657, RRC 655, PDCP 640, RLC 630, MAC 620, and PHY 610. In this example, upper layers 660 may be built on top of NAS 657, including an IP layer 661, SCTP 662, and an application layer signaling protocol (AP) 663.

[0138] In an NR specific implementation, the AP 663 can be an NG application protocol layer (NGAP or NG-AP) 663 for the NG interface 313 defined between the NG-RAN node 311 and the AMF, or the AP 663 can be an Xn application protocol layer (XnAP or Xn-AP) 663 for the Xn interface 312 defined between two or more RAN nodes 311.

[0139] The NG-AP 663 may support the functionality of the NG interface 313 and may include an elementary procedure (EP). The NG-AP EP may be an interaction unit between the NG-RAN point 311 and the AMF. NG-AP 663 services may include two groups: UE-associated services (e.g., services related to the UE 301) and non-UE-associated services (e.g., services related to the entire NG interface instance between the NG-RAN node 311 and the AMF). These services may include functions including, but not limited to: a paging function for sending a paging request to an NG-RAN node 311 involved in a specific paging area; a UE context management function for allowing the AMF to establish, modify and / or release the UE context in the AMF and the NG-RAN node 311; a mobility function for the UE 301 in ECM-CONNECTED mode, for intra-system HO to support mobility within the NG-RAN, and for inter-system HO to support mobility from / to the EPS system; a NAS signaling transport function for transferring or rerouting NAS messages between the UE 301 and the AMF; a NAS node selection function for determining the association between the AMF and the UE 301; an NG interface management function for setting up the NG interface and monitoring errors over the NG interface; a warning message sending function for providing a means to transfer a warning message via the NG interface or to cancel an ongoing warning message broadcast; a configuration transfer function for requesting and transferring RAN configuration information (e.g., SON information, performance measurement (PM) data, etc.) between two RAN nodes 311 via the CN 320; and / or other similar functions.

[0140] The XnAP 663 may support the functionality of the Xn interface 312 and may include XnAP basic mobility procedures and XnAP global procedures. The XnAP basic mobility procedures may include procedures for handling UE mobility within the NG RAN 311 (or E-UTRAN 410), such as handover preparation and cancellation procedures, SN status transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, and procedures related to dual connectivity. The XnAP global procedures may include procedures unrelated to a specific UE 301, such as Xn interface setup and reset procedures, NG-RAN update procedures, and cell activation procedures.

[0141] In an LTE implementation, the AP 663 may be an S1 application protocol layer (S1-AP) 663 for the S1 interface 313 defined between the E-UTRAN node 311 and the MME, or the AP 663 may be an X2 application protocol layer (X2AP or X2-AP) 663 for the X2 interface 312 defined between two or more E-UTRAN nodes 311.

[0142] The S1 application protocol layer (S1-AP) 663 may support the functionality of the S1 interface, and similar to the NG-AP discussed previously, the S1-AP may include an S1-AP EP. The S1-AP EP may be the interaction unit between the E-UTRAN node 311 and the MME 421 within the LTE CN 320. S1-AP 663 services may include two groups: UE-associated services and non-UE-associated services. These services perform functions including, but not limited to, E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling, RAN Information Management (RIM), and configuration transfer.

[0143] The X2AP 663 may support the functionality of the X2 interface 312 and may include X2AP basic mobility procedures and X2AP global procedures. The X2AP basic mobility procedures may include procedures for handling UE mobility within the E-UTRAN 320, such as handover preparation and cancellation procedures, SN status transfer procedures, UE context retrieval and UE context release procedures, RAN paging procedures, and procedures related to dual connectivity. The X2AP global procedures may include procedures unrelated to a specific UE 301, such as X2 interface setup and reset procedures, load indication procedures, error indication procedures, and cell activation procedures.

[0144] The SCTP layer (alternatively referred to as the SCTP / IP layer) 662 can provide guaranteed delivery of application layer messages (e.g., NGAP or XnAP messages in NR implementations, or S1-AP or X2AP messages in LTE implementations). SCTP 662 can ensure reliable delivery of signaling messages between the RAN node 311 and the AMF / MME 421 based in part on the IP protocol supported by IP 661. The Internet Protocol layer (IP) 661 can be used to perform packet addressing and routing functions. In some implementations, the IP layer 661 can use point-to-point transport to deliver and transmit PDUs. In this regard, the RAN node 311 can include L2 and L1 layer communication links (e.g., wired or wireless) with the MME / AMF to exchange information.

[0145] In a second example, the user plane protocol stack may include, in order from highest layer to lowest layer, SDAP 647, PDCP 640, RLC 630, MAC 620, and PHY 610. The user plane protocol stack may be used for communication between UE 301, RAN node 311, and UPF in an NR implementation, or for communication between S-GW 422 and P-GW 423 in an LTE implementation. In this example, upper layers 651 may be built on top of SDAP 647 and may include a user datagram protocol (UDP) and IP security layer (UDP / IP) 652, a general packet radio service (GPRS) tunneling protocol for a user plane layer (GTP-U) 653, and a user plane PDU layer (UP PDU) 663.

[0146] The transport network layer 654 (also referred to as the "transport layer") may be built on an IP transport, and the GTP-U 653 may be used on top of the UDP / IP layer 652 (including the UDP layer and the IP layer) to carry user plane PDUs (UP-PDUs). The IP layer (also referred to as the "Internet layer") may be used to perform packet addressing and routing functions. The IP layer may assign IP addresses to user data packets in any of the IPv4, IPv6, or PPP formats, for example.

[0147] GTP-U 653 can be used to carry user data within the GPRS core network and between the radio access network and the core network. For example, the transmitted user data can be packets in any of the IPv4, IPv6, or PPP formats. UDP / IP 652 can provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication for selected data flows. The RAN node 311 and the S-GW 422 can exchange user plane data using the S1-U interface via a protocol stack including the L1 layer (e.g., PHY 610), the L2 layer (e.g., MAC 620, RLC 630, PDCP 640, and / or SDAP 647), the UDP / IP layer 652, and the GTP-U 653. The S-GW 422 and the P-GW 423 can exchange user plane data using the S5 / S8a interface via a protocol stack including the L1 layer, the L2 layer, the UDP / IP layer 652, and the GTP-U 653. As previously discussed, the NAS protocol may support mobility and session management procedures of the UE 301 to establish and maintain an IP connection between the UE 301 and the P-GW 423 .

[0148] In addition, despite Figure 6Not shown, an application layer may exist above the AP 663 and / or transport network layer 654. The application layer may be the layer where a user of the UE 301, RAN node 311, or other network element interacts with, for example, a software application executed by the application circuitry 505. The application layer may also provide one or more interfaces for the software application to interact with the communication system of the UE 301 or RAN node 311. In some implementations, the IP layer and / or the application layer may provide functionality that is the same as or similar to layers 5 through 7 of the Open Systems Interconnection (OSI) model, or portions thereof (e.g., OSI layer 7—application layer, OSI layer 6—presentation layer, and OSI layer 5—session layer).

[0149] Figure 7 is a block diagram illustrating components capable of reading instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some exemplary embodiments. Specifically, Figure 7 A schematic diagram of hardware resources 700 is shown, including one or more processors (or processor cores) 710, one or more memory / storage devices 720, and one or more communication resources 730, each of which may be communicatively coupled via a bus 740. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 702 may be executed to provide an execution environment in which one or more network slices / subslices utilize the hardware resources 700.

[0150] Processor 710 may include, for example, processor 712 and processor 714. Processor 710 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0151] The memory / storage device 720 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 720 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state storage, etc.

[0152] The communication resources 730 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 704 or one or more databases 706 via the network 708. For example, the communication resources 730 may include a wired communication component (e.g., for coupling via USB), a cellular communication component, an NFC component, (or Low power consumption) components, components and other communication components.

[0153] The instructions 750 may include software, a program, an application, an applet, an application, or other executable code for causing at least one of the processors 710 to perform any one or more of the methodologies discussed herein. The instructions 750 may reside, in whole or in part, within at least one of the processor 710 (e.g., within a cache memory of the processor), the memory / storage device 720, or any suitable combination thereof. Furthermore, any portion of the instructions 750 may be transmitted to the hardware resources 700 from any combination of the peripheral device 704 or the database 706. Thus, the memory of the processor 710, the memory / storage device 720, the peripheral device 704, and the database 706 are examples of computer-readable and machine-readable media.

Claims

1. A method for wireless communication, the method comprising: receiving a radio resource control (RRC) message from an integrated access and backhaul (IAB) central unit node, the RRC message including an uplink-downlink configuration setting; determining, at least in part, a new resource availability configuration for backhaul resources associated with an IAB node using the uplink-downlink configuration settings from the RRC message, wherein the new resource availability configuration includes a hard resource availability bitmap and a soft resource availability bitmap, the hard resource availability bitmap and the soft resource availability bitmap each having one or more bits corresponding to different backhaul resources associated with the IAB node; and In response to determining the new resource availability configuration, conditionally communicating with the IAB central unit node via the backhaul resource according to the new resource availability configuration, Each of the one or more bits in the hard resource availability bitmap indicates whether the corresponding backhaul resource is a hard resource, each of the one or more bits in the soft resource availability bitmap indicates whether the corresponding backhaul resource is a soft resource, and a backhaul resource that is not indicated as a hard resource in the hard resource availability bitmap and is not indicated as a soft resource in the soft resource availability bitmap is an unavailable resource.

2. The method of claim 1 , wherein the new resource availability configuration defines the backhaul resource as hard available, and wherein communicating with the IAB central unit node via the backhaul resource according to the new resource availability configuration comprises making the backhaul resource unconditionally available for transmitting backhaul data.

3. The method of claim 1 , wherein the new resource availability configuration defines the backhaul resource as softly available, and wherein communicating with the IAB central unit node via the backhaul resource according to the new resource availability configuration comprises making the backhaul resource conditionally available for transmitting backhaul data.

4. The method of claim 1 , wherein the new resource availability configuration defines the backhaul resource as softly available, and wherein communicating with the IAB central unit node via the backhaul resource in accordance with the new resource availability configuration comprises making the backhaul resource unavailable for transmitting backhaul data.

5. The method of claim 1 , wherein a value of 1 in a bit in the hard resource availability bitmap indicates that the corresponding resource is unconditionally available for transmitting backhaul data, and a value of 1 in a bit in the soft resource availability bitmap indicates that the corresponding resource is conditionally available for transmitting backhaul data. 6 . The method of claim 5 , wherein a value of 0 in a bit in both the hard resource availability bitmap and the soft resource availability bitmap indicates that the corresponding resource is unavailable for transmitting backhaul data.

7. The method of claim 1, wherein the backhaul resources comprise one or more of: an uplink symbol, a downlink symbol, an uplink time slot, or a downlink time slot.

8. The method of claim 1, wherein the uplink-downlink configuration setting includes a number of symbols in the new resources that are hard resources or soft resources.

9. A method for wireless communication, the method comprising: determining, by an integrated access and backhaul (IAB) central unit node, a new resource availability configuration for backhaul resources associated with an IAB node, wherein the new resource availability configuration comprises a hard resource availability bitmap and a soft resource availability bitmap, the hard resource availability bitmap and the soft resource availability bitmap each having one or more bits corresponding to different backhaul resources associated with the IAB node; generating a radio resource control (RRC) message in response to determining the new resource availability configuration, the RRC message including the new resource availability configuration for the backhaul resources in an uplink-downlink configuration setup; as well as transmitting the RRC message including the uplink-downlink configuration setting to the IAB node, Each of the one or more bits in the hard resource availability bitmap indicates whether the corresponding backhaul resource is a hard resource, each of the one or more bits in the soft resource availability bitmap indicates whether the corresponding backhaul resource is a soft resource, and a backhaul resource that is not indicated as a hard resource in the hard resource availability bitmap and is not indicated as a soft resource in the soft resource availability bitmap is an unavailable resource.

10. The method of claim 9, wherein the new resource availability configuration defines the backhaul resource as hard available, and wherein the new resource availability configuration directs the IAB node to make the backhaul resource unconditionally available for transmitting backhaul data.

11. The method of claim 9, wherein the new resource availability configuration defines the backhaul resource as softly available, and wherein the new resource availability configuration directs the IAB node to make the backhaul resource conditionally available for transmitting backhaul data.

12. The method of claim 9, wherein the new resource availability configuration defines the backhaul resource as unavailable, and wherein the new resource availability configuration directs the IAB node to make the backhaul resource unavailable for transmitting backhaul data.

13. The method of claim 9, wherein a value of 1 in a bit in the hard resource availability bitmap indicates that the corresponding resource is unconditionally available for transmitting backhaul data, and a value of 1 in a bit in the soft resource availability bitmap indicates that the corresponding resource is conditionally available for transmitting backhaul data.

14. The method of claim 13, wherein a value of 0 in a bit in both the hard resource availability bitmap and the soft resource availability bitmap indicates that the corresponding resource is unavailable for transmitting backhaul data.

15. The method of claim 9, wherein the backhaul resources comprise one or more of: an uplink symbol, a downlink symbol, an uplink time slot, or a downlink time slot.

16. The method of claim 9, comprising, at least in part in response to transmitting the RRC message including the uplink-downlink configuration setting to the IAB node, communicating with the IAB node via the backhaul resources according to the new resource availability configuration.

17. An apparatus for integrating access and backhaul (IAB) networks, the apparatus comprising a non-transitory computer-readable storage device having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a radio resource control (RRC) message from the IAB central unit node, the RRC message including an uplink-downlink configuration setting; determining, at least in part, a new resource availability configuration for backhaul resources associated with an IAB node using the uplink-downlink configuration settings from the RRC message, wherein the new resource availability configuration includes a hard resource availability bitmap and a soft resource availability bitmap, the hard resource availability bitmap and the soft resource availability bitmap each having one or more bits corresponding to different backhaul resources associated with the IAB node; and In response to determining the new resource availability configuration, conditionally communicating with the IAB central unit node via the backhaul resource according to the new resource availability configuration, Each of the one or more bits in the hard resource availability bitmap indicates whether the corresponding backhaul resource is a hard resource, each of the one or more bits in the soft resource availability bitmap indicates whether the corresponding backhaul resource is a soft resource, and a backhaul resource that is not indicated as a hard resource in the hard resource availability bitmap and is not indicated as a soft resource in the soft resource availability bitmap is an unavailable resource.

18. The apparatus of claim 17, wherein the new resource availability configuration defines the backhaul resource as hard available, and wherein communicating with the IAB central unit node via the backhaul resource according to the new resource availability configuration comprises making the backhaul resource unconditionally available for transmitting backhaul data.

Images