Technical Field

[1] The following disclosure relates to user plane transmission for integrated access and backhaul (IAB) deployments in cellular networks.

Background

[2] Wireless communication systems, such as the third-generation (3G) of mobile telephone standards and technology are well known. Such 3G standards and technology have been developed by the Third Generation Partnership Project (3GPP). The 3rd generation of wireless communications has generally been developed to support macro-cell mobile phone communications. Communication systems and networks have developed towards a broadband and mobile system.

[3] In cellular wireless communication systems User Equipment (UE) is connected by a wireless link to a Radio Access Network (RAN). The RAN comprises a set of base stations which provide wireless links to the UEs located in cells covered by the base station, and an interface to a Core Network (CN) which provides overall network control. As will be appreciated the RAN and CN each conduct respective functions in relation to the overall network. For convenience the term cellular network will be used to refer to the combined RAN & CN, and it will be understood that the term is used to refer to the respective system for performing the disclosed function.

[4] The 3rd Generation Partnership Project has developed the so-called Long Term Evolution (LTE) system, namely, an Evolved Universal Mobile Telecommunication System Territorial Radio Access Network, (E-UTRAN), for a mobile access network where one or more macro-cells are supported by a base station known as an eNodeB or eNB (evolved NodeB). More recently, LTE is evolving further towards the so-called 5G or NR (new radio) systems where one or more cells are supported by a base station known as a gNB. NR is proposed to utilise an Orthogonal Frequency Division Multiplexed (OFDM) physical transmission format.

[5] Integrated Access and Backhaul (IAB) is a system which provides integrated backhauling of user traffic over an NR radio interface. An IAB node (access IAB node or intermediate IAB node) consists of a Mobile Termination (MT) part and a Distributed Unit (DU) part. The MT part terminates the radio interface layers of the backhaul Uu interface toward the IAB-donor or other IAB-nodes. The IAB-node connects to an upstream IAB-node or an IAB-donor-DU via the MT part. The DU terminates the F1* interface (F1 interface over NR backhaul) connected with the gNB-CU, and provides wireless backhaul to the downstream IAB-nodes and UEs.

[6] Figures 1 & 2 show aspects of the IAB architecture.

[7] Figure 3 shows the IAB user plane protocol stack (in the case of connection to 5GC). For the purposes of the following disclosure, the data path within the NG-RAN, i.e. the PDCP connection between the CU and UE is relevant. This remains applicable for using EPC instead of 5GC (in which case SDAP is not applicable, and NG interface is replaced by S1-U). The PDCP layer offers the radio bearer service to upper layers. In the context of user plane, i.e. transport of user plane data, PDCP offers data radio bearer service. A data radio bearer transports PDCP SDUs (embedded in PDCP PDUs) between the transmitting and receiving PDCP entities.

[8] The F1-U interface is defined in TS 38.474, and relies on a GTP-U tunnel to transport PDCP PDUs.

[9] The disclosure below relates to various improvements to IAB networks.

Summary [10] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[11] There is provided a method of transmitting data from a central unit to a UE in an IAB network via a distributed unit, the method comprising receiving an F1-AP configuration message at a distributed unit (DU), wherein the configuration message indicates to the DU to activate or deactivate PDCP PDU reordering in the DU on a DRB basis, receiving PDCP PDUs at the DU for transmission to a UE, and if the configuration message indicated to activate PDCP PDU reordering for the relevant DRB applying PDCP PDU reordering to the received PDCP PDUs at the DU to the received PDCP PDUs prior to transmission to the UE.

[12] The configuration message may be an F1-AP message.

[13] The method may further comprise the step of transmitting a PDCP header only packet to the UE when a PDCP PDU is identified to be missing, wherein the PDCP SN of the header only packet corresponds to the missing PDCP PDU’s PDCP SN.

[14] The reordering may be performed based on PDCP SNs or NR-U SNs.

[15] If the configuration message indicated to deactivate PDCP PDU reordering for the relevant DRB the DU forwards the received PDCP PDUs without reordering.

[16] If the configuration message indicated to activate PDCP PDU reordering, the DU identifies and waits for missing packets based on NR-U SN before sending buffered PDCP PDUs with higher PDCP SNs to the UE.

[17] The DU may wait for a predetermined packet forwarding waiting delay after detecting a PDCP PDU SN gap created by a missing packet before forwarding subsequent buffered PDCP PDUs to the UE.

