RELATED APPLICATIONS

[0001] This application claims the benefits of priority of U.S. Provisional Patent Application No. 63/093,553, entitled “Parent control of timing alignment for case-6” and filed at the United States Patent and Trademark Office on October 19, 2020, the content of which is incorporated herein by reference.

TECHNICAL FIELD

[0002] The present description generally relates to wireless communication systems and more specifically to parent control of timing aligning and simultaneous transmissions in an Integrated Access Backhaul (IAB) network.

BACKGROUND

[0003] In Third Generation Partnership Project (3 GPP) Release (Rel)-17, there is a new Work Item (WI) on enhancement to IAB (3GPP RP-193251- December 2019) based on 3GPP Rel-16 IAB WID (3GPP RP-200084) and the earlier study item documented in 3GPP TR 38.874 V16.0.0. The purpose of IAB is to replace existing wired backhaul or a wireless backhaul with flexible wireless backhaul using the existing 3 GPP bands providing not only backhaul but also existing cellular services in the same node.

[0004] Each IAB node holds a Distributed Unit (DU) function and a Mobile Termination (MT) function as shown in a reference architecture in FIG. 1 (also depicted in 6.3.1-1 in 3GPP TR38.874, VI 6.0.0). Via the MT, the lAB-node connects to an upstream IAB node, which could also be a donor node (see 3GPP TR 38.874, V16.0.0). Via the DU, the IAB node establishes Radio Link Control (RLC) channels to MTs of downstream IAB nodes or provides access links to User Equipment (UEs). FIG. 1 conceptually shows the possible connections for an IAB node, including access link to UEs and backhaul links to both an upstream parent and a downstream child IAB node.

[0005] An IAB node carries out two types of transmissions:

[0006] - IAB-MT uplink (UL) transmissions towards the parent node, and

[0007] - IAB-DU downlink (DL) transmissions towards devices and child IAB nodes.

[0008] An lAB-node also carries out two types of receptions: [0009] - IAB-MT DL receptions from the parent IAB-DU transmissions, and

[0010] - IAB-DU UL receptions from devices and child IAB-MT transmissions.

[0011] Typically, an IAB-MT transmission or reception is determined by the parent IAB-DU, while an IAB-DU transmission or reception to and from a UE or child lAB-node are under the control of the lAB-node. In many ways, the IAB-MT acts as a UE towards its parent IAB-DU and much of its behaviour is inherited from normal UE behaviour. As such, the parent IAB-DU controls an IAB-MT in terms of transmit power, timing and scheduling both for its UL and DL. The lAB-node has the corresponding control over its child lAB-nodes and UEs that are connected to it.

[0012] Different cases of transmission timing alignment across lAB-nodes and lAB-donors have been considered. 3GPP TR 38.874, V16.0.0 lists, amongst others, the following:

[0013] - Case #1: DL transmission timing alignment across lAB-nodes and lAB-donors: i. If DL Transmission (TX) and UL Reception (RX) are not well aligned at the parent node, additional information about the alignment is needed for the child node to properly set its DL TX timing for Over the Air (OTA)-based timing & synchronization.

[0014] - Case #2: DL and UL transmission timing is aligned within an lAB-node;

[0015] - Case #3: DL and UL reception timing is aligned within an lAB-node;

[0016] - Case #6 (Case#l DL transmission timing + Case #2 UL transmission timing): i. The DL transmission timing for all lAB-nodes is aligned with the parent IAB- node or donor DL timing; ii. The UL transmission timing of an lAB-node can be aligned with the IAB- node's DL transmission timing.

[0017] - Case #7 (Case#l DL transmission timing + Case #3 UL reception timing): i. The DL transmission timing for all lAB-nodes is aligned with the parent IAB- node or donor DL timing; ii. The UL reception timing of an lAB-node can be aligned with the lAB-node's DL reception timing; iii. If DL TX and UL RX are not well aligned at the parent node, additional information about the alignment is needed for the child node to properly set its DL TX timing for OTA-based timing & synchronization. [0018] 3GPP TR 38.874, V16.0.0, states further that “the use of Case #6, if supported, at the IAB- node should be under the control of the parent node or network.”

[0019] However, it is unclear what timing an IAB node should use for the transmission and reception of the different links.

