Patent Description:
The present application claims the Paris Convention priority of European patent application <CIT>.

Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present disclosure.

Third and fourth generation wireless communications systems, such as those based on the third generation partnership project (3GPP) defined UMTS and Long Term Evolution (LTE) architecture are able to support sophisticated services such as instant messaging, video calls as well as high speed internet access. The demand to deploy third and fourth generation networks is therefore strong and the coverage area of these networks, i.e. geographic locations where access to the networks is possible, is expected to increase rapidly.

However, whilst fourth generation networks can support communications at high data rate and low latencies from devices such as smart phones and tablet computers, it is expected that future wireless communications networks will need to support communications to and from a much wider range of devices, including reduced complexity devices, machine type communication (MTC) devices, wearable devices, devices which require little or no mobility, high resolution video displays and virtual reality headsets. As such, the supporting of such a wide range of communications devices, and the device-to-device (D2D) communications between them, can represent a technical challenge for a wireless communications network.

A current technical area of interest to those working in the field of wireless and mobile communications is known as "The Internet of Things" or IoT for short. The 3GPP has proposed to develop technologies for supporting narrow band (NB)-IoT using an LTE or <NUM> wireless access interface and wireless infrastructure. Such IoT devices are expected to be low complexity and inexpensive devices requiring infrequent communication of relatively low bandwidth data. It is also expected that there will be an extremely large number of IoT devices which would need to be supported in a cell of the wireless communications network. Furthermore such NB-IoT devices are likely to be deployed indoors and /or in remote locations making radio communications challenging.

There is therefore expected to be a desire for future wireless communications networks, which may be referred to as <NUM> or new radio (NR) system / new radio access technology (RAT), networks, to efficiently support connectivity for a wide range of devices associated with different applications with different characteristic data traffic profiles, resulting in different devices have different operating characteristics / requirements, such as:.

The introduction of new radio access technology (RAT) systems / networks therefore gives rise to new challenges for providing efficient operation for devices operating in new RAT networks, including devices able to operate in both new RAT networks (e.g. a 3GPP <NUM> network) and currently deployed RAT networks (e.g. a 3GPP <NUM> or LTE network). There is a desire to provide mobile communications systems in which processing overheads of devices may be reduced, leading to improved efficiency and performance. Methods of doing so are addressed by embodiments of the present technique.

<CIT> pertains to a data packet transmission from a transmitter to a receiver with a radio access network for reliable acknowledgement communication.

<CIT> relates to a method and system that properly triggers a polling operation for a transmitter to request a receiving status of a receiver.

<CIT> relates to a method of data transmission, a data structure employed in such a method and to transmitting and receiving devices arranged for use in such a method.

<CIT> is directed to a system and method for controlling the transmission of polling information with one or more protocol data units in a wireless communications system.

According to embodiments of the present technique, there is provided a transmitting node operating with a mobile communications system. The transmitting node comprises transmitter circuitry configured to transmit signals representing protocol data units formed from one or more service data units via a wireless access interface of the mobile communications system to a receiving node of the mobile communications system according to an automatic repeat request process, receiver circuitry configured to receive signals from the receiving node via the wireless access interface, controller circuitry configured to control the transmitter circuitry to transmit the signals and to control the receiver circuitry to receive the signals, and a buffer configured to store data conveyed by or representing the protocol data units for transmission to the receiving node according to the automatic repeat request process, wherein each of the protocol data units has a sequence number defining their position in a predetermined order. The controller circuitry is configured in combination with the transmitter circuitry and the buffer to detect, based on the sequence number of one or more of the protocol data units, whether predetermined criteria are satisfied, wherein the predetermined criteria comprises the sequence number of the one or more of the protocol data units being equal to a fixed one of one or more values of sequence numbers which are configurable by the network and provided to the transmitting node and the receiving node, and in response to transmit a polling bit to the receiving node in the one or more of the protocol data units for which the sequence number satisfies the predetermined criteria.