[18] There is also provided a method of transmitting data from a central unit to a UE via a distributed unit in an IAB network, the method comprising configuring a distributed unit (DU) with a lost packet detection delay, and the DU declaring a missing PDCP PDU as lost after expiration of the lost packet detection delay after detection of the missing PDCP PDU.

[19] The lost packet detection delay may be defined on a DRB or UE basis.

[20] The lost packet detection delay may be signalled to the DU via F1-C.

[21] The lost packet detection delay may be equal to a packet forwarding waiting delay defined at the DU for the relevant DRB or UE.

[22] The lost packet delay may be larger than a packet forwarding waiting delay defined at the DU for the relevant DRB or UE.

[23] If a PDCP PDU declared as lost is received by the DU prior to expiry of a PDCP reordering time transmitting the PDCP PDU to the UE.

[24] The method may further comprise transmitting a report from the DU to the relevant CU of the IAB network indicating lost PDCP PDUs.

[25] The method may further comprise transmitting a report from the DU to the relevant CU of the IAB network indicating missing PDCP PDUs.

[26] The report may be a Downlink Data Delivery Status Report.

[27] There is also provided a method of transmitting data from a central unit to a UE via a distributed unit in an IAB network, the method comprising transmitting a DDDS report from a Distributed Unit (DU) to a Central Unit (CU), wherein the DDDS report includes a missing/late packet report which indicates packets which are missing and/or late but not yet declared lost.

[28] The missing packet report transmission may be enabled at the DU by F1-AP signalling on a DRB basis.

[29] A missing packet report delay may be configured at the DU using F1-AP signalling on a DRB basis, such that when a Missing packet report is sent, only packets missing for a time greater than this value are indicated to the CU.

Brief description of the drawings

[30] Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. Like reference numerals have been included in the respective drawings to ease understanding.

[31] Figures 1 and 2 shows aspects of the IAB architecture;

[32] Figure 3 shows the IAB user plane protocol stack; and

[33] Figure 4 shows selected elements of a cellular network.

Detailed description of the preferred embodiments

[34] Those skilled in the art will recognise and appreciate that the specifics of the examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.

[35] Figure 4 shows a schematic diagram of three base stations (for example, eNB or gNBs depending on the particular cellular standard and terminology) forming a cellular network. Typically, each of the base stations will be deployed by one cellular network operator to provide geographic coverage for UEs in the 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 via the X2 interface and are connected to a core network via the S1 interface. As will be appreciated only basic details are shown for the purposes of exemplifying the key features of a cellular network. The interface and component names mentioned in relation to Figure 4 are used for example only and different systems, operating to the same principles, may use different nomenclature.

[36] The base stations each comprise hardware and software to implement the RAN’s functionality, including communications with the core network and other base stations, carriage of control and data signals between the core network and UEs, and maintaining wireless communications with UEs associated with each base station. The core network comprises hardware and software to implement the network functionality, such as overall network management and control, and routing of calls and data.

[37] The NR user plane protocol is specified in TS 38.425. It is located in the User Plane of the Radio Network layer over either the Xn or the X2 or the F1 interface, within the "NR RAN Container" GTP-U extension header. It is used to convey control information related to the user data flow management of data radio bearers. Each NR user plane protocol instance is associated to one data radio bearer only. There is one NR user plane instance per GTP tunnel. When a GTP tunnel is set up, a new NR user plane instance is set up. The NR UP protocol will often be referred to as NR-U.

[38] It allows flow control of user data packets transferred from the node hosting NR PDCP to the corresponding node (the corresponding node means the node that does not host the NR PDCP entity). In the context of IAB, F1-U is used between donor CU (node hosting NR-PDCP) and access DU (corresponding node).

[39] As indicated above, F1-U relies on a GTP tunnel to transport PDCP PDUs. More exactly, GTP-U protocol is used, i.e. GTP-U PDUs are conveyed, embedding the PDCP PDU. The NR UP protocol information is added to this PDU. It will be often referred to as a “NR-U packet”. For an initial transmission the node hosting the NR PDCP entity assigns consecutive NR-U sequence numbers to each transferred NR-U packet. The corresponding node detects whether an NR-U packet was lost and records the respective sequence number after it has declared the respective NR-U packet as being "lost".