[0020] It is assumed that the transmission timing of IAB-MT uplink transmissions is controlled by a parent IAB-DU in the same way as a base station controls the transmission timing of uplink transmissions from UEs, i.e. by means of explicit timing control commands. This control is such that the uplink transmission is received at the base station with an appropriate timing. An appropriate timing in an IAB network is an IAB-DU internal decision.

[0021] It has been further agreed that, in Rel-16, lAB-nodes should support timing alignment of Case #1. This is achieved by the parent node providing information about its timing relation of its DL transmissions and UL receptions (also known as T delta in 3GPP, TS 38.213, V16.3.0). Though not explicitly mentioned in the definition of timing alignment of Case #1, the transmission timing of uplink transmissions from an IAB-MT is controlled by its parent IAB-DU in the same way as the parent IAB-DU controls the transmission timing of uplink transmissions from UEs. FIG. 2 depicts the transmission and reception timing relations of some lAB-nodes operating in Case#l transmission timing alignment. For example, for each node (Nl, N2, N3), the relation of propagation delay is shown for a UE transmission compared to the one of a DL transmission, so that the UL transmission can be aligned with the DL transmission (e.g. the UL transmission is started earlier by a propagation delay).

[0022] In 3GPP TSG RAN WG1 Meeting #102-e, “Chairman's Notes RANl#102-e final”, August 2020, it has been agreed that:

[0023] - Case#6 timing alignment is supported in Rel-17 for lAB-nodes operating in multiplexing scenario Case A (simultaneous MT-TX/DU-TX): i. Radio Access Network 1 (RANI) should strive to minimize specification impact due to this feature.

[0024] FIG. 3 depicts the transmission and reception timing relations of some lAB-nodes operating in Case#6 transmission timing alignment.

[0025] As can be seen from FIG. 3, first, all the DL transmissions and UL transmissions from all the nodes are aligned. Secondly, the uplink reception timing of an IAB-DU is not necessarily set by some internal preferences but determined by the propagation delay between the lAB-node and its child lAB-node.

[0026] For Case #6 timing alignment and disregarding the impact and changes on the transmission timing of uplink transmissions from UEs, an IAB-MT should not necessarily set its transmission timing according to explicit timing control commands from its parent IAB-DU relative to its received downlink timing from the parent IAB-DU, but to its collocated IAB-DU downlink transmission timing. At the same time, the use of Case #6 at the lAB-node should be under the control of the parent lAB-node or the network.

SUMMARY

[0027] There are some challenges with the existing solutions.

[0028] Existing cellular networks typically communicate in a strict hierarchical control regarding uplink transmission timing - the DU (gNB) is in control and the UE adheres to this control. Furthermore, the DU typically uses a constant and common uplink reception timing for all UEs; in case of IAB, this uplink reception timing at a parent IAB-DU also applies for its child lAB-MTs. With the introduction of lAB-nodes operating with timing alignment of Case #6, a similar one-sided relation may still be preferable, i.e., a parent lAB-node should be in certain control of what kind of uplink transmit timings downstream lAB-MTs are allowed to use and when. However, the parent lAB-node usually does not know when an uplink transmission is received from its child IAB nodes. As such, it is not clear how the parent IAB node can have a certain control of uplink transmissions from downstream IAB nodes.

[0029] Furthermore, there is presently no functionality in the specification that allows and coordinates Case#6 timing alignment operation by lAB-nodes. Also, it is sensible from a network perspective to maximize overall network performance, something that may not be feasible without the parent lAB-node allowing simultaneous transmission of downstream lAB-MTs and collocated lAB-DUs. Hence, there is a need for a method to allow and coordinate how and what lAB-nodes can use in the Case#6 timing alignment, in order to increase the network performance.

[0030] The disclosure provides a method in a parent lAB-node to allow an lAB-node to set its UL transmission timing towards the parent lAB-node to its own preference. This allowing can be based on information that the parent lAB-node has received from, e,g., network and/or IAB-CU. This allowing can be conditional, e.g., based on the impact of the parent’s IAB-DU RX timing and/or the parent lAB-DU’s capabilities. [0031] The disclosure also provides a method that allows an lAB-node to enable its parent lAB-node to set its timing for UL reception from this lAB-node, if the lAB-node operates in a timing configuration enabling simultaneous transmissions on the parent and child links. This is achieved by the parent lAB-node and lAB-node exchanging information indicating the intent by the lAB-node, to simultaneously transmit on its parent and child links, the parent lAB-node confirming or denying (e.g. ACK/NACK) that intent and the lAB-node providing information that enables the parent lAB-node to set its timing for UL reception from the lAB-node accordingly. Such information can be the IAB- node’s estimate (or update) of the propagation delay (between parent lAB-node and lAB-node), changes or increments/decrements suggested to the parent lAB-node of the timing for receiving transmissions from the lAB-node. The IAB node, based on the parent lAB-node feedback, may perform an action towards a child IAB node or a UE. Such action could be a change in scheduling/resource assignment strategy on child links, including routing decisions, or a change in transmit power decisions like distribution of available transmit power between all involved transmitters or related signaling to a parent lAB-node.

