User interface for integrated access and backhaul

Abstract

The present invention relates to an integrated access and backhaul user interface, describes various techniques and procedures for transmitting data over an integrated access and backhaul network, and discloses methods for traffic control and handling of lost or delayed packets.

Description

TECHNICAL FIELD

[0001] The present invention relates to data transmission for user interface for integrated access and backhaul (IAB) deployment in cellular networks. BACKGROUND

[0002] Wireless communication systems such as the well-known third generation (3G) mobile telephony standards and technologies have been developed by the Third Generation Partnership Project (3GPP). Third generation wireless communication has generally been developed to support macrocell mobile telephony communications. The communication systems and networks have evolved towards broadband and mobile systems.

[0003] In a cellular wireless communication system, user equipment (UE) is connected to a radio access network (RAN) over a wireless link. The radio access network comprises a set of base stations providing wireless links for user equipment located in cells covered by the base stations, and an interface to a core network (CN) providing overall network control. As will be appreciated, the radio access network and core network each perform respective functions relating to the overall network. For convenience, the term cellular network will be used to refer to the combined radio access network and core network, and it will be understood that the term is used to refer to the corresponding system for performing the disclosed functions.

[0004] The Third Generation Partnership Project developed a so-called Long Term Evolution (LTE) system, i.e. an Evolved Universal Mobile Telecommunications System Terrestrial Radio Access Network (E-UTRAN), for a mobile access network of one or more cells supported by base stations known as eNodeBs or Enbs (E-UTRAN). More recently, LTE has evolved further towards a so-called 5G or NR (E-UTRAN) system in which one or more cells are supported by base stations known as gNBs. NR is proposed to use an Orthogonal Frequency Division Multiplexing (OFDM) physical transmission format.

[0005] Integrated Access and Backhaul (IAB) is a system that provides an integrated backhaul for user traffic over the NR radio interface. An Integrated Access and Backhaul node (Access IAB node or Intermediate IAB node) consists of a Mobile-Termination (MT) part and a Distributed Unit (DU) part. The Mobile-Termination (MT) part terminates the radio interface layer of the backhaul Uu interface to an IAB-donor or other IAB-nodes. The IAB-node connects to an upstream IAB-node or IAB-donor-DU through the Mobile-Termination part. The DU terminates the F1* interface (F1 interface over NR backhaul) connected to a gNB-CU and provides wireless backhaul for downstream IAB-nodes and UEs.

[0006] Figure 1 and Figure 2 Aspects of an integrated access and backhaul architecture are shown.

[0007] Figure 3 An integrated access and backhaul user interface protocol stack (in case of connection to 5GC) is shown. For the purpose of the following disclosure, the data path within the NG-RAN, i.e. the packet data convergence protocol (PDCP) connection between the central unit and the user equipment (UE) is relevant. This still applies with EPC instead of 5GC (in this case, SDAP does not apply, and the NG interface is replaced by the S1-U interface). The packet data convergence protocol layer provides radio bearer services to upper layers. In the context of the user interface, i.e. the transmission of user interface data, the packet data convergence protocol provides data radio bearer services. A data radio bearer transports packet data convergence protocol SDUs (embedded in packet data convergence protocol protocol data units) between the transmitting and receiving packet data convergence protocol entities.

[0008] The F1-U interface is defined in TS 38.474 and relies on GTP-U tunnels to transport packet data convergence protocol protocol data units (Protocol Data Unit).

[0009] Therefore, it is necessary to provide a new user interface in an integrated access and backhaul network. SUMMARY

[0010] The purpose of the present application is to provide a new user interface in an integrated access and backhaul network.

[0011] The purpose of the present application is achieved by the technical solution one: a method for transmitting data from a central unit to a user equipment through a distributed unit in an integrated access and backhaul network, the method comprising receiving, at the distributed unit, an F1 application flow protocol configuration message, the configuration message indicating the distributed unit to activate or deactivate, on a data radio bearer basis, packet data convergence protocol protocol data unit reordering in the distributed unit, receiving, at the distributed unit, packet data convergence protocol protocol data units for transmission to the user equipment, and if the configuration message indicates to activate packet data convergence protocol protocol data unit reordering for the relevant data radio bearer, the distributed unit reordering the packet data convergence protocol protocol data units before transmitting the packet data convergence protocol protocol data units to the user equipment.

[0012] Further, the configuration message is a message of the F1 application flow protocol.

[0013] Further, the method further comprises the step of sending to the user equipment only packet data convergence protocol header packets when a packet data convergence protocol protocol data unit is identified as missing, wherein the length of the SN of the packet data convergence protocol of the only header packets corresponds to the length of the SN of the packet data convergence protocol of the missing packet data convergence protocol protocol data unit.

[0014] Further, the reordering is performed based on the SN or the NR-U SN of the packet data convergence protocol.

[0015] Further, if the configuration message indicates that packet data convergence protocol protocol data unit reordering is deactivated for the concerned data radio bearer, the received packet data convergence protocol protocol data units are forwarded without reordering.

[0016] Further, if the configuration message indicates that packet data convergence protocol protocol data unit reordering is activated, the distributed unit identifies and waits for missing packets based on the NR-U SN before sending to the user equipment the buffered packet data convergence protocol protocol data units with higher SN of the packet data convergence protocol.

[0017] Further, upon detecting a packet data convergence protocol protocol data unit SN gap created by a missing packet before forwarding the subsequently buffered packet data convergence protocol protocol data units to the user equipment, the distributed unit waits for a predetermined packet forwarding waiting delay.