[40] The corresponding node transfers the remaining NR PDCP PDUs towards the UE and records the highest NR PDCP PDU sequence number of the NR PDCP PDU that was successfully delivered (as defined in TS 36.322 and TS 38.322) in sequence towards the UE (in case RLC AM is used) and the highest NR PDCP PDU sequence number of the NR PDCP PDU that was transmitted to the lower layers. Each node may not receive all PDCP packets since the data radio bearer (DRB), can be split over several legs (whereby the transport of PDCP PDUs of the same DRB can use different legs).

[41] In an example, the CU sends PDCP PDUs to a DU1 with PDCP SN u _n ., where n=0, 1, 2,

... represents the corresponding NR-U SN related to F1-U between CU and DU1. The CU may send also PDCP PDUs to a DU2 with PDCP SN v _n ., where n=0, 1, 2, ... represents the corresponding NR-U SN related to F1-U between CU and DU2.

[42] The CU may use a split bearer and send alternate packets to each link:- uo=0, ui=2, U ₂ =4, U ₃ =6, etc vo=1 , V ₂ =3, V ₂ =5, V ₃ =7, etc

[43] However, there is no restriction on CU scheduling, and in another example the CU may duplicate PDUs on both links:- uo=0, ui=1 , U ₂ =2, U ₃ =3, etc vo=0, v ₂ =1, V ₂ =2, V ₃ =3, etc

[44] Thus, for a given F1-U interface to a DU, the packets are sent by the CU in in-sequence increasing order of NR-U SNs (no NR-U SN gaps), and in increasing order of corresponding PDCP SNs (but those SNs may have already gaps, as shown in the example of the split bearer).

[45] For retransmissions the node hosting the NR PDCP entity indicates to the corresponding node whether this NR-U packet is a retransmission of NR PDCP PDU. A retransmitted NR PDCP PDU is be assigned a new NR-U sequence number.

[46] In an example, the CU sends packets to DU1 and DU2 uo=0, ui=2, U ₂ =4, U ₃ =6, etc vo=1 , V ₂ =3, V ₂ =5, V ₃ =7, etc

[47] However, if DU1 has a temporary outage and packets with PDCP SN 4 and 6 could not be sent to the destination UE. The CU can retransmit those packets to DU2.

V ₄ =4, V ₅ =6 etc

[48] Even when using only one link to one DU, the CU may retransmit PDCP packets if it has knowledge that some packets were missing:

• uo=0, ui=1 , U ₂ =2, U ₃ =3, ui notified as missing

U ₄ =1 (PDCP SN 1 retransmitted)

[49] The retransmitted PDCP packets need to be explicitly tagged as retransmissions because the ordering of their PDCP SN does not follow the same flow as the one corresponding to the initial transmissions, and hence require a specific processing.

[50] The node hosting the NR PDCP entity can indicate to the corresponding node to either discard all NR PDCP PDUs up to and including a defined DL discard NR PDCP PDU SN or discard one or a number of blocks of downlink NR PDCP PDUs.

[51] The Downlink Data Delivery Status (DDDS) procedure provides feedback from the corresponding 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 via the corresponding node for the respective data radio bearer, 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 corresponding node. The DDDS is defined in TS 38.425.

[52] The NR user plane protocol along with DDDS is used to guarantee lossless transmission by having the CU perform necessary retransmissions (TS 38.401 , 8.3).

[53] As explained above, one of the main goals for NR-U is to address flow control in DL between the CU and the DU. This means, to control how much data should be sent in DL from the CU to the DU to not cause congestion while still avoiding any starvation, in order to optimize the final throughput.

[54] IAB is intended to leverage mmWave spectrum, which is less reliable and subject to temporary blockage. This is anticipated to be mitigated by utilising route redundancy. Different paths can be used between the CU and the UE depending on RF conditions. Those paths may be configured/used simultaneously (this assumes multi-connectivity from UE and/or IAB nodes), and/or switched.

[55] Assuming path 1 , which is being utilised, becomes unreliable, the CU may decide to use path 2 instead. In case of AM bearer, it is expected that lossless transmission is ensured. In Rel- 15, a centralized (fast) retransmission feature was defined to allow the CU to retransmit PDCP PDUs from one leg to a different leg, based on DDDS feedback.

[56] The NR-U protocol specifies that the corresponding node should detect whether an NR-U packet was lost, but the implementation of this function is undefined.