According to embodiments of the present technique, there is provided a receiving node operating with a mobile communications system. The receiving node comprises receiver circuitry configured to receive signals representing protocol data units formed from one or more service data units via a wireless access interface of the mobile communications system from a transmitting node of the mobile communications system according to an automatic repeat request process, transmitter circuitry configured to transmit signals to the transmitting node via the wireless access interface, and controller circuitry configured to control the transmitter circuitry to transmit the signals and to control the receiver circuitry to receive the signals, wherein each of the protocol data units has a sequence number defining their position in a predetermined order. The controller circuitry is configured in combination with the receiver circuitry to detect based on the sequence number of one or more of the protocol data units, that a protocol data unit satisfying predetermined criteria and carrying a polling bit is lost, wherein the predetermined criteria comprises the sequence number of the protocol data unit being equal to a fixed one of one or more values of sequence numbers which are configurable by the network and provided to the transmitting node and the receiving node, and in response to transmit a status report message comprising a negative acknowledgement for one or more protocol data units which were not successfully received.

Further embodiments of the present disclosure relate to a method of controlling communications at a transmitting node operating with a mobile communications system, a method of controlling communications at a receiving node operating with a mobile communications system, circuitry for a transmitting node operating with a mobile communications system, circuitry for a receiving node operating with a mobile communications system and a mobile communications system comprising a transmitting node and a receiving node.

<FIG> provides a schematic diagram illustrating some basic functionality of a mobile telecommunications network / system operating in accordance with LTE principles and which may be adapted to implement embodiments of the disclosure as described further below. Various elements of <FIG> and their respective modes of operation are well-known and defined in the relevant standards administered by the 3GPP (RTM) body, and also described in many books on the subject, for example, Holma H. It will be appreciated that operational aspects of the telecommunications network which are not specifically described below may be implemented in accordance with any known techniques, for example according to the relevant standards.

The network <NUM> includes a plurality of base stations <NUM> connected to a core network <NUM>. Each base station provides a coverage area <NUM> (i.e. a cell) within which data can be communicated to and from communications devices <NUM>. Data is transmitted from base stations <NUM> to communications devices <NUM> within their respective coverage areas <NUM> via a radio downlink. Data is transmitted from communications devices <NUM> to the base stations <NUM> via a radio uplink. The uplink and downlink communications are made using radio resources that are licenced for exclusive use by the operator of the network <NUM>. The core network <NUM> routes data to and from the communications devices <NUM> via the respective base stations <NUM> and provides functions such as authentication, mobility management, charging and so on. Communications devices may also be referred to as mobile stations, user equipment (UE), user device, mobile radio, and so forth. Base stations may also be referred to as transceiver stations / infrastructure equipment / NodeBs / eNodeBs (eNB for short), and so forth.

Wireless communications systems such as those arranged in accordance with the 3GPP defined Long Term Evolution (LTE) architecture use an orthogonal frequency division modulation (OFDM) based interface for the radio downlink (so-called OFDMA) and a single carrier frequency division multiple access scheme (SC-FDMA) on the radio uplink.

An example configuration of a wireless communications network which uses some of the terminology proposed for NR and <NUM> is shown in <FIG>. In <FIG> a plurality of transmission and reception points (TRPs) <NUM> are connected to distributed control units (DUs) <NUM>, <NUM> by a connection interface represented as a line <NUM>. Each of the TRPs 210is arranged to transmit and receive signals via a wireless access interface within a radio frequency bandwidth available to the wireless communications network. Thus within a range for performing radio communications via the wireless access interface, each of the TRPs <NUM>, forms a cell of the wireless communications network as represented by a dashed line <NUM>. As such wireless communications devices <NUM> which are within a radio communications range provided by the cells <NUM> can transmit and receive signals to and from the TRPs <NUM> via the wireless access interface. Each of the distributed control units <NUM>, <NUM> are connected to a co-ordinating unit (CU) <NUM> via an interface. The co-ordinating unit <NUM> is then connected to the a core network <NUM> which may contain all other functions required to transmit data for communicating to and from the wireless communications devices and the core network <NUM> may be connected to other networks <NUM>.

The TRPs <NUM> of <FIG> may in part have a corresponding functionality to a base station or eNodeB of an LTE network. Similarly the communications devices <NUM> may have a functionality corresponding to UE devices known for operation with an LTE network. It will be appreciated therefore that operational aspects of a new RAT network (for example in relation to specific communication protocols and physical channels for communicating between different elements) may be different to those known from LTE or other known mobile telecommunications standards. However, it will also be appreciated that each of the core network component, base stations and terminal devices of a new RAT network will be functionally similar to, respectively, the core network component, base stations and terminal devices of an LTE wireless communications network.

