Patent Description:
In the standardized Rel-<NUM> LWA, uplink data transmissions are done via LTE only. In this LWA context and others, complexities arise in transmitting and retransmitting packets (e.g., PDCP PDUs) when those packets may be transmitted and retransmitted over different types of radio links (e.g., LTE and WLAN). These complexities exist especially in situations (e.g., as in LWA uplink) where scheduling decisions are made at the node which receives those packets rather than at the node which transmits the packets.

Document <CIT> resp. <CIT> relates to an LTE scenario in which data units can be transmitted from a primary base station to a terminal either directly or via a secondary base station. The terminal may, based on a status variable in the receiving window, determine a data unit for which a link needs to be switched to perform transmission, and indicate an according sequence number in a PDCP status report. The primary base station then determines that the data unit is to be sent via the respective other link.

According to one or more embodiments herein, a receiving radio node that schedules its receipt of a packet on one or more of multiple different types of radio links also controls the type of radio link over which that packet is to be retransmitted. Methods and apparatus according to the invention are defined in the appended claims. More particularly, embodiments herein include a method implemented by a transmitting radio node for transmitting packets (e.g., packet data convergence protocol, PDCP, packets) in a wireless communication system according to claim <NUM>. The method comprises transmitting packets to a receiving radio node as scheduled by the receiving radio node over one or more of multiple different types of radio links between which transmission of the packets is configured to be split or switched. The method also comprises receiving from the receiving radio node a retransmission link indication that indicates over which of the multiple different types of radio links packet retransmission is to be performed. The method further comprises performing packet retransmission based on the retransmission link indication. The method further comprises receiving from the receiving radio node a retransmission packet indication that indicates a particular packet to retransmit to the receiving radio node, wherein the retransmission link indication indicates over which of the multiple different types of radio links to retransmit that particular packet.

Embodiments further include a method implemented by a receiving radio node for receiving packets (e.g., packet data convergence protocol, PDCP, packets) in a wireless communication system according to claim <NUM>. The method comprises scheduling packets to be transmitted from a transmitting radio node over one or more of multiple different types of radio links between which transmission of the packets is configured to be split or switched. The method also comprises transmitting to the transmitting radio node a retransmission link indication that indicates over which of the multiple different types of radio links packet retransmission is to be performed. The method further comprises transmitting to the transmitting radio node a retransmission packet indication that indicates a particular packet to retransmit to the receiving radio node, wherein the retransmission link indication indicates over which of the multiple different types of radio links to retransmit that particular packet.

In both above methods, the retransmission link indication and the retransmission packet indication are included in a request message transmitted from the receiving radio node to the transmitting radio node requesting retransmission of the particular packet. Also, in both cases the different types of radio links use different radio access technologies
Embodiments further include corresponding apparatus, computer programs, and computer program products.

<FIG> illustrates a wireless communication system <NUM> according to some embodiments. The system <NUM> includes a transmitting radio node <NUM> that is configured to transmit packets <NUM> to a receiving radio node <NUM>. <FIG> for example shows the transmitting radio node <NUM> as a wireless communication device (e.g., a user equipment) and the receiving radio node <NUM> as a base station (e.g., an eNodeB), such that the packets <NUM> are transmitted in an uplink direction of the system <NUM>. Embodiments herein however are applicable also to downlink and/or sidelink communication.

Regardless, the receiving radio node <NUM> schedules the transmitting radio node's transmission of the packets <NUM> to the receiving radio node <NUM>. The receiving radio node <NUM> may for instance schedule the packets <NUM> to be transmitted by the transmitting radio node <NUM> on certain radio resources, e.g., in time, frequency, code, space, or the like. The receiving radio node <NUM> may then send the transmitting radio node <NUM> a scheduling grant indicating the receiving radio node's scheduling decision.

In any event, the receiving radio node <NUM> notably may schedule the packets <NUM> to be transmitted over one or more of multiple different types of radio links <NUM>, <NUM> between which transmission of the packets <NUM> is configured to be split or switched. As shown, for instance, packets <NUM> may be transmitted over one type of radio link <NUM> (e.g., a wireless wide area network, WWAN, link) to the receiving radio node <NUM> directly. Packets <NUM> may alternatively be switched to being transmitted over, or may additionally be split to being simultaneously transmitted over, a different type of radio link <NUM> (e.g., a wireless local area network, WLAN, link) to an intermediate receiving radio node <NUM>, which in turn transmits the packets <NUM> to the receiving radio node <NUM> over a backhaul link <NUM>. In other (e.g., co-located) embodiments, though, the different types of radio links <NUM>, <NUM> are terminated at the receiving radio node <NUM> itself.

