Integrating latency management in access and backhaul networks

Abstract

Methods, systems, and devices for delay management in an integrated access and backhaul (IAB) network for mobile communications are described. An example method for wireless communications includes receiving, by a first network node, a measurement configuration from a second network node, performing one or more delay measurements based on the measurement configuration, and transmitting a measurement report to the second network node, the measurement report including one or more delay measurements or an identification of a channel used for the one or more delay measurements.

Description

Technical Field

[0001] This patent document relates generally to wireless communications. Background Art

[0002] Wireless communication technology is driving the world towards an increasingly connected and networked society. The rapid growth of wireless communications and technological advances have led to greater demands for capacity and connectivity. Other aspects, such as energy consumption, equipment cost, spectrum efficiency, and latency, are also important to meet the needs of various communication scenarios. Compared with existing wireless networks, next-generation systems and wireless communication technologies will support more users and devices and support higher data rates. Summary of the invention

[0003] The present document relates to methods, systems and devices for delay management in integrated access and backhaul (IAB) networks for mobile communications, including 5th Generation (5G) and New Radio (NR) communication systems.

[0004] In one exemplary aspect, a wireless communication method is disclosed. The method includes receiving, by a first network node, a measurement configuration from a second network node, performing one or more delay measurements based on the measurement configuration, and transmitting a measurement report to the second network node, the measurement report including the one or more delay measurements or an identification of a channel used for the one or more delay measurements.

[0005] In another exemplary aspect, a wireless communication method is disclosed. The method includes transmitting, by a second network node to a first network node, a measurement configuration and, after transmitting, receiving a measurement report including one or more delay measurements or an identification of a channel used for the one or more delay measurements.

[0006] In yet another exemplary aspect, a wireless communication method is disclosed. The method includes configuring, by a first network node, a discard timer for a backhaul channel, and determining whether a received data packet is subsequently transmitted or discarded on the backhaul channel based on the discard timer.

[0007] In yet another exemplary aspect, the above method is embodied in the form of processor executable code and stored in a computer readable program medium.

[0008] In yet another exemplary embodiment, a device configured or operable to perform the above method is disclosed.

[0009] The above and other aspects and embodiments thereof are described in more detail in the drawings, the description and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1A An example of an integrated access and backhaul (IAB) network is shown.

[0011] Figure 1B An example of an IAB user plane protocol stack is shown.

[0012] Figure 2A and Figure 2B Examples of packet delay budgets (PDBs) for New Radio (NR) and IAB networks are shown, respectively.

[0013] FIG. 3A to FIG. 3C An example of latency measurement and reporting is shown.

[0014] Figure 4A and Figure 4B An example of a PDB-based discard mechanism is shown.

[0015] FIG. 5A to FIG. 5C An example of a wireless communication method is shown.

[0016] Figure 6 is a block diagram representation of a portion of an apparatus that can be used to implement the methods and techniques described in this document. DETAILED DESCRIPTION

[0017] As the number of applications and services for digital data continues to explode, the demands and challenges on network resources and operators will continue to increase. Being able to deliver the various network performance characteristics that future services will demand is one of the main technical challenges facing service providers today. The performance requirements placed on the network will demand connectivity in terms of data rate, latency, QOS, security, availability, and many other parameters, all of which will vary from service to service. Therefore, enabling the network to allocate resources in a flexible manner to provide customized connectivity for each different type of service will greatly enhance the network's ability to meet future demands.

[0018] To meet these needs, the development of 5th generation (5G) mobile wireless technologies and standards is well underway. One such technology is a split network architecture, in which the Radio Access Network (RAN) functions are separated between a central unit (CU) and multiple distributed units (DU). For example, the RAN functions can be separated at a point between the Packet Data Convergence Protocol (PDCP) layer and the Radio Link Control (RLC) layer of the 5G protocol stack, where the DU will handle all processes up to and including the RLC layer functions, and the CU will handle the PDCP and higher layer functions before the core network. This decomposition of RAN functions will provide many advantages for mobile network operators. For example, by isolating the stack from the PDCP layer and upwards, the CU will be able to act as a cloud-based convergence point between multiple heterogeneous technologies in a pre-allocated network, and will therefore be able to serve multiple heterogeneous DUs.

[0019] Another technology being developed for 5G networks is an integrated access and backhaul (IAB) architecture for providing high-speed wireless backhaul to cell sites (e.g., base stations). As data demand and the number of cell sites increase, it becomes increasingly difficult to provide traditional fiber backhaul access to each cell site, especially for small cell base stations. Under the IAB architecture, the same infrastructure and resources (e.g., IAB nodes) can be used to provide both access and backhaul to support, for example, user equipment (UE) packet data unit (PDU) sessions. The IAB architecture for new radio (NR) networks will provide wireless backhaul and relay links, and thereby enable flexible and dense deployment of NR cells without proportionally increasing the density of the transmission network. In addition, IAB technology will allow dense networks of self-backhauled NR cells to be more easily deployed in a more integrated and robust manner. For example, IAB technology in 5G NR networks will support multi-hop relay systems where the network topology also supports redundant connections.

[0020] Figure 1A A block diagram of an IAB architecture network 100 is shown, wherein a core network 102 is connected to a donor IAB node 104. As used herein, the term "connected" refers to a wired or cable connection (e.g., a fiber optic cable) between two nodes or devices. The donor IAB node 104 is wirelessly coupled to a plurality of intermediate IAB nodes 106a and 106b and two serving IAB nodes 106c and 106d. As used herein, the term "coupled" refers to direct or indirect and wired or wireless communication between two nodes or devices.