<FIG> provides a schematic representation of the wireless communications network shown in <FIG> arranged to illustrate a scenario of communication with a UE <NUM> which is mobile. As will be appreciated if a UE <NUM> is transmitting from left to right and detecting the beams formed by the TRPs <NUM>, <NUM> the UE <NUM> may be able to detect each of the beams in turn but not contemporaneously. Accordingly, the UE <NUM> should be arranged to hand over between different TRPs to transmit and/or receive signals represented as different beams as it travels from a left hand side of <FIG> to the right hand side. Thus as shown by a first arrow <NUM> as a UE <NUM> travels from an area where it can receive a first of the beams <NUM> to an area where it can receive a second of the beams <NUM>, the UE <NUM> should hand over transmission and reception from the first beam <NUM> to the second beam <NUM>. However as represented by a second arrow <NUM>, as the UE <NUM> travels further to detect a first beam <NUM> of a second TRP <NUM>, then the UE <NUM> should hand over from the first TRP <NUM> to the second TRP <NUM>. Furthermore as the UE <NUM> travels further <NUM> to detect a further beam <NUM> transmitted by a third TRP <NUM>, then the UE <NUM> should hand over from a first of the distributed units <NUM> to a second the distributed units <NUM>. More details of the handover arrangement are disclosed in [<NUM>].

3GPP have started the standardisation process of the new <NUM> radio access technology as described with reference to <FIG> and <FIG> above. A RAN study item [<NUM>] provides justification and objectives with the development of NR systems, as described in the text taken from [<NUM>] below.

"Work has started in ITU and 3GPP to develop requirements and specifications for new radio (NR) systems, as in the <NPL>", as well as 3GPP SA1 study item New Services and Markets Technology Enablers (SMARTER) and SA2 study item Architecture for NR System. In addition, a joint RAN-SA document [SP-<NUM>] from RAN#<NUM> outlines the "NR" timeline for 3GPP, further detailed in the September RAN workshop on NR [RWS-<NUM>].

3GPP has to identify and develop the technology components needed for successfully standardizing the NR system timely satisfying both the urgent market needs, and the more long-term requirements set forth by the ITU-R IMT-<NUM> process. Further, the NR system should be able to use any spectrum band ranging at least up to <NUM> that may be made available for wireless communications even in a more distant future.

The [SP-<NUM>] foresaw the following timeline.

RAN#<NUM> saw the first draft study item proposals for discussion for points <NUM>) [RP-<NUM>] and <NUM>) [RP-<NUM>], and further RAN#<NUM> saw the first draft study item proposals for <NUM>) in [RP-<NUM>] and [RP-<NUM>]. A study item on <NUM>) [RP-<NUM>] started in RAN#<NUM>.

This study item will address point <NUM>) and build on the work done in the three preceding steps, discussions in the RAN workshop on NR, and the draft SIDs submitted to RAN#<NUM>.

The study aims to develop an NR access technology to meet a broad range of use cases including enhanced mobile broadband, massive MTC, critical MTC, and additional requirements defined during the RAN requirements study.