In one or more embodiments, transmission of the packets <NUM> is configured to be split or switched at a radio access network level. Correspondingly, reception of the packets <NUM> is configured to be aggregated or switched at the radio access network level. The receiving radio node <NUM> may for instance receive packets <NUM> whose transmission is split over the different radio links <NUM>, <NUM> and then aggregate those packets <NUM>, e.g., for sending on a single radio bearer towards a core network of the system <NUM>. In this and other embodiments, therefore, the packets <NUM> may be packet data units (PDUs) formed from service data units (SDUs) received at the transmitting radio node <NUM> over a single radio bearer, such that the single radio bearer is configured to be a split or switched bearer.

<FIG> illustrates one example where the packets <NUM> are formed by a sublayer <NUM> of a data link layer <NUM> at the transmitting radio node <NUM>. In this case, the packets <NUM> as shown in <FIG> are split or switched at this sublayer <NUM>. Indeed, as shown, SDUs may be received on a single split bearer <NUM>. Packets <NUM> in the form of PDUs formed from those SDUs are split onto different protocol stacks <NUM>, <NUM> associated with the different types of radio links <NUM>, <NUM>. <FIG> also shows that SDUs may be received on a single switched bearer <NUM>. Packets <NUM> in the form of PDUs formed from those SDUs may be switched onto the protocol stack <NUM> associated with a particular type of radio link <NUM>. This bearer <NUM> however is switchable such that its SDUs may be switched onto the protocol stack <NUM> associated with another type of radio link <NUM>.

In some embodiments, the packets <NUM> are packet data convergence protocol (PDCP) packets. In this case, transmission of these PDCP packets is configured to be split or switched at a PDCP layer between the multiple different types of radio links <NUM>, <NUM>. With reference to <FIG>, then, the sublayer <NUM> may be the PDCP layer.

<FIG> and <FIG> illustrate embodiments where the packets are PDCP packets and the types of radio links <NUM>, <NUM> are LTE and WLAN links. <FIG> illustrates the protocol stacks from the perspective of the eNB. <FIG> shows the envisaged protocol architecture for LTE-WLAN aggregation from the perspective of both the UE and eNB. The WLAN termination (WT) point in the network may be implemented by an WLAN access point (AP) and/or access controller (AC) or a further network node. The interface protocol between eNB and WT is denoted Xw.

Accordingly, the radio links <NUM>, <NUM> may be different types in the sense that the radio links <NUM>, <NUM> use different radio access technologies (RATs). For example, radio link <NUM> may use LTE whereas radio link <NUM> may use WLAN (e.g., WiFi). Alternatively or additionally, the radio links <NUM>, <NUM> may be different types in the sense that the radio links <NUM>, <NUM> are deployed in different types of spectrum (e.g., licensed vs. unlicensed). Alternatively or additionally, the radio links <NUM>, <NUM> may be different types in the sense that the radio links <NUM>, <NUM> have different radio protocol stacks or otherwise employ different radio link processing. In the same or different embodiments, the different types of radio links <NUM>, <NUM> may use different error control protocols for handling erroneous transmission of a packet <NUM>. For example, one type of radio link <NUM> may substantially guarantee error-free delivery of packets <NUM> from the perspective of sublayer <NUM>, absent certain circumstances (e.g., handover) requiring reestablishment of the error control protocol. The other type of radio link <NUM> may by contrast not provide that guarantee under any circumstances, e.g., failure to deliver a packet <NUM> after a certain amount of time or certain number of attempts results in packet loss.

Regardless of the particular types of the radio links <NUM>, <NUM>, though, one or more embodiments herein account for the different nature of the radio links <NUM>, <NUM> by having the receiving radio node <NUM> not only schedule packet transmission over the links <NUM>, <NUM> but also control over which of the radio links <NUM>, <NUM> packet retransmission is to be performed. As shown in <FIG> in this regard, the receiving radio node <NUM> transmits a retransmission link indication <NUM> to the transmitting radio node <NUM>. This indication <NUM> indicates over which of the multiple different types of radio links <NUM>, <NUM> packet retransmission is to be performed. The transmitting radio node <NUM> correspondingly performs packet retransmission based on that indication <NUM>. <FIG> for instance shows that retransmission of a packet 14A may be performed over a particular one of the radio links <NUM>, <NUM> based on the retransmission link indication <NUM>. In this way, the retransmitted packet 14A may be subjected to particular radio link processing <NUM> or <NUM> (e.g., error control processing) for a particular link <NUM> or <NUM>, as controlled by the receiving radio node <NUM> (e.g., based on link quality, load balancing, or the like). The receiving radio node <NUM> in some embodiments thereby decides on which link <NUM> or <NUM> packet retransmission is to occur based on one or more criteria, e.g., as part of balancing (re)transmission efficiency and link load.

