WO2018086707A1

WO2018086707A1 - Feedback based flexible transmission scheme for contention-based urllc transmission

Info

Publication number: WO2018086707A1
Application number: PCT/EP2016/077478
Authority: WO
Inventors: Zexian Li; Bikramjit Singh; Mikko Aleksi Uusitalo
Original assignee: Nokia Technologies Oy
Priority date: 2016-11-11
Filing date: 2016-11-11
Publication date: 2018-05-17

Abstract

A flexible transmission scheme for contention-based transmission. A UE is configured to perform an initial transmission of a data packet over a network, and await an ACK indicating successful transmission of the data packet. If the ACK is not received, the UE determines that the initial transmission has failed and then transmits a plurality of data packets during a re-transmission attempt. The plurality of data packets are transmitted without waiting for an ACK between the transmission of each data packet. This transmission scheme enables the UE to achieve relevant reliability requirements whilst minimising transmission latency.

Description

DESCRIPTION

Title FEEDBACK BASED FLEXIBLE TRANSMISSION SCHEME FOR CONTENTION-BASED URLLC TRANSMISSION

Field The present application relates to a method, apparatus, system and computer program and in particular but not exclusively to a method and apparatus for use in a

communication network.

Background

A communication system may be a facility that enables communication between two or more nodes or devices, such as fixed or mobile communication devices. Signals can be carried on wired or wireless carriers. An example of a cellular communication system is an architecture that is being standardized by the 3^rd Generation Partnership Project (3GPP). A recent development in this field is often referred to as the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology. E-UTRA (evolved UMTS Terrestrial Radio Access) is the air interface of 3GPP's Long Term Evolution (LTE) upgrade path for mobile networks. In LTE, base stations or access points (APs), which are referred to as enhanced Node AP (eNBs), provide wireless access within a coverage area or cell. In LTE, mobile devices, user devices or mobile stations are referred to as user equipments (UEs). Currently 3GPP is also developing the new 5G standards, known as New Radio. Such development is taking place, for example, in the Radio Access Network (RAN) working group.

In some wireless networks, user devices or UEs may contend for resource access. When collisions occur between UEs, this can decrease reliability of a system since data packets may not be successfully transmitted to their destinations.

Summary of the Invention According to a first aspect, there is provided a method comprising: causing transmission of a first data packet to a receiving entity; awaiting an acknowledgment message from the receiving entity of the first data packet transmission to the receiving entity; determining if the acknowledgment message has been received; and in response to determining that the acknowledgment message has not been received, causing transmission of a plurality of copies of the first data packet to the receiving entity, each of said plurality of copies having a different transmission diversity. In one embodiment, each of the plurality of copies of the first data packet is transmitted without determining if any acknowledgment message associated with any of the plurality of copies of the first data packet has been received at the receiving entity.

In one embodiment, it is determined that the first data packet was not successfully received at the receiving entity if a message indicating failure of transmission is received.

In one embodiment, the causing transmission of the plurality of copies of the first data packet to the receiving entity comprises causing transmission of at least some of said plurality of copies in consecutive time slots.

In one embodiment, the causing transmission of the first data packet to a receiving entity comprises causing transmission of the first data packet in a frequency band randomly selected from a set of frequency bands. In one embodiment, the causing transmission of the plurality of copies of the first data packet to the receiving entity comprises causing transmission of each copy of the first data packet in a frequency band randomly selected from a set of frequency bands.

In one embodiment, the causing transmission of a plurality of copies of the first data packet to the receiving entity comprises causing transmission of at least some of said plurality of copies in separate frequency bands.

In one embodiment, the causing transmission of a plurality of copies of the first data packet to the receiving entity comprises causing transmission of at least some of said plurality of copies via different transmission beams.

In one embodiment, the method further comprises: receiving from a network node information indicating a number of copies of the first data packet to be transmitted, wherein the step of causing transmission of the plurality of copies of the first data packet to the receiving entity consists of causing transmission of the number of copies of the first data packet to the receiving entity. According to a second aspect, there is provided a computer program product for a computer comprising software code portions for performing the steps of any of the embodiments of the first aspect, when the program is run on the computer.

According to a third aspect, there is provided an apparatus comprising: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: cause transmission of a first data packet to a receiving entity; await an acknowledgment message from the receiving entity of the first data packet transmission to the receiving entity; determine if the acknowledgment message has been received; and in response to determining that the acknowledgment message has not been received, cause transmission of a plurality of copies of the first data packet to the receiving entity, each of said plurality of copies having a different transmission diversity.

In one embodiment, the apparatus is a user equipment.

According to a fourth aspect, there is provided an apparatus comprising: means for causing transmission of a first data packet to a receiving entity; means for awaiting an acknowledgment message from the receiving entity of the first data packet transmission to the receiving entity; means for determining if the acknowledgment message has been received; and means for, in response to determining that the acknowledgment message has not been received, causing transmission of a plurality of copies of the first data packet to the receiving entity, each of said plurality of copies having a different transmission diversity. According to a fifth aspect, method comprising: determining a reliability requirement for transmissions from a transmitting entity in a wireless network, the transmissions comprising transmitting a data packet and, optionally, a plurality of copies of that data packet to a receiving entity, each of said plurality of copies having a different transmission diversity; determining, in the wireless network, a rate of failure of an initial transmission of a respective data packet to a respective receiving entity; and determining, in dependence upon the rate of failure and the reliability requirement, a number of copies of the data packet to be transmitted if said initial transmission of said respective data packet is unsuccessful. In one embodiment, the method further comprises: determining, a rate of failure of transmission of the acknowledgement messages to the transmitting entity, wherein the transmission diversity level is further determined in dependence upon the rate of failure of transmission of the acknowledgement messages.

According to a sixth aspect, there is provided a computer program product for a computer comprising software code portions for performing the steps of any of the embodiments of the fifth aspect, when the program is run on the computer.