The new RAT will consider frequency ranges up to <NUM> [TR38.

Detailed objectives of the study item are:.

RAN2 meeting documents [<NUM>] to [<NUM>] discuss various aspects of the <NUM> NR system, which are summarised below.

<FIG> is taken from [<NUM>] and depicts retransmission in the RLC layer. RLC transmission could overcome the drawbacks of PDCP transmission in that no extra delay is incurred from the non-ideal link between sender PDCP and sender RLC during the retransmission process.

<FIG> is taken from [<NUM>], and illustrates an example of SO-based segmentation and resegmentation. The same size of segmented SDU with a previous LTE case (which is described in [<NUM>] with reference to <FIG> of [<NUM>]) is assumed in the example. <FIG> shows that it is possible for SO-based segmentation to perform the same level of segmentation of LTE. This means that segmentation and resegmentation can be unified by SO-based segmentation.

<FIG> is also taken from [<NUM>], and illustrates an example of pre-processing of RLC PDUs and segmentation for SO-based segmentation. In the example, <NUM> RLC PDUs are assumed to be constructed in advance. If the RLC PDU with SN=<NUM> is segmented into <NUM> RLC PDUs, then in a framing info (FI)-based segmentation example (which is described in [<NUM>] with reference to <FIG> of [<NUM>]) requires an additional consecutive sequence number, i.e., SN = <NUM>. This means that the other pre-processed RLC PDUs should change their SNs, thus pre-processing of these PDUs becomes weaker. On the other hand, the SO-based segmentation as shown in <FIG> does not need to change sequence number of each pre-processed RLC PDU. Therefore, pre-processing of RLC PDUs for reducing real-time processing requires SO-based segmentation rather than FI-based segmentation.

<FIG> shows an acknowledged mode (AM) RLC entity <NUM>, comprising a transmission buffer <NUM>, segmentation and concatenation means <NUM>, RLC header addition means <NUM>, retransmission buffer <NUM>, RLC control means <NUM>, routing means <NUM>, a reception buffer <NUM> which may carry out re-ordering in accordance with a HARQ protocol, RLC removal means <NUM> and SDU reassembly means <NUM>. When a transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer. The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ). If the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the RLC data PDU into AMD PDU segments and the number of re-segmentation is not limited. When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD PDU segments from RLC data PDUs to be retransmitted, it shall include relevant RLC headers in the RLC data PDU. When the receiving side of an AM RLC entity receives RLC data PDUs, it shall detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs, reorder the RLC data PDUs if they are received out of sequence, detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity and reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence. At the time of RLC reestablishment, the receiving side of an AM RLC entity shall if possible, reassemble RLC SDUs from the RLC data PDUs that are received out of sequence and deliver them to upper layer, discard any remaining RLC data PDUs that could not be reassembled into RLC SDUs and initialise relevant state variables and stop relevant timers.

The user-plane protocol architecture for LTE is shown in <FIG>. Protocol architecture of a UE <NUM> comprises, at layer <NUM> of the protocol stack, a PDCP layer <NUM>, an RLC layer <NUM> and a MAC layer <NUM>, all above the physical layer <NUM> at layer <NUM> of the protocol stack. Likewise, protocol architecture of an eNodeB <NUM> comprises, at layer <NUM> of the protocol stack, a PDCP layer <NUM>, an RLC layer <NUM> and a MAC layer <NUM>, all above the physical layer <NUM> at layer <NUM> of the protocol stack. Data is able to be communicated between the PDCP layer <NUM> of the UE <NUM> and the PDCP layer <NUM> of the eNodeB <NUM>, between the RLC layer <NUM> of the UE <NUM> and the RLC layer <NUM> of the eNodeB <NUM>, between the MAC layer <NUM> of the UE <NUM> and the MAC layer <NUM> of the eNodeB <NUM> and between the physical layer <NUM> of the UE <NUM> and the physical layer <NUM> of the eNodeB <NUM>.

Significantly, most of the optimisations proposed from UE and chipset vendors aim to simplify the overall user-plane protocol stack implementation, and in particular to reduce processing overhead - reducing the amount of processing the UE needs to do for each transmitted data packet. In addition, the removal of concatenation allows for pre-processing the RLC headers as well as optimizing the implementation by allowing some pre-processing of the data packets including ciphering, rather than having to do this in real time. If concatenation is not used, then there is no need to include additional length fields in the RLC header and the header can be a fixed size.

One of the aspects not yet discussed with regards to the <NUM> new RAT systems is that of RLC polling and status reporting. In LTE, RLC polling is specified as follows (from [<NUM>]).

An AM RLC entity can poll its peer AM RLC entity in order to trigger STATUS reporting at the peer AM RLC entity.

Upon assembly of a new AMD PDU, the transmitting side of an AM RLC entity shall:.

Upon assembly of an AMD PDU or AMD PDU segment, the transmitting side of an AM RLC entity shall:.

To include a poll in a RLC data PDU, the transmitting side of an AM RLC entity shall:.

After delivering a RLC data PDU including a poll to lower layer and after incrementing of VT(S) if necessary, the transmitting side of an AM RLC entity shall:.

In summary, the UE RLC entity maintains <NUM> counters. One counter counts transmitted RLC PDUs, and the other counts transmitted bytes. If either count reaches the configured threshold, a poll is sent (requesting ACK/NACK in a status report) and the counters are reset.