[57] In a non-IAB scenario, the interface (X2/Xn/F1) conveying NR-U is wired, generally using an IP backbone. Packet loss or out-of-delivery on such wireline interface is expected to be an extremely rare event. In an unusual case where a packet is delivered out-of-order, it is also expected that the added delay will be short. Hence, an appropriate implementation could be that as soon a NR-U sequence number gap is noticed, the missing NR-U packets are declared lost. Another implementation could delay the packet lost declaration by a very short timeframe, e.g. 1ms.

[58] In an example with only one DU, we may have following packets sent from the CU to the DU: uo=0, ui=1 , U ₂ =2, U ₃ =3, etc

[59] At the DU, packets are expected to arrive in order and without loss: uo=0, ui=1 , U ₂ =2, U ₃ =3, etc [60] In rare exceptional cases, out-of-order can happen: uo=0, U ₂ =2, UI=1 , U ₃ =3, etc

[61] In rare exceptional cases, packet loss can happen: uo=0, U ₂ =2, U ₃ =3, etc (ui=1 never received)

[62] Those cases are assumed very rare and exceptional as F1-U as transport layer is wired in a non-IAB scenario. In above cases, it is expected that the DU will wait for packet ui for a very short time, since it is not expected to be delayed by a wired interface. This could be e.g. 1ms.

[63] In contrast, in IAB scenarios, NR-U is conveyed on an air interface. Packet out-of-order delivery is expected to be likely (due to HARQ and/or ARQ, as well as using different paths). Packet losses are also expected to be common in UM. In AM, packet losses are expected mainly in case of radio link outage (or temporary blockage), requesting the use of an alternative path. A legacy implementation for an AM bearer providing lossless delivery, reacting instantly to NR-U SN gaps, would have the following behaviour.

[64] Packets corresponding to NR-U gaps are not waited for and are declared lost (even though they may be just delayed and arrive later through HARQ/ARQ/alternative IAB path). The HARQ delay may be limited to a few ms, depending on the PHY layer configuration (HARQ RTT and maximum number of repetitions). The ARQ delay can be much more significant. Typical RLC RTT are indicated in Table 4.1.4-1 of TS 38.306. The RTTs in TS 38.306 are only indicative, and may be larger depending of the configuration. These delays may scale up with the number of hops. The delay introduced by using an alternative IAB path is likely to be even more important.

[65] Lost packets are reported to CU in DDDS and will be retransmitted by CU in a new NR-U packet. The node hosting PDCP has to retransmit any reported lost packets, because any of them could have been really lost. The retransmission can take place on the same GTP-U tunnel or an alternative one (if available). In case of IAB, the retransmission may take place on an alternative path (same or different tunnel). As retransmitted packets use the same protocol, they may be declared lost as well (as soon as one is delayed), which might again trigger retransmission.

[66] The Highest successfully delivered NR PDCP Sequence Number represents “highest NR PDCP PDU sequence number successfully delivered in sequence to the UE among those NR PDCP PDUs received from the node hosting the NR PDCP entity”. This parameter is key for the CU knowledge of which PDCP PDUs eventually made it successfully to the UE. How this is related to packet loss is not detailed in the current standards, but it is anticipated that once a packet is declared lost, then the highest delivered NR PDCP SN may move forward (since a missing packet is no longer waited for). The highest delivered NR PDCP SN is initially meant for flow control to prevent more than half of the PDCP SN space to be sent (in order to avoid HFN desynchronization issues). Hence, this can be an issue since those lost packets may still be delivered later.

[67] In an example, considering only one DU, we may have following packets sent from the CU to the DU: uo=0, ui=1 , U ₂ =2, U ₃ =3, etc

[68] A legacy DU implementation would expect packets to arrive in order and without loss: uo, ui, u ₂ , u ₃ , u ₄ , u ₅ , u ₆ , U7,

[69] However, due to HARQ retransmissions, packets may arrive as follows: uo, ui, u ₄ , u ₅ , u ₂ , u ₃ , u ₆ , U7, [70] For example, packets U ₂ , U ₃ are delayed because they were in a transport block which underwent an HARQ retransmission. If HARQ retransmission of that TB fails, ARQ retransmission will be triggered (at RLC level). This will delay even more packets, such that the DU may receive: uo, ui, u ₄ , u ₅ , u ₆ , u _7, u ₈ , Uio, u ₉ ,... , ui _76, u ₂ , u ₃ , ...