Accordingly, in some embodiments, the retransmission link indication <NUM> indicates that packet retransmission is to be performed over a different radio link than the radio link over which original packet transmission is configured to be performed. That is, the retransmission link indication <NUM> effectively switches the radio link over which retransmission is performed. The retransmission link indication <NUM> may for example effectively switch packet retransmission from WLAN to LTE in order to exploit RLC ARQ for realizing lossless PDCP PDU transmission, e.g., unless LTE link quality is below a threshold and/or LTE load is above a threshold.

No matter the particular criteria on which the retransmission link decision is made by the receiving radio node <NUM>, that decision may be made specifically for packet transmissions that are retransmissions (separate and apart from any decision made specifically for packet transmissions that are original transmissions). Alternatively, the decision may be made more generally for any transmissions irrespective of whether they are original packet transmissions or packet retransmissions. Accordingly, in some embodiments, the retransmission link indication may in a sense be a transmission link indication that indicates generally over which of the multiple different types of radio links <NUM>, <NUM> packet transmission and retransmission is to be performed. The transmitting radio node <NUM> in this case may base its determination of over which radio link <NUM>, <NUM> to perform packet transmission on the transmission link indication, irrespective of whether that packet transmission is an original transmission or a retransmission.

The retransmission link indication <NUM> may be conveyed in any number of ways. In some embodiments, for example, the retransmission link indication <NUM> is signaled to the transmitting radio node <NUM> in a semi-static manner such as via radio resource control (RRC) configuration. In these and other embodiments, therefore, the retransmission link indication <NUM> may be included in an RRC message, such as an RRC connection reconfiguration message and/or an RRC command. Alternatively or additionally, the retransmission link indication <NUM> may be signaled to the transmitting radio node <NUM> in a more dynamic manner. The retransmission link indication <NUM> may be included for instance in a PDCP control PDU, e.g., an extended version of a PDCP status report, PDCP LWA status report, or a variant of these. Regardless, in some embodiments, a dynamically signaled retransmission link indication <NUM> (e.g., via a PDCP control PDU) may override or have priority over any retransmission link indication <NUM> semi-statically signaled (e.g., via RRC). In fact, in some embodiments, a dynamically signaled retransmission link indication <NUM> may indicate that a radio link other than the one that is semi-statically configured for original packet transmission is to be used for packet retransmission.

In one or more embodiments, for example, the retransmission link indication <NUM> comprises a flag in a control message, e.g., in a PDCP control PDU. Setting the flag may indicate in some embodiments that the not-RRC-configured radio link is to be used for packet retransmission, i.e., not the radio link used for original packet transmission (also referred to as continuous packet transmission/operation). Alternatively, the flag being set may indicate in other embodiments that packet retransmission is to be performed over a particular one of the radio links (e.g., an LTE link), and the flag not being set may indicate that packet retransmission is to be performed over a different one of the radio links (e.g., a WLAN link). In still other embodiments, instead of the flag indicating the radio link that is to be used for retransmissions specifically, setting the flag may indicate the radio link to be used for both original transmissions and retransmissions is to be changed to another radio link, i.e., the radio link (or radio link direction) to be used is toggled.

No matter the particular way in which the retransmission link indication <NUM> is conveyed, the retransmission link indication <NUM> in some embodiments is retransmission-agnostic in the sense that it controls the link <NUM>, <NUM> over which any retransmission is made. That is, the indication <NUM> governs the link <NUM>, <NUM> over which a retransmission is made no matter the packet being retransmitted and/or no matter which of potentially multiple retransmission attempts is being performed for a given packet. In other embodiments, by contrast, the retransmission link indication <NUM> is retransmission-specific in the sense that it controls the link <NUM>, <NUM> over which a particular retransmission is made. In this case, the indication <NUM> may govern the link <NUM>, <NUM> over which a retransmission is made for a specific packet and/or for a specific one of potentially multiple retransmission attempts performed for a given packet.