If the UE does not receive a response to the poll within the t-PollRetransmit then the PDU containing the poll is resent (Assumed to be not received).

The main purpose of the polling mechanism is to advance the transmission window, which avoids protocol stalling. Errors are typically corrected at HARQ, with any leftover errors detected by the receiving RLC entity using the reordering timer. The polling mechanism confirms the last acknowledged sequence number so that the window can be advanced so to accept new data from upper layers. The reason for maintaining <NUM> counters is to account for variable PDU size. In case of good radio conditions, the PDU size is large and so memory would be the limitation (UE can reserve a fixed amount of memory to store/buffer data). In case of poor radio conditions, the PDU size is small, so the RLC sequence number is the limitation. If the poll is sent after more than half of the SN range, then there is a risk of protocol stalling.

In UMTS a similar mechanism exists "Every Poll_SDU SDU. ", whereby the UE counts the number of transmitted PDUs - however, both transmissions and retransmissions are counted, so UE has to calculate in every TTI whether to set a poll bit. The various UMTS polling triggers are shown below (from <NUM>).

According to embodiments of the present technique, polling is based on the sequence number rather than the number of PDUs which have been transmitted. This means that the poll bit is always sent in a fixed SN, so can be included in the UE pre-generated RLC headers rather than having to determine in real-time. No counters are used. It has previously been proposed in a 3GPP document [<NUM>] that PDCP sequence numbers could be used for performing RLC ARQ. However, there is no disclosure in this document that the PDCP sequence numbers could be used for setting the poll bit (which may be managed by either RLC or PDCP), nor that the sequence numbers themselves could be used as a basis for the receiver of the PDUs to trigger a status report message to the transmitter.

<FIG> is a part schematic representation, part message flow diagram of communications between a transmitting node <NUM> and a receiving node <NUM> of a mobile communications system <NUM> in accordance with embodiments of the present technique.

The transmitting node <NUM> comprises transmitter circuitry <NUM> configured to transmit <NUM> signals representing protocol data units formed from one or more service data units via a wireless access interface <NUM> of the mobile communications system <NUM> to the receiving node <NUM> of the mobile communications system <NUM> according to an automatic repeat request process, receiver circuitry <NUM> configured to receive signals from the receiving node <NUM> via the wireless access interface <NUM>, controller circuitry <NUM> configured to control the transmitter circuitry <NUM> to transmit the signals and to control the receiver circuitry <NUM> to receive the signals, and a buffer <NUM> configured to store data conveyed by or representing the protocol data units for transmission to the receiving node <NUM> according to the automatic repeat request process. Each of the protocol data units, as can be seen in <FIG>, has a sequence number defining its position in a predetermined order.

The receiving node <NUM> comprises receiver circuitry <NUM> configured to receive <NUM> the signals representing protocol data units formed from one or more service data units via the wireless access interface <NUM> of the mobile communications system <NUM> from the transmitting node <NUM> of the mobile communications system <NUM> according to the automatic repeat request process, transmitter circuitry <NUM> configured to transmit signals to the transmitting node <NUM> via the wireless access interface <NUM>, and controller circuitry <NUM> configured to control the transmitter circuitry <NUM> to transmit the signals and to control the receiver circuitry <NUM> to receive the signals.

In some embodiments of the present technique, the controller circuitry <NUM> of the transmitting node <NUM> is configured in combination with the transmitter circuitry <NUM> and the buffer <NUM> of the transmitting node <NUM> to detect <NUM>, based on the sequence number of one or more of the protocol data units, whether predetermined criteria are satisfied, and in response, to transmit <NUM> a polling bit to the receiving node <NUM> in the one or more of the protocol data units for which the sequence number satisfies the predetermined criteria. The controller circuitry <NUM> may then be configured in combination with the transmitter circuitry <NUM>, the receiver circuitry <NUM> and the buffer <NUM> to receive <NUM>, from the receiving node <NUM>, in response to the polling bit, a status report message comprising a negative acknowledgement for one or more protocol data units which were not successfully received by the receiving node <NUM>, and to re-transmit to the receiving node <NUM> the one or more protocol data units which were not successfully received by the receiving node <NUM>.