According to a seventh aspect, apparatus comprising: at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: determine a reliability requirement for transmissions from a transmitting entity in a wireless network, the transmissions comprising transmitting a data packet and, optionally, a plurality of copies of that data packet to a receiving entity, each of said plurality of copies having a different transmission diversity; determine, in the wireless network, a rate of failure of an initial transmission of a respective data packet to a respective receiving entity; and determine, in dependence upon the rate of failure and the reliability requirement, a number of copies of the data packet to be transmitted if said initial transmission of said respective data packet is unsuccessful.

In one embodiment, the apparatus is a user equipment. According to an eighth aspect, apparatus comprising: means for determining a reliability requirement for transmissions from a transmitting entity in a wireless network, the transmissions comprising transmitting a data packet and, optionally, a plurality of copies of that data packet to a receiving entity, each of said plurality of copies having a different transmission diversity; means for determining, in the wireless network, a rate of failure of an initial transmission of a respective data packet to a respective receiving entity; and means for determining, in dependence upon the rate of failure and the reliability requirement, a number of copies of the data packet to be transmitted if said initial transmission of said respective data packet is unsuccessful. Brief Description of Drawings Embodiments will now be described, by way of example only, with reference to the accompanying Figures in which: figure 1 is a block diagram of a wireless network according to an example implementation; figure 2 shows a schematic diagram of an example mobile communication device; figure 3 shows an example transmission pattern for data packets from a plurality of UEs; figure 4 shows an example signaling diagram in the case where the initial data packet transmitted by the transmitting entity is successfully received by the network node; figure 5 shows an example signaling diagram in the case where the initial data packet transmitted by the transmitting entity is not successfully received by the network node; figure 6 shows an example of a transmission pattern according to embodiments of the application; figure 7 shows an example probability tree diagram for successful and unsuccessful transmission; figure 8 shows an example method by which a transmitting entity may transmit a data packet to a receiving entity; figure 9 shows an example method by which a network node may determine and broadcast a suitable diversity level; and figure 10 shows a schematic diagram of an example control apparatus. Detailed Description

Before explaining in detail the examples, certain general principles of a wireless communication system and mobile communication devices are briefly explained with reference to figures 1 to 2 to assist in understanding the technology underlying the described examples.

Figure 1 is a block diagram of a wireless network 100 according to an example implementation. In the wireless network 100 of FIG. 1 , user devices 131 , 132, 133 and 135, which may also be referred to as mobile stations (MSs) or user equipment (UEs), may be connected (and in communication) with a base station (BS) 134, which may also be referred to as an access point (AP), an enhanced Node B (eNB) or a network node. At least part of the functionalities of an access point (AP), base station (BS) or (e)Node B (eNB) may be also be carried out by any node, server or host which may be operably coupled to a transceiver, such as a remote radio head. BS (or AP) 134 provides wireless coverage within a cell 136, including to user devices 131 , 132, 133 and 135. Although only four user devices are shown as being connected or attached to BS 134, any number of user devices may be provided. BS 134 is also connected to a core network 150 via a S1 interface 151 . This is merely one simple example of a wireless network, and others may be used.

A user device (user terminal, user equipment (UE) or mobile station) may refer to a portable computing device that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (MS), a mobile phone, a cell phone, a smartphone, a personal digital assistant (PDA), a handset, a device using a wireless modem (alarm or measurement device, etc.), a laptop and/or touch screen computer, a tablet, a phablet, a game console, a notebook, and a multimedia device, as examples. It should be appreciated that a user device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. By way of illustrative example, the various example implementations or techniques described herein may be applied to various user devices, such as machine type communication (MTC) user devices, enhanced machine type communication (eMTC) user devices, Internet of Things (loT) user devices, and/or narrowband loT user devices. loT may refer to an ever-growing group of objects that may have Internet or network connectivity, so that these objects may send information to and receive information from other network devices. For example, many sensor type applications or devices may monitor a physical condition or a status, and may send a report to a server or other network device, e.g., when an event occurs. Machine Type Communications (MTC, or Machine to Machine communications) may, for example, be characterized by fully automatic data generation, exchange, processing and actuation among intelligent machines, with or without intervention of humans.

Also, in an example implementation, a user device or UE may be a UE/user device with ultra reliable low latency communications (URLLC) applications. A cell (or cells) may include a number of user devices connected to the cell, including user devices of different types or different categories, e.g., including the categories of MTC, NB-loT, URLLC, or other UE category.

In LTE (as an example), core network 150 may be referred to as Evolved Packet Core (EPC), which may include a mobility management entity (MME) which may handle or assist with mobility/handover of user devices between BSs, one or more gateways that may forward data and control signals between the BSs and packet data networks or the Internet, and other control functions or blocks.

The various example implementations may be applied to a wide variety of wireless technologies or wireless networks, such as LTE, LTE-A, 5G, cmWave, and/or mmWave band networks, loT, MTC, eMTC, URLLC, etc., or any other wireless network or wireless technology. These example networks or technologies are provided only as illustrative examples, and the various example implementations may be applied to any wireless technology/wireless network.

A possible UE will now be described in more detail with reference to Figure 2 showing a schematic, partially sectioned view of a UE 200. An appropriate UE may be provided by any device capable of sending and receiving radio signals. Non-limiting examples comprise a mobile station (MS) or mobile device such as a mobile phone or what is known as a 'smart phone', a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), personal data assistant (PDA) or a tablet provided with wireless communication capabilities, or any combinations of these or the like. A UE may provide, for example, communication of data for carrying communications such as voice, electronic mail (email), text message, multimedia, and so on. Users may thus be offered and provided numerous services via their communication devices. Non-limiting examples of these services comprise two-way or multi-way calls, data communication or multimedia services or simply an access to a data communications network system, such as the Internet. Users may also be provided broadcast or multicast data. Non-limiting examples of the content comprise downloads, television and radio programs, videos, advertisements, various alerts and other information. The UE 200 may receive signals over an air or radio interface 207 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In Figure 2, transceiver apparatus is designated schematically by block 206. The transceiver apparatus 206 may be provided for example by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the mobile device.