[0021] like Figure 1A As shown, serving IAB nodes 106c and 106d are directly coupled to UEs 108a and 108b, respectively, and function as serving cell site base stations or access points for UEs 108a and 108b. UEs 108a and 108b are referred to herein as "access UEs." Serving IAB nodes 106c and 106d also function as relays and can forward their respective UE signals to their respective next downlink nodes in the transmission path, and forward downlink signals to their respective UEs 108a and 108b. Figure 1A As shown, the serving IAB node 106c may forward uplink UE signals to one or both of the intermediate IAB nodes 106a and 106b, and receive downlink UE signals from one or both of the intermediate IAB nodes 106a and 106b. The intermediate IAB nodes 106a and 106b may forward uplink UE signals to the donor IAB node 104, and forward downlink signals to the serving IAB node 106d. The serving IAB node 106c may forward uplink UE signals to the donor IAB node 104, which may then forward all received signals to the core network 102, and may forward downlink signals from the donor IAB node 104 to the access UE 108a.

[0022] Each of the IAB nodes 106a to 106d can have two functions: a base station (BS) function and a mobile terminal (MT) function. The BS function means that the IAB node can work like a base station to provide a radio access function for the UE. As used herein, the "BS part" of the IAB node refers to the part of the IAB node that includes all hardware, firmware and / or software related to performing the BS function of the IAB node. The MT function means that the IAB node can work like a mobile terminal and is controlled and scheduled by an IAB donor node or an upper-level IAB node. As used herein, the "MT part" of the IAB node refers to the part of the IAB node that includes all hardware, firmware and / or software related to performing the MT function of the IAB node.

[0023] Still reference Figure 1A If network 100 also implements a split architecture, donor IAB node 104 will be replaced by a donor CU (not shown) connected to core network 102 and a donor DU (not shown) connected to the donor CU. Each of IAB nodes 106a to 106d will be coupled to the donor DU in a manner similar to how they are coupled to donor IAB node 104, such as Figure 1A shown.

[0024] In a split architecture network, each of the IAB nodes 106a to 106d may have two functions: a DU function and a mobile terminal (MT) function. The DU function means that the IAB node can work like a DU to provide a predetermined DU function for the UE. As used herein, the "DU portion" of the IAB node refers to the portion of the IAB node that includes all hardware, firmware, and / or software related to performing the DU function of the IAB node. The MT function and MT portion of the IAB node in the split architecture network are the same as those described above for the non-split architecture network.

[0025] Figure 1B The IAB user plane protocol stack between the IAB-DU and the IAB-donor-CU is shown. F1-U uses the IP transport layer between the IAB-DU and the IAB-donor-CU. The IP layer can be further protected by security. On the wireless backhaul, the IP layer is carried on the Backhaul Adaptation Protocol (BAP) sublayer, which implements routing and bearer mapping over multiple hops. On each backhaul link, the BAP PDU is carried by a BH RLC channel. Multiple BH RLC channels can be configured on each BH link to allow traffic prioritization and QoS implementation.

[0026] The implementation of split architecture and IAB architecture techniques in 5G networks has presented many challenges. One such challenge is that additional delay components (e.g., delays between intermediate IAB nodes) should be considered. It is necessary to design a new discard mechanism for the IAB node to determine whether a relayed data packet should be discarded.

[0027] Embodiments of the disclosed technology are directed to designing a delay-aware routing mechanism that guarantees a packet delay budget (PDB) for UE data radio bearers (DRBs) in an integrated access and backhaul (IAB) network. In an example, a donor CU may collect one-hop delay information within the IAB network and then configure a routing path whose cumulative delay is less than the PDB of a UE DRB / QoS flow. In another example, a packet discard mechanism may be designed that requires an IAB node to discard data packets whose PDB requirements cannot be met. Alternatively, if an IAB node / donor DU detects that the routing path selected for a data packet cannot meet the PDB requirements, it may reselect a routing path that can meet the PDB requirements.

[0028] This document uses section headings and subheadings for ease of understanding rather than for limiting the scope of the disclosed techniques and embodiments to certain sections. Therefore, the embodiments disclosed in different sections can be used interchangeably. In addition, this document uses examples from 3GPP New Radio (NR) network architecture and 5G protocols only for ease of understanding and the disclosed techniques and embodiments can be practiced in other wireless systems using communication protocols different from the 3GPP protocols.

[0029] Overview of latency in the IAB network

[0030] Each QoS flow or UE DRB is associated with a 5QI value that defines a packet delay budget (PDB). The PDB defines an upper bound on the time that a packet may be delayed between the UE and the UPF. The PDB is used to support the configuration of scheduling and link layer functions (such as the setting of scheduling priority and HARQ target operating point). For delay-critical GBR QoS flows, if the data burst transmitted within the PDB period is less than the maximum data burst amount, packets delayed beyond the PDB are considered lost and the QoS flow does not exceed the GFBR. The PDB is included in the QoS information of the QoS flow and or DRB during the PDU session management process via the Ng interface or during the UE context management process via the F1 interface.

[0031] If we can Figure 2A As can be seen, the PDB corresponding to the data packet includes the delayed components of Tuu and Tng. According to the current specification, the UL Tuu requirement is reflected via the PDCP discard timer associated with each UE bearer. Upon receiving a PDCP SDU from the upper layer, the transmitting PDCP entity shall start the discard timer associated with this PDCP SDU. When the discard timer for the PDCP SDU expires, the transmitting PDCP entity shall discard the PDCP SDU together with the corresponding PDCP data PDU. If the corresponding PDCP data PDU has been submitted to the lower layer, the discard is indicated to the lower layer. Regarding the delay of Tng, no clear indication is found in the specification. However, the implementation of the gNB may take this into account. For example, the gNB may estimate Tng based on the implementation method, and then configure the discard timer with a value lower than (PDB–Tng). In this way, the PDB of UL data packet transmission can be guaranteed.

[0032] When the IAB network is involved, the additional latency component for the IAB network should be considered. Figure 2BAs shown in , in addition to the delays of Tuu and Tng, delay components such as Tun and Tf1 should also be considered. Tun represents the delay between IAB nodes or between an IAB node and a donor DU, while Tf1 represents the delay between a donor DU and a donor CU. Similar to Tng, the delay of Tf1 is transmitted via wire and can be derived based on the implementation of the donor CU. When the donor CU performs the timer configuration for PDCP discard of UL transmission of the UE, it may derive the discard timer value by removing the delay component parts of Tng and Tf1 from the PDB associated with the DRB. Taking UL transmission as an example, after receiving a PDCP SDU from an upper layer, the transmitting PDCP entity of the UE will start a discard timer associated with this PDCP SDU. When the discard timer for the PDCP SDU expires, the transmitting PDCP entity should discard the PDCP SDU if it has not been transmitted to IAB node 1. Assuming that IAB node 1 receives a data packet from a UE and schedules it to be transmitted to IAB node 2, it is necessary to further determine whether the PDB of the data packet can be guaranteed. Figure 1B As shown, the intermediate IAB node (eg, IAB-Node 1) does not support PDCP processing for relaying data packets, and the PDCP-based method is no longer available.