In some embodiments of the present technique, the controller circuitry <NUM> of the receiving node <NUM> is configured in combination with the receiver <NUM> of the receiving node <NUM> to detect <NUM>, based on the sequence number of one or more of the protocol data units, whether predetermined criteria are satisfied, and in response to transmit <NUM> a status report message comprising a negative acknowledgement for one or more protocol data units which were not successfully received. The status report message may be transmitted <NUM> on the basis of the detection <NUM> of the sequence numbers alone or alternatively in response to the reception <NUM> of a polling bit from the transmitting node <NUM>. The receiving node <NUM> may then, in some embodiments of the present technique, be configured to receive from the transmitting node <NUM> as a re-transmission, in response to the status report message, the one or more protocol data units which were not successfully received from the transmitting node <NUM>.

In some embodiments of the present technique, the buffer <NUM> comprises a sliding window which represents protocol data units which have been transmitted by the transmitting node <NUM> but not yet successfully acknowledged by the receiving node <NUM>, an upper edge of the sliding window being set to a first value equal to a sequence number to be assigned for a next newly generated protocol data unit at the transmitting node <NUM> and a lower edge of the sliding window being set to a second value equal to a sequence number of a next protocol data unit for which a successful acknowledgement is to be received from the receiving node <NUM> in the predetermined order, and the controller circuitry <NUM> is configured in combination with the transmitter circuitry <NUM>, the receiver circuitry <NUM> and the buffer <NUM> to receive from the receiving node an indication that one or more of the protocol data units have not been successfully received by the receiving node <NUM>, to re-transmit from the buffer <NUM> the one or more of the protocol data units which have not been successfully received by the receiving node <NUM>, and to advance the sliding window according to the second value, such that memory of the buffer <NUM> is freed at locations at which are stored each of the protocol data units in the predetermined order which have been successfully received before the one or more protocol data units which have not been successfully received.

Of course, it may be the case that the PDUs up to a particular sequence number, for example PDUs up to and including the PDU containing the polling bit, or the PDUs up to and including the PDU with a sequence number satisfying the predetermined criteria. For example, PDUs with SN = <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may be transmitted, where SN = <NUM> satisfies the predetermined criteria. If all five of those PDUs have been successfully received, the sliding window can advance according to the SN value of <NUM>. Alternatively, a number of PDUs up to any other PDU up to the PDU containing the poll bit or satisfying the predetermined criteria may all be successfully received. The status report may contain an indication of the last successfully received SN in order and may contain indications of the SNs of any PDUs which have not successfully been received. For example, again, PDUs with SN = <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may be transmitted, where SN = <NUM> satisfies the predetermined criteria. However, if the PDU with an SN = <NUM> is not successfully received by the receiver, then the sliding window can advance according to the SN value of <NUM>, freeing space at the three locations where PDUs with SN = <NUM>, <NUM>, <NUM> were stored, whilst the PDU with SN = <NUM> requires a re-transmission. In both of the above cases, in some embodiments of the present technique, the sliding window of the buffer can be advanced to free the memory of the buffer at locations at which are stored each of those PDUs which were successfully received in sequence number order, as no re-transmissions for any of those PDUs are therefore required.

In other words, in some embodiments of the present technique, the buffer comprises a sliding window which represents protocol data units which have been transmitted by the transmitting node but not yet successfully acknowledged by the receiving node, an upper edge of the sliding window being set to a first value equal to a sequence number to be assigned for a next newly generated protocol data unit at the transmitting node and a lower edge of the sliding window being set to a second value equal to a sequence number of a next protocol data unit for which a successful acknowledgement is to be received from the receiving node in the predetermined order, and the controller circuitry is configured in combination with the transmitter circuitry, the receiver circuitry and the buffer to receive from the receiving node an indication that all of the protocol data units up to and including the protocol data unit having a sequence number equal to the second value, and to advance the sliding window according to the second value, such that memory of the buffer is freed at locations at which are stored each of the protocol data units in the predetermined order which have been successfully received before the one or more protocol data units which have not been successfully received.

The main advantage of using a fixed SN is that it is no longer necessary to maintain any counters, which involve some processing overhead to manage. The RLC headers can be hard-coded with a poll bit in certain SNs. In other words, the protocol data units each include a header which is at least partly pre-generated to include the sequence number of the each of the protocol data units.