[71] The legacy implementation may declare the packets u ₂ and u ₃ as lost before they are received, which has 2 main impacts:

[72] Firstly, in DDDS, u ₂ , u ₃ ,are reported as lost, and will be retransmitted by the CU. Generally, due to HARQ/ARQ and also multi-hops, it is expected that a large subset of the packets are delayed (at least 10% which is the normal HARQ BLER operating point for one link), and this would scale with multi-hop transmissions. All those packets would be declared as lost and retransmitted by the CU, which is not desirable.

[73] Secondly, the “Highest successfully delivered NR PDCP SN” DELI V_SN would be set to the highest successfully delivered NR PDCP SN at the time the DDDS is sent, ignoring the missing u ₂ and u ₃ which are no longer expected. This allows the CU to transmit up to DELIV_SN + half PDCP SN space. However, the UE is still waiting for u ₂ , u ₃ during the configured reordering timer. The PDCP receiving window at the UE side is not moving while the PDCP transmitting window at the CU side is moving, whereas the transmitter PDCP window should only be allowed to move based on the moving the PDCP receiving window. This can lead to packets being received by the UE out of the PDCP receive window (ignored) or within the PDCP receive window, but very late (PDCP SN rollover) causing HFN desynchronization issue (all packets will be wrongly deciphered from that point).

[74] Considering some typical figures, a datarate of 10Gbps (common for NR), and SDU size of 1500 bytes, leads to 833 packets per ms. By using the maximum PDCP SN length of 18bits, half of the PDCP SN space is 131072 which is reached in only 157ms. This shows that above scenario may easily happen.

[75] Set out below are techniques intended to improve flow control in relation to wireless backhaul systems, in particular IAB.

[76] In an IAB system, it is anticipated that PDCP PDUs will frequently arrive out-of-order at the corresponding node (IAB access node) due to HARQ, ARQ, or alternative paths for the NR backhaul. There may be advantages to reordering the PDCP PDUs before they are transmitted to the UE.

[77] In a first example, PDCP PDUs may be reordered before forwarding to the UE, which may assist with compliance with the requirement to include “the highest NR PDCP PDU sequence number successfully delivered in sequence" in a DDDS report. Reordering means that the highest NR PDCP PDU SN successfully delivered in sequence can be derived in a straightforward manner from the cumulative RLC ACK SN received from lower layers as the highest NR PDCP PDU SN will correspond to the RLC PDU with RLC ACK SN. Reordering may also reduce the UE buffering requirements as a larger number of PDUs will be received at the UE in order, and most buffering will be performed in the DU during the reordering process.

[78] However, reordering at the corresponding node does increase complexity of the DU, and it will introduce latency at the DU. If a packet is lost (for example, on the interface between CU and DU at the donor), it will be waited for twice - firstly at the DU, and then at the UE. Such a delay could be alleviated by creating and sending a dummy “PDCP header only” packet to avoid a PDCP SN gap at the UE, but this would require additional complexity and may require amendment of standards. [79] The reordering may be based on PDCP SNs or NR-U SNs. The result will be the same for initial transmissions, but different for retransmissions.

[80] There is therefore provided a method of transmitting data from a DU to a UE in an IAB network, in which the DU reorders PDCP PDUs prior to transmitting those PDUs to the UE.

[81] In a second example, PDCP PDUs may not be reordered at the corresponding node. In such a configuration PDCP is applied end-to-end between the UE and the CU, with reordering only being performed at the UE or CU, with the elements along the path simply forwarding received PDUs with minimal queuing and processing. This has an advantage of reducing latency and if a packet is lost only the UE will wait (before forwarding later PDUs to the application layer). The lack of reordering also simplifies the configuration of the corresponding node.

[82] There is therefore provided a method of transmitting data from a DU to a UE in an IAB network, in which the DU does not reorder PDCP PDUs prior to transmitting those PDUs to the UE.

[83] A potential drawback of not reordering at the DU is that the buffer size at the UE may be increased, and derivation of the highest NR PDCP PDU sequence number successfully delivered in sequence at the DU may be more complex. The DU can still keep track of which PDCP PDU are successfully delivered or not (as there is a one to one mapping between RLC PDUs and PDCP PDUs), and still provide the same feedback to the CU.