[0033] On the other hand, the BH RLC channel is configured by the IAB donor CU on the wireless backhaul link. The BH RLC channel is configured with QoS information or priority level and is used to deliver backhaul CP and UP traffic. For the QoS information associated with the BH RLC channel, the PDB defines an upper bound on the time that a packet may be delayed between the gNB-DU and its child IAB-MT. In this way, the PDB of the BH RLC channel can be used to determine the priority of the logical channel and thus influence the scheduling decision.

[0034] Example Embodiments for Latency Measurement and Reporting

[0035] In some embodiments, when routing data packets of a UE in an IAB network, the multi-hop data forwarding delay between IAB nodes should be considered as the total delay, which should be lower than PDB. To support delay-aware routing in a multi-hop IAB network, potential per-hop delays along different data forwarding paths should be considered.

[0036] One-hop delay can be roughly estimated by the time difference between the packet arrival time and the packet departure time within an IAB node. For example, the time between the IAB node receiving a packet from an upper layer or a neighboring IAB node and the packet being successfully transmitted (HARQ / ARQ ACK is received) can be detected as one-hop delay. In addition, considering the different priorities and their impact on scheduling, packets belonging to different logical channels should be measured separately. Based on this observation, the one-hop delay of each RLC channel is more accurate for making routing decisions. Taking into account the delay fluctuations, the average delay of each BH RLC channel / DRB / SRB may be a filtered value for the delay measurement of multiple data packets.

[0037] In some embodiments, the donor CU may configure the IAB MT / DU with delay measurement. For example, the donor CU may configure the IAB MT / DU as to whether one-hop delay should be measured, or which BH RLC channel / DRB / SRB should be measured. In addition, filter coefficients may be configured for one-hop delay measurement. In addition, the donor CU may configure the IAB MT / DU to report one-hop delay.

[0038] In some embodiments, the donor CU may configure the IAB MT / DU with at least one of the following information: whether a one-hop delay should be reported, a list of RLC channels / DRBs / SRBs for which a one-hop delay should be reported, and whether the report is event-triggered or periodically triggered. For event-triggered reporting, the donor CU may further configure one or more delay thresholds. For example, when the measured one-hop delay for the BH RLC channel exceeds threshold 1, the one-hop delay should be reported. When the measured one-hop delay for the BH RLC channel / DRB is less than threshold 2, the one-hop delay should not be reported. When the change in the measured one-hop delay is greater than threshold 3, the one-hop delay should be reported. For periodically triggered reporting, the donor CU may further configure the periodicity of delay reporting.

[0039] Figure 3A An example is shown in which IAB MT 1 is configured by the donor CU to measure and periodically report the one-hop delay of BH RLC channels 1 and 2, which results in IAB MT 1 measuring the one-hop delay. Once the periodic reporting timer expires, IAB MT 1 can send the one-hop delay to the donor CU. In addition, IAB MT 1 can send the BH RLC channel ID / logical channel ID / DRBID / SRB ID and or link ID and or UL / DL direction to the donor CU. It should be noted that the link ID is the BAP address of the next hop node / UE of the BH RLC channel / DRB / SRB connection.

[0040] Similarly, if Figure 3BAs shown, IAB DU1 is configured by the donor CU to measure and report the one-hop delay of BH RLC channels 1 and 2, which causes IAB MT 1 to measure the one-hop delay. Once an event is triggered, IAB DU1 can send the one-hop delay measurement result to the donor CU. In addition, IAB DU1 can send the BH RLC channel ID / logical channel ID / DRB ID / SRB ID and or link ID and or UL / DL direction to the donor CU.

[0041] In addition, in some embodiments, the IAB MT may report a one-hop delay to the parent IAB node, such as Figure 3C As shown in . In addition, the IAB DU can report a one-hop delay to the child IAB node. This report can be sent via BAP control PDU / MAC CE / RRC signaling. The one-hop delay report can be delivered via a specific BH RLC channel / DRB / SRB. Alternatively, the one-hop delay report may include a one-hop delay and an associated BH RLC channel ID / logical channel ID / DRB ID / SRB ID. In addition, the one-hop delay report can be sent after a delay polling request from a parent / child IAB node. The polling request can be delivered via a specific BH RLC channel / DRB / logical channel. Alternatively, the delay polling request may include a BH RLC channel ID / logical channel ID / DRB ID / SRB ID. Based on the one-hop delay report from the IAB MT, the parent IAB DU can report a one-hop delay for both UL and DL directions to the donor CU.

[0042] Although the above operations have been described in the context of an IAB DU / MT, they are equally applicable to a donor DU.

[0043] After receiving the one-hop delay information from the IAB MT / DU or donor DU, the donor CU can estimate the delay for different routing paths. Assume that the donor CU needs to set up a set of BH RLC channels to support new UE DRBs along the candidate routing path. The donor CU can use the one-hop delay reports of existing BH RLC channels / DRBs / SRBs with similar channel priorities along the candidate routing path to estimate potential delays. If no one-hop delay with similar channel priority is available, the donor CU can initially configure the routing path without considering the PDB DRB associated with the UE. At the same time, the donor CU can configure IAB nodes along the routing path to measure and report one-hop delays separately. After the donor CU collects the one-hop delays associated with the BH RLC channels along the routing path, the donor CU can reconfigure the routing path associated with the UE DRB / UL GTP tunnel / DL IP flow if necessary.

[0044] Example Embodiment for PDB-Based Discard Mechanism