A UE is typically provided with at least one data processing entity 201 , at least one memory 202 and other possible components 203 for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The data processing, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference 204. The user may control the operation of the mobile device by means of a suitable user interface such as key pad 205, voice commands, touch sensitive screen or pad, combinations thereof or the like. A display 208, a speaker and a microphone can be also provided. Furthermore, a UE may comprise appropriate connectors (either wired or wireless) to other devices and/or for connecting external accessories, for example hands-free equipment, thereto.

The 5th Generation (5G) of wireless networks provides expansion of International Mobile Telecommunications (IMT) that go beyond those of IMT-2000 and I MT- Advanced mobile broadband (MBB) service, and also envisioning to address new services and use cases. These new services are not only for human interaction, but also a huge growth in machine-type communications (MTC) driven by e.g., factory automation and flexible process control. Another new use case is ultra reliable low latency communications (URLLC), which may require very high reliability and low latency.

According to an illustrative example, URLLC may, for example, require a reliability target or reliability requirement of 99.999 % under the radio latency bound of 1 ms. Some example targets or requirements for URLLC may include a maximum packet error rate of 10^~5, where maximum allowable radio latency, including retransmissions is down to 1 ms. These are merely some illustrative example performance targets (or requirements) and other numbers may be used. In the current LTE systems, the minimal resource unit (or Transmission Time Interval (TTI)) size is of 1 ms (e.g., where the TTI is a length of a subframe). A significant improvement in latency is possible for 5G networks, for example, with a new numerology for 5G of, for example, 0.125ms TTI size and each TTI contains (or may contain) both control and data information. According to an example implementation, one or more resource access techniques may be used to allow user devices in a cell or network to access or obtain uplink resources for uplink transmission. Two general resource allocation techniques may include scheduling- based resource access and contention-based resource access. Scheduling-based resource allocation may include a BS (or other network device) allocating or scheduling uplink resources for a user device, or for each of a plurality of user devices. The BS may send an uplink resource grant (which may also be referred to as an uplink grant) that indicates uplink resource(s) that may be used by the user device to transmit uplink data to the BS. Therefore, in the case where scheduling-based resource allocation is used, there is a 0% probability of a collision with a transmission from another user device within the same cell, because the BS has reserved or allocated this uplink resource only for the user device.

Contention-based resource allocation may include one or more user devices contending for access to a channel or wireless link, to allow the user device to transmit uplink to the BS. For example, a contention-based random access procedure may be used, e.g., where the user device may select a random access preamble index at random, and then transmit the random access preamble sequence to the BS. The BS may then transmit a random access response that includes an uplink grant. In another embodiment, the user device can transmit both preamble and data packet in the first message without requesting any UL grant. However, a collision may occur, since another user device may also have selected the same random access preamble index and transmitted the same random access preamble sequence to the BS. In such a case, two user devices may attempt to transmit on the uplink resource, which will typically cause a collision.

Reference is made to figure 3 which shows an example of a transmission pattern for data packets from seven different UEs. On one axis, the transmission time interval (TTI) in which a packet is transmitted is indicated. On the other axis, the resource block (RB) in which a data packet is transmitted is indicated. Each RB on this axis may represent transmission in a different frequency range. For example, each resource block may be 180 kHz wide. As may be seen in the figure, the packet j transmitted by UE #2 is transmitted in the same RB, and at the same TTI as the packet I is transmitted by the UE #4. A collision therefore occurs between the two packets which results in the packets failing to be transmitted to their intended destinations. Such collisions result in a reduction in the reliability of transmissions.

According to an example implementation, one way in which the reliability of contention- based transmissions can be improved is through the use of transmission diversity, in which the BS may instruct a user device to transmit each data packet during each of X consecutive or non-consecutive time periods (e.g., transmit the data/data packet in each of X subframes) - where X may be 1 , 2, 3, 4, 5, or other number - or in different frequency bands. In some cases of transmission diversity, each data packet may be transmitted in the same time period but in a different frequency band. In some cases of transmission diversity, each data packet may be transmitted in the same frequency band but in different time periods. In some cases, the time periods and the frequency bands used for transmission may differ whilst some may be the same. In some cases of transmission diversity, the same data packet can be transmitted over multiple antenna beams, i.e. spatial diversity. Thus, transmission diversity includes transmission of data a plurality of times, with a transmission of the data or data packet during each of X successive subframes or successive transmission opportunities, for example. Transmission diversity (or a transmission diversity level, referred to above as the number X) may be determined or selected by the BS, e.g., based on channel conditions of a wireless link between the user device and the BS and a load on (or usage of) contention resources. For example, a higher transmission diversity level (meaning a higher number of

transmissions/retransmissions of the data or a data packet over X periods or subframes or transmission opportunities) may be used for a lower channel quality and/or higher interference (e.g., for a lower signal-to-interference plus noise ratio or SINR, or for a lower received signal strength or RSSI). Thus, more transmissions of a data packet may be used to increase the probability that the data (or data packet) will be successfully received by the BS. Transmission diversity may involve or include the transmission of a same data/data packet a plurality of times, or may include the transmission of different redundancy versions of a packet or data, which may be combined at the receiver. Thus, transmission diversity may include a user device transmitting a plurality of instances of data or data packet (e.g., same data or different redundancy versions of the data) based on the transmission diversity level. Thus, for example, if 1 resource block is required to transmit a data packet, then 3 resource blocks (RBs) will be required to transmit the data packet during each of three different subframes, for a transmission diversity level = 3 for a user device. According to an example implementation, for contention-based access, a different transmission diversity level may be used by each user device. In some embodiments, the same transmission diversity level may be used by each user device. The transmission diversity may be dependent upon network conditions. Thus, while contention-based access cannot offer completely collision-free communications, the reliability of contention-based communication can be improved by transmission diversity (or by transmitting the data or data packet in each of a plurality of time periods, which may be consecutive or non-consecutive time periods).