In these latter and other embodiments, the receiving radio node <NUM> may transmit to the transmitting radio node <NUM> a retransmission packet indication that indicates a particular packet (e.g., a particular PDCP PDU) to retransmit to the receiving radio node <NUM>. In this case, the retransmission link indication <NUM> may indicate over which of the multiple different types of radio links to retransmit that particular packet. In some embodiments, the retransmission link indication <NUM> and the retransmission packet indication are included in a request message transmitted from the receiving radio node <NUM> to the transmitting radio node <NUM>, e.g., requesting retransmission of the particular packet.

In some embodiments where packets are assigned respective sequence numbers (SNs), the retransmission packet indication may be a first missing sequence (FMS) number which specifies the sequence number of the first missing packet (i.e., the earliest SN among missing packets). Alternatively or additionally, the retransmission packet indication may be included in a bitmap or list which specifies SNs of one or more packets to be retransmitted. In yet other embodiments, the retransmission packet indication may be indicated (indirectly) as a number of missing packets (NMPs) and/or a highest received SN (e.g., a highest received SN over WLAN, HRW).

In other embodiments, by contrast, rather than the receiving radio node <NUM> actually controlling which particular packet to retransmit, the transmitting radio node <NUM> may autonomously decide which packets to retransmit at least under some circumstances. In this case, then, the transmitting radio node <NUM> may perform retransmissions on its own in an unsolicited manner, i.e., without request from the receiving radio node <NUM>. This autonomous decision in some embodiments may be overridden by the receiving radio node <NUM> sending an indication to retransmit a particular packet.

<FIG> illustrates one embodiment for how a transmitting radio node <NUM> autonomously decides which packets to retransmit. As shown, the transmitting radio node <NUM> sends a packet <NUM> (e.g., a PDCP PDU) from a higher layer <NUM> (e.g., PDCP layer) to a lower layer <NUM> (e.g., MAC) of a protocol stack for transmission of the packet <NUM> from the transmitting radio node <NUM> to the receiving radio node <NUM>, as scheduled by the receiving radio node <NUM>. The transmitting radio node <NUM> (e.g., using an intermediate layer or sublayer between the higher and lower layers) monitors an automatic repeat request (ARQ) process <NUM> at the lower layer <NUM>. The transmitting radio node <NUM> performs unsolicited retransmission of the packet <NUM> to the receiving radio node <NUM> based on this monitoring.

As shown in <FIG> for instance, the transmitting radio node <NUM> may retransmit packet 14A if packet <NUM> is not acknowledged at the lower layer <NUM>, even if the receiving radio node <NUM> does not request that the packet be retransmitted. In some embodiments, the transmitting radio node <NUM> does so if the packet <NUM> is not acknowledged within a defined time interval since sending the packet <NUM> from the higher layer <NUM> to the lower layer <NUM>. The receiving radio node <NUM> may generate and send signaling to the transmitting radio node <NUM> indicating this defined time interval that the transmitting radio node <NUM> is to wait for acknowledgement of a packet at the lower layer <NUM> before performing unsolicited retransmission of the packet. In some embodiments, the receiving radio node <NUM> determines this defined time interval based on the length of its current reordering buffer (e.g., so as to prevent the transmitting radio node <NUM> from retransmitting packets that can no longer be reordered at the receiving radio node <NUM>). Regardless, the transmitting radio node <NUM> may correspondingly configure the defined time interval based on the received signaling.

Note that the embodiment in <FIG> may be implemented separately from the embodiment illustrated in <FIG>, e.g., without regard to splitting or switching of packets between radio links <NUM>, <NUM>. Indeed, <FIG> may be implemented with a single radio link <NUM>. In other embodiments, though, <FIG> is applicable to a particular radio link of <FIG>, e.g., link <NUM>.

In view of the above modifications and variations, <FIG> illustrates a method <NUM> performed by a receiving radio node <NUM> for receiving packets <NUM> in a wireless communication system <NUM> according to some embodiments. The method <NUM> includes scheduling packets <NUM> to be transmitted from a transmitting radio node <NUM> over one or more of multiple different types of radio links <NUM>, <NUM> between which transmission of the packets is configured to be split or switched (Block <NUM>). The method <NUM> also includes transmitting to the transmitting radio node <NUM> a retransmission link indication <NUM> that indicates over which of the multiple different types of radio links packet retransmission is to be performed (Block <NUM>).

<FIG> correspondingly illustrates a method <NUM> performed by a transmitting radio node <NUM> for transmitting packets in a wireless communication system <NUM>. The method <NUM> includes transmitting packets <NUM> to a receiving radio node <NUM> as scheduled by the receiving radio node <NUM> over one or more of multiple different types of radio links <NUM>, <NUM> between which transmission of the packets <NUM> is configured to be split or switched (Block <NUM>). The method <NUM> also includes receiving from the receiving radio node <NUM> a retransmission link indication <NUM> that indicates over which of the multiple different types of radio links <NUM>, <NUM> packet retransmission is to be performed (Block <NUM>). The method <NUM> further includes performing packet retransmission based on the retransmission link indication (Block <NUM>).