[0045] In some embodiments, a remaining packet delay budget for data packets along a routing path in a multi-hop IAB network cna may be obtained and used to support delay management in the IAB network.

[0046] like Figure 4A As shown, for the UL direction, the donor CU can configure the access IAB node 1 with PDBs associated with certain UE DRBs. As noted above, the PDBs associated with the UE DRBs define an upper bound on the time that a packet can be delayed between the UE and the UPF. In order for the access IAB node 1 to determine potential PDBs on the wireless backhaul, the donor CU can configure the access IAB node 1 with a PDB associated with each UE DRB, which only indicates the allowed delay for the wireless backhaul. The PDB for the UE DRB can be used by the access IAB MT 1 to set the BAP discard timer associated with the data packet from this UE DRB. In addition, the access IAB node 1 can derive the remaining PDBs.

[0047] In some embodiments, the remaining PDB may be derived from the PDB for the DRB minus a one-hop delay associated with the mapped egress BH RLC channel. The access IAB node 1 includes a PDB field in the BAP header of this data packet. The PDB field may be set to the value of the remaining PDB. Upon receiving such Figure 2B After the data packet is transmitted, the IAB node 2MT can use the PDB included in the BAP header to set the BAP discard timer associated with the data packet. In addition, the IAB node 2 can update the remaining PDB. The new remaining PDB can be derived from the original PDB included in the BAP header minus the one-hop delay associated with the mapped BH RLC channel. The IAB node 2 then updates the PDB field in the BAP header of this data packet accordingly. In this way, the PDB included in the header of each data packet is updated at each intermediate IAB node until it reaches the donor DU. When the data packet arrives at the donor DU, the donor DU should remove the BAP header.

[0048] It should be noted that for access IAB node 1 and all intermediate IAB nodes, if the discard timer associated with the data packet / BAP PDU / SDU expires, the data packet / BAP PDU / SDU may be discarded. In addition, if the remaining PDB is less than 0, the BAP PDU / SDU may also be discarded.

[0049] like Figure 4BAs shown, for the DL direction, the donor CU configures the donor DU with the PDB associated with the DL IP flow. The DL IP flow can be identified by a traffic identifier, such as a combination of the destination IP address / IPv6 prefix, IPv6 flow label, or a differentiated services code point (DSCP). This PDB can be used by the donor DU to set a BAP discard timer associated with a data packet that satisfies a traffic specifier, such as a destination IP address / IPv6 prefix, IPv6 flow label, or DSCP. In addition, the donor DU can derive the remaining PDB. In some embodiments, the remaining PDB can be derived from the PDB minus a one-hop delay associated with the mapped egress BH RLC channel. The donor DU then includes the remaining PDB in the PDB field in the BAP header of this data packet. Upon receiving such Figure 2B After the data packet shown, the IAB node 2DU can use the PDB included in the BAP header to set the BAP discard timer associated with the data packet. In addition, the IAB node 2 can update the remaining PDB. The new remaining PDB can be derived by deducting the one-hop delay associated with the mapped exit BH RLC channel from the original PDB included in the BAP header. Then the IAB node 2 updates the PDB field in the BAP header of this data packet accordingly. In this way, the PDB included in the header of each data packet is updated at each intermediate IAB node until it reaches the destination IAB node 1. When the data packet arrives at the IAB node 1, the IAB node 1 should remove the BAP header. In addition, the IAB node 1DU can use the PDB included in the BAP header to set the BAP discard timer associated with the data packet. In addition, the IAB node 1 can derive the remaining PDB. In other embodiments, the remaining PDB can be derived by deducting the one-hop delay associated with the UE DRB from the original PDB included in the BAP header.

[0050] In some embodiments, for IAB Node 1, donor DU and all intermediate IAB nodes, if the discard timer associated with the data packet / BAP PDU / SDU expires, the data packet / BAP PDU / SDU may be discarded. On the other hand, if the remaining PDB is less than 0, the BAP PDU / SDU may also be discarded.

[0051] Considering that the PDB information does not have to be included in the BAP header for all BAP PDUs, the donor CU may send the indication to the IAB DU / MT and / or donor DU, which indicates whether the PDB information should be included in the BAP header. The indication may be indicated per UE DRB / flow specifier (combination of destination IP address / IPv6 prefix, IPv6 flow label and / or DSCP) / BH RLC channel.

[0052] Example Embodiment for Timestamp and PDB Based Discard Mechanism

[0053] In some embodiments, it is assumed that all UEs and IAB nodes are synchronized and maintain the same timing. For UL, assuming that the IAB node 1 receives the data packet at t1, the transmission start time of the data packet may be at t1. Alternatively, the IAB node 1 may derive Tuu based on a report from the UE or based on its downlink Uu transmission delay estimate. Alternatively, the donor CU may configure the IAB node DU / MT 1 with the estimated one-hop delay in the UE DRB. Assuming that the IAB node 1 receives the data packet at t1, the transmission start time of the data packet may be at t1 or at (t1-Tuu). The IAB node 1 may include the transmission start time of the data packet as a timestamp in the BAP header of the data packet.

[0054] The donor CU may configure the IAB Node 1 DU / MT with a PDB associated with each UE DRB. This PDB may indicate the PDB used for the wireless backhaul. The PDB for the UE DRB may be used by the IAB MT 1 to set the BAP discard timer associated with the data packet from this UE DRB. The IAB Node 1 DU / MT may then determine whether the discard timer has expired. If it has expired, this data packet will be discarded. The IAB Node 1 may include a PDB information field in the BAP header of this data packet.

[0055] Subsequently, the IAB node 1MT transmits the data packet to the parent IAB node 2. After receiving the data packet, the IAB node 2 can obtain the timestamp information included in the BAP header. The parent IAB node 2 then checks whether the packet should be discarded based on the timestamp information and the PDB information associated with this data packet. In some embodiments, the IAB node 2 can derive the time the data packet has passed by subtracting the timestamp included in the BAP header from the current time. If the time the data packet has passed is greater than the PDB included in the BAP header, the data packet should be discarded. This discard check is performed at each intermediate IAB node until the data packet arrives at the donor DU.