Also, to improve reliability of uplink communications, the BS may allocate or schedule a resource (e.g., a resource block or a plurality of resource blocks) for each of a plurality of user devices in a cell, e.g., if there are sufficient resources to be allocated to each user device. As noted, a cell may include many different types of categories of user devices/UEs, e.g., loT, MTC, eMTC, URLLC. In an illustrative example implementation, it is desirable, and in fact, may be required in some cases, to meet a specific reliability target (e.g., reliability of 99.999%, or other reliability target) for a category of user devices, such as for URLLC user devices in a cell. On the other hand, reliability requirements for other categories or types of user devices (e.g., loT, MTC, ...) may be significantly less demanding than for the URLLC user devices. According to an example implementation, a user device/UE may have a plurality of applications and may have a plurality of service flows (e.g., a service flow(s) for each application on the user device/UE). A user device may have one or more URLLC service flows, and may have one or more other type/category of service flows. Thus, according to an example implementation, user devices with a URLLC application, a URLLC service flow or URLLC services may be referred to as a URLLC user device/UE. The transmitting entity (which may comprise a UE such as that described above with reference to figure 2), may determine whether or not a data packet which it transmitted has been successfully received at the receiving entity (which may also comprise a UE such as that described above with reference to figure 2) , by using a feedback technique (e.g. the HARQ technique). Using such a feedback technique, when the data packet has been successfully received at the receiving entity, the receiving entity is configured to transmit an acknowledgement message (ACK) to the transmitting entity. An ACK indicates that the data packet has been successfully received at the receiving entity. If the data packet is not successfully received, the ACK is not transmitted and the transmitting entity may determine after a certain period of time that the transmission has failed. In another embodiment, if the data packet is not successfully received at the receiving entity, the receiving entity may transmit a negative acknowledgment message (NACK) to the transmitting entity and the transmitting entity may determine from the NACK that the transmission has failed.

When transmitting entities transmit data packets in contention mode and the transmission of those data packet fails due to collision, one possibility could be to re-transmit the data packets using scheduling-based resource allocation. However, the BS may be unable to determine the identity of the transmitting entities which transmitted the collided data packets and therefore may be unable to grant scheduled access to those transmitting entities during the next re-transmission.

Another solution when a transmitting entity determines that a data packet that it transmitted in contention mode has failed to be received could be to re-transmit that data packet and await the receipt of the ACK message indicating that the re-transmitted data was successfully received. If t e transmitting entity does not receive the ACK (because the re-transmitted data packet is not successfully received), the transmitting entity may retransmit the data packet again and await an ACK message. The transmitting entity may continue this process until an ACK message is received, thereby indicating successful transmission of the data packet. Although this solution has the advantage that it ensures reliability of transmission, it has the disadvantage of increasing the latency, since after failed transmission, the transmitting entity must wait a certain period of time for an ACK message before performing another re-transmission. There is therefore a need for a solution to the problem of collided data packets that meets both the reliability and latency requirements.

According to embodiments of the application, the transmitting entity is configured to transmit a data packet and determine whether that data packet has been successfully received at the receiving entity. The transmitting entity may await an ACK from the receiving entity. If the transmitting entity determines that the transmission has failed - because, for example, the ACK is not received within a predefined time period or a NACK is received - the transmitting entity may then transmit a plurality of copies of the data packet to the receiving entity. Following the transmission of the plurality of copies of the data packet, the transmitting entity may not await the receipt of the ACK for the sent plurality of copies of the data packet and may not perform any further retransmission regardless of whether or not the plurality of copies of the data packet is successfully received at the receiving entity. The transmission of the plurality of copies of the data packet may comprise transmitting a plurality of copies of the data packet to the receiving entity. Each copy is transmitted with a different transmission diversity. For example, at least some of the copies may be transmitted with different spatial diversity (i.e. along different transmission paths by different antennae). At least some of the copies, may be transmitted with different time diversity (i.e. in different time slots or TTI). At least of the copies may be transmitted with different frequency diversity (i.e. in different frequency bands). By transmitting a plurality of copies of the data packet without waiting for ACKs to be received for each data packet, the latency of the transmission process may be reduced. Hence, embodiments are able to meet both the reliability and latency requirements. Furthermore, according to embodiments of the application, a network node (e.g. a base station) may be configured to transmit to one or more transmitting entities an indication of the number of copies of a data packet that should be transmitting during re-transmission when a transmitting entity has determined that the transmission has failed. The transmitting entity may determine this number by determining the number of data packets that must be transmitted in order to satisfy the reliability requirements.

Reference is made to figure 4, which shows an example signaling diagram 400 in the case where the initial data packet transmitted by the transmitting entity 420 is successfully received by the network node 410. The network node 410 is configured to broadcast the diversity level 430, which indicates to the transmitting entity 420, the number of data packets that should be transmitted during a re-transmission if the initial transmission fails. The transmitting entity is configured to transmit an initial data packet 440 to a receiving entity through the network node 410. In this case, the data packet 440 is successfully received at the receiving entity and so the receiving entity transmits an ACK 450, which is received by the transmitting entity. Since the transmitting entity receives the ACK, it determines that the data packet 440 has been successfully received at the receiving entity, and it therefore does not perform any re-transmissions for the data packet. In this example, the data packet 440 is transmitted through the network node 410 to the receiving entity. However, the data packet 440 and the ACK 450 may be transmitted through a network node 410 different to that which broadcasts the diversity level. In one embodiment, the network node 410 may be the receiving entity to which the data packet is transmitted.