The fixed SN could be fixed in the specification (e.g. on SN =<NUM> and SN = half of the maximum SN) or it might be configurable by the network (e.g. poll every SN mod N). In other words, the predetermined criteria comprises the sequence number of the one or more of the protocol data units being equal to one of one or more predetermined values of sequence numbers, the one or more predetermined values of sequence numbers being known by the transmitting device and the receiving device, or wherein the predetermined criteria comprises the sequence number of the one or more of the protocol data units being equal to one of one or more values of sequence numbers configured by the mobile communications system and provided to the transmitting node and the receiving node. In some embodiments of the present technique, the predetermined criteria comprises the sequence number of the one or more of the protocol data units being greater than or equal to one of one or more predetermined values of sequence numbers, the one or more predetermined values of sequence numbers being known by the transmitting device and the receiving device, or wherein the predetermined criteria comprises the sequence number of the one or more of the protocol data units being greater than or equal one of one or more values of sequence numbers configured by the mobile communications system and provided to the transmitting node and the receiving node - these embodiments include those in which polling bits are not used, or a polling bit is not successfully received by the receiving node, which then triggers the sending of a status report message when a higher SN than expected is received.

An example of basic polling operation and transmitter window state variables in accordance with the present technique is shown in <FIG>. The fixed SN is always known to both the transmitter and the receiver. Due to this, the receiver can proactively send a status report if it receives any PDU with a higher sequence number than the fixed polling SN. This is particularly useful in case the PDU containing a poll bit is received out of order, or has been lost on the radio link and needs to be retransmitted. It allows the receiver to trigger a status report more quickly, and so any PDUs for which a NACK is transmitted by the receiving node can be retransmitted more quickly by the transmitting node, improving the overall performance as well as the processing benefit at the transmitter.

<FIG> shows an example of transmitting negative acknowledgements (NACKs) by the receiving device automatically based on the sequence number in accordance with embodiments of the present technique. As can be seen, in case the receiver detects SN > N, a status report is automatically generated. This allows recovery of the error and advancing the window more quickly. The drawback of this approach is a slightly increased overhead due to the additional STATUS report - therefore it's possible such behaviour is configurable, so that the network can choose the operation it prefers (faster error recovery, or less overhead). Another alternative is to remove the poll bit in case of retransmission.

It is expected that the UE has to be able to include poll bits under some other conditions too. For example, a poll bit should be included when the buffer becomes empty, in order to trigger a status report for acknowledgement of all of the data. For example, PDUs with SN = <NUM>, <NUM>, <NUM>, <NUM> may be transmitted. In this case, the buffer still contains all four of these PDUs, but since the PDU with SN = <NUM> is the last one being transmitted from the buffer, a poll bit is set. The final PDU might alternatively be a re-transmission. For example, if PDUs with SN = <NUM>,<NUM>,<NUM>,<NUM> are transmitted, and then a NACK is received for the PDU with for SN = <NUM> , this PDU is re-transmitted following the transmissions of the PDUs with SN = <NUM> and <NUM> (and the reception of the NACK for the PDU with SN = <NUM>, whether in a status report message or otherwise) and a poll bit is sent with the re-transmitted PDU with SN = <NUM>, as it is the last one in the buffer to be sent. In other words, the transmitting node is configured to detect that the next of the protocol data units to be transmitted is the last protocol data unit in the buffer, and to transmit a polling bit to the receiving node along with the next of the protocol data units to be transmitted.

In addition, it might also be necessary to maintain a byte counter, in case of any memory limitation. The fixed SN polling might also work in parallel with the PDU count, however this partly reduces the benefit of being able to avoid processing overhead - the SN based polling should be enough for managing the transmit window in a very simple manner. In other words, the transmitting node is configured to detect that the number of protocol units or the number of bytes stored in the buffer exceeds a predetermined threshold, and in response to transmit a polling bit to the receiving node along with the next of the protocol data units to be transmitted.

It is also expected the receiver can trigger a status report in case it detects an error. The LTE mechanism uses a reordering timer, however it might also be considered that a status report can be triggered in case a missing RLC SN is detected, at current SN - N. In other words, the receiving node is configured to detect that a received protocol data unit has a sequence number which is received out of an expected order corresponding to the order of the sequence numbers, and in response to transmit to the transmitting node a status report comprising a negative acknowledgement for a protocol data units having the expected sequence number to match the predetermined criteria, and to receive from the transmitting node as a re-transmission a polling bit and the protocol data unit having the expected number to match the predetermined criteria. In some embodiments of the present technique, receiving a small number of PDUs out of order is tolerated by the receiving node, to compensate for HARQ retransmissions of PDUs which were not successfully received during their first transmissions. However, a gap in reception of PDUs may be detected by the receiving node, which would receive nothing at a time when it would be expecting to receive a PDU with a particular SN.