[84] Reordering or not reordering at the corresponding node may be preferred for different use cases or services. It is therefore preferable to be able to activate or deactivate reordering before forwarding to the UE at the corresponding node. In an example, F1-AP is able to configure reordering in the DU on a DRB basis (messages UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST).

[85] There is therefore provided a method of transmitting a message using F1-AP to a DU to activate, or de-activate, PDCP PDU reordering in the DU while transmitting PDCP PDUs to a UE.

[86] When PDCP PDU reordering at the corresponding node is configured, the DU has to wait for missing NR-U packets (having created PDCP SN gaps) before sending buffered PDCP PDUs (with higher PDCP SNs) to the UE. The DU does not consider gaps in the PDCP SN sequence, since this is a common scenario whenever a split bearer is used. The NR-U SN is only used to identify missing packets. A “Packet forwarding waiting delay” may be introduced to indicate how much maximum time the node should wait after noticing a PDCP PDU SN gap created by a missing packet (NR-U SN gap) before forwarding the subsequent buffered PDCP PDUs to the UE.

[87] There is therefore provided a method of transmitting data from a DU to a UE in an IAB network, in which the DU is configured with a packet forwarding waiting delay and wherein, when detecting a PDCP PDU SN gap due to a missing PDU, the DU waits for at least the packet forwarding waiting delay before transmitting subsequent PDCP PDUs to the UE.

[88] In contrast to wired backhaul, packet loss may be relatively common in wireless backhaul, and accordingly a stronger process for handling such loss may be desirable to ensure consistent handling. A parameter, “lost packet detection delay” may be defined for the NR-U corresponding node to indicate how long the node should wait after detecting a missing packet (from NR-U SN gap) before the packet is declared as lost. This parameter may be utilised both whether reordering is or is not enabled at the DU.

[89] There is therefore provided a method of transmitting data from a DU to a UE in an IAB network, in which the DU is configured with a lost packet detection delay and wherein the DU declares a missing PDCP PDU lost only after the lost packet detection delay has elapsed following detection of the missing packet.

[90] The lost packet detection delay may be related to a configured PDCP reordering timer in the UE to which the PDCP PDUs will be transmitted. For example, there is no benefit in the lost packet timer being larger than the UE’s reordering timer since any packets arriving at the corresponding node after the UE’s reordering time will be discarded when they reach the UE. Similarly, if the lost packet timer is smaller than the reordering timer the CU’s PDCP transmitter window will move faster than the PDCP receiver window at the UE. This increases the risk of transmitted packets falling outside of the UE’s receiver window, or in extreme cases arriving within the window but with the wrong HFN leading to HFN desynchronization. The lost packet detection delay timer value may thus be same as the PDCP reordering timer value at the UE to which the PDUs are being transmitted. In an example, the value is signalled to the DU for the relevant DRB via F1-C. That is to say, the “UE PDCP reordering timer” may be configured to the DU, to be used for the detection of lost packets at the DU, via F1-AP signalling. The UE’s reordering timer may also be set to a relatively high value to allow for packets arriving from 2 different links (i.e. 2 DUs). In contrast, each DU has only one link towards the CU and hence may be configured with a small delay value. As it can be seen, there is an advantage to be able to configure a “Lost packet detection delay” with a value different from the one of the “UE PDCP reordering timer”, as a shorter delay will enable faster flow control feedback and lost packet feedback. F1-AP may therefore be defined to enable configuration of the “Lost packet detection delay” in a DU on a DRB basis (messages UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST).

[91] If PDCP PDU reordering in the DU is enabled, different values may be defined for the “Packet forwarding waiting delay” and “Lost packet detection delay”. In particular, the forwarding waiting delay may be smaller than the lost packet detection delay. In an example, the packet forwarding waiting delay may be 20 ms, and the lost packet detection delay may be 50 ms. Alternatively, the same value may be used for the two parameters. The values may be provided on a UE basis or on a DU basis, instead of a UE-DRB basis, in order to lower the configuration signalling overhead.

[92] Other techniques may also be utilised to enable an IAB access DU to operate with NR-U SN gaps. As an initial step, signalling may be required to indicate to a DU that it is an IAB access DU such that it can apply a configuration to use with wireless backhaul (otherwise the DU may not be aware it is not operating with a wired backhaul on a conventional F1 protocol). The necessary indication may be provided to the DU with the F1-C is first set up. Other information such as the number of wireless hops, HARQ RTT, ARQ RTT, and queuing delay may be provided to the DU, on a per DRB, UE, or DU basis. From this information, the DU can derive how much to wait for missing packets.