[0018] The object of the present invention is achieved by the following technical solution two: a method for transmitting data from a central unit to a user equipment by a distributed unit in an integrated access and backhaul network, the method comprising configuring a missing packet detection delay for the distributed unit, upon detecting a missing packet data convergence protocol protocol data unit, the distributed unit declares the missing packet data convergence protocol protocol data unit upon expiration of the missing packet detection delay.

[0019] Further, the missing packet detection delay is defined for the data radio bearer or the user equipment.

[0020] Further, the missing packet detection delay is signaled to the distributed unit over the F1 control plane interface.

[0021] Further, the missing packet detection delay is equal to a packet forwarding waiting delay defined for the concerned data radio bearer or the user equipment at the distributed unit.

[0022] Further, the missing packet detection delay is greater than a packet forwarding waiting delay defined for the concerned data radio bearer or the user equipment at the distributed unit.

[0023] Further, if a protocol data unit of the in- cast protocol is received by the distributed unit declaring missing before the in-cast protocol reordering time expires, the protocol data unit of the in-cast protocol is sent to the user equipment.

[0024] Further, the method comprises transmitting from the distributed unit to the relevant central unit of the integrated access and backhaul network a report indicating protocol data units of the in-cast protocol missing.

[0025] Further, the method comprises transmitting from the distributed unit to the relevant central unit of the integrated access and backhaul network a report indicating protocol data units of the in-cast protocol missing.

[0026] Further, the report is a downlink data delivery status report.

[0027] The object of the present invention is achieved by the following technical solution three: a method for transmitting data from a central unit to a user equipment by a distributed unit in an integrated access and backhaul network, the method comprising transmitting a DDDS report from the distributed unit to the central unit, wherein the DDDS report comprises a missing / delayed packet report indicating missing / delayed but not yet declared missing packets.

[0028] Further, the missing packet report transmission is enabled at the distributed unit by a data radio bearer based Fl application procedure protocol signal instruction.

[0029] Further, the missing packet report delay can be configured at the distributed unit using a data radio bearer based Fl application procedure protocol signal instruction, such that when a missing packet report is sent, only packets whose missing time is greater than this value are indicated to the central unit. BRIEF DESCRIPTION OF DRAWINGS

[0030] Figure 1 and Figure 2 Various aspects of an integrated access and backhaul architecture are shown.

[0031] Figure 3 An integrated access and backhaul user interface protocol stack is shown.

[0032] Figure 4 Selected elements of a cellular network are shown. DETAILED DESCRIPTION

[0033] The person skilled in the art will recognize and appreciate that the details of the described examples are merely illustrative of some embodiments and are not to be understood as limiting the present invention and that the teachings set forth herein apply to various alternative settings.

[0034] Figure 4A schematic diagram showing three base stations (e.g. eNBs or gNBs, depending on the particular cellular standard and terminology) that make up a cellular network is shown. Typically, each base station will be deployed by a cellular network operator to provide geographical coverage for UEs in that area. The base stations form a Radio Area Network (RAN). Each base station provides wireless coverage for UEs in its area or cell. The base stations are interconnected by X2 interfaces and connected to a core network by S1 interfaces. As will be appreciated, only basic details are shown in order to illustrate key features of a cellular network. Related interface and component names are used only as examples, different systems operating on the same principles can use different nomenclature. Figure 4

[0035] Each base station contains hardware and software that implements the radio access network functionality, including communication with the core network and other base stations, control and data signal transmission between the core network and UEs, and maintaining wireless communication with UEs associated with each base station. The core network includes hardware and software that implements network functionality, such as overall network management and control, and routing of cells and data.

[0036] The NR User Plane Protocol is specified in TS 38.425. It is located in the user plane of the radio network layer, on the Xn or X2 or F1 interface, inside the “NR RAN container” GTP-U extension header. It is used to transfer control information related to user data flow management for data radio bearers. Each NR User Plane Protocol instance is associated with only one data radio bearer. There is one NR User Plane instance per GTP tunnel. A new NR User Plane instance is established when a GTP tunnel is established. The NR UP protocol is often referred to as NR-U.

[0037] It allows flow control for user data packets transmitted from a node carrying NR PDCP (packet data convergence protocol) to a corresponding node (a corresponding node refers to a node that does not carry an NR PDCP entity). In the context of integrated access and backhaul, F1-U is used between a donor CU (a node hosting NR-PDCP) and a visitor DU (a corresponding node).

[0038] ​As mentioned above, Fl-U relies on GTP tunnels to transport the Protocol Data Units (PDUs) of the packet data convergence protocol. More precisely, the GTP-U protocol is used, i.e. GTP-U PDUs are transported, embedding the PDUs of the packet data convergence protocol. NR UP protocol information is added to this PDU. It is commonly referred to as “NR-U packet”. For initial transmissions, the node hosting the NR PDCP entity assigns a consecutive NR-U sequence number to each transmitted NR-U packet. The corresponding node detects whether an NR-U packet is lost and records the corresponding sequence number after it declares the corresponding NR-U packet as “lost”.

[0039] The corresponding node delivers the remaining PDUs of the packet data convergence protocol to the UE and records the highest PDU sequence number (used in case of RLC AM) of the PDUs of the packet data convergence protocol successfully delivered in sequence to the UE and the highest PDU sequence number of the PDUs of the packet data convergence protocol sent to lower layers for the PDUs of the packet data convergence protocol of the NR. Each node can not receive all PDCP packets as a data radio bearer (DRB) can be split into multiple legs (thus the transmission of the PDUs of the packet data convergence protocol of the same DRB can use different legs).