[0032] According to an aspect, some embodiments include methods performed by a network node, which can be a first Integrated Access Backhaul (IAB) node in a chain of connected IAB nodes for enabling simultaneous transmissions at an IAB node to upstream IAB nodes and downstream IAB nodes. A method may comprise: receiving a message from a second IAB node, the message comprising an indication for determining a timing for data transmission or reception; in response to the receipt of the message, determining the timing in accordance with the indication; and performing one of a transmission and a reception based on the determined timing.

[0033] According to another aspect, some embodiments include a network node configured, or operable, to perform one or more functionalities (e.g., actions, operations, steps, etc.) as described herein. The network node may be an IAB node, for example.

[0034] In some embodiments, the network node may comprise one or more communication interfaces configured to communicate with one or more other radio nodes and/or with one or more network nodes, and processing circuitry operatively connected to the communication interface, the processing circuitry being configured to perform one or more functionalities as described herein. In some embodiments, the processing circuitry may comprise at least one processor and at least one memory storing instructions which, upon being executed by the processor, configure the at least one processor to perform one or more functionalities as described herein. [0035] In some embodiments, the network node may comprise one or more functional modules configured to perform one or more functionalities as described herein.

[0036] According to yet another aspect, some embodiments include a non-transitory computer- readable medium storing a computer program product comprising instructions which, upon being executed by processing circuitry (e.g., at least one processor) of the network node, configure the processing circuitry to perform one or more functionalities as described herein.

[0037] The advantages/technical benefits of the embodiments of the present disclosure are:

[0038] The proposed embodiments enable and coordinate timing operation among lAB-nodes. The involved additional signaling and change of overall network operation is most often a small expense, in order to allow for more flexible and efficient IAB backhaul and access link operation. Hence, overall network performance can be increased.

[0039] This summary is not an extensive overview of all contemplated embodiments and is not intended to identify key or critical aspects or features of any or all embodiments or to delineate the scope of any or all embodiments. In that sense, other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Exemplary embodiments will be described in more detail with reference to the following figures, in which:

[0041] FIG. 1 illustrates an example of IAB nodes connected to each other, such as IAB-MT and IAB-DU for backhaul and access link.

[0042] FIG. 2 illustrates examples of transmission and reception timing relations of lAB-nodes operating in Case#l transmission timing alignment (for simplification, no UL-to-DL switching gap is assumed).

[0043] FIG. 3 illustrates examples of transmission and reception timing relations of lAB-nodes operating in Case#6 transmission timing alignment (for simplification, no UL-to-DL switching gap is assumed).

[0044] FIG. 4 illustrates an example to align IAB-MT TX timing to IAB-DU TX timing at an IAB node according to Approach 1, where IAB-MT TX timing at the child IAB node is adjusted. [0045] FIG. 5 illustrates a solution according to Approach 2, where the parent lAB-node RX timing is adjusted.

[0046] FIG. 6 is a flow chart of a method in a first network node, in accordance with an embodiment. [0047] FIG. 7 illustrates one example of a wireless communications system in which embodiments of the present disclosure may be implemented.

[0048] FIGs. 8 and 9 are block diagrams that illustrate a wireless device according to some embodiments of the present disclosure.

[0049] FIGs. 10 and 11 are block diagrams that illustrate a network node according to some embodiments of the present disclosure.

[0050] FIG. 12 illustrates a virtualized environment of a network node, according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

[0051] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

[0052] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

[0053] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. [0054] As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0055] Two approaches are disclosed herein to allow an lAB-node to operate in a Case#6 timing alignment configuration under the parent control. One approach is initiated from a parent lAB-node perspective, the other approach is initiated from an lAB-node perspective by starting to signal to its parent lAB-node.