[93] When a packet is declared lost, the parameter Highest successfully delivered NR PDCP SN should be updated.

[94] For example, a CU may send packets to DU 1 uo=0, ui=1 , U2=2, U3=3, U4=7, US=8, U ₆ =10, U7=11 (some PDCP packets are sent via a different DU)

[95] The DU1 receives packets

Ui = 1, Uo=0, U2=2, U ₃ =3, U5=8, U ₇ =11, U ₆ =10, . U4=7, It this example, it is assumed the packets are successfully forwarded to the UE (reception acknowledged by the UE).

[96] Packet U ₄ =7 is delayed and arrives after the Lost packet detection delay , which was measured from the time packet us was received (indicating that U4 packet was missing).

[97] Before Packet U ₄ =7 is declared lost, “Highest successfully delivered NR PDCP SN ” is set to 3. At the time Packet U ₄ =7 is declared lost ( Lost packet detection delay after U4 is identified as missing), “Highest successfully delivered NR PDCP SN" should be updated and in this example is set to 11. Although U ₄ =7 does eventually arrive, at the expiry of the lost 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 lost. This is required because the packet U4 may be actually really lost, hence not updating “Highest successfully delivered NR PDCP SN” in that case would stale the transmitter.

[98] If packets do arrive after they are assumed lost (as in the above example), the packets may still be transmitted to the UE, or the packets may be discarded. It may be preferable to transmit the packets in the case that the lost packet detection delay is smaller than the UE PDCP reordering timer, since in such a case the packets will still be handled correctly at the UE. However, this does increase the risk of packets arriving at the UE outside of its reception window, or even within the reception window, but with the wrong HFN, leading to HFN desynchronization. In a particular example, both “Lost packet detection delay” and “UE PDCP reordering timer” are configured for the DU, and the packets are forwarded to the DU as long as the delay is lower than the value of the “UE PDCP reordering timer”.

[99] There is therefore provided a method of transmitting data from a DU to a UE in an IAB network, in which the DU is configured to declare PDCP PDUs lost after expiry of a lost packet detection delay and to transmit any packets declared lost if they are subsequently available for transmission before expiry of a UE PDCP reordering timer.

[100] Discarding packets that are assumed lost may be a safer option as there is no risk of HFN desynchronization (assuming the “Lost packet detection delay” is correctly set) but requires a retransmission process.

[101] The “Lost packet detection delay” discussed above can be set by the CU to account for delays introduced by HARQ/ARQ/alternative path usage. Since multi-hop transmissions are supported the highest possible delay may be a large delay. The highest delay should include possible queuing delays at each intermediate node.

[102] Selecting a low value for the lost packet detection delay may increase the number of packets which are assumed lost but subsequently arrive, thus increasing unrequired retransmissions which consume resources. The node hosting the PDCP (CU in the IAB system) cannot discriminate between real lost packets and false lost packets since the highest successfully delivered PDCP SN will be incremented as if the corresponding packets were successfully delivered. In case lossless transmission is desired, the node hosting PDCP has to retransmit any reported lost packets, because any of them could have been really lost. Then, as retransmitted packets use the same protocol, they may be declared lost as well, which might again trigger retransmission. By using a low value for the lost packet detection delay, the corresponding node will declare and report a lot of lost packets (up to all delayed packets would be reported as late packets), for which the CU will have to perform retransmission, and may have to stop without any guarantee/acknowledgment that the packet was actually successfully delivered. [103] In contrast, using a higher value (as implied by setting the “Lost packet detection delay” to the maximum possible delay value) may delay the detection of lost packets and hence the centralized (PDCP level) retransmission of the lost packet, thereby introduced undesired latency into transmission.

[104] The DDDS message may include a missing/late packet report in addition to a lost packet report. This report may indicate the SN of packets which are missing, but which are still being waited for (i.e. there is a gap in the SN sequence and the CU is still waiting for them).

[105] There is therefore provided a method of transmitting a DDDS report from a DU to a CU, wherein the DDDS report includes a missing/late packet report which indicates packets which are late but not yet declared lost.