[0040] In one example, the CU sends the PDUs of the packet data convergence protocol to DU1 with PDCP SN un, where n = 0, 1, 2,... denotes the corresponding NR-U SN related to Fl-U between the CU and DU1. The CU can also send the PDUs of the packet data convergence protocol to DU2 with PDCP SN vn, where n = 0, 1, 2,... denotes the corresponding NR-U SN related to Fl-U between the CU and DU2.

[0041] The CU can use split bearers and send spare packets to each link:

[0042] u0 = 0, u1 = 2, u2 = 4, u3 = 6, etc.,

[0043] v0 = 1, v2 = 3, v2 = 5, v3 = 7, etc.

[0044] However, there is no restriction on the CU scheduling and in another example, the CU can duplicate the PDU on both links:

[0045] u0 = 0, u1 = 1, u2 = 2, u3 = 3, etc.,

[0046] v0=0, v2=1, v2=2, v3=3, etc.

[0047] Thus, for a given F1-U interface to a DU, the data packets are ordered by the CU in increasing order of NR-U SNs (without NR-U SN gaps) and in increasing order of the corresponding PDCP SNs (but those SNs can already have gaps, as shown in the example of split bearers).

[0048] For retransmissions, the node carrying the NR PDCP entity indicates to the respective node whether this NR-U data packet is a retransmission of a protocol data unit of the NR- in-Data-Packet-Set protocol. A retransmission of a protocol data unit of the NR-in-Data-Packet-Set protocol is assigned a new NR-U sequence number.

[0049] For example, the CU sends data packets to DU1 and DU2,

[0050] u0=0, u1=2, u2=4, u3=6, etc.

[0051] v0=1, v2=3, v2=5, v3=7, etc.

[0052] However, if DU1 experiences a temporary interruption and data packets with PDCP SNs 4 and 6 cannot be sent to the target UE. The CU can retransmit these data packets to DU2.

[0053] V4=4, V5=6, etc.

[0054] Even if only one link to one DU is used, the CU can retransmit PDCP data packets if it knows that certain data packets are missing:

[0055] u0=0, u1=1, u2=2, u3=3,

[0056] ui informs that it is missing,

[0057] u4=1 (retransmission of PDCP SN 1).

[0058] Retransmitted PDCP data packets need to be explicitly marked as retransmissions because their order of PDCP SNs is different from the corresponding stream of initial transmissions and thus require specific handling.

[0059] The node carrying the NR PDCP entity can indicate to the respective node to discard all protocol data units of the NR-in-Data-Packet-Set protocol up to and including a defined DL Discard NR-in-Data-Packet-Set protocol data unit SN, or to discard one or more blocks of downlink protocol data units of the NR-in-Data-Packet-Set protocol.

[0060] The Downlink Data Delivery Status (DDDS) procedure provides feedback from the respective node to the node hosting the NR PDCP entity to allow the node hosting the NR PDCP entity to control the downlink user data flow for the respective data radio bearers by the respective node and also to provide feedback to allow the node hosting the NR PDCP entity to control the successful delivery of DL control data to the respective node. The DDDS is defined in TS 38.425.

[0061] The NR User Interface protocol is used together with the DDDS to guarantee lossless transmission by letting the CU perform the necessary retransmissions (TS 38.401, 8.3).

[0062] As mentioned above, one of the main objectives of NR-U is to solve the flow control in DL between CU and DU. This means that the control should be done on how much data is sent from the CU to the DU in DL to avoid congestion while still avoiding any starvation to optimize the final throughput.

[0063] Integrated Access and Backhaul aims at utilizing the mmWave spectrum, which is less reliable and prone to temporary blockage. It is expected that this will be mitigated by utilizing routing redundancy. Depending on the RF conditions, different paths can be used between the CU and the UE. These paths can be configured / used simultaneously (this assumes multi-connectivity from the UE and / or the integrated access and backhaul node) and / or switched.

[0064] Assuming that the path 1 that is being used becomes unreliable, the CU can decide to use path 2 instead. In case of AM bearers, lossless transmission is expected. In Rel-15, a centralized (fast) retransmission function is defined to allow the CU to retransmit the protocol data units of the packet data centralized protocol from one leg to another leg according to the DDDS feedback.

[0065] The NR-U protocol specifies that the respective node shall detect whether an NR-U packet is lost, but the implementation of this function is not defined.

[0066] In non-integrated access and backhaul scenarios, the interface (X2 / Xn / F1) over which the NR-U is transported is wired, typically using an IP backbone. It is expected that packet loss or non-delivery over such wired interfaces will be a very rare event. In the exceptional case of packet out-of-order delivery, it can also be expected that the increased delay will be short. Therefore, a possible implementation can be that, upon noticing an NR-U sequence number gap, the lost NR-U packet is declared lost. Another implementation can delay the packet loss declaration for a short time range, e.g. 1 ms.

[0067] In the example where there is only one DU, we can send the following packets from the CU to the DU:

[0068] u0=0, u1=1, u2=2, u3=3, etc.

[0069] At the DU, data packets should arrive in order and without loss:

[0070] u0=0, u1=1, u2=2, u3=3, etc.

[0071] In rare exceptions, out-of-order delivery can occur:

[0072] u0=0, u2=2, u1=1, u3=3, etc.

[0073] In rare exceptions, packet loss can occur:

[0074] u0=0, u2=2, u3=3, etc. (u1=1 is never received).

[0075] These cases are considered very rare and exceptional, as F1-U as transport layer is wireline in non-integrated access and backhaul scenarios. In the above cases, it is expected that the DU will wait for data packet u1 for a very short time, as it is expected not to be delayed by the wireline interface. This can be for example 1 ms.

[0076] In contrast, in integrated access and backhaul scenarios, NR-U is transmitted over the air interface. It is expected that out-of-order delivery of data packets can occur (due to HARQ and / or ARQ, and use of different paths). It is expected that packet loss is also common in UM. In AM, packet loss is expected mainly in case of radio link interruption (or temporary blocking), requiring the use of alternative paths. A traditional implementation of an AM bearer providing lossless delivery, reacting immediately to NR-U SN gaps, would have the following behavior.

[0077] Data packets corresponding to NR-U gaps are not waited for and declared lost (even though they can just be delayed and arrive later through HARQ / ARQ / alternative integrated access and backhaul path). HARQ delays can be limited to a few milliseconds, depending on the PHY layer configuration (HARQ RTT and maximum number of repetitions). ARQ delays can be more significant. Typical RLC RTT is indicated in Table 4.1.4-1 of TS 38.306. The RTT in TS 38.306 is only for reference, and can be larger depending on the configuration. These delays can increase with the number of hops. Delays introduced using alternative integrated access and backhaul paths can be more important.

[0078] Missing packets are reported to the CU in the DDDS and will be retransmitted by the CU in new NR-U packets. The node hosting the PDCP must retransmit any reported missing packets as any of them can have really been lost. The retransmission can be done on the same GTP-U tunnel or an alternative tunnel if available. In the case of integrated access and backhaul, the retransmission can happen on an alternative path (same or different tunnel). As the retransmitted packets use the same protocol, they can also be declared missing (once delayed), which can trigger retransmission again.

[0079] The highest successfully delivered NR PDCP sequence number represents "the highest NR packet data set protocol data unit sequence number successfully delivered to the UE in order among those NR packet data set protocol data units received from the node hosting the NR PDCP entity". This parameter is key for the CU to know which packet data set protocol data units have finally arrived successfully to the UE. There is no detail in the current standard on how this relates to packet loss, but it is expected that once a packet is declared lost, the highest delivered NR PDCP SN can move forward (as it is no longer waiting for the missing packet). The NR highest PDCP SN is initially used for flow control to prevent sending more than half of the PDCP SN space (to avoid HFN desynchronization issues). Therefore, this can be an issue as these missing packets can still be delivered later.

[0080] In one example, considering only one DU, we can have the following packets sent from the CU to the DU:

[0081] u0=0, u1=1, u2=2, u3=3, etc.

[0082] A traditional DU implementation would expect the packets to arrive in order and without loss:

[0083] u0, u1, u2, u3, u4, u5, u6, u7,

[0084] However, due to HARQ retransmission, the packets can arrive as follows:

[0085] u0, u1, u4, u5, u2, u3, u6, u7,

[0086] For example, packets U2, U3 are delayed as they are in a transport block that experienced HARQ retransmission. If the HARQ retransmission of this TB fails, an ARQ retransmission (at RLC level) will be triggered. This will delay more packets, so that the DU can receive:

[0087] u0, u1, u4, u5, u6, u7, u8, u10, u9... u176, u2, u3...

[0088] A conventional implementation can declare u2 and u3 lost before they are received, which has two main impacts:

[0089] First, in DDDS, u2, u3 are reported as lost, which will be retransmitted by the CU. Typically, due to HARQ / ARQ and multi-hop, a significant subset of the data packets is expected to be delayed (at least 10%, which is a normal HARQ BLER operating point for a link), which will expand the hop transmission as multi-hop. All these data packets will be declared lost by the CU and retransmitted, which is not desirable.

[0090] Second, the "Highest successfully delivered NR PDCP SN" DELIV_SN will be set to the highest NR PDCP SN successfully delivered at the time of sending the DDDS, ignoring the lost u2 and u3 which are not expected anymore. This allows the CU to transmit at most DELIV_SN + half the PDCP SN space. However, during the configured reordering timer, the UE is still waiting for u2, u3. The PDCP reception window at the UE side does not move, while the PDCP transmission window at the CU side moves, while the transmitting side PDCP window is only allowed to move based on the movement of the PDCP reception window. This can lead to the UE receiving data packets outside the PDCP reception window (ignored) or within the PDCP reception window but very late (PDCP SN wraparound) causing HFN desynchronization issues (from this point, all data packets will be decrypted wrongly).

[0091] Considering some typical data, a data rate of 10 Gbps (common for NR) and a SDU size of 1500 bytes leads to 833 data packets per ms. With a maximum PDCP SN length of 18 bits, half the PDCP SN space is 131072, which takes only 157 ms. This shows that the above situation can easily happen.

[0092] The following techniques are listed below, aiming at improving the flow control related to wireless backhaul systems, especially integrated access and backhaul.

[0093] In an integrated access and backhaul system, due to HARQ, ARQ or alternative paths for the NR backhaul, protocol data units of the packet data convergence protocol are expected to arrive out of order at the corresponding node (integrated access and backhaul access node) frequently. It can be beneficial to reorder the protocol data units of the packet data convergence protocol before sending them to the UE.