<FIG> shows a method <NUM> performed by a transmitting radio node <NUM> for transmitting a packet <NUM> in a wireless communication system <NUM> according to still other embodiments. The method <NUM> includes sending a packet <NUM> from a higher layer <NUM> to a lower layer <NUM> of a protocol stack for transmission of the packet <NUM> from the transmitting radio node <NUM> to a receiving radio node <NUM>, as scheduled by the receiving radio node <NUM> (Block <NUM>). The method <NUM> also includes monitoring an automatic repeat request process at the lower layer <NUM> (Block <NUM>) and performing unsolicited retransmission of the packet <NUM> to the receiving radio node <NUM> based on said monitoring (Block <NUM>).

<FIG> shows a corresponding method <NUM> performed by receiving radio node <NUM> for receiving a packet in a wireless communication system according to some embodiments. The method <NUM> includes scheduling transmission of a packet <NUM> from a transmitting radio node <NUM> to the receiving radio node <NUM> (Block <NUM>). The method <NUM> also includes generating signaling indicating a defined time interval that the transmitting radio node <NUM> is to wait for the packet <NUM> to be acknowledged at a lower layer <NUM> of a protocol stack at the transmitting radio node <NUM>, before the transmitting radio node <NUM> is to perform unsolicited retransmission of the packet <NUM> to the receiving radio node <NUM> (Block <NUM>). The method <NUM> further includes sending the generated signaling to the transmitting radio node <NUM> (Block <NUM>).

A radio node herein is any type of node (e.g., a base station or wireless communication device) capable of communicating with another node over radio signals. A radio network node is any type of radio node within a wireless communication network, such as a base station. A wireless communication device is any type of radio node capable of communicating with a radio network node over radio signals. A wireless communication device may therefore refer to a machine-to-machine (M2M) device, a machine-type communications (MTC) device, a NB-loT device, etc.. The wireless device may also be a user equipment (UE), however it should be noted that the UE does not necessarily have a "user" in the sense of an individual person owning and/or operating the device. A wireless device may also be referred to as a radio device, a radio communication device, a wireless terminal, or simply a terminal - unless the context indicates otherwise, the use of any of these terms is intended to include device-to-device UEs or devices, machine-type devices or devices capable of machine-to-machine communication, sensors equipped with a wireless device, wireless-enabled table computers, mobile terminals, smart phones, laptop-embedded equipped (LEE), laptop-mounted equipment (LME), USB dongles, wireless customer-premises equipment (CPE), etc. In the discussion herein, the terms machine-to-machine (M2M) device, machine-type communication (MTC) device, wireless sensor, and sensor may also be used. It should be understood that these devices may be UEs, but are generally configured to transmit and/or receive data without direct human interaction.

In an IOT scenario, a wireless communication device as described herein may be, or may be comprised in, a machine or device that performs monitoring or measurements, and transmits the results of such monitoring measurements to another device or a network. Particular examples of such machines are power meters, industrial machinery, or home or personal appliances, e.g. refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a wireless communication device as described herein may be comprised in a vehicle and may perform monitoring and/or reporting of the vehicle's operational status or other functions associated with the vehicle.

Note that a transmitting radio node <NUM> (e.g., base station or a wireless communication device such as a UE) as described above may perform the method <NUM> or <NUM> and any other processing herein by implementing any functional means or units. In one embodiment, for example, the transmitting radio node <NUM> comprises respective circuits or circuitry configured to perform the steps shown in <FIG> or <FIG>. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

<FIG> illustrates the transmitting radio node <NUM> in the form of a transmitting radio node 12A in accordance with one or more embodiments. As shown, the transmitting radio node 12A includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. Such communication may occur via one or more antennas that are either internal or external to the transmitting radio node 12A. The processing circuitry <NUM> is configured to perform processing described above, e.g., in <FIG> or <FIG>, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