[0056] In addition, the IAB node 2 can start a discard timer associated with the data packet. The initial value of the discard timer is set to the PDB minus the time elapsed by the data packet. The IAB node 2 DU / MT can then determine whether the discard timer has expired. If it has expired, the data packet will be discarded.

[0057] In some embodiments, for DL, the donor CU configures the donor DU with a PDB associated with the DL IP flow. The DL IP flow can be identified by a traffic identifier, such as a combination of destination IP address / IPv6 prefix, IPv6 flow label, or differentiated services code point (DSCP). After receiving a data packet from the donor CU, the donor DU starts a discard timer for this data packet set to the associated PDB. Once the discard timer expires, the donor DU should discard this data packet. Assuming that the donor DU receives the data packet at t1, the donor DU can include the packet transmission start time (e.g., t1) as a timestamp in the BAP header and transmit it to the IAB node 2. In addition, the donor DU can include PDB information in the BAP header of this data packet.

[0058] Assuming that IAB node 2 receives the packet at t2, IAB node 2 can use the timestamp to determine the time elapsed by the calculation (t2-timestamp). IAB node 2 can use the remaining PDB (PDB-elapsed time) to set the discard timer and detect whether the data packet should be discarded. If it should not be discarded, the data packet is continuously forwarded along the data path toward the serving IAB node 1. Each intermediate IAB node uses a similar mechanism as IAB node 2 to check whether the PDB can be guaranteed.

[0059] As described above, the PDB of the data packet can be included in the BAP header together with the timestamp. Alternatively, the donor CU can configure the PDB associated with the DL IP flow. The DL IP flow can be identified by a traffic identifier, such as a combination of the destination IP address / IPv6 prefix, IPv6 flow label, or a differentiated service code point (DSCP) to the IAB node and the donor DU. In this way, the PDB does not have to be included in the BAP header. Alternatively, the BAP header may contain a UE bearer / flow id, which is set by the access IAB node and the donor DU for UL and DL packets respectively. This requires the donor CU to configure the donor DU / IAB node DU with a mapping between the PDB and the UE bearer / flow id or a combination of the destination IP address / IP prefix, IPv6 flow label and or DSCP.

[0060] Example embodiments for delay and hop-aware rerouting

[0061] In some embodiments, delay and hop-aware rerouting may be implemented in the IAB network for delay management. As previously described in the example embodiments for delay measurement and reporting, after the donor CU collects the one-hop delays associated with the BHRLC channel along the routing path, the donor CU may (re)configure the appropriate routing path associated with the UE DRB / UL GTP tunnel / DL IP flow (identified by a combination of destination IP address / IP prefix, IPv6 flow label and or DSCP).

[0062] In addition, the donor CU may configure the IAB DU / donor DU with routing information. The routing information includes at least one of the following information: routing index, routing id, next hop BAP address, egress BH RLC channel id, remaining hops, and per-hop delay.

[0063] After receiving the packet, the IAB node / donor DU determines the remaining PDB based on an example embodiment for a discard mechanism. In addition, the IAB node / donor DU can determine the expected delay for the selected routing path as (remaining number of hops * delay per hop). The IAB node / donor DU then checks whether the remaining PDB is greater than the expected delay for the selected routing path. If so, this selected routing path can still be used. Otherwise, the IAB node / donor DU reselects another routing path that has the same destination BAP address and the expected delay is less than or equal to the remaining PDB.

[0064] In some embodiments, and for bearer mapping, the default BH RLC channel or any egress BH RLC channel may be used on the reselected routing path as long as the expected delay is less than the remaining PDB. In addition, the IAB node MT / DU or the donor DU may send a rerouting indication to the donor CU. The reason for the rerouting (e.g., delay or the original routing path cannot satisfy the PDB) may also be sent to the donor CU. The routing id of the original routing path that cannot satisfy the PDB may also be indicated to the donor CU. Upon receiving such an indication, the donor CU may reconfigure the routing path accordingly.

[0065] Example embodiments for delay-aware rerouting

[0066] In some embodiments, in the IAB network, delay-aware rerouting may be implemented for delay management. As previously described in the example embodiments for delay measurement and reporting, after the donor CU collects the one-hop delays associated with the BH RLC channel along the routing path, the donor CU may (re)configure the appropriate routing path associated with the UE DRB / UL GTP tunnel / DL IP flow (identified by a combination of destination IP address / IP prefix, IPv6 flow label and or DSCP).

[0067] In addition, the donor CU may configure the IAB DU / donor DU with routing information. The routing information includes at least one of the following information: routing index, routing id, next hop BAP address, egress BH RLC channel id, estimated path delay, and residual path delay.

[0068] After receiving the packet, the IAB node / donor DU determines the remaining PDB based on the PDB information or timestamp information included in the BAP header. The IAB node / donor DU then checks whether the remaining PDB is greater than the estimated path delay or the remaining path delay for the selected routing path. If so, this selected routing path can still be used. Otherwise, the IAB node / donor DU reselects another routing path with the same destination BAP address while also ensuring that the expected delay is less than or equal to the remaining PDB.

[0069] In some embodiments, and for bearer mapping, the default BH RLC channel or any egress BH RLC channel can be used on the reselected routing path as long as the estimated path delay or the remaining path delay is less than the remaining PDB. In addition, the IAB node MT / DU or the donor DU can indicate to the donor CU that the rerouting of the PDB cannot be satisfied due to the delay or the original routing path. The routing id of the original routing path that cannot satisfy the PDB can also be indicated to the donor CU. Upon receiving such an indication, the donor CU can reconfigure the routing path accordingly. The estimated path delay or the remaining path delay can also be referred to as a path weight.

[0070] Example embodiment for a drop mechanism based on a BH RLC channel

[0071] In some embodiments, a BH RLC channel based drop mechanism for the IAB network may be used for delay management.