[0056] In this disclosure, the terms “transmission timing” and “transmit timing” are used interchangeably. Also, the terms “reception timing” and “receive timing” are used interchangeably.

[0057] Approach 1:

[0058] With reference to FIG. 4, an example of a method 80 for allowing and coordinating Case#6 timing operations between IAB nodes, will be described. Method 80 can be implemented in an IAB node, which is connected to a parent IAB node and a child IAB node, for example. Method 80 comprises:

[0059] Step 90 (this step is optional): the parent IAB node can receive some capability information about an IAB node from an IAB network capability management function, for example.

[0060] Step 100: based on some capability information about an lAB-node that can be provided by an IAB network capability management function (see step 90), a parent lAB-node signals “allowance” to a downstream lAB-node that it can set its transmit timings based on a certain configuration of the lAB-node.

[0061] Step 110: The IAB node sets its IAB-MT and/or IAB-DU transmit timing configuration.

[0062] In some examples, the IAB network capability management function can be located in the network, e.g., core network, a RAN node or an lAB-donor-CU or an Operation Administration and Maintenance (0AM) system. The lAB-node’ s timing configuration can be according to the IAB- node’s internal decision, e.g., based on or equal to the lAB-node’s DL transmit timing, or any other favorable relation between its IAB-MT’ s and/or IAB-DU’ s transmit timing. This relation can be conditional on the lAB-node’ s capabilities with respect to, but not limited by, its capabilities of digital signal processing (DSP), such as shared or unshared or coordinated (e.g. in time, processing resources, memory) DSP, and/or analog frontend capabilities, e.g. shared or separated radio and/or antenna panels. The parent lAB-node’s indication of “allowance” can be as simple as a single signaling of a bit (allowed, not-allowed) or more bits can be used or any other ways of signaling can be used, as will be appreciated by a person skilled in the art. In a variant, the indication of “allowance (allowed or not allowed)” can be conditional based on a validity period for the allowance and/or a range the lAB-MT’s timing advance (TA) must fall into and/or on the impact of the parent lAB-DU’s receive timing and/or the parent lAB-DU’s capabilities. For example, the signaling may include a certain window that the parent IAB-DU receive timing should eventually fall into, and information directed to the lAB-node on how to achieve that by modifying the lAB-nodes uplink transmit timing. In this case, it could be up to the lAB-node to decide to set its IAB-MT and/or IAB-DU transmit timing configuration, e.g., to achieve a certain relation between the parent and child links.

[0063] The “allowance” indication can include additional information about another lAB-node. In this case, any condition indicated by the parent lAB-node also applies to the other lAB-node. Such an “allowance” indication method allows to provide the lAB-node with information, such that if the lAB-node would change to another lAB-node as the parent lAB-node, it might be able to operate in a Case#6 timing configuration.

[0064] Approach 2:

[0065] In 3 GPP Rel- 161 AB, a method has been specified for an lAB-node to estimate the propagation delay between itself and its parent lAB-node (see 3GPP, TS 38.213, V16.3.0). The method is based on the lAB-MT’s timing advance (TA) setting (see 3GPP TS 38.211, V16.2.0 (2020-06)) and the parent lAB-node providing a parameterized information, T delta (see 3GPP, TS 38.213, V16.3.0), such that the lAB-node can assume (or derive/determine) what the propagation delay (T_prop) can be, for example, by calculating T_prop=TA/2+T_delta. In an opposite way, the parent lAB-node could derive an estimate of T_prop, if it is provided with the TA as set and/or measured by the IAB- MT. Furthermore, in case different transmit timings are defined for different types of transmissions, for example, then, a timing offset can be signaled or indicated. The timing offset can be the difference between the different transmit timings or between a transmit timing and a reference timing (which can be a reference transmit timing or a reference receive timing), for example. The information about the propagation delay (or an estimate thereof) or about the timing advance or about the timing offset can be used in a method 190 for allowing and coordinating Case#6 timing operations between IAB nodes. FIG. 5 illustrates an example of method 190. As a note, T delta can be signaled in different ways, based on a T delta’ for example. Indeed, in another example, T delta can be also expressed as T_delta= offset + stepsize* T delta’, where T delta’ can be signaled as an index.

[0066] Method 190 can be implemented in a parent IAB node, which is connected to an IAB node, for example. Method 190 comprises:

[0067] Step 200: receiving a signal from the lAB-node, the signal including either an estimate of or information about T_prop. Alternatively, the parent IAB node can receive information/indication of a timing offset. This timing offset can provide information about an intended transmit timing relative to another timing, such as a reference transmit timing.

[0068] Step 210: upon receipt of the signal, the parent IAB node sets its reception timing for transmissions from the IAB-MT to (DL TX timing + T_prop), where the DL TX timing is the transmission timing of the parent IAB node for downlink transmissions. As a note, the propagation delay (T_prop) can be also indicated to the parent lAB-node by using TA as set by the IAB-MT. The lAB-node can send a signal comprising a value of the TA or an indication for the TA. Since the parent IAB node already knows its T delta, it can derive an estimate of the propagation delay (T_prop) by using the received TA and the known T delta, in the same way as the lAB-node calculates T_prop having information about T delta. An advantage of signaling the TA could be that TA signaling/specification (as usually used from the parent IAB-DU to IAB-MT) can be reused (from IAB-MT to parent IAB-DU) to indicate TA or updates. If the parent lAB-node sets its UL reception timing this way, the lAB-node has a proper IAB-MT transmit timing, equal to its collocated IAB-DU transmit timing, as defined for a Case#6 timing configuration.

[0069] In the case where the received signal includes information about a timing offset, the parent lAB-node can determine its reception timing based on the information of the timing offset, e.g. based on a reference reception timing and the timing offset. As an example, the parent lAB-node can set its reception timing as the sum of the uplink reception timing and the timing offset value.

[0070] Also, any signaling of information about T_prop and/or the lAB-node’s TA from the IAB- node to the parent IAB node can indicate to the parent lAB-node the intent by the lAB-node, to simultaneously transmit on its parent and child links and also to do that in a Case#6 timing configuration.

[0071] Step 220: after receiving such intent indication, the parent IAB node provides feedback to the lAB-node to grant such intent, i.e., to allow the IAB node to transmit simultaneously on its parent and child links. To do so, the parent IAB node can for example respond to the IAB node by a simple ACK/NACK indication. The parent lAB-node can also decide to not allow the IAB node to transmit simultaneously on its parent and child links, for the following reasons. For example, if the simultaneous operation requires a transmit timing change, it has implication on the parent nodes Rx timing (since the parent IAB node needs to set its reception timing). The parent node might not be (technically, implementation-wise) able to adjust its Rx timing accordingly, or it is not suitable for the parent node operation at some points.

[0072] Step 230: Depending on the parent IAB-node’ s feedback, the lAB-node can take different actions, such as for example, preparations of adjusting its child lAB-node’s configuration, adjustments or preparations in scheduling or routing decision, or a change in transmit power decisions like distribution of available transmit power between all involved transmitters or related signaling to the parent IAB-node.

[0073] In some examples, an intent for entering in a Case#6 timing configuration can also be signaled by the IAB-node by providing changes or increment/decrement information to the parent IAB-node about the timing for receiving transmissions from the IAB-node. The parent IAB-node can use such information to further fine-tune or improve timing setting for receiving transmissions from the IAB- node. The parent IAB-node can provide feedback again, such as ACK/NACK, for example for the IAB-node to know it does not need to repeat signaling about the change of information or for the IAB-node to know it can adjust, e.g., its IAB-DU transmission timing, or for the IAB-node to know it is able to continue operating in a Case#6 timing configuration or not; in this case, the IAB node can again adjust, e.g., its scheduling and/or routing strategies on child and/or access links.

[0074] The grant or allowance of the intent can be conditional based on a validity period for the allowance and/or a range of values of the timing advance (TA) of the IAB-MT to fall into and/or based on the impact of the parent lAB-DU’s receive timing and/or the parent lAB-DU’s capabilities. For example, the signaling may include a certain window within which the parent IAB-DU receive timing should fall into.

[0075] Now turning to FIG. 6, a method 250 in a first IAB node for enabling simultaneous transmissions at an IAB node to upstream IAB nodes (e.g., via lAB-MTs) and downstream nodes (e.g., via lAB-DUs), such as in Case#6 timing, will be described. For example, the IAB-node performs simultaneous transmissions on its parent IAB link (i.e., in UL by its MT) and child IAB links (i.e., in DL by the (relative to MT) collocated DU). [0076] The first IAB node can be the network node 320 of FIGs. 7 and 10, for example. Method 250 comprises:

[0077] Step 260: receiving a message from a second IAB node, the message comprising an indication for determining a timing for data transmission or reception;

[0078] Step 270: in response to the receipt of the message, determining the timing in accordance with the indication; and

[0079] Step 280: performing one of a transmission and a reception based on the determined timing.

[0080] Method 250 can be applied to Approach 1 or to Approach 2.

[0081] When method 250 is applied to Approach 1, the second IAB node is a parent IAB node and the first IAB node is an lAB-node connected to the parent IAB node and the IAB node is the same as the first IAB node. Furthermore, method 250 in this case is similar to method 80 of FIG. 4, but method 250 is seen from the point of view of the IAB node connected to the parent IAB node.

[0082] Also, in this case, determining the timing means determining a transmit timing of a mobile termination (MT) of the first IAB node.

[0083] And performing one of the transmission or reception means performing a transmission based on the determined transmit timing.

[0084] In some examples, the message received from the second IAB node may be based on capability information about the first IAB node, the capability information provided by a network node.

[0085] In some examples, the indication for determining a timing may be an indication of allowance for the first IAB node to set the timing to a transmit timing of the first IAB node.

[0086] In some examples, determining the timing may comprise determining a transmit timing based on or being equal to a downlink (DL) transmit timing of the first lAB-node.

[0087] In some examples, determining the timing may comprise determining a transmit timing based on a relation between an lAB-MT’s and/or lAB-DU’s transmit timing of the first IAB node.

[0088] In some examples, the indication may be given by one or more bits indicating allowance or not for the first IAB node to set the timing for data transmission or reception to a transmit timing of the first IAB node.

[0089] In some examples, the indication of allowance may be conditional to at least one of: a validity period for the allowance or a range of timing advance (TA) values of an IAB-MT of the first IAB node. [0090] In some examples, the message can include a window indicating a range of values of a receive timing of an IAB-DU of the second IAB node.

[0091] In some examples, the message can further include information for the first IAB node to modify an uplink transmit timing.

[0092] Details and examples for this case have been also described under the section of Approach 1. [0093] When method 250 is applied to Approach 2, the first IAB node is a parent IAB node and the second IAB node is an lAB-node connected to the parent IAB node and the second IAB node is the same as the IAB node.

[0094] Also, in this case, determining the timing means determining a receive timing. And performing one of the transmission or reception means performing a reception based on the determined receive timing.

[0095] Method 250 in this case is similar to method 190 of FIG. 5, but method 250 is seen from the point of view of the parent IAB node to which an IAB node is connected.

[0096] In some examples, the indication for determining a timing may comprise an indication of a propagation delay or an indication of a timing advance (TA) value or an indication of a timing offset. [0097] In some examples, the indication of the propagation delay may be an estimate of the propagation delay, determined based on a timing advance of a MT of the second IAB node and a parameter provided by the first IAB node.

[0098] In some examples, the first IAB node may derive the propagation delay based at least on the indicated timing advance value.

[0099] In some examples, the receive timing may be determined as a sum between a downlink transmission timing and the indicated propagation delay or derived propagation delay.

[0100] In some examples, the receive timing may be determined as a sum of an uplink reception timing and the indicated timing offset.

[0101] In some examples, the message may further comprise an indication of an intent of the second IAB node to simultaneously transmit on parent and child links.

[0102] In some examples, the first IAB node may send a response to the second IAB node, the response indicating allowance or no allowance of the intent.

[0103] In some examples, the message may further comprise increment or decrement information related to a timing for receiving transmissions from the second lAB-node. [0104] In some examples, determining the receive timing may further comprise determining the receive timing based on the increment/decrement information.

[0105] In some examples, the first IAB node may send a response to the second IAB node, the response providing instructions to the second IAB node. For example, the instructions may be one or more of the following: the second lAB-node does not need to repeat signaling of change information, the second lAB-node can adjust its IAB-DU transmission timing, the second IAB node can continue operating in a simultaneous parent and child link transmission configuration.