In some embodiments, the transmission of the data packet may comprise transmitting data information directly with minimal control information alongside for a random packet transmission. This can be very useful for URLLC use case and perhaps conserves lot of TTIs by sending data at first rather than control information alone. Besides, the packet error rate (or collision rate) must be under the reliability levels for URLLC.

Reference is made to figure 5, which shows an example signaling diagram 500 in the case where the initial data packet 540 transmitted by the transmitting entity 420 is not successfully received by the network node 410. As in the example of figure 4, the network node 410 is configured to broadcast the diversity level 530, which indicates to the transmitting entity 420, the number of data packets that should be transmitted during a retransmission if the initial transmission fails. The transmitting entity is configured to transmit an initial data packet 540 to a receiving entity through the network node 410. In this example, the data packet 540 is not successfully received at the receiving entity, and so no ACK is received at the transmitting entity 420. In one embodiment, the transmitting entity 420 may determine that the transmission was unsuccessful after a certain time period has expired with no ACK being received. In one embodiment, if the network node 410 is unable to detect or decode the data packet 540, the transmitting entity determines that the transmission was unsuccessful after a certain time period has expired with no ACK being received. Alternatively or additionally, the transmitting entity may determine that the transmitted data packet 540 was unsuccessfully received when a corresponding NACK is received. In one embodiment, if the network node 410 is able to determine the identity of the transmitting entity, the transmitting entity 420 determines that the transmitted data packet 540 was unsuccessfully received when a corresponding NACK is received.

In response to determining that the data packet 540 was not successfully received at the receiving entity, the transmitting entity 420 is configured to transmit one or more copies 560 of the initial data packet 540 to the receiving entity. The number of copies 560 transmitted by the transmitting entity 420 may be determined by the diversity level 530 that was broadcast by the network node 410. The transmitting entity may transmit a plurality of copies 560, with each copy being transmitted at a different time. Each copy may be transmitted in a different resource, for example, in a different transmission time interval (TTI). The different TTI may be consecutive to one another. The transmission at each TTI may occur at a frequency that is randomly selected for each TTI from a set of available transmission frequencies. Alternatively or additionally, the transmitting entity 420 may transmit the plurality of copies 560 at different frequencies. One or more of the copies 560 may be transmitted at the same TTI but at different frequencies. Alternatively or additionally, the plurality of copies 560 may transmitted at different points in the spatial domain. For example, the transmitting entity 420 may have a plurality of transmission beams, which can be used for the transmission of different data packets. Although the examples given in figures 4 and 5 show the data packets being transmitted by the UE 420 to the network node 410, it should be understood that in other

embodiments the roles of the network node and the UE could be reversed. In some embodiments, the network node 410 may transmit a data packet to a UE 420, and await the receipt of an ACK indicating successful transmission. If the ACK is not received by the network node 410 from the UE 420, then the network node is configured to transmit a plurality of copies of the data packet to the UE 420 at a determined diversity level, wherein each copy has a different transmission diversity.