[0072] For the UL direction, the donor CU may configure the IAB node MT with a discard timer associated with each BH RLC channel. Upon receiving a UL data packet, the IAB node MT may start a discard timer for the data packet. The discard timer is configured based on the discard timer for the corresponding egress BH RLC channel. If the discard timer associated with the data packet / BAP PDU / SDU expires, the data packet / BAP PDU / SDU may be discarded at the IAB node MT.

[0073] For DL ​​direction, the donor CU configures the donor DU / IABDU with a discard timer associated with each BH RLC channel. Upon receiving a DL data packet, the IAB node DU / donor DU may start a discard timer for the data packet. The discard timer is configured based on the discard timer for the corresponding egress BH RLC channel. If the discard timer associated with the data packet / BAP PDU / SDU expires, the data packet / BAP PDU / SDU may be discarded at the IAB node DU / donor DU.

[0074] Example Embodiments for Latency Configuration and Reporting

[0075] Based on consideration of different options for delay reporting, the donor CU may configure the IAB MT / DU or donor DU with an indication of whether the one-hop delay should be reported to the parent IAB node or the donor CU. Considering different options for carrying delay-related information in the BAP header / BAP control PDU, the donor CU may configure the IAB MT / DU or donor DU with an indication of whether the timestamp and or PDB should be included in the BAP header or BAP control PDU. The indication may be configured per BH RLC channel / UE DRB / SRB.

[0076] In addition, the IAB MT / DU may report at least one of the following information to the donor CU, such as its delay measurement / estimation capability, BAP discard capability, timestamp-based BAP header, PDB-based BAP header capability.

[0077] In some embodiments, for configuration / reporting between CU and DU, F1 Application Protocol (F1AP) may be used to carry this information. For configuration / reporting between MT and CU, RRC messages may be used to carry this information. For reporting / PDB / timestamp information between MT and DU, BAP header / BAP control PDU / MAC CE may be used to carry this information. The example embodiments for delay configuration and reporting are applicable to all previously described embodiments.

[0078] Example methods and implementations for the disclosed technology

[0079] Figure 5A An example of a wireless communication method is shown. The method 500 includes, at operation 502, receiving, by a first network node, a measurement configuration from a second network node.

[0080] The method 500 includes, at operation 504 , performing one or more delay measurements based on the measurement configuration.

[0081] The method 500 includes, at operation 506, transmitting a measurement report to the second network node, the measurement report including one or more delay measurements or an identification of a channel used for the one or more delay measurements.

[0082] Figure 5B An example of a wireless communication method is shown. The method 530 includes, at operation 532, transmitting, by the second network node, a measurement configuration to the first network node.

[0083] The method 530 includes, at operation 534, after the transmitting, receiving a measurement report including one or more delay measurements or an identification of a channel used for the one or more delay measurements.

[0084] In some embodiments, the method 530 further includes the operation of estimating delays for different routing paths based on the measurement reports.

[0085] In some embodiments, method 530 also includes configuring the operation of the first network node with a routing path based on the measurement report, wherein the routing path satisfies a packet delay budget (PDB) for a user equipment (UE) dedicated radio bearer (DRB), an uplink (UL) GPRS tunneling protocol (GTP) tunnel, or a downlink (DL) Internet Protocol (IP) flow.

[0086] In some embodiments, the one or more delay measurements are for packet transmission delays for an uplink channel or a downlink channel on a link for the first network node.

[0087] In some embodiments, the channel is a backhaul channel or a bearer channel.

[0088] In some embodiments, the backhaul channel is a backhaul (BH) radio link control (RLC) channel, wherein the bearer channel is a signaling radio bearer (SRB) or a dedicated radio bearer (DRB), wherein the identification of the backhaul channel is a BH RLC channel ID, and wherein the identification of the bearer channel is an SRB ID or a DRB ID.

[0089] In some embodiments, the first network node comprises an integrated access and backhaul (IAB) node or an IAB mobile terminal (IAB MT) or an IAB distributed unit (IAB DU) or a donor distributed unit (donor DU), and wherein the second network node comprises a donor centralized unit (CU) or a base station (BS).

[0090] In some embodiments, the measurement configuration includes one or more of the following items: (a) an indication of whether delay should be measured, (b) an indication of whether a backhaul channel or a bearer channel should be used to measure delay, (c) filter coefficients for one or more delay measurements, (d) an indication of whether delay should be reported, (e) a list of backhaul or bearer channels for which delay should be reported, (f) an indication of whether the measurement report is triggered by an event and an associated delay threshold, and (g) an indication of whether the measurement report is triggered periodically and an associated periodicity for the measurement report.

[0091] In some embodiments, the first network node is configured to transmit the measurement report to a parent IAB node or a child IAB node.

[0092] In some embodiments, the first network node is configured to receive a polling request from a parent IAB node or a child IAB node.

[0093] In some embodiments, the polling request is transmitted on a specific or configured backhaul radio link control (RLC) channel.

[0094] In some embodiments, the first network node is configured to receive routing information from the second network node.

[0095] In some embodiments, the routing information includes one or more of a routing identification (ID), a bearer ID, a next hop Backhaul Adaptation Protocol (BAP) address, an expected delay, a hop count, and a per-hop delay.

[0096] In some embodiments, the first network node is configured to receive a data packet destined for a third network node and determine whether a remaining value of a packet delay budget (PDB) is sufficient to use a selected routing path towards the third network node based on expected delay, hop count, or per-hop delay.

[0097] In some embodiments, the third network node is a donor distributed unit (donor DU) or an integrated access and backhaul (IAB) node.

[0098] In some embodiments, the first network node is configured to select a new routing path after determining that the selected routing path does not satisfy the remaining value of the PDB, and transmit the data packet on the new routing path, wherein the new routing path includes the same destination Backhaul Adaptation Protocol (BAP) address as the selected routing path, and wherein the expected delay of the new routing path is less than or equal to the remaining value of the PDB.

[0099] In some embodiments, the expected delay of a default backhaul (BH) radio link control (RLC) channel or an egress BH RLC channel is less than or equal to a residual value of the PDB on the new routing path.

[0100] In some embodiments, the first network node is configured to transmit the data packet on the selected routing path upon determining that the selected routing path satisfies the remaining value of the PDB.