<FIG> illustrates the transmitting radio node <NUM> in the form of a transmitting radio node 12B implemented in accordance with one or more other embodiments. As shown, the transmitting radio node 12B implements various functional means, units, or modules, e.g., via the processing circuitry <NUM> in <FIG> and/or via software code. These functional means, units, or modules, e.g., for implementing the method in <FIG>, include for instance a transmission module <NUM> for transmitting packets to a receiving radio node <NUM> as scheduled by the receiving radio node <NUM> over one or more of multiple different types of radio links <NUM>, <NUM> between which transmission of the packets is configured to be split or switched. Also included is a receiving module <NUM> for receiving from the receiving radio node <NUM> a retransmission link indication <NUM> that indicates over which of the multiple different types of radio links packet retransmission is to be performed. Further included is a retransmission module <NUM> for performing packet retransmission based on the retransmission link indication <NUM>.

<FIG> illustrates the transmitting radio node <NUM> in the form of a transmitting radio node 12C implemented in accordance with one or more other embodiments. As shown, the transmitting radio node 12C implements various functional means, units, or modules, e.g., via the processing circuitry <NUM> in <FIG> and/or via software code. These functional means, units, or modules, e.g., for implementing the method in <FIG>, include for instance a sending module <NUM> for sending a packet <NUM> from a higher layer <NUM> to a lower layer <NUM> of a protocol stack for transmission of the packet <NUM> from the transmitting radio node 12C to a receiving radio node <NUM>, as scheduled by the receiving radio node <NUM>. Also included is a monitoring module <NUM> for monitoring an automatic repeat request process at the lower layer <NUM>. Further included is a retransmission module <NUM> for performing unsolicited retransmission of the packet <NUM> to the receiving radio node <NUM> based on said monitoring.

Also note that a receiving radio node <NUM> (e.g., base station or a wireless communication device such as a UE) as described above may perform the method <NUM> or <NUM> and any other processing herein by implementing any functional means or units. In one embodiment, for example, the receiving radio node <NUM> comprises respective circuits or circuitry configured to perform the steps shown in <FIG> or <FIG>. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and/or one or more microprocessors in conjunction with memory. In embodiments that employ memory, which may comprise one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc., the memory stores program code that, when executed by the one or more processors, carries out the techniques described herein.

<FIG> illustrates the receiving radio node <NUM> in the form of a receiving radio node 16A in accordance with one or more embodiments. As shown, the receiving radio node 16A includes processing circuitry <NUM> and communication circuitry <NUM>. The communication circuitry <NUM> is configured to transmit and/or receive information to and/or from one or more other nodes, e.g., via any communication technology. Such communication may occur via one or more antennas that are either internal or external to the receiving radio node 16A. The processing circuitry <NUM> is configured to perform processing described above, e.g., in <FIG> or <FIG>, such as by executing instructions stored in memory <NUM>. The processing circuitry <NUM> in this regard may implement certain functional means, units, or modules.

<FIG> illustrates the receiving radio node <NUM> in the form of a receiving radio node 16B implemented in accordance with one or more other embodiments. As shown, the receiving radio node 16B implements various functional means, units, or modules, e.g., via the processing circuitry <NUM> in <FIG> and/or via software code. These functional means, units, or modules, e.g., for implementing the method in <FIG>, include for instance a scheduling module <NUM> for scheduling packets to be transmitted from a transmitting radio node <NUM> over one or more of multiple different types of radio links <NUM>, <NUM> between which transmission of the packets is configured to be split or switched. Also included is a transmitting module <NUM> for transmitting to the transmitting radio node <NUM> a retransmission link indication <NUM> that indicates over which of the multiple different types of radio links packet retransmission is to be performed.

<FIG> illustrates the receiving radio node <NUM> in the form of a receiving radio node 16C implemented in accordance with one or more other embodiments. As shown, the receiving radio node 16C implements various functional means, units, or modules, e.g., via the processing circuitry <NUM> in <FIG> and/or via software code. These functional means, units, or modules, e.g., for implementing the method in <FIG>, include for instance a scheduling module <NUM> for scheduling transmission of a packet <NUM> from a transmitting radio node <NUM> to the receiving radio node 16C. Further included is a generating module <NUM> for generating signaling indicating a defined time interval that the transmitting radio node <NUM> is to wait for the packet <NUM> to be acknowledged at a lower layer <NUM> of a protocol stack at the transmitting radio node <NUM>, before the transmitting radio node <NUM> is to perform unsolicited retransmission of the packet <NUM> to the receiving radio node 16C. Also included is a sending module <NUM> for sending the generated signaling to the transmitting radio node <NUM>.

A computer program comprises instructions which, when executed on at least one processor of a node, cause the node to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions that, when executed by a processor of a node, cause the node to perform as described above.