Reference is made to figure 6, which shows an example of a transmission pattern 600 that may be implemented in embodiments of the application. At resource block 610, a first transmitting entity (UE #2) transmits a first data packet (j), and second transmitting entity (UE #4) transmits a second data packet (I). Since these data packets are transmitted in the same frequency range and in the same TTI, a collision occurs and the transmission of the data packets to their respective destinations fails.

During the following TTI 620, no ACKs are received at either the first transmitting entity or the second transmitting entity. Therefore, the first transmitting entity and the second transmitting entity determine that the transmission has failed and that re-transmission should be commenced.

At the resource block 630, the first transmitting entity transmits a first copy of the first data packet, and the second transmitting entity transmits a first copy of the second data packet. Since, as before, these data packets are transmitted in the same frequency range and in the same TTI, a collision occurs and the transmission of the data packets to their respective destinations fails.

At the resource block 640, the first transmitting entity transmits a second copy of the first data packet. At resource block 650, the second transmitting entity transmits a second copy of the second data packet. Although, in this case, the second copy of the first data packet and the second copy of the second data packet are transmitted at the same transmission time interval, they are transmitted at different frequencies and hence in different resource blocks. Hence, there is no collision between the second copy of the first data packet and the second copy of the second data packet and both of the data packets are successfully transmitted to their destinations.

According to embodiments, the network node may transmit the diversity level (i.e. the number of data packets that should be transmitted in the re-transmission) to one or more transmitting entities periodically. The rate of successful transmission of data packets may be monitored at the network node, and the network node may be configured to use this rate to determine a suitable diversity level such that the reliability requirements for packet transmission are met. The network node may record the number of packets received in order to determine the rate of successful transmission. The network node may receive an indication of successful transmission rates from transmitting entities or from receiving entities. The diversity level may be determined in dependence upon at least one of: the URLLC target, the number of failed initial transmissions from at least one transmitting entity, the number of failed transmission of ACKs transmitted to the at least one transmitting entity, and the available resources. Since the traffic load in the network node can change with time, the diversity level may be calculated and broadcasted to the transmitting entities at regular intervals. Alternatively or additionally, the diversity level may be calculated and broadcast to the transmitting entities in response to a change in conditions in the network. The broadcasting of the diversity level may happen when the amount of change in a particular parameter describing the network conditions exceeds a threshold. For example, the diversity level may be broadcast in response to a change in the number of data packets being transmitted by transmitting entities in the network. In another example, the diversity level may be broadcast to the at least one transmitting entity in response to a change in the rate of failure of initial transmissions of data packets from the at least one data packet.

An explanation of how the diversity level may be calculated according to embodiments will now be given. The communication system (e.g. LTE system) may administer services to N transmitting/receiving entities (e.g. UEs) through contention-based access. The transmitting/receiving entities may be configured to transmit and receive data packets in a bandwidth consisting of K resource blocks (RBs). Then the smallest resource unit available to a transmitting/receiving entity is a RB during a particular TTI. Each RB that is used by a transmitting entity for transmission of data packet may use a bandwidth of 1 RB for transmission and the transmission may take place during one TTI.

When a transmitting entity transmits the initial data packet, only one data packet is transmitted and then the transmitting entity awaits an ACK. In this case, the transmission diversity level/repetition is 1 . The collision probability Pci for this initial transmission is given by

where μ is the average rate of arrival of data packets at the network node.

When a collision occurs, copies of the initial data packets are transmitted Γ times.

Therefore, the average rate of arrival of data packets at the network node becomes μ→ μ + ΓμΡ_ε1 (2)

The probability of a collision occurring for each of the Γ copies of the data packet transmitted during re-transmission is given by

As noted above, a reliability target may be set. URLLC may, for example, have a reliability target or reliability requirement wherein 99.999 % of data packets reach their destination, even if retransmission is required. Taking P^^se to be the probability of at least one of the initial data packets and any copies of the initial data packet that are sent in retransmission of reaching the receiving entity, P^ ^Se is related to P_clP_c2 as follows:

(4)

Reference is made to figure 7, which shows how net collision probability (i.e. the probability that the initial data packet and the re-transmitted copies of the data packet will collide and therefore fail to be transmitted to the receiving entity) and the net success probability (i.e. the probability that at least one of the initial data packet and the retransmitted copies of the data packet will be successfully transmitted to the receiving entity) may be determined. As shown, a failure of any of the data packets to reach the receiving entity only occurs if both of the transmissions (i.e. the initial transmission and the re-transmission) fail. Therefore, the net collision probability is given by P_clP_c2 - On the other hand, a successfully transmission can occur if either of the transmissions (i.e. the initial transmission and the re-transmission) succeed. The net success probability is given y P_si + PciPci - Examples of how the above analysis can be used to determine a suitable transmission diversity level/ repetition may now be given. For the first analysis, the case is considered where the transmitting entity does not await an ACK from the receiving entity before transmitting the next data packet, and no re-transmission is performed if the initial transmission fails. In the second analysis below, the case is considered where - in accordance with embodiments of the application - the transmitting entity is configured to transmit an initial data packet, determine whether or not the initial data packet was successfully received at the receiving entity, and if the data packet was not successfully received, transmit one or more copies of the data packet. By comparing the two following analysis it may be seen how embodiments of the application may have advantages over the alternative method.

For the first analysis, if the TTI length is 0.125ms, i.e. there are 8000 TTIs in one second, and the average inter-arrival time is 0.5 seconds, the arrival rate is given by μ =

1/(8000 x 0.5). Taking there to be 10 transmitting/receiving entities in the system (N=10), the bandwidth for transmitting data packets is dividing into 6 Resource blocks (K= 6RBs), and the P^ ^Be = 99.999% (i.e. the net error or net collision probability is p_c ^target = i - P_rel ⁸ = 0.00001). Here feedback error (i.e. failure in t e transmission of the ACKs) is not considered. However with feedback error incorporated, more resources for the retransmission would be needed. If a transmitting entity transmits an initial data packet but is configured to not perform any re-transmission if the transmission of the initial data packet fails (i.e. Γ = 0) then the estimated arrival rate is μ→ μ, and using equation (1 ) the net collision probability is obtained at P_c = 1.04 x 10^~4, which is far more than p_c ^target which equals 10^~5.

Table 1 gives figures for the net collision probability when a plurality of data packets are transmitted as an initial transmission. In this case, the transmitting entity does not await an ACK from the receiving entity before transmitting the next data packet, and no retransmission is performed if the initial transmission fails. The table shows the net collision probability when using different values for the transmission diversity level/repetition. These figures may be calculated using equation (3).

Table 1

It may be understood from table 1 that for the net collision probability to be less than 10^~5, as required by the target value, the transmission diversity level must be at least 4.

However, using such a value for the transmission diversity level results in an overall traffic

40

arrival rate of Λ/Γμ = = 0.01.

^ 8000 x 0.5

For the second analysis, if instead of transmitting a plurality of data packets in the initial transmission, as in accordance with embodiments of the application - the transmitting entity is configured to transmit an initial data packet, determine whether or not the initial data packet was successfully received at the receiving entity, and if the data packet was not successfully received, transmit one or more copies of the data packet - it is determined using equations (1 ) - (4) that the transmission repetition need only be Γ = 1 , i.e. only one copy of the data packet need be transmitted during re-transmission for the net collision probability to be less than the target of p_c ^target = io^~5. In the case that Γ = 1 , P_cl = 37.5031 x 10^"5 and hence overall traffic arrival rate is Νμ(1 + FP_cl) =

10.0038/(8000 x 0.5). This value is significantly lower than the value of the arrival rate of 40/(8000 x 0.5), which was calculated in the previous example where a repetition of 4 was used for the initial transmission of data packets. Furthermore, transmission latency is 1 TTI for non-collided UEs, and 3 TTIs for collided transmitting entities. Whereas, if transmitting entities transmit with repetition order 4 in first transmission (case with no re- transmission), then every transmitting entity has latency is 1 -4 TTI(s). Therefore, by not using feedback control for the initial transmission of the data packet, the latency is likely to be increased.

Hence by using feedback control and transmitting one or data packets in retransmission, the latency performance is improved and the network capacity is increased. This permits the network to accommodate more transmitting/receiving entities. The network is able to continue to accommodate more transmitting/receiving entities providing the following inequality holds

Γ(1 - P_cl) < 1

(5) In another example, the average inter-arrival time may be 0.05 seconds. If a transmitting entity is configured to initially transmit a plurality of copies of a data packet without requiring feedback (i.e. receipt of an ACK) between each transmission of the plurality of initial data packets, then to have collision probability under P_c ^target, the transmitting entity must transmit with a repetition of Γ = 6. The latency in this case is 1 -6 TTI(s) for all transmitting entities. However, with a provision of feedback control in first transmission, the transmission repetition order reduces to Γ = 2 during the re-transmission. Since the latency for non-collided transmitting entities is 1 TTI, whereas for collided UEs is 3-4 TTIs, the latency is likely to be reduced in comparison to the case of no feedback control in which the latency is 1 -6 TTI(s) for all transmitting entities.

In embodiments of the application a suitable range of values for the transmission diversity level may be in the range 2 to 4. However, this is an example only; the range of values for the transmission diversity level may be greater than or lesser than the values for this range. In different cases, the latency requirement for the transmission of data may be different. The transmission diversity level may be dependent upon the latency

requirement. Therefore, different latency requirements may result in different ranges for the transmission diversity level.

As explained above, therefore, in some embodiments, the transmission diversity level may be vary in dependence upon different parameters, such as the rate of detected rate of successful transmission of traffic. In other embodiments, however, the transmission diversity level may be fixed. The transmission diversity level may be fixed for a particular type of traffic, but may vary between different types of traffic. The transmission diversity level may be fixed for a particular values in a set of one or more parameters, but may vary for different values for those parameters.

In some embodiments, the network node may be configured to increase the number of resource blocks available in the bandwidth for transmission so as to reduce the collision rate. This may be achieved by reducing the frequency range/bandwidth of each resource block. It may also be achieved by increasing the size of the total available bandwidth for transmission.

Reference is made to figure 8, which shows a method 800 according to embodiments of the application, but which a transmitting entity may transmit a data packet to a receiving entity. It would be understood by the person skilled in the art that not all of these steps are essential to the invention, and that some are optional and may be omitted in

embodiments.

At S810, the transmitting entity is configured to transmit the data packet to the receiving entity. The transmitting entity must then determine whether or not the data packet was successfully received at the receiving entity. This may be achieved by S820 and S830.

At S820, the transmitting entity waits for an acknowledgement message from the receiving entity, indicating that the transmitted data packet has been successfully received at the receiving entity. In some embodiments, the transmitting entity may not transmit any further data packet until the acknowledgment message has been received.

At S830, it is determined whether or not the acknowledgement message has been received. If the acknowledgment message has been received, the method ends since the data packet has been successfully received at the receiving entity and there is no need to perform any re-transmissions. If the acknowledgment message is not received, the method proceeds to S840.

At S840, the transmitting entity is configured to perform re-transmission of the data packet. This comprises re-transmitting a plurality of copies of the data packet to the receiving entity. The number of data packets transmitted may be determined by the diversity level, which may have been received at the transmitting entity from a network node. Reference is made to figure 9, which shows a method 900 in accordance with

embodiments of the application by which a network node may determine a suitable number of data packets (i.e. diversity level) to be transmitted during the re-transmission carried out by the transmitting entity. It would be understood by the person skilled in the art that not all of these steps are essential to the invention, and that some are optional and may be omitted in embodiments.

At S910, the network node obtains the various parameters that may be used by the network node to determine a suitable diversity level are gathered. These parameters may include at least one of: the rate of successful transmission of data packets in the first attempt, URLLC inputs, packet arrival rates, the number of transmitting entities in the system for which re-transmission is carried out, the length of a time slot for transmission of a data packet (e.g. TTI length), the number of frequency bands (i.e. number of RBs) that may be selected for transmission of a data packet, the resource in the network, history information.

At S920, the network node may use the gathered parameters to determine a suitable number of copies of the data packet that should be transmitted during the re-transmission by a transmitting entity in order to meet the reliability and latency requirements. This number may be determined using the equations (1 ) - (4) given above.

At S930, the network node is configured to transmit the determined diversity level to one or more transmitting entities which may then transmit the indicated number of data packets in the re-transmission.

At S940, an interval of time may elapse before the method is repeated. The method may be repeated so as to take into account changes in the network conditions, which may alter the diversity level necessary to meet the reliability and latency requirements. The network node may broadcast updated diversity level information in response to, for example, an increased rate of collision between data packets or an increased number of transmitting entities in the network.

It is noted that whilst embodiments have been described in relation to one example of a standalone LTE network, similar principles maybe applied in relation to other examples of standalone 3G, LTE or 5G networks. It should be noted that other embodiments may be based on other cellular technology other than LTE or on variants of LTE. Therefore, although certain embodiments were described above by way of example with reference to certain example architectures for wireless networks, technologies and standards, embodiments may be applied to any other suitable forms of communication systems than those illustrated and described herein.

It is also noted herein that while the above describes example embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

The method may additionally be implemented in a control apparatus as shown in Figure 10. The method may be implemented in a single processor 201 or control apparatus or across more than one processor or control apparatus. Figure 10 shows an example of a control apparatus 1000 for a communication system, for example to be coupled to and/or for controlling a station of an access system, such as a RAN node, e.g. a base station, (e) node B, a central unit of a cloud architecture or a node of a core network such as an MME or S-GW, a scheduling entity such as a spectrum management entity, or a server or host. The control apparatus may be integrated with or external to a node or module of a core network or RAN. In some embodiments, base stations comprise a separate control apparatus unit or module. In other embodiments, the control apparatus can be another network element such as a radio network controller or a spectrum controller. In some embodiments, each base station may have such a control apparatus as well as a control apparatus being provided in a radio network controller. The control apparatus 1000 can be arranged to provide control on communications in the service area of the system. The control apparatus 1000 comprises at least one memory 1010, at least one data processing unit 1020, 1030 and an input/output interface 1040. Via the interface the control apparatus can be coupled to a receiver and a transmitter of the base station. The receiver and/or the transmitter may be implemented as a radio front end or a remote radio head. For example, the control apparatus 1000 or processor 201 can be configured to execute an appropriate software code to provide the control functions. Control functions may comprise a method comprising: causing transmission of a first data packet to a receiving entity; awaiting an acknowledgment message from the receiving entity of the first data packet transmission to the receiving entity; determining if the acknowledgment message has been received; and in response to determining that the acknowledgment message has not been received, causing transmission of a plurality of copies of the first data packet to the receiving entity, each of said plurality of copies having a different transmission diversity. Alternatively, or in addition, control functions may comprise a method comprising:

determining a reliability requirement for transmissions from a transmitting entity in a wireless network, the transmissions comprising transmitting a data packet and, optionally, a plurality of copies of that data packet to a receiving entity, each of said plurality of copies having a different transmission diversity; determining, in the wireless network, a rate of failure of an initial transmission of a respective data packet to a respective receiving entity; and determining, in dependence upon the rate of failure and the reliability requirement, a number of copies of the data packet to be transmitted if said initial transmission of said respective data packet is unsuccessful.

It should be understood that the apparatuses may comprise or be coupled to other units or modules etc., such as radio parts or radio heads, used in or for transmission and/or reception. Although the apparatuses have been described as one entity, different modules and memory may be implemented in one or more physical or logical entities.

In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The embodiments of this invention may be implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware. Computer software or program, also called program product, including software routines, applets and/or macros, may be stored in any apparatus-readable data storage medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computer- executable components which, when the program is run, are configured to carry out embodiments. The one or more computer-executable components may be at least one software code or portions of it.

Further in this regard it should be noted that any blocks of the logic flow as in the Figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The physical media is a non-transitory media.

The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may comprise one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), FPGA, gate level circuits and processors based on multi core processor architecture, as non-limiting examples.