[0101] In some embodiments, the first network node is a first integrated access and backhaul (IAB) node, wherein the second network node is a parent IAB node or a donor distributed unit (donor DU), and wherein the third network node is a second IAB node or a downstream IAB node.

[0102] In some embodiments, the first network node is a parent integrated access and backhaul (IAB) node, wherein the second network node is an IAB node, and wherein the third network node is a donor distributed unit (donor DU).

[0103] In some embodiments, the first network node is a first donor distributed unit (donor DU), wherein the second node is a child integrated access and backhaul (IAB) node, and wherein the third network node is a second donor DU.

[0104] In some embodiments, the one or more delay measurements include a one-hop delay measurement.

[0105] Figure 5C An example of a wireless communication method is shown. The method 560 includes, at operation 562, configuring, by the first network node, a discard timer for a backhaul channel.

[0106] The method 560 includes, at operation 564, determining whether the received data packet is subsequently transmitted on the backhaul channel or discarded based on the discard timer.

[0107] In some embodiments, the method 560 also includes an operation of receiving, by the first network node, a configuration for a discard timer from the second network node.

[0108] In some embodiments, the first network node is an integrated access and backhaul (IAB) mobile terminal (IAB MT), an IAB distributed unit (DU), or a donor DU, and wherein the second network node is a donor centralized unit (donor CU).

[0109] In some embodiments, the method 560 further includes the operations of starting a discard timer after receiving the data packet for the backhaul channel and discarding the data packet after determining that the discard timer has expired.

[0110] In some embodiments, a Backhaul Adaptation Protocol (BAP) header of the data packet includes a Packet Delay Budget (PDB), and wherein the PDB drop timer is configured based on that.

[0111] In some embodiments, the PDB is configured by the second network node and is associated with a combination of one or more of a UE dedicated radio bearer (DRB), uplink (UL) user plane (UP) transport network layer (TNL) information, a destination Internet Protocol (IP) address, an IPv6 prefix, an IPv6 flow label, or a differentiated services code point (DSCP).

[0112] In some embodiments, a Backhaul Adaptation Protocol (BAP) header of the data packet includes a timestamp, and wherein the discard timer is configured based on the timestamp.

[0113] In some embodiments, the data packet comprises a BAP protocol data unit (PDU) or a service data unit (SDU).

[0114] Figure 6 605 is a block diagram representation of a portion of an apparatus according to some embodiments of the presently disclosed technology. An apparatus 605, such as a base station or a wireless device (or UE), can include a processor electronic device 610, such as a microprocessor, which implements one or more of the technologies presented in this document. The apparatus 605 can include a transceiver electronic device 615 to send and / or receive wireless signals through one or more communication interfaces such as an antenna 620. The apparatus 605 can include other communication interfaces for transmitting and receiving data. The apparatus 605 can include one or more memories (not explicitly shown) configured to store information such as data and / or instructions. In some embodiments, the processor electronic device 610 can include at least a portion of the transceiver electronic device 615. In some embodiments, the apparatus 605 is used to implement at least some of the disclosed technologies, modules, or functions.

[0115] Some embodiments described herein are described in the general context of a method or process, which may be implemented in one embodiment by a computer program product embodied in a computer-readable medium, which includes computer executable instructions, such as program code, executed by a computer in a network environment. Computer-readable media may include removable and non-removable storage devices, including but not limited to read-only memory (ROM), random access memory (RAM), compact disk (CD), digital versatile disk (DVD), etc. Therefore, computer-readable media can include non-transitory storage media. Typically, program modules may include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer or processor executable instructions, associated data structures, and program modules represent examples of program codes for executing the steps of the methods disclosed herein. A specific sequence of such executable instructions or associated data structures represents an example of corresponding actions for implementing the functions described in such steps or processes.

[0116] Some disclosed embodiments can be implemented as devices or modules using hardware circuits, software or a combination thereof. For example, a hardware circuit implementation can include discrete analog and / or digital components, which are, for example, integrated as a part of a printed circuit board. Alternatively or additionally, the disclosed components or modules can be implemented as application specific integrated circuits (ASICs) and / or as field programmable gate arrays (FPGAs) devices. Some embodiments can additionally or alternatively include a digital signal processor (DSP), which is a specialized microprocessor whose architecture is optimized for the operational requirements of digital signal processing associated with the functions disclosed in the present application. Similarly, various components or subcomponents within each module can be implemented with software, hardware or firmware. The connection between the modules and / or the components within the modules can be provided using any of the connection methods and media known in the art, including but not limited to the communication performed by the Internet, wired or wireless networks using appropriate protocols.

[0117] Although this document contains many details, these should not be interpreted as limitations on the scope of the claimed invention or the scope of the invention that may be claimed, but as a description specific to a particular embodiment. Certain features described in the context of a separate embodiment in this document may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination. In addition, although the above-mentioned features may be described as working in certain combinations and even initially claimed in such a manner, in some cases, one or more features from the claimed combination may be deleted from the combination, and the claimed combination may be directed to a sub-combination or a variant of a sub-combination. Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring such operations to be performed in the particular order shown or in a sequential order, or requiring all illustrated operations to be performed to achieve the desired result.

[0118] Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this disclosure.

Claims

1. A method for wireless communication, comprising: Receiving, by the first network node, a measurement configuration from the second network node; performing one or more delay measurements based on the measurement configuration; transmitting a measurement report to the second network node, the measurement report comprising the one or more delay measurements or an identification of a channel used for the one or more delay measurements; Receiving, by the first network node, routing information, wherein the routing information includes one or more of an expected delay, a hop count, and a per-hop delay; receiving, by the first network node, a data packet configured for a third network node; determining, by the first network node, whether a remaining value of a packet delay budget (PDB) is sufficient to use the selected routing path toward the third network node based on a Backhaul Adaptation Protocol (BAP) header of the data packet, the expected delay, the hop count, or the per-hop delay; and After determining that the selected routing path satisfies the remaining value of the PDB, the first network node transmits the data packet on the selected routing path; or A new routing path is selected upon determining that the selected routing path does not satisfy the remaining value of the PDB, and the data packet is transmitted on the new routing path, wherein the new routing path includes the same destination BAP address as the selected routing path, and wherein an expected delay of the new routing path is less than or equal to the remaining value of the PDB.