Although various embodiments are described where splitting or switching occurs at the PDCP layer, embodiments herein are extendable to other layers as well. In some embodiments, for example, splitting or switching occurs at any layer that has packet reordering processing and is split or switched into lower layer links. Moreover, although various embodiments herein illustrate the different types of radio links <NUM>, <NUM> as LTE and WLAN, embodiments herein are extendable to any other radio link types as well.

Notwithstanding, one or more embodiments below illustrate examples in a context where splitting or switching occurs at the PDCP layer, and the radio links are LTE and WLAN. In this regard, it has been proposed for Rel-<NUM> to enhance LWA with allowing uplink transmissions in WLAN, either such that uplink (UL) is switched to WLAN or that UL is split between LTE and WLAN. Challenges exist regarding how the UE can be configured and handle uplink transmissions in LWA.

In LTE the uplink access is eNB controlled, i.e. scheduled. In this case, the UE would report to the eNB when data is available for transmissions, e.g. by sending a scheduling request message (SR). Based on this, the eNB would grant the UE transmission of a certain size of data. Further, as there is an RLC layer and more specifically as RLC acknowledged mode (AM) mode is possible, the LTE link may be seen as a lossless link due to the automatic repeat request (ARQ) protocol at the RLC layer. For continuous LTE only operation, there is no need to have PDCP retransmission. PDCP retransmissions are only done at specific occasions, such as handovers and split bearer to non-split bearer transitions in dual carrier. Essentially, PDCP retransmissions are only needed in cases where the RLC entity is released, which involves data loss on the RLC layer.

On WLAN, there is only the MAC hybrid ARQ (HARQ) protocol for handling retransmissions. But MAC HARQ may stop retransmissions after a number of failed attempts. Thus, on the WLAN side, PDCP PDUs may be lost also during the normal operation in both UL and DL. In Rel-<NUM>, where only DL traffic could be steered to WLAN, flow control reports sent from UE to eNB could be used for PDCP retransmissions.

Two different formats on flow control reports from UE to eNB were specified in Rel-<NUM>. According to the first format, a legacy PDCP report contains a field for first missing sequence (FSM) number which is set to the first missing PDCP SDU. The legacy PDCP report also contains a bitmap field of length in bits equal to the number of PDCP SNs from and not including the first missing PDCP SDU up to and including the last out-of-sequence PDCP SDUs, rounded up to the next multiple of <NUM>. According to the first format, an LWA status report contains: FMS (First Missing PDCP sequence number (SN)), HRW (Highest Received PDCP SN on WLAN), and NMP (Number of Missing PDUs).

There are the following issues for using these messages for UL. The use case for these UL messages would be mainly to avoid hyperframe number (HFN) desync which can be achieved by FMS and PDCP retransmission, and which can to some extent be achieved by the bitmap. The LWA status report can mainly be used for rate estimation which is not that important as the UE anyway cannot control data rate on LTE side as those schedulings are done by the eNB. The information that is missing is the UL path on which these retransmissions should be performed. Further, it should be the eNB's decision as to which PDCP PDUs it requests the UE to retransmit; there may be more efficient formats for such an indication. Third, if those reports are regardless made UE autonomous, one should be able to somehow control that the UE does not retransmit PDCP PDUs that the eNB cannot anymore reorder (SNs that do not anymore belong to the current reordering buffer).

One or more embodiments herein provide methods for UL PDCP retransmission for Rel-<NUM> eLWA, where UL is steered on WLAN or is operating in split mode between LTE and WLAN UL. By providing an efficient means for PDCP retransmissions in the uplink to avoid data loss when using WLAN resources in eLWA, data loss is hidden from higher layers and corrected, which improves the end user performance and/or experience.

In some embodiments referred to as Embodiments A, the eNB requests PDCP retransmissions and includes in the request one or several of the following information: (i) an indication which PDCP PDUs should be retransmitted by the UE; and/or (ii) an indication where (LTE or WLAN) the retransmission should take place.

In one or more of these embodiments, based on eNB request and information, the UE retransmits the PDCP SNs indicated as not yet acknowledged, i.e. for retransmission. The request for retransmission can also be interpreted by the UE as a recommendation, although it is more likely that UE needs to retransmit what is requested. The UE uses the indicated UL direction by the eNB.

The eNB may convey this information to the UE by PDCP Control PDU, for example an extended version of the PDCP status report or the PDCP LWA status report or a variant of those.

In one version, the request is optionally FMS, and one of the following (or a variant): (i) bitmap for the PDCP PDU SNs to be retransmitted; (ii) list of PDCP SNs to be retransmitted; (iii) optionally start and optionally end PDCP SNs to be retransmitted; (iv) HRW (Highest Received PDCP SN on WLAN) and/or NMP (Number of Missing PDUs).