[106] The missing/late packet report may utilise the NR-U SN, since such SNs are uniquely defined for the corresponding NR-U instance and incremented by 1 for each sequential packet being sent on the corresponding GTP-U tunnel (covering both initial transmission as well as centralized retransmission cases). The CU can then configure a reasonably high “Lost packet detection delay”, covering the HARQ/ARQ/alternative path delays. Using the “Missing packet report” the CU may also decide depending on available resources/links to e.g. trigger retransmission on a different link.

[107] F1-AP may be defined to enable the “Missing packet report” in the DU to be configured on a DRB basis (messages UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST). Alternatively, this could be enabled conditionally to other information conveyed to the DU, such as information that it is an IAB node DU, or information that a “Lost packet detection delay’ was configured.

[108] The identification of packets with only a small delay, which may still be recovered by HARQ or ARQ processes, may not be relevant to the CU. However, packets with a larger delay may be relevant to the CU. A missing packet report delay may thus be configured such that when a report is sent by the DU, only packets missing for greater than this value are indicated to the CU. This parameter may be signalled utilising F1-AP signalling.

[109] There is therefore provided a method of transmitting a DDDS report from a DU to a CU, wherein the DDDS report includes a missing/late packet report which indicates packets which are late by greater than a missing packet report delay, but not yet declared lost.

[110] F1-AP may be defined to enable the “Missing packet report delay” in the DU to be configured on a DRB basis (messages UE CONTEXT SETUP REQUEST / UE CONTEXT MODIFICATION REQUEST).

[111] In order to conserve signalling resources missing packets may be reported only once, or it may be preferred to continue to include missing packets in reports until they are declared lost, or they are successfully received.

[112] The DU may be configured to transmit a missing packet report in the DDDS, for instance when the lost report is already included, or upon other conditions. Alternatively, a separate polling bit or indication can be added to NR-U packets sent by the CU to request sending of the missing packet report in DDDS.

[113] Table 1 below shows an example format for a DDDS report including the parameters discussed hereinbefore which may be utilised for transmission of information from the DU to the CU.

Table 1

[114] Instead of considering delays, the various approaches above may consider SN deltas. For instance, considering lost packet detection delay, a packet with NR-U SN X may be declared lost when a received NR-U SN exceeds N+”lost packet detection SN delta”. This has the advantage of enabling easier implementation.

[115] The various methods described hereinbefore may be applied individually, or in combination with each other.

[116] Aspects of this disclosure may also be applicable in the UL direction. [117] Although not shown in detail any of the devices or apparatus that form part of the network may include at least a processor, a storage unit and a communications interface, wherein the processor unit, storage unit, and communications interface are configured to perform the method of any aspect of the present invention. Further options and choices are described below.

[118] The signal processing functionality of the embodiments of the invention especially the gNB and the UE may be achieved using computing systems or architectures known to those who are skilled in the relevant art. Computing systems such as, a desktop, laptop or notebook computer, hand-held computing device (PDA, cell phone, palmtop, etc.), mainframe, server, client, or any other type of special or general purpose computing device as may be desirable or appropriate for a given application or environment can be used. The computing system can include one or more processors which can be implemented using a general or special-purpose processing engine such as, for example, a microprocessor, microcontroller or other control module.

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

[120] The computing system may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other 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 disc (CD) or digital video drive (DVD) read or write drive (R or RW), or other removable or fixed media drive. Storage media may 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 media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.

[121] In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. Such components may 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 computing system.

[122] The computing system can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via a 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 medium.

[123] In this document, the terms ‘computer program product’, ‘computer-readable medium’ and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the computer system to cause the processor to perform specified operations. Such instructions, generally 45 referred to as ‘computer program code’ (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system to perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.

[124] The non-transitory computer readable medium may comprise at least one from a group consisting 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, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory. In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code), when executed by the processor in the computer system, causes a processor to perform the functions of the invention as described herein.

[125] Furthermore, the inventive concept can be applied to any circuit for performing signal processing functionality within a network element. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a microcontroller of a digital signal processor (DSP), or application-specific integrated circuit (ASIC) and/or any other sub-system element.

[126] It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, 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 organisation.

[127] Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may 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.

[128] Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps.

[129] Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion 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 a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.

[130] Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to ‘a’, ‘an’, ‘first’, ‘second’, etc. do not preclude a plurality.

[131] Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ or “including” does not exclude the presence of other elements.