2. The method according to claim 1, wherein: The one or more delay measurements are for packet transmission delays for an uplink channel or a downlink channel on a link for the first network node.

3. The method according to claim 1, wherein: The channel is a backhaul channel or a bearer channel.

4. The method according to claim 3, wherein: The backhaul channel is a backhaul BH radio link control RLC channel, wherein the bearer channel is a signaling radio bearer SRB or a dedicated radio bearer DRB, wherein the identifier of the backhaul channel is a BH RLC channel ID, and wherein the identifier of the bearer channel is an SRB ID or a DRB ID.

5. The method according to claim 1, wherein: The first network node comprises an Integrated Access and Backhaul IAB node or an IAB Mobile Terminal IAB MT or an IAB Distributed Unit IAB DU or a Donor Distributed Unit (Donor DU), and wherein the second network node comprises a Donor Centralized Unit CU or a Base Station BS.

6. The method according to any one of claims 1 to 5, wherein: The measurement configuration includes one or more of the following: an indication of whether the delay should be measured, an indication of whether a backhaul channel or a bearer channel should be used to measure the delay, filter coefficients for the one or more delay measurements, an indication of whether the delay should be reported, a list of backhaul or bearer channels for which the delay should be reported, an indication of whether the measurement report is triggered by an event and an associated delay threshold, and An indication of whether the measurement report is triggered periodically and an associated periodicity for the measurement report.

7. The method according to claim 5, wherein: The first network node is configured to transmit the measurement report to a parent IAB node or a child IAB node.

8. The method according to claim 7, wherein: The first network node is configured to receive a polling request from the parent IAB node or the child IAB node.

9. The method according to claim 8, wherein: The polling request is transmitted on a specific or configured backhaul radio link control, RLC, channel.

10. The method according to claim 1, wherein: The third network node is a Donor Distributed Unit (Donor DU) or an Integrated Access and Backhaul IAB node.

11. The method according to claim 1, wherein: An expected delay of a default backhaul BH Radio Link Control RLC channel or an egress BHRLC channel is less than or equal to a residual value of the PDB on the new routing path.

12. A method of wireless communication, comprising: transmitting, by the second network node, the measurement configuration to the first network node; receiving a measurement report after the transmitting, the measurement report comprising one or more delay measurements or an identification of a channel used for the one or more delay measurements; as well as The second network node transmits routing information to the first network node, wherein the routing information includes one or more of an expected delay, a hop count, and a per-hop delay, so that the first network node can: determining whether a remaining value of a packet delay budget PDB is sufficient to use the selected routing path towards the third network node based on a Backhaul Adaptation Protocol (BAP) header of the data packet, the expected delay, the hop count or the per-hop delay; and After determining that the selected routing path satisfies the remaining value of the PDB, transmitting the data packet on the selected routing path; or A new routing path is selected upon determining that the selected routing path does not satisfy the remaining value of the PDB, and the data packet is transmitted on the new routing path, wherein the new routing path includes the same destination BAP address as the selected routing path, and wherein an expected delay of the new routing path is less than or equal to the remaining value of the PDB.

13. The method according to claim 12, further comprising: Delays for different routing paths are estimated based on the measurement reports.

14. The method according to claim 12, further comprising: Based on the measurement report, the first network node is configured with a routing path that meets a packet delay budget PDB for a user equipment UE dedicated radio bearer DRB, an uplink UL GPRS tunneling protocol GTP tunnel or a downlink DL Internet Protocol IP flow.

15. The method according to claim 12, wherein: The one or more delay measurements are for packet transmission delays for an uplink channel or a downlink channel on a link for the first network node.

16. The method according to claim 12, wherein: The channel is a backhaul channel or a bearer channel.

17. The method according to claim 16, wherein: The backhaul channel is a backhaul BH radio link control RLC channel, wherein the bearer channel is a signaling radio bearer SRB or a dedicated radio bearer DRB, wherein the identifier of the backhaul channel is a BH RLC channel ID, and wherein the identifier of the bearer channel is an SRB ID or a DRB ID.

18. The method according to claim 12, wherein: The first network node comprises an Integrated Access and Backhaul IAB node or an IAB Mobile Terminal IAB MT or an IAB Distributed Unit IAB DU or a Donor Distributed Unit (Donor DU), and wherein the second network node comprises a Donor Centralized Unit CU or a Base Station BS.

19. The method according to any one of claims 12 to 18, wherein: The measurement configuration includes one or more of the following: an indication of whether the delay should be measured, an indication of whether a backhaul channel or a bearer channel should be used to measure the delay, filter coefficients for the one or more delay measurements, an indication of whether the delay should be reported, a list of backhaul or bearer channels for which the delay should be reported, an indication of whether the measurement report is triggered by an event and an associated delay threshold, and An indication of whether the measurement report is triggered periodically and an associated periodicity for the measurement report.

20. The method according to claim 18, wherein: The first network node is configured to transmit the measurement report to a parent IAB node or a child IAB node.

21. The method according to claim 20, wherein: The first network node is configured to receive a polling request from the parent IAB node or the child IAB node.

22. The method according to claim 21, wherein: The polling request is transmitted on a specific or configured backhaul radio link control, RLC, channel.

23. The method according to claim 12, wherein: The third network node is a Donor Distributed Unit (Donor DU) or an Integrated Access and Backhaul IAB node.

24. The method according to claim 12, wherein: An expected delay of a default backhaul BH Radio Link Control RLC channel or an egress BHRLC channel is less than or equal to a residual value of the PDB on the new routing path.

25. A wireless communication device, comprising a processor and a memory, wherein: The processor is configured to read code from the memory and implement the method of any one of claims 1 to 24.

26. A computer program product comprising computer readable program medium code stored thereon, which, when executed by a processor, causes the processor to implement the method of any one of claims 1 to 24.

Images