Embodiments of the inventions may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

The foregoing description has provided by way of non-limiting examples a full and informative description of the exemplary embodiment of this invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention as defined in the appended claims. Indeed there is a further embodiment comprising a combination of one or more embodiments with any of the other embodiments previously discussed.

Claims

Claims 1 . A method comprising:

causing transmission of a first data packet to a receiving entity;

awaiting an acknowledgment message from the receiving entity of the first data packet transmission to the receiving entity;

determining if the acknowledgment message has been received; and

in response to determining that the acknowledgment message has not been received, causing transmission of a plurality of copies of the first data packet to the receiving entity, each of said plurality of copies having a different transmission diversity.

2. A method as claimed in claim 1 , wherein each of the plurality of copies of the first data packet is transmitted without determining if any acknowledgment message associated with any of the plurality of copies of the first data packet has been received at the receiving entity.

3. A method as claimed in claim 1 or 2, wherein it is determined that the first data packet was not successfully received at the receiving entity if a message indicating failure of transmission is received.

4. A method as claimed in any preceding claim, wherein the causing transmission of the plurality of copies of the first data packet to the receiving entity comprises causing transmission of at least some of said plurality of copies in consecutive time slots.

5. A method as claimed in any preceding claim, wherein the causing transmission of the first data packet to a receiving entity comprises causing transmission of the first data packet in a frequency band randomly selected from a set of frequency bands.