[0106] Details and examples for this case have been also described under the section of Approach 2. [0107] FIG. 7 illustrates an example of a wireless network 300 that may be used for wireless communications. Wireless network 300 includes UEs 310 and a plurality of radio network nodes 320 (e.g., Node Bs (NBs) Radio Network Controllers (RNCs), evolved NBs (eNBs), next generation NB (gNBs), etc.) directly or indirectly connected to a core network 330 which may comprise various core network nodes. The network 300 may use any suitable radio access network (RAN) deployment scenarios, including Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (UTRAN), and Evolved UMTS Terrestrial Radio Access Network (EUTRAN). UEs 310 may be capable of communicating directly with radio network nodes 320 over a wireless interface. In certain embodiments, UEs may also be capable of communicating with each other via device-to- device (D2D) communication. In certain embodiments, network nodes 320 may also be capable of communicating with each other, e.g., via an interface (e.g., X2 in LTE or other suitable interface).

[0108] As an example, UE 310 may communicate with radio network node 320 over a wireless interface. That is, UE 310 may transmit wireless signals to and/or receive wireless signals from radio network node 320. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of the wireless signal coverage associated with a radio network node 320 may be referred to as a cell.

[0109] It should be noted that a UE may be a wireless device, a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iP D, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Universal Serial Bus (USB) dongles, Customer Premises Equipment (CPE) etc.

[0110] In some embodiments, the “network node” can be any kind of network node which may comprise of a radio network node such as a radio access node (which can include a base station, radio base station, base transceiver station, base station controller, network controller, gNB, NR BS, evolved Node B (eNB), Node B, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU), Remote Radio Head (RRH), a multi-standard BS (also known as MSRBS), etc.), a core network node (e.g., MME, SON node, a coordinating node, positioning node, MDT node, etc.), or even an external node (e.g., 3rd party node, a node external to the current network), etc. The network node may also comprise a test equipment. The network node 320 may be an IAB node, a child IAB node, a parent IAB node or an IAB donor. Furthermore, the IAB node 320 may have components as a MT and/or DU (see for example FIG. 1).

[0111] In certain embodiments, network nodes 320 may interface with a radio network controller (not shown). The radio network controller may control network nodes 320 and may provide certain radio resource management functions, mobility management functions, and/or other suitable functions. In certain embodiments, the functions of the radio network controller may be included in the network node 320. The radio network controller may interface with the core network node 340. In certain embodiments, the radio network controller may interface with the core network node 340 via the interconnecting network 330.

[0112] The interconnecting network 330 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. The interconnecting network 330 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.

[0113] In some embodiments, the core network node 340 may manage the establishment of communication sessions and various other functionalities for wireless devices 310. Examples of core network node 340 may include MSC, MME, SGW, PGW, O&M, OSS, SON, positioning node (e.g. E-SMLC), MDT node, etc. Wireless devices 110 may exchange certain signals with the core network node 340 using the non-access stratum layer. In non-access stratum signaling, signals between wireless devices 310 and the core network node 340 may be transparently passed through the radio access network. In certain embodiments, network nodes 320 may interface with one or more other network nodes over an internode interface. For example, network nodes 320 may interface each other over an X2 interface. [0114] Although FIG. 7 illustrates a particular arrangement of network 300, the present disclosure contemplates that the various embodiments described herein may be applied to a variety of networks having any suitable configuration. For example, network 300 may include any suitable number of wireless devices 310 and network nodes 320, as well as any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device (such as a landline telephone). The embodiments may be implemented in any appropriate type of telecommunication system supporting any suitable communication standards and using any suitable components and are applicable to any radio access technology (RAT) or multi-RAT systems in which the wireless device receives and/or transmits signals (e.g., data). While certain embodiments are described for NR and/or LTE, the embodiments may be applicable to any RAT, such as UTRA, E-UTRA, narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT (NR, NX), 4G, 5G, LTE FDD/TDD, etc.

[0115] FIG. 8 is a schematic block diagram of the wireless device 310 according to some embodiments of the present disclosure. As illustrated, the wireless device 310 includes circuitry 400 comprising one or more processors 410 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like) and memory 420. The wireless device 310 also includes one or more transceivers 430 each including one or more transmitters 440 and one or more receivers 450 coupled to one or more antennas 460. Furthermore, the processing circuitry 400 may be connected to an input interface 480 and an output interface 485. The input interface 480 and the output interface 485 may be referred to as communication interfaces. The wireless device 310 may further comprise power source 490.

[0116] In some embodiments, the functionality of the wireless device 310 described above may be fully or partially implemented in software that is, e.g., stored in the memory 420 and executed by the processor(s) 410. For example, the processor 410 is configured to perform all the functionalities performed by the wireless device 310.