And the indication of the UL direction may be conveyed in the PDCP level request or the UL direction for retransmission may be RRC configured.

To indicate the uplink direction within a PDCP Control PDU, a flag may be used in some embodiments. If the flag is set, LTE should be used for the retransmissions. If the flag is not set, WLAN should be used. In another variant, setting the flag indicates that the not-RRC-configured uplink direction is used (i.e. not the one for continuous UL operation). An extended LWA status report or PDCP status report may be used as basis for extending the PDCP control PDU.

In yet another variant, instead of the flag indicating the uplink direction for retransmissions, setting the flag means that the uplink direction from now on, i.e. for both retransmission and continuous operation, changes to another uplink direction, i.e. the uplink direction is toggled.

Alternatively the eNB may convey this information to the UE in form of an RRC command. It may be indicated in the RRC-connection-reconfiguration, e.g. which uplink direction PDCP retransmissions could take, which can be separate to the configuration of which direction continuous uplink directions would take. In this example, it can also be preconfigured by RRC or standardized, that uplink retransmissions should take another direction (LTE or WLAN) than continuous uplink transmissions. on top of this preconfiguration, the eNB could issue, or the UE could trigger the retransmissions dynamically, e.g. based on PDCP control.

In other embodiments referred to as Embodiments B, in case the UE keeps track of not successfully sent PDCP PDUs by monitoring WLAN HARQ retransmissions, a timer is used to control how old packets must be before being retransmitted. An indication may govern where (LTE or WLAN) the retransmission should take place, similar to the eNB request case in embodiments A.

In embodiments B, the UE may also do retransmissions on its own without eNB request. Some embodiments in this regard add ARQ functionality to the Rel-<NUM> LWAAP layer that does retransmissions similar to LTE RLC layer. The ARQ on the LWAAP sublayer in the UE may be triggered by the lack of a WLAN MAC layer ACK. Such retransmissions may be timer based such that the UE retransmits PDCP PDUs that are not ACKed by WLAN MAC layer within a timer configured by eNB. The timer in some embodiments starts when the PDCP layer sends a PDCP PDU to the WLAN MAC layer. One benefit of the timer is that the retransmitted PDCP PDUs are more probably still useful at the eNB. Such a timer indication may for example be configured in the UE by the eNB through the RRC reconfiguration procedure when establishing / configuring LWA. In this embodiment, the UL path may be indicated separately using similar means as with the eNB request cases.

In yet another embodiment, a mixture of the above embodiments A and B may be applied. As one example, the eNB may periodically send FMS to UE in order for the UE to keep SFN sync. The eNB may send PDCP retransmission requests and the UL direction is set according to an option in "indication of UL path". As another example, the eNB periodically sends FMS to UE in order for the UE to keep SFN sync. UE does retransmissions based on own its bookkeeping of not successfully transmitted PDCP PDUs. The eNB may send PDCP retransmission requests and the UL direction is set according to an option in "indication of UL path".

Other combinations are possible as well. Note in this regard that embodiments A and B may be combined such that even if B is true. the eNB may send retransmission requests.

Claim 1:
A method implemented by a transmitting radio node (<NUM>) for transmitting packets in a wireless communication system (<NUM>), the method comprising:
receiving, at the transmitting node (<NUM>) from a receiving node (<NUM>), a scheduling grant indicating the receiving radio node's scheduling decision, scheduling the packets to be transmitted over one or more of multiple different types of radio links;
transmitting (<NUM>) packets to the receiving radio node (<NUM>) as scheduled by the receiving radio node (<NUM>) over the one or more of multiple different types of radio links (<NUM>, <NUM>) between which transmission of the packets is configured to be split or switched, said different types of radio links using different radio access technologies;
receiving (<NUM>) from the receiving radio node (<NUM>) a retransmission link indication (<NUM>) that indicates over which of the multiple different types of radio links (<NUM>, <NUM>) packet retransmission is to be performed;
performing (<NUM>) packet retransmission based on the retransmission link indication (<NUM>); and wherein the method also comprises
receiving from the receiving radio node (<NUM>) a retransmission packet indication that indicates a particular packet to retransmit to the receiving radio node (<NUM>), and wherein the retransmission link indication (<NUM>) indicates over which of the multiple different types of radio links (<NUM>, <NUM>) to retransmit that particular packet,
wherein the retransmission link indication (<NUM>) and the retransmission packet indication are included in a request message transmitted from the receiving radio node (<NUM>) to the transmitting radio node (<NUM>) requesting retransmission of the particular packet.