<FIG> shows a flow diagram illustrating a method of communications between a transmitting node and a receiving node of a mobile communications system in accordance with embodiments of the present technique. The process begins in step S1. The method comprises, in step S2, the transmission of by the transmitting node and reception of by the receiving node signals representing protocol data units formed from one or more service units via a wireless access interface of the mobile communications system according to an automatic repeat request process, wherein each of the protocol data units has a sequence number defining their position in a predetermined order - these protocol data units are stored in a buffer at the transmitting node once they have been transmitted to the receiving node. The method then comprises in step S3, detecting, based on the sequence number of one or more of the protocol data units, the predetermined criteria are satisfied. In some embodiments of the present technique, the process advances to step S4, which comprises the transmission of by the transmitting node and reception of by the receiving node a polling bit. Dependent on either the transmitted/received polling bit or the sequence numbers of received protocol data units, in step S5, the method comprises the transmission of by the receiving node and reception of by the transmitting node a status report message comprising a negative acknowledgement for one or more protocol data units which were not successfully received by the receiving node. In some embodiments of the present technique, the process then advances to step S6, which comprises the re-transmitting of by the transmitting node and reception of by the receiving node the PDUs for which the negative acknowledgements were transmitted by the receiving node in the status report message. The process ends in step S7.

In embodiments of the present technique, the receiving node forms part of a mobile communications network and may, for example, be an infrastructure equipment (base station/eNodeB etc.) The transmitting node may, for example, be a communications device, or user equipment (UE).

In embodiments of the present disclosure, the transmitter circuitry <NUM>, <NUM> may include analogue and digital circuitry such as radio frequency circuits and filters, analogue amplifiers as well as digital signalling processing software implemented as application specific semiconductor circuits, dedicated signalling processing logic and other processors. Similarly the receiver circuitry <NUM>, <NUM> may include radio frequency circuitry and filters, signal processing software in the form of digital signal processors and other devices for detecting signals. The controller circuitry <NUM>, <NUM> may be formed from processors executing software, application specific semiconductor circuits or hardware circuits comprising digital logic. In some examples the controller circuitry <NUM> of the receiving node <NUM> can include a so-called "scheduler" which schedules the transmission of signals and the reception of signals via the wireless access interface.

Advantages of embodiments of the present technique include the simplification of RLC polling. Pre-configuration of RLC headers is enabled, which reduces processing overheads especially at a high data throughput. Furthermore, embodiments of the present technique allow the receiver to automatically respond without re-transmission of PDUs containing poll bits, allowing for faster re-transmission and improved overall performance.

Claim 1:
A transmitting node (<NUM>) operating with a mobile communications system (<NUM>) comprising
transmitter circuitry (<NUM>) configured to transmit (<NUM>) signals representing protocol data units formed from one or more service data units via a wireless access interface (<NUM>) of the mobile communications system to a receiving node (<NUM>) of the mobile communications system according to an automatic repeat request process,
receiver circuitry (<NUM>) configured to receive signals from the receiving node via the wireless access interface,
controller circuitry (<NUM>) configured to control the transmitter circuitry to transmit the signals and to control the receiver circuitry to receive the signals, and
a buffer (<NUM>) configured to store data conveyed by or representing the protocol data units for transmission to the receiving node according to the automatic repeat request process,
wherein each of the protocol data units has a sequence number defining their position in a predetermined order, and the controller circuitry is configured in combination with the transmitter circuitry and the buffer
to detect (<NUM>), based on the sequence number of one or more of the protocol data units, whether predetermined criteria are satisfied, wherein the predetermined criteria comprises the sequence number of the one or more of the protocol data units being equal to a fixed one of one or more values of sequence numbers which are configurable by the network and provided to the transmitting node and the receiving node, and in response
to transmit (<NUM>) a polling bit to the receiving node in the one or more of the protocol data units for which the sequence number satisfies the predetermined criteria.