6. A method as claimed in any preceding claim, wherein the causing transmission of the plurality of copies of the first data packet to the receiving entity comprises causing transmission of each copy of the first data packet in a frequency band randomly selected from a set of frequency bands.

7. A method as claimed in any preceding claim, wherein the causing transmission of a plurality of copies of the first data packet to the receiving entity comprises causing transmission of at least some of said plurality of copies in separate frequency bands.

8. A method as claimed in any preceding claim, wherein the causing transmission of a plurality of copies of the first data packet to the receiving entity comprises causing transmission of at least some of said plurality of copies via different transmission beams.

9. A method as claimed in any preceding claim, further comprising:

receiving from a network node information indicating a number of copies of the first data packet to be transmitted, wherein the step of causing transmission of the plurality of copies of the first data packet to the receiving entity consists of causing transmission of the number of copies of the first data packet to the receiving entity.

10. A computer program product for a computer, comprising software code portions for performing the steps of any of claims 1 to 9, when the program is run on the computer.

1 1 . An apparatus comprising:

at least one processor and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to:

cause transmission of a first data packet to a receiving entity;

await an acknowledgment message from the receiving entity of the first data packet transmission to the receiving entity;

determine if the acknowledgment message has been received; and

in response to determining that the acknowledgment message has not been received, cause transmission of a plurality of copies of the first data packet to the receiving entity, each of said plurality of copies having a different transmission diversity.

12. A method comprising:

determining a reliability requirement for transmissions from a transmitting entity in a wireless network, the transmissions comprising transmitting a data packet and, optionally, a plurality of copies of that data packet to a receiving entity, each of said plurality of copies having a different transmission diversity;

determining, in the wireless network, a rate of failure of an initial transmission of a respective data packet to a respective receiving entity; and

determining, in dependence upon the rate of failure and the reliability requirement, a number of copies of the data packet to be transmitted if said initial transmission of said respective data packet is unsuccessful.

13. A method as claimed in claim 12, further comprising: determining, a rate of failure of transmission of the acknowledgement messages to the transmitting entity,

wherein the transmission diversity level is further determined in dependence upon the rate of failure of transmission of the acknowledgement messages.

14. A computer program product for a computer, comprising software code portions for performing the steps of either of claims 12 or 13, when the program is run on the computer.

15. An apparatus comprising:

determine a reliability requirement for transmissions from a transmitting entity in a wireless network, the transmissions comprising transmitting a data packet and, optionally, a plurality of copies of that data packet to a receiving entity, each of said plurality of copies having a different transmission diversity;

determine, in the wireless network, a rate of failure of an initial transmission of a respective data packet to a respective receiving entity; and

determine, in dependence upon the rate of failure and the reliability requirement, a number of copies of the data packet to be transmitted if said initial transmission of said respective data packet is unsuccessful.