[0094] In a first example, the protocol data units of the packet data convergence protocol can be reordered before forwarding to the UE, which helps to comply with the requirement in the DDDS report to include "the sequence number of the highest NR packet data convergence protocol protocol data unit successfully delivered in order". Reordering means that the highest NR packet data convergence protocol protocol data unit SN can be derived directly from the cumulative RLC ACK SN received at lower layers, as the highest NR packet data convergence protocol protocol data unit SN will correspond to the RLC PDU with the RLC ACK SN. Reordering can also reduce the UE buffering requirements, as a large number of PDUs will be received in order at the UE and most of the buffering will be performed in the DU during the reordering process.

[0095] However, reordering at the respective nodes does increase the complexity of the DU and can introduce a delay at the DU. If one packet is lost (e.g. on the interface between the donor's CU and DU), it will be waited for twice - first at the DU and then at the UE. This delay can be mitigated by creating and sending a dummy "PDCP header only" packet to avoid PDCP SN gaps at the UE, but this will require additional complexity and can require modifications to the standard.

[0096] Reordering can be based on PDCP SN or NR-U SN. The outcome of the initial transmission is the same, but the outcome of the retransmission is different.

[0097] Thus, there is provided a method of transmitting data from a DU to a UE in an integrated access and backhaul network, wherein the DU reorders the protocol data units of the packet data convergence protocol before transmitting the protocol data units of the packet data convergence protocol to the UE.

[0098] In a second example, the protocol data units of the packet data convergence protocol can not be reordered at the respective nodes. In this configuration, PDCP is applied end-to-end between the UE and the CU, reordering is performed only at the UE or the CU, and the elements along the path forward the received PDUs with minimal queuing and processing. This has the advantage of reducing the delay, as if a packet is lost, only the UE will wait (before forwarding the later PDUs to the application layer). Not reordering also simplifies the configuration of the corresponding nodes.

[0099] Thus, there is provided a method of transmitting data from a DU to a UE in an integrated access and backhaul network, wherein the DU does not reorder the protocol data units of the packet data convergence protocol before transmitting those PDUs to the UE.

[0100] A potential drawback of not reordering at the DU is that the buffer size at the UE can increase and the derivation of the protocol data unit sequence number of the highest NR packet data convergence protocol successfully delivered in sequence at the DU can be more complex. The DU can still keep track of the protocol data units of the packet data convergence protocol that were successfully delivered (as there is a one-to-one mapping between the RLC PDU and the protocol data unit of the packet data convergence protocol) and still provide the same feedback to the CU.

[0101] For different use cases or services, reordering or not reordering at the respective node can be preferred. Therefore, it is preferred to be able to activate or deactivate reordering before forwarding to the UE at the respective node. In one example, the F1-AP (F1 Application Protocol) can configure reordering in the DU based on the DRB (message UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST).

[0102] Therefore, a method is provided for using the F1-AP to send a message to the DU to activate or deactivate the reordering of the protocol data units of the packet data convergence protocol in the DU when sending the protocol data units of the packet data convergence protocol to the UE.

[0103] When the reordering of the protocol data units of the packet data convergence protocol is configured at the respective node, the DU has to wait for the missing NR-U packet (PDCP SN gap has been created) before sending the buffered protocol data units of the packet data convergence protocol (with higher PDCP SN) to the UE. The DU does not take into account the gap in the PDCP SN sequence as this is a common case when using split bearers. The NR-U SN is only used to identify the missing packet. A “packet forwarding waiting delay” can be introduced to indicate how long the node should wait after noticing the protocol data unit SN gap of the packet data convergence protocol created by the missing packet (NR-U SN gap) before forwarding the subsequent buffered protocol data units of the packet data convergence protocol to the UE.

[0104] Therefore, a method is provided for transmitting data from a DU to a UE in an integrated access and backhaul network, wherein the DU is configured with a packet forwarding waiting delay, and wherein, when a protocol data unit SN gap of the packet data convergence protocol due to a missing PDU is detected, the DU waits at least for the packet forwarding waiting delay before sending the subsequent protocol data units of the packet data convergence protocol to the UE.

[0105] Compared to wired backhaul, packet loss can be relatively common in wireless backhaul, and thus a more robust procedure to handle such loss can be needed to ensure consistent handling. A parameter "loss packet detection delay" can be defined for the corresponding node of NR-U to indicate how long the node should wait after detecting a loss packet (from the NR-U inter-SN gap) before declaring the packet loss. This parameter can be used regardless of whether reordering is enabled at the DU.

[0106] Thus, there is provided a method of transmitting data from a DU to a UE in an integrated access and backhaul network, wherein the DU is configured with a loss packet detection delay, and wherein the DU only declares a protocol data unit of a packet data convergence protocol lost after a loss packet detection delay has elapsed after detecting a loss packet.

[0107] The loss packet detection delay can be related to the PDCP reordering timer configured in the UE to which the protocol data unit of the packet data convergence protocol is to be sent. For example, there is no benefit for the loss packet timer to be larger than the reordering timer of the UE, as any data packet arriving at the corresponding node after the UE reordering time will be discarded upon arrival at the UE. Similarly, if the loss packet timer is smaller than the reordering timer, the PDCP sender window of the CU will move faster than the PDCP receiver window of the UE. This increases the risk of the transmitted data packet falling outside the UE receiver window, or in the extreme case, arriving within the window but causing HFN de-synchronization with the wrong HFN. The loss packet detection delay timer value can thus be the same as the PDCP reordering timer value at the UE to which the PDU is sent. In one example, the value is signaled to the DU of the relevant DRB over F1-C (F1 control plane interface). That is, the DU can be configured with a "UE PDCP reordering timer" for detecting loss packets at the DU through F1-AP signaling. The reordering timer of the UE can also be set to a relatively high value to allow data packets from 2 different links (i.e. 2 DUs) to arrive. By contrast, each DU only has one link to the CU, and thus can be configured with a small delay value. It can be seen that it is advantageous to be able to configure the "loss packet detection delay" to a value different from the value of the "UE PDCP reordering timer", as a shorter delay will enable faster flow control feedback and loss packet feedback. Thus, F1-AP can be defined to enable the "loss packet detection delay" configuration in the DU on a DRB basis (message UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST).

[0108] If the protocol data unit reordering of the protocol in the packet data concentration in the DU is enabled, different values can be defined for the "data packet forwarding wait delay" and the "missing data packet detection delay". In particular, the forwarding wait delay can be smaller than the missing packet detection delay. In one example, the packet forwarding wait delay can be 20 ms and the missing packet detection delay can be 50 ms. Alternatively, the same value can be used for both parameters. The values can be provided on a UE basis or on a DU basis instead of on a UE-DRB basis in order to reduce the configuration signaling overhead.

[0109] Other techniques can also be used to enable integrated access and backhaul access DUs to operate with NR-U inter-slot gaps. As an initial step, signaling can be needed to indicate to the DU that it is an integrated access and backhaul access DU so that it can apply the configuration to be used with wireless backhaul (otherwise the DU can not know that it is not in a traditional Fl protocol). The necessary indication can be provided to the DU in case the Fl-C is first set up. Other information such as wireless hop count, HARQ RTT, ARQ RTT, and queuing delay can be provided to the DU on a per DRB, UE, or DU basis. From this information, the DU can derive the time to wait for missing data packets.

[0110] When a data packet is declared missing, the parameter highest successfully delivered NR PDCP SN should be updated.

[0111] For example, the CU can send data packets to DU 1:

[0112] u0 = 0, ui = 1, u2 = 2, u3 = 3, u4 = 7, u5 = 8, u6 = 10, u7 = 11 (some PDCP data packets are sent through different DUs).

[0113] DU 1 receives data packets:

[0114] ui = 1, u0 = 0, u2 = 2, u3 = 3, u5 = 8, u7 = 11, u6 = 10... u4 = 7,

[0115] In this example, it is assumed that the data packets are successfully forwarded to the UE (UE acknowledges the reception).

[0116] Data packet u4 = 7 is delayed and arrives after the missing data packet detection delay, which is measured from the time we received the data packet (indicating that U4 data packet is missing).

[0117] The "Highest successfully delivered NR PDCP SN" is set to 3 before the packet u4=7 is declared missing. At the time the packet u4=7 is declared missing (loss packet detection delay after u4 is identified as missing), the "Highest NR PDCP SN" should be updated, in this example set to 11. Although u4=7 does eventually arrive, at the expiration of the loss packet detection delay, the packet is assumed lost. Although u4=7 is not received, the highest successfully delivered NR PDCP SN is set to 11, rather than staying at 3, because u4 has been declared missing. This is necessary because the packet U4 could have actually been lost, and thus not updating the "Highest successfully delivered NR PDCP SN" would cause the transmitter to be out of date.

[0118] If the packet does arrive after being assumed lost (as in the example above), the packet can still be transmitted to the UE, or the packet can be discarded. Transmitting the packet can be preferable in the case where the loss packet detection delay is less than the UE PDCP reordering timer, because in this case the packet will still be handled correctly at the UE. However, this does increase the risk of the packet arriving at the UE outside of its receive window, or even within the receive window, but with the wrong HFN, causing HFN de-synchronization. In one specific example, the DU is configured with a "Lost packet detection delay" and a "UE PDCP reordering timer", and as long as the delay is less than the value of the "UE PDCP reordering timer", the packet is forwarded to the DU.

[0119] Thus, there is provided a method of transmitting data from a DU to a UE in an integrated access and backhaul network, wherein the DU is configured to declare a loss of a protocol data unit of a protocol of a packet data convergence protocol after expiry of a loss packet detection delay, and to transmit any packets declared lost before expiry of a UE PDCP reordering timer, they are subsequently available for transmission.

[0120] Discarding the assumed lost packet can be a safer option, as there is no risk of HFN de-synchronization (assuming the "Lost packet detection delay" is set correctly), but requires a retransmission procedure.

[0121] The "Lost packet detection delay" discussed above can be set by the CU to take into account the delay introduced by the use of HARQ / ARQ / alternative paths. As multi-hop transmission is supported, the highest possible delay can be a large delay. The highest delay should include the possible queuing delay at each intermediate node.

[0122] Selecting a low value for the packet loss detection delay can increase the number of packets that are assumed lost but subsequently arrive, increasing the unnecessary retransmissions of resources consumed. The node hosting the PDCP (CU in integrated access and backhaul systems) cannot distinguish between truly lost packets and falsely lost packets, as the highest PDCP SN that is successfully delivered will be incremented as if the corresponding packet was successfully delivered. If lossless transmission is required, the node hosting the PDCP must retransmit any reported lost packets, as any of them can have truly been lost. Then, as the retransmitted packets use the same protocol, they can also be declared lost, which can trigger retransmission again. By using a lower packet loss detection delay value, the corresponding node will declare and report a large number of lost packets (up to all delayed packets will be reported as late packets), for which the CU must perform retransmission and can have to stop without any guarantee / confirmation that the packets were actually successfully delivered.

[0123] In contrast, using a higher value (as implied by setting the "lost packet detection delay" to the maximum possible delay value) can delay the detection of lost packets, and thus the centralized (PDCP level) retransmission of lost packets, introducing an unwanted delay in the transmission.

[0124] In addition to the lost packet report, the DDDS message can also include a lost / delayed packet report. This report can indicate the SN of the packets that are lost but still waiting (i.e., there is a gap in the SN sequence, and the CU is still waiting for them).

[0125] Therefore, there is provided a method of transmitting a DDDS report from a DU to a CU, wherein the DDDS report includes a lost / delayed packet report, which indicates packets that are delayed but not yet declared lost.

[0126] The lost / delayed packet report can use the NR-U SN, as such SN is uniquely defined for the corresponding NR-U instance and is incremented by 1 for each consecutive packet sent on the corresponding GTP-U tunnel (covering the initial transmission as well as the case of centralized retransmission). The CU can then configure a rather high "lost packet detection delay", covering the HARQ / ARQ / alternative path delay. Using the "lost packet report", the CU can also decide based on the available resources / links, e.g., to trigger retransmission on a different link.

[0127] The Fl-AP can be defined to enable the configuration of the "missing packet report" in the DU on a DRB basis (message UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST). Alternatively, this can conditionally enable the passing of other information to the DU, such as information that it is an integrated access and backhaul node DU, or information that the "missing packet detection delay" is configured.

[0128] The identification of packets with only small delays (which can still be recovered through HARQ or ARQ processes) can be irrelevant to the CU. However, packets with larger delays can be relevant to the CU. Therefore, a missing packet report delay can be configured so that when the DU sends a report, only packets missing for greater than this value are indicated to the CU. This parameter can be sent using Fl-AP signaling.

[0129] Therefore, a method of transmitting a DDDS report from a DU to a CU is provided, where the DDDS report includes a missing / delayed packet report that indicates packets that have a delay greater than a missing packet report delay but have not yet been declared missing.

[0130] The Fl-AP can be defined to enable the configuration of the "missing packet report delay" in the DU on a DRB basis (message UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST).

[0131] To save signaling resources, missing packets can be reported only once, or preferably continue to be included in the report until they are declared missing, or they are successfully received.

[0132] The DU can be configured to send a missing packet report in the DDDS, such as when a missing report has been included, or under other conditions. Alternatively, a separate polling bit or indication can be added to the NR-U data packets sent by the CU to request that a missing packet report be sent in the DDDS.

[0133] The following Table 1 shows an example format for a DDDS report, including the parameters discussed earlier that can be used to transmit information from the DU to the CU.

[0134]

[0135]

[0136] Table 1

[0137] The various methods above can take into account the SN increment, rather than the delay. For example, taking into account the packet loss detection delay, when the received NR-U SN exceeds N + "packet loss detection SN increment", the packet with NR-U SN X can be declared lost. This has the advantage of making implementation easier.

[0138] The various methods described above can be applied individually or in combination with each other.

[0139] Aspects of the disclosure can also be applied in the UL direction.

[0140] Although not shown in detail, any device or apparatus forming part of a network can comprise at least a processor unit, a storage unit and a communication interface, wherein the processor unit, the storage unit and the communication interface are configured to perform the method of any aspect of the application. Further options and choices are described below.

[0141] The signal processing functionality of embodiments of the application, in particular the gNB and the UE, can be implemented using computing systems or architectures known to those of skill in the art in view of the teachings herein. Examples of computing systems, equipment, and architectures can include a desktop, laptop or notebook computer; hand-held computer; tablet computer; notebook computer; netbook computer; cellular telephone; game device; dedicated machine; or virtually any computer implementation device known in the art capable of netting the teachings herein. Computing systems can be implemented using any of a number of well-known computer systems, such as a server computer, a desktop computer, a notebook computer, a laptop computer, a handheld device, or various intermediate forms of these. Computing systems can also include automated and / or virtual machines, servers, clients, or any other type of special- or general-purpose computing devices.

[0142] The computing system can also include a main memory, such as random access memory (RAM) or other dynamic storage devices, for storing information and instructions to be executed by the processor. Such main memory also can be for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system can likewise include a read-only memory (ROM) or other static storage device for storing static information and instructions for the processor.

[0143] The computing system can also include an information storage system, which can include, for example, a media drive and a removable storage interface. The media drive can include a drive or mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disk (CD) or digital video drive (DVD) read or write drive (R or RW), or other removable or fixed media drive. Storage media can include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by the media drive. Storage media can include a computer-readable storage medium, having stored therein particular computer software or data.

[0144] In alternative embodiments, information storage systems can include other similar components for allowing computer programs or other instructions or data to be loaded into a computing system. Such components can include, for example, a removable storage unit and an interface, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to a computing system.

[0145] A computing system can also include a communications interface. This communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interface components can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via the communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface.

[0146] In this document, the terms "computer program product" "computer-readable medium" and the like can be used to generally refer to tangible media such as memory, storage devices, or storage units. These, and other forms of computer-readable media, can store one or more instructions for use by a processor including a computer system to cause the processor to perform a certain operation. Such instructions, generally referred to as "computer program code" (which can be grouped in the form of computer programs or other groupings) when executed, enable a computing system to perform the functions of embodiments of the present application. Note that the code can directly cause a processor to perform specified operations, be compiled to

[0147] A non-transitory computer readable medium can include at least one of a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an EPROM, an electrically erasable programmable read-only memory, and a flash memory, from the group. In embodiments in which elements are implemented using software, the software can be stored in a computer readable medium and loaded into a computing system using, for example, a removable storage drive. The control module (in this example, software instructions or executable computer program code) when executed by a processor in a computer system, causes the processor to perform the functions of the present application as described herein.

[0148] Furthermore, the inventive concept can be applied to any circuitry for performing signal processing functions within a network element. It is further envisaged that, for example, a semiconductor manufacturer can employ the inventive concept in the design of standalone devices such as microcontrollers, for example, digital signal processors (DSPs) or application specific integrated circuits (ASICs), and / or any other sub-system elements.

[0149] It will be appreciated that, for clarity, the above description has described embodiments of the application with reference to a single processing logic. However, the inventive concept can equally be implemented by means of a plurality of distinct functional units and processors to provide the signal processing functionality. Accordingly, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

[0150] Aspects of the application can be implemented in any suitable form including hardware, software, firmware or any combination of these. The application can optionally be implemented at least partly as computer software running on one or more data processors and / or digital signal processors or configurable module components such as FPGA devices.

[0151] Accordingly, elements and components of embodiments of the application can be physically, functionally and logically implemented in any suitable way. Indeed, the functionality can be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the application should not be limited to the specific embodiments described herein, but should be given the widest scope consistent with the principles and features described herein. Further, the described embodiments are to be considered in a descriptive sense only and not for purposes of limitation. The scope of the application is limited only by the claims.

[0152] Furthermore, although individually listed, a plurality of means, elements or method steps can be implemented by, e.g., a single unit or processor. Additionally, although individual features can be included in different claims, these can advantageously be combined, and the inclusion of such features in different claims does not imply that a combination of features is not feasible and / or advantageous. Also, the inclusion of a feature in one category of claims does not imply that the feature cannot be used in other categories of claims. Further, no language in the specification should be construed as indicating any non-claimed element as essential.

[0153] Furthermore, no element, component or method step in the present disclosure is intended to be dedicated to the public, regardless of whether the element, component or method step is explicitly recited in the claims. Furthermore, the order in which the features are presented in the claims is intended to be a logical order for implementing the features in a system or apparatus having the recited features, and not an order in which the features must be implemented in the claims. The claims have one or more embodiments thereof, and are entitled to benefit from each and every claim forming a part of the application.

[0154] Finally, it should be noted that the above examples are only used to illustrate the technical solutions of the present application, and are not intended to limit the same; although the present application has been described in detail with reference to the foregoing examples, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing examples, or make equivalent substitutions for some or all of the technical features thereof; and such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

[0155] The above only describes some embodiments of the present application, not all embodiments, and any equivalent changes made by those of ordinary skill in the art to the technical solutions of the present application by reading the present application are covered by the claims of the present application.

Claims

1. A method for transmitting data from a central unit to a user equipment via distributed units in an integrated access and backhaul network, characterized in that, The method comprises: receiving, at the distributed unit, an Fl application procedure protocol configuration message indicating that the distributed unit is to activate or deactivate protocol data unit reordering of the packet data concentration protocol in the distributed unit on a data radio bearer basis, receiving, at the distributed unit, protocol data units of the packet data concentration protocol for transmission to the user equipment, and if the configuration message indicates that protocol data unit reordering of the packet data concentration protocol is activated for the relevant data radio bearer, reordering the received protocol data units of the packet data concentration protocol before transmitting them to the user equipment. 2.The method for transmitting data from a central unit to a user equipment through a distributed unit in an integrated access and backhaul network according to claim 1, wherein, Further comprising the steps of: when a protocol data unit of the packet data concentration protocol is identified as missing, sending to the user equipment only a packet data concentration protocol header packet, wherein the SN length of the packet data concentration protocol of the only header packet corresponds to the SN length of the packet data concentration protocol of the missing protocol data unit of the packet data concentration protocol. 3.The method for transmitting data from a central unit to a user equipment through a distributed unit in an integrated access and backhaul network according to claim 1, wherein: The reordering is performed based on the SN or NR-USN of the packet data concentration protocol. 4.The method for transmitting data from a central unit to a user equipment through a distributed unit in an integrated access and backhaul network according to claim 1, wherein: if the configuration message indicates that protocol data unit reordering of the packet data concentration protocol is deactivated for the relevant data radio bearer, forwarding the received protocol data units of the packet data concentration protocol without reordering. 5.The method for transmitting data from a central unit to a user equipment through a distributed unit in an integrated access and backhaul network according to claim 1, wherein: if the configuration message indicates that protocol data unit reordering of the packet data concentration protocol is activated, the distributed unit identifies and waits for missing packets based on the NR-U SN before sending to the user equipment the buffered protocol data units of the packet data concentration protocol with higher SN of the packet data concentration protocol. 6.The method for transmitting data from a central unit to a user equipment through a distributed unit in an integrated access and backhaul network according to claim 1, wherein: after detecting a protocol data unit SN gap of the packet data concentration protocol created by a missing packet before forwarding the subsequently buffered protocol data units of the packet data concentration protocol to the user equipment, the distributed unit waits for a predetermined packet forwarding waiting delay.

Images