[0117] In some embodiments, a computer program including instructions which, when executed by the at least one processor 410, causes the at least one processor 410 to carry out the functionality of the wireless device 310 according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). [0118] FIG. 9 is a schematic block diagram of the wireless device 310 according to some other embodiments of the present disclosure. The wireless device 310 includes one or more modules 495, each of which is implemented in software. The module(s) 495 provide the functionality of the wireless device 310 described herein.

[0119] FIG. 10 is a schematic block diagram of a network node 320 according to some embodiments of the present disclosure. As illustrated, the network node 320 includes a processing circuitry 500 comprising one or more processors 510 (e.g., CPUs, ASICs, FPGAs, and/or the like) and memory 520. The network node also comprises a network interface 530. The network node 320 also includes one or more transceivers 540 that each include one or more transmitters 550 and one or more receivers 560 coupled to one or more antennas 570. In some embodiments, the functionality of the network node 320 described above may be fully or partially implemented in software that is, e.g., stored in the memory 520 and executed by the processor(s) 510. For example, the processor 510 can be configured to perform any steps of method 80 of FIG. 4, method 190 of FIG. 5 and method 250 of FIG. 6, whether the network node 320 is an IAB node or parent IAB node.

[0120] FIG. 11 is a schematic block diagram of the network node 320 according to some other embodiments of the present disclosure. The network node 320 includes one or more modules 580, each of which is implemented in software. The module(s) 580 provide the functionality of the network node 320 described herein, such as operating the steps of method 80 of FIG. 4, method 190 of FIG. 5 and method 250 of FIG. 6.

[0121] FIG. 12 is a schematic block diagram that illustrates a virtualized embodiment of the wireless device 310 or network node 320, according to some embodiments of the present disclosure. As used herein, a “virtualized” node 1200 is a network node 320 or wireless device 310 in which at least a portion of the functionality of the network node 320 or wireless device 310 is implemented as a virtual component (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). For example, in FIG. 16, there is provided an instance or a virtual appliance 1220 implementing the methods or parts of the methods of some embodiments. The one or more instance(s) runs in a cloud computing environment 1200. The cloud computing environment provides processing circuits 1230 and memory 1290-1 for the one or more instance(s) or virtual applications 1220. The memory 1290- 1 contains instructions 1295 executable by the processing circuit 1260 whereby the instance 1220 is operative to execute the methods or part of the methods described herein in relation to some embodiments. [0122] The cloud computing environment 1200 comprises one or more general-purpose network devices including hardware 1230 comprising a set of one or more processor(s) or processing circuits 1260, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or special purpose processors, and network interface controller(s) (NICs) 1270, also known as network interface cards, which include physical Network Interface 1280. The general- purpose network device also includes non-transitory machine-readable storage media 1290-2 having stored therein software and/or instructions 1295 executable by the processor 1260. During operation, the processor(s)/processing circuits 1260 execute the software/instructions 1295 to instantiate a hypervisor 1250, sometimes referred to as a virtual machine monitor (VMM), and one or more virtual machines 1240 that are run by the hypervisor 1250.

[0123] A virtual machine 1240 is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine; and applications generally do not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, though some systems provide para-virtualization which allows an operating system or application to be aware of the presence of virtualization for optimization purposes. Each of the virtual machines 1240, and that part of the hardware 1230 that executes that virtual machine 1240, be it hardware 1230 dedicated to that virtual machine 1240 and/or time slices of hardware 1230 temporally shared by that virtual machine 1240 with others of the virtual machine(s) 1240, forms a separate virtual network element(s) (VNE).

[0124] The hypervisor 1250 may present a virtual operating platform that appears like networking hardware to virtual machine 1240, and the virtual machine 1240 may be used to implement functionality such as control communication and configuration module(s) and forwarding table(s), this virtualization of the hardware is sometimes referred to as network function virtualization (NFV). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in Data centers, and customer premise equipment (CPE). Different embodiments of the instance or virtual application 1220 may be implemented on one or more of the virtual machine(s) 1240, and the implementations may be made differently. [0125] In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0126] Some embodiments may be represented as a non-transitory software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to one or more of the described embodiments. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine-readable medium. Software running from the machine-readable medium may interface with circuitry to perform the described tasks.

The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description.