Patent Description:
The invention further relates to a method for reliable low latency communication.

The invention also relates to a computer program product enabling a computer system to perform such method.

<NUM> cellular communication technology aims to support industrial applications among many other vertical industries. One of the key requirements of the industrial application is to provide ultra-reliable low-latency communications (URLLC) between different sensors and actuators in the factory. However, high reliability and low latency are often difficult to achieve simultaneously. High reliability is usually achieved through introducing redundancy in space (e.g. antenna diversity or multiple radio links), time (e.g. repetitions or retransmissions) and code (e.g. source/channel coding) domain, which results in extra latency and overheads in the wireless communication system. Low latency could be achieved by transmitting whenever data is available. However, wireless systems typically use shared radio resources and therefore due to collisions and/or interference the communication reliability cannot be guaranteed.

"<NPL>, discloses recent 3GPP improvements for low latency in Release <NUM> for <NUM> (NR). These improvements include shorter time slots than <NUM> (e.g. mini time-slots of <NUM>), reducing the HARQ round trip time for the retransmissions, pre-emptive resource allocation when multiplexing eMBB and URLLC data. These improvements are addressing the user plane data transfer when the UE is in connected mode and communicating with the gNB. <NPL>" represents an example of the prior art.

However, use of the above improvements when there are no dedicated radio resources given to the terminal for uplink transmission does not result in a low latency and high reliability for the high demands of certain industrial applications.

It is a first object of the invention to provide a device for transmitting a preamble, and data which can be used to provide ultra-reliable low-latency communications to highly demanding applications.

It is a second object of the invention to provide a method of transmitting a preamble and data, which can be used to provide ultra-reliable low-latency communications to highly demanding applications.

It is a third object of the invention to provide a computer program.

The inventors have recognized that device-to-device (D2D) communication has the potential to address the low-latency and high-reliability requirements of certain, e.g. industrial, applications. The low-latency is achieved as the D2D approach allows for direct communications between a group of client devices (UEs) without always going through the base station (e.g. eNB or gNB).

The state of the art D2D communication techniques as currently standardized by 3GPP are not designed to support industrial applications requiring URLLC between the UEs. The inventors have therefore come up with improvements to the currently standardized D2D communication techniques. By using multiple, separate frequency resources to transmit copies or portions of data and by letting client devices transmit an URLLC preamble just before transmitting their URLLC data and letting other devices (e.g. the base station, regular client devices and D2D enabled devices that do not require URLLC data transmission) refrain from transmitting during this time interval, the reliability requirements of highly demanding applications may be met without increasing latency. In contrast, typical time domain packet retransmissions like ARQ and HARQ would increase the latency such that it would no longer meet the latency requirements of highly demanding applications. If the copies or portions are coded, the copy or portion transmitted in the first frequency resource may be coded differently than the copy or portion transmitted in the second frequency resource. The invention may also be used for other communication over shared resources than D2D communication.

According to the the present invention, said preamble indicates that data transmitted in said second time interval requires reliable and urgent reception by a recipient of said data. For example, the preamble may be an URLLC flag and/or may be transmitted in a time slot reserved specifically for URLLC preambles. This may be standardized, e.g. in a 3GPP standard. In an embodiment, said first frequency resource is allocated to device-to-device communication and said second frequency resource is not allocated to device-to-device communication. Currently, UEs in LTE utilize (uplink) frequency resources specifically dedicated/allocated to D2D communication. To achieve reliable and low latency communication, frequency resources not dedicated/allocated to D2D communication may be used.

Said at least one processor may be configured to classify said data in one of a plurality of classes and use said at least one transmitter to transmit said preamble in dependence on said determined class of said data. Although certain devices may be configured to transmit only URLLC data, many devices will have both URLLC data and non-URLLC data and must only transmit the preamble before transmitting URLLC data in order to achieve the latency and reliability requirements.

Said time intervals may each comprise a first period for transmitting data, a second period for transmitting said preamble following said first period and a guard period following said second period. Thus, the invention may be implemented by using a small portion of the normal transmission time interval (e.g. TTI) for transmitting the preamble. The guard period helps the other devices process the preamble and decide whether to transmit or not in the next transmission time interval. Preferably, said second period consumes <NUM>% or less of said time intervals.

Said preamble may identify said first frequency resource and said second frequency resource. This allows the other devices (receiving the preamble) to still transmit their data in the second time interval in a different frequency resource. The preamble may also identify further frequency resources used by the device to transmit further copies or portions of the data.

Said at least one processor may be configured to use said at least one transmitter to transmit a third copy or third portion of said data in a third frequency resource in said second time interval. It is beneficial to let the amount of duplication, portion splitting and/or coding overhead depend on the network conditions and communications link's reliability requirements. In this case, it may be determined that an additional frequency resource is desired.

Preferably, said preamble consumes <NUM>% or less of said first time interval. This is typically sufficient to communicate the intent to transmit URLLC data and leaves sufficient time to transmit the data (payload) itself. Other systems and/or devices may transmit an URLLC preamble the second, third and/or fourth intervals. In this case, these preambles also preferably consume <NUM>% or less of the corresponding time interval.

Said first frequency resource and/or said third frequency resource may normally be dedicated to transmissions from client devices to base station and said second frequency resource may be normally dedicated to transmissions from base station to client devices. Alternatively, said first frequency resource and said second frequency resource may normally be dedicated to transmissions from client devices to base station. Currently, UEs in LTE utilize only uplink frequency resources for D2D communication between each other. Use of these D2D uplink frequency resources for the URLLC data transmission (which may require duplicate transmission or transmission of data portions) stays close to the current standard, for example. Additional uplink frequency resources, e.g. uplink frequency resources not reserved for D2D communication, may be used for the URLLC transmission(s), but when the base station refrains from transmitting, downlink frequency resources could be used as well.

According to the invention, the second object is realized in that the method of transmitting a preamble comprises transmitting a preamble in a first time interval in a first frequency resource, said preamble indicating that data transmitted in a second time interval requires reliable and urgent reception by a recipient of said data, transmitting a first portion or a first copy of data in said first frequency resource in a second time interval, said second time interval succeeding said first time interval, and transmitting a second portion or second copy of said data in a second frequency resource in said second time interval, said second frequency resource being separate from said first frequency resource.

Moreover, a computer program for carrying out the method described herein, as well as a non-transitory computer readable storage-medium storing the computer program are provided.

A non-transitory computer-readable storage medium stores at least a first software code portion, the first software code portion, when executed or processed by a computer, being configured to perform executable operations comprising: transmitting a preamble in a first time interval in a first frequency resource, transmitting a first portion or a first copy of data in said first frequency resource in a second time interval, said second time interval succeeding said first time interval, and transmitting a second portion or second copy of said data in a second frequency resource in said second time interval, said second frequency resource being separate from said first frequency resource.

A non-transitory computer-readable storage medium stores at least a second software code portion, the second software code portion, when executed or processed by a computer, being configured to perform executable operations comprising: listening for transmission of a preamble, transmitting data in a second time interval succeeding a first time interval upon determining that said preamble was not received in said first time interval, and refraining from transmitting data in said second time interval upon determining that said preamble was received in said first time interval.

Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system.

<FIG> depicts the system and the device of the disclosure. A sensor <NUM> (S1), a sensor <NUM> (S2), an actuator <NUM> (A1), an actuator <NUM> (A2) and a mobile device <NUM> (UE1) are located in a cell covered by a base station <NUM>, e.g. an eNB or a gNB. The sensors <NUM> and <NUM>, the actuators <NUM> and <NUM>, and the mobile device <NUM> are all referred to as User Equipment (UEs) in most telecommunication standards and in this description. In an example scenario, sensor <NUM> transmits data to actuator <NUM>, sensor <NUM> transmits data to actuator <NUM> and mobile device <NUM> transmits data to base station <NUM>. In this scenario, the sensors <NUM> and <NUM> and the actuators <NUM> and <NUM> communicate directly from device to device (D2D).

In this scenario, it is assumed that all UEs requiring D2D communication (including ones transmitting URLLC data) indicate their intention to use D2D communication to the base station <NUM> and that all the UEs are in coverage and connected with the base station <NUM>. The sensors <NUM> and <NUM> comprises a processor <NUM>, a receiver <NUM>, and a transmitter <NUM>. The base station <NUM> comprises a processor <NUM>, a receiver <NUM>, and a transmitter <NUM>. The mobile device <NUM> comprises a processor <NUM>, a receiver <NUM>, a transmitter <NUM>, and a memory <NUM>.

In order to achieve low latency communication, the processor <NUM> of the sensors <NUM> and <NUM> is configured to use the transmitter <NUM> to transmit a preamble in a first time interval and use the transmitter <NUM> to transmit data in a second time interval succeeding the first time interval. The preamble indicates that data transmitted in the time interval succeeding the first time interval requires reliable reception by a recipient of the data. This data is also referred to as ultra-reliable low latency communication (URLLC) data and this preamble is also referred to as URLLC preamble in this description.

The processor <NUM> of the sensors <NUM> and <NUM> is further configured to use the receiver <NUM> to listen for transmission of a preamble, use the transmitter <NUM> to transmit data in a second time interval succeeding a first time interval upon determining that the preamble was not received in the first time interval, and refrain from transmitting data in the second time interval upon determining that the preamble was received in the first time interval.

This allows the sensor <NUM> (S1), for example, to transmit URLLC data to the actuator <NUM> (A1). When the sensor <NUM> detects the preamble transmitted by the sensor <NUM> in the first time interval and it has no own URLLC data to transmit, then it refrains from transmitting data in the frequency resource(s) used by sensor <NUM> (S1). This results in a lower latency for URLLC data.

The processor <NUM> of the sensors <NUM> and <NUM> is further configured use the transmitter <NUM> to transmit the preamble in the first time interval in a first frequency resource, use the transmitter <NUM> to transmit a first portion or a first copy of data in the first frequency resource in the second time interval and use the transmitter <NUM> to transmit a second portion or second copy of the data in a second frequency resource in the second time interval. The second frequency resource is separate from the first frequency resource. This results in more reliable communication without increasing the latency.

In <FIG>, the mobile communication network has reserved a set of uplink (UL) resources for D2D packet transmissions, as currently specified in 3GPP for autonomous D2D resource utilization. All the UEs, including sensors <NUM> and <NUM> and mobile device <NUM>, are able to listen to these UL resources and the D2D capable UEs, including sensors <NUM> and <NUM>, are also capable to transmit data (either URLLC or non-URLLC packets) on these UL resources.

As second frequency resource, downlink (DL) resources may be used, for example. In order to achieve low latency reliable communication, the processor <NUM> of the base station <NUM> is configured to use the receiver <NUM> to listen for transmission of a preamble, use the transmitter <NUM> to transmit data in a second time interval succeeding a first time interval upon determining that the preamble was not received in the first time interval, and refrain from transmitting data in the second time interval upon determining that the preamble was received in the first time interval.

In other words, upon reception of the URLLC preamble in the UL resource by the base station <NUM>, the DL scheduler frees up (associated) DL resources so that the URLLC transmission by the UE (sensor <NUM> in the above example scenario) can use these additional DL time/frequency resources for the URLLC data transmission. This increases the reliability of the URLLC packet transmission, while not increasing the delay, as the second copy or portion of the data is not transmitted later, but in a different frequency resource.

The mobile device <NUM> is not communicating directly with other devices and therefore will normally not transmit data in the UL resources reserved for D2D communication. The mobile device <NUM> will also not transmit data in the DL resources, because these are reserved for communication by the base station <NUM>.

If it might happen that the second frequency resource or a third frequency resource is an UL resource not reserved for D2D communication, then in order to achieve low latency communication, the processor <NUM> of the mobile device <NUM> may be configured to use the receiver <NUM> to listen for transmission of a preamble (in a UL resource reserved for D2D communication), use the transmitter <NUM> to transmit data in a UL resource not reserved for D2D communication in a second time interval succeeding a first time interval upon determining that the preamble was not received in the first time interval, and refrain from transmitting data in a UL resource not reserved for D2D communication in the second time interval upon determining that the preamble was received in the first time interval.

In <FIG>, in order to increase the reliability further, the processor <NUM> of the base station <NUM> is further configured to use the receiver <NUM> to listen for transmission of a preamble by a transmitting device (e.g. sensor <NUM>) to a recipient (e.g. actuator <NUM>) and use the receiver to receive data in a second time interval upon receiving the preamble in a first time interval. The second time interval succeeds the first time interval. The processor <NUM> is further configured to use the receiver <NUM> to listen for transmission by the recipient of a message indicating that data transmitted in the second time interval was not successfully received by the recipient, e.g. a NACK, and use transmitter <NUM> to retransmit the data in a fourth time interval upon receiving the message in a third time interval.

Note that the invention is particularly advantageous in cases where traffic cannot be scheduled beforehand, e.g. if a UE has URLLC packets when an event take place (e.g. emergency breakdown, alarms, etc.). As the arrival of URLLC packets is unpredictable, such traffic should not be scheduled beforehand. Even if it could be scheduled by reserving resources, this will not be efficient as most of the time the reserved radio resources are not utilized as there is no actual URLLC traffic in the system. There are other types of URLLC applications in which devices generate periodic traffic that needs to be transmitted with low latency and with high reliability. Such traffic is preferably scheduled either in a regular fashion (by involving the base station) or by utilizing D2D communications with periodic resource reservation.

In <FIG>, the sensors <NUM> and <NUM> comprise one processor <NUM>. In an alternative aspect, one or more of the sensors comprise multiple processors. The receiver <NUM> and the transmitter <NUM> of the sensors <NUM> and <NUM> may use one or more cellular communication technologies such as GPRS, CDMA, UMTS, LTE, and/or <NUM> NR to communicate with the actuators <NUM> and <NUM> and the base station <NUM>, for example. The receiver <NUM> and the transmitter <NUM> may be combined in a transceiver. The processor <NUM> may be a general-purpose processor, e.g. an ARM processor, or an application-specific processor. The sensors may comprise other components typical for a sensor, e.g. a battery. The sensor may be a motion sensor, for example. The device of the invention may be another device than a sensor, actuator, or a mobile device.

In in <FIG>, the base station <NUM> comprises one processor <NUM>. In an alternative aspect, the base station <NUM> comprises multiple processors. The processor <NUM> of the base station <NUM> may be a general-purpose processor, e.g. an Intel or an AMD processor, or an application-specific processor, for example. The processor <NUM> may comprise multiple cores, for example. The processor <NUM> may run a Unix-based or Windows operating system, for example.

The receiver <NUM> and the transmitter <NUM> may use one or more cellular communication technologies such as GPRS, CDMA, UMTS, LTE and/or <NUM>/NR to communicate with UEs (e.g. mobile device <NUM>, sensors <NUM> and <NUM> and actuators <NUM> and <NUM>), for example. The receiver <NUM> and the transmitter <NUM> may be combined in a transceiver. Base station <NUM> may comprise other components typical for a component in a (e.g. mobile) communication network, e.g. a power supply. In the embodiment shown in <FIG>, the base station <NUM> comprises one device. In an alternative embodiment, the base station <NUM> comprises a plurality of devices. The system of the invention may be another system than a base station or a mobile device.

In <FIG>, the mobile device <NUM> comprises one processor <NUM> In an alternative embodiment, the mobile device comprises multiple processors. The receiver <NUM> and the transmitter <NUM> of the mobile device <NUM> may use one or more cellular communication technologies such as GPRS, CDMA, UMTS, LTE, and/or <NUM> NR to communicate with the base station <NUM>, for example. The receiver <NUM> and the transmitter <NUM> may be combined in a transceiver.

The processor <NUM> may be a general-purpose processor, e.g. an ARM processor, or an application-specific processor. The processor <NUM> may run Google Android or Apple iOS as operating system, for example. The memory <NUM> may comprise one or more memory units. The memory <NUM> may comprise solid state memory, for example. The mobile device may comprise other components typical for a mobile device, e.g. a display and a battery. The mobile device may be a mobile phone, for example. The device of the invention may be another device than a sensor, actuator, or a mobile device.

A first method is shown in <FIG>. A step <NUM> comprises transmitting a preamble in a first time interval in a first frequency resource. A step <NUM> comprises transmitting a first portion or a first copy of data in the first frequency resource in a second time interval. The second time interval succeeds the first time interval. A step <NUM> comprises transmitting a second portion or second copy of the data in a second frequency resource in the second time interval. The second frequency resource is separate from the first frequency resource. In an alternative embodiment, the first method does not comprise step <NUM> and the data is transmitted in a single frequency resource. In the embodiment of <FIG>, the preamble indicates that data transmitted in a second time interval succeeding the first time interval requires reliable reception by a recipient of the data.

A second method is shown in <FIG>. A step <NUM> comprises listening for transmission of a preamble. A step <NUM> comprises transmitting data in a second time interval succeeding a first time interval upon determining in step <NUM> that the preamble was not received in the first time interval. A step <NUM> comprises refraining from transmitting data in the second time interval upon determining in step <NUM> that the preamble was received in the first time interval.

A second aspect of the first and second methods is shown in <FIG>. Typically, an URLLC device performs both the first and second methods. This is shown in <FIG>. In step <NUM>, it is determined whether the device has any data to be transmitted. If not, step <NUM> is performed again until the device has data to transmit. In other words, step <NUM> comprises waiting until the device has data to transmit. If the device has data to be transmitted, step <NUM> is performed next.

In <FIG>, data has been classified in one of a plurality of classes. The class of the data to be transmitted is checked in step <NUM>. If the device has URLLC data to be transmitted, then step <NUM> is performed next. In step <NUM>, the preamble is transmitted. If the device has non-URLLC data to transmit, the URLLC preamble is not transmitted, but step <NUM> is performed next. In step <NUM>, the device listens for transmission of the URLLC preamble. The steps performed after step <NUM> are shown in <FIG>. The steps performed after step <NUM> are shown in <FIG>. After the data has been transmitted in step <NUM> (non-URLLC data) or in steps <NUM> and <NUM> (URLLC data), step <NUM> is performed again. If the device refrained from transmitting, i.e. performed step <NUM>, then step <NUM> is repeated and the device listens for transmission of the URLLC preamble again to check whether it is now allowed to transmit its non-URLLC data.

A third method is shown in <FIG>. A step <NUM> comprises listening for transmission of a preamble by a transmitting device to a recipient. If it is determined in step <NUM> that a preamble has been received, a step <NUM> is performed next. Step <NUM> comprises receiving data in a second time interval upon receiving the preamble in a first time interval. The second time interval succeeds the first time interval. A step <NUM> comprises listening in a third time interval succeeding the second time interval for transmission by the recipient of a message indicating that data transmitted in the second time interval was not successfully received by the recipient. If it is determined in step <NUM> that a message has been received, a step <NUM> is performed next. Step <NUM> comprises retransmitting the data, received in step <NUM>, in a fourth time interval upon receiving the message in a third time interval.

<FIG> depicts an example of the first method performing transmissions in certain time intervals and frequency resources. The preamble <NUM> is transmitted in step <NUM> of <FIG> in the first time interval ti1. The data <NUM> is transmitted in step <NUM> of <FIG> in the second time interval ti2 in the same frequency resource as the preamble. The data <NUM> is transmitted in a period <NUM> for transmitting data, as shown for time interval ti3. The preamble <NUM> is transmitted in a period <NUM> for transmitting the preamble, as shown for time interval ti3. Period <NUM> follows period <NUM> and a guard period <NUM> follows period <NUM>. The guard-period <NUM> is present to help the base station and other UEs process the information transmitted through the preamble and make a decision about the possible communication scheduled at the next time interval. The preamble preferably consumes <NUM>% or less of the first time interval. In other words, the period <NUM> preferably consumes <NUM>% or less of the time intervals.

<FIG> depicts in table <NUM> a first example of the methods performing transmissions and receptions in certain time intervals and frequency resources. In the example of <FIG>, sensor S1 (sensor <NUM> of <FIG>) transmits URLLC data to actuator A1 (actuator <NUM> of <FIG>) in uplink resource u2. Uplink resource u2 is reserved for D2D communication. Before transmitting URLLC data, the sensor S1 transmits a preamble <NUM>, e.g. a flag, in uplink resource u2. This preamble <NUM> is detected by the base station and by other UEs (the ones that do not require D2D URLLC communication) in close proximity. The preamble <NUM> indicates that the UE will attempt an URLLC transmission in the next time interval. The preamble <NUM> is followed directly by a guard period, as shown in <FIG>. The guard period marks the end of the time interval. The inclusion of the preamble and guard period in the time interval also means that the payload of the URLLC D2D data transmission in the succeeding time interval has to be slightly shorter than the total time interval length in order to have space for transmission of a next URLLC preamble either by the same or other UEs requiring URLLC transmission. This is shown in <FIG>.

The regular UEs (e.g. UEs for eMMB services) and the D2D UEs with non-URLLC packets first have to listen for transmission of an URLLC preamble before the start of the intended/scheduled time interval. The D2D UEs having non-URLLC packets only transmit in the UL resources reserved for D2D communication if they don't receive a URLLC preamble. The regular UEs (e.g. UEs for eMBB services) refrain from fully using the UL resources assigned by the base station scheduler in the next time interval, as some of these UL resources might be also used by the URLLC transmissions. The UEs with non-URLLC packets will transmit the data (whenever allowed) without transmitting a preamble first, unlike the UEs with URLLC packets.

For improved reliability, a second copy or portion of the URLLC packet is transmitted by the sensor S1 on the 'associated/pre-configured' DL resource d2 in addition to the UL resource u2. The actuator A1 receives/listens to the same UL resource u2 and DL resource d2. The base station will release this DL resource d2 for URLLC transmission after detecting the URLLC preamble <NUM> transmitted just before the start of the time interval ti2.

In the example of <FIG>, the UL frequency resource u2 is allocated to device-to-device communication and the DL frequency resource d2 is not allocated to device-to-device communication. In the example of <FIG>, the first copy or portion of the URLLC packet is transmitted on an UL frequency resource, which is normally dedicated to transmissions from client devices to base station, and the second copy or portion of the URLLC packet is transmitted on a DL frequency resource, which is normally dedicated to transmissions from base station to client devices. In an alternative embodiment, the second copy or portion of the URLLC packet is also transmitted on a frequency resource normally dedicated to transmissions from client devices to base station.

Optionally, the sensor S1 can transmit another copy or portion of the URLLC packet on additional 'associated/pre-configured' UL resource. This is because the regular UEs (e.g. eMBB users) might refrain from fully using allocated UL resources by the base station scheduler upon the reception of the URLLC preamble. This is not shown in <FIG>. The actuator A1 will listen to both UL resource u2 and DL resource d2 in time interval ti2. Optionally, the actuator A1 will also listen to the additional UL resource (not shown in <FIG>) that could have been used by regular (e.g. eMBB users) UEs.

In <FIG>, different data copies are transmitted on different frequency resources. In an alternative aspect, different data portions are transmitted on different frequency resources.

In <FIG>, The base station is also listening to the UL resource u2 (i.e. the same frequency resource in which the preamble was transmitted) to decode the URLLC packet for (possible) retransmissions in the future in case the actuator A1 fails to receive the packet (data1) and sends a broadcast NACK in UL resource u2. Thus, the data and the NACK are transmitted in a frequency resource normally dedicated to transmission from client devices to base station. In this embodiment, the actuator A1 decides to transmit a broadcast NACK, because it received the preamble <NUM> in time interval ti1. In an alternative embodiment, actuator A1 decides to transmit a broadcast NACK, because the packet (data1) indicates that data1 is URLLC data. In the example of <FIG>, the actuator A1 fails to receive the URLLC packet in time interval ti2 and transmits a broadcast NACK in time interval ti3. The base station receives this NACK, but also sensor S1 and sensor S2 receive this NACK.

After the sensors S1 and S2 have received the NACK, the sensors S1 and S2 retransmit the URLLC packet (data1) by using the UL resource u2 in the time interval ti4, as there is no new URLLC packet ready for transmission. In this example, two sensors retransmit the URLLC packet. In practice, how many devices would retransmit an URLLC packet would likely depend on how many devices are nearby and willing to retransmit data for other devices. When multiple devices transmit the same URLLC packet, the URLLC packet may travel over different paths, thereby increasing the probability of the URLLC packet being received correctly by a suitably configured receiver. Retransmission of URLLC packets will get priority over new non-URLLC D2D packets. After the base station has detected the NACK, the base station frees-up the previously scheduled communication in the DL resource d2 of time interval ti4 and uses it for re-transmitting the URLLC packet (data1). Thus, it retransmits the data in a frequency resource normally dedicated to transmissions from base station to client devices. After the actuator A1 has transmitted the NACK, the actuator A1 will start listening in both UL resource u2 and DL resource d2 to receive the URLLC packet retransmitted by the sensor S1 and the base station in time interval ti4.

For non-URLLC D2D traffic, only the pre-configured UL time/frequency resources u2 are used and no preamble is transmitted prior to non-URLLC packet transmission. In this case, the base station can proceed with scheduling the regular traffic in the DL time/frequency resources d2 as the non-URLCC traffic can afford longer delays. The regular UEs providing eMBB services can be scheduled for a much longer duration (comprising multiple TTIs) compared to the scheduling duration required for URLLC services. In case a URLLC packet arrives in between of a scheduled eMBBs packet, the URLLC packet can take the portion it requires by using puncturing techniques.

Also shown in <FIG> is the base station transmitting a non-URLLC packet to UE1 (mobile device <NUM> of <FIG>) in DL resource d4 in time interval ti1, and UE1 transmitting an ACK (ack2) to the base station in UL resource u4 (which is not reserved for D2D communication) in time interval ti4. In the example of <FIG>, UE1 does not retransmit the URLLC packet transmitted by sensor S1, because UE1 was receiving the non-URLLC packet from the base station. In another example, UE1 might additionally or alternatively have retransmitted the URLLC packet transmitted by sensor S1.

<FIG> depicts in table <NUM> a second example of the methods performing transmissions and receptions in certain time intervals and frequency resources. In the embodiment of <FIG>, two sensors transmit URLLC data at the same time in different frequency resources. UL frequency resource u2 and DL frequency resource d2 have been assigned to sensor S1 and UL frequency resource u4 and DL frequency resource d4 have been assigned to sensor S2.

Sensor S2 transmits an URLLC preamble <NUM> in frequency resource u4 in time interval ti1 and then transmits a first copy or portion of an URLLC packet (data3) in frequency resource u4 in time interval ti2 and a second copy or portion of the URLLC packet in frequency resource d4 in time interval ti2 to actuator A2. When the base station detects transmission of a NACK by actuator A2 in UL frequency resource u4 time interval ti3, it retransmits the URLLC packet (data3) to actuator A2. Another difference with the example of <FIG> is that the sensors S1 and S2 do not receive the broadcast NACKs in time interval ti3 and therefore do not retransmit the URLLC packet in time interval ti4. Only the base station retransmits the URLLC packet in time interval ti4.

<FIG> depicts a third example of the methods performing transmissions and receptions in certain time intervals and frequency resources. <FIG> shows four D2D pairs having URLLC transmissions at the same time, namely (S1,A1) to (S4,A4). If the same UL and/or DL resources are used by these D2D pairs then packet collision and interference might occur, resulting in corrupted data and longer delays. This problem may be mitigated by having separate UL (and DL) resources for (S1,A1) to (S4,A4) that are non-overlapping in order to prevent that the D2D pairs collide with their URLLC packet transmissions.

The allocation of the non-overlapping resource pools for the pairs (S1,A1) to (S4,A4) is done via signalling from the base station and using their Radio Network Temporary Identifier (RNTI). Thus, a message assigning one or more frequency resources to the sensors S1 to S4 is received by the sensors S1 to S4 and if a sensor does not have an URLLC packet, it listens for transmission of the preamble on at least one of the one or more assigned frequency resources and/or on an anchor frequency resource (which may be an assigned frequency resource). If other D2D pairs exist in the coverage area of the base station and they do not cause significant interference to the (S1,A1) to (S4,A4) pairs, then their resource might be reused.

In order to avoid packet collisions/interference between the different D2D pairs, the amount of non-overlapping UL (and DL) resources should match the number of D2D pairs aiming at simultaneous URLLC transmission. The base station should monitor the traffic conditions and then allocate more resources or release some of the allocated resources depending on the number of simultaneously active D2D URLLC pairs in orderto avoid resource reservation overhead.

Further, in case of multiple simultaneous URLLC D2D transmissions the solutions should also consider the transmission of the preamble and its mapping to the UL and DL resources. For the simultaneous preamble transmissions for the URLLC D2D pairs there are two options:.

In <FIG>, two of the UEs transmit a third copy or third portion of the URLLC data in a third frequency resource in the time interval ti3. The first frequency resource and the third frequency resource in which these UEs transmit their URLLC data are normally dedicated to transmissions from client devices to base station i.e. an uplink frequency resource) and the second frequency resource in which these UEs transmit their URLLC data is normally dedicated to transmissions from base station to client devices (i.e. a downlink frequency resource).

In the example of <FIG>, a first UE transmits its URLLC data in frequency/time resources <NUM> (D2D UL) and <NUM> (regular DL), a second UE transmits its URLLC data in frequency/time resources <NUM> (D2D UL), <NUM> (regular UL) and <NUM> (regular DL), a third UE transmits its URLLC data in frequency/time resources <NUM> (D2D UL) and <NUM> (regular DL), and a fourth UE transmits its URLLC data in frequency/time resources <NUM> (D2D UL), <NUM> (regular UL) and <NUM> (regular DL). The preambles <NUM>-<NUM> are transmitted in the D2D uplink frequency resources (u3-u6).

The preambles transmitted in time interval ti2 also indicate which UL and DL resources will be used (as pre-configured in agreement with the base station) in the time interval ti3 for the actual URLLC data transmission. The frequency resources u1 and u2 might be shared among D2D and no-D2D types of devices. In such cases, the non D2D users will listens to the mapped D2D resources (e.g. in <FIG> these are u4 and u6) for possible preamble transmission before transmitting their packets in the UL resources u1 and u2.

In <FIG>, the preamble identifies assigned frequency resources. This is beneficial if other devices know on which frequency resource to listen for preambles, but do not know which other frequency resources will be used to transmit the URLLC data in the succeeding time interval. Alternatively, other devices might listen to assignment broadcasts by the base station.

The base station listens on all D2D reserved UL resources (e.g. u3 to u6 in <FIG>) in which a preamble can be transmitted in time interval ti2 in order to detect the announcement (in the form of a preamble) of the URLLC data transmission in time interval ti3. The D2D capable UEs without URLLC data listen for a preamble on the D2D reserved UL resource on which they would transmit a preamble themselves (assigned to them by the base station). The non-D2D UEs listen for a preamble on the D2D reserved UL resource that is paired to a non-D2D UL resource on which they would transmit data. Information on which channels are paired may be broadcast by the base station.

With regard to the data, in time interval ti3, the D2D recipient (e.g. A1 to A4 in <FIG>) listens only on the mapped UL and DL resources in which the transmitting D2D device will transmit the URLLC data (e.g. actuator A2 listens on frequency resources <NUM>,<NUM> and <NUM>), while the base stations can listen to either all possible mapped UL and DL resources or some of these frequency resources (e.g. one or more of frequency resources <NUM>-<NUM>) in order to be able to receive the data correctly and if needed retransmit it later as explained below. The inactive surrounding UEs listen to all or some of the frequency resources in which they would transmit their own data or frequency resources paired with these frequency resources in order to be able to receive the data correctly and if needed retransmit it later as explained below.

<FIG> depicts a fourth example of the methods performing transmissions and receptions in certain time intervals and frequency resources. <FIG> shows a situation in which data is retransmitted and there are multiple simultaneous URLLC data transmissions. After the data transmission in time interval ti3 and if the recipient has sent a broadcast NACK in time interval ti4 (because it received corrupted data) for the retransmissions, the data is retransmitted twice:.

In the telecommunications system <NUM> of <FIG>, three generations of networks are schematically depicted together for purposes of brevity. A more detailed description of the architecture and overview can be found in <NPL>' which is included in the present application by reference in its entirety. Other types of cellular telecommunication system can alternatively or additionally be used, e.g. a <NUM> cellular telecommunication system.

The lower branch of <FIG> represents a GSM/GPRS or UMTS network.

For a GSM/GPRS network, a radio access network (RAN) system <NUM> comprises a plurality of nodes, including base stations (combination of a BSC and a BTS), not shown individually in <FIG>. The core network system comprises a Gateway GPRS Support Node <NUM> (GGSN), a Serving GPRS Support Node <NUM> (SGSN, for GPRS) or Mobile Switching Centre (MSC, for GSM, not shown in Fig. <NUM>) and a Home Location Register <NUM> (HLR). The HLR <NUM> contains subscription information for user devices <NUM>, e.g. mobile stations MS.

For a UMTS radio access network (UTRAN), the radio access network system <NUM> also comprises a Radio Network Controller (RNC) connected to a plurality of base stations (NodeBs), also not shown individually in <FIG>. In the core network system, the GGSN <NUM> and the SGSN <NUM>/MSC are connected to the HLR <NUM> that contains subscription information of the user devices <NUM>, e.g. user equipment UE.

The upper branch of the telecommunications system in Fig. <NUM> represents a <NUM> network, commonly indicated as Long Term Evolution (LTE) system or Evolved Packet System (EPS).

The radio access network system <NUM> (E-UTRAN) of the EPS, comprises base stations (evolved NodeBs, eNodeBs or eNBs), not shown individually in <FIG>, providing cellular wireless access for a user device <NUM>, e.g. user equipment UE. The core network system comprises a PDN Gateway (P-GW) <NUM> and a Serving Gateway <NUM> (S-GW). The E-UTRAN <NUM> of the EPS is connected to the S-GW <NUM> via a packet network. The S-GW <NUM> is connected to a Home Subscriber Server HSS <NUM> and a Mobility Management Entity MME <NUM> for signalling purposes. The HSS <NUM> includes a Subscription Profile Repository SPR for user devices <NUM>.

For GPRS, UMTS and LTE systems, the core network system is generally connected to a further packet network <NUM>, e.g. the Internet.

Further information of the general architecture of an EPS network can be found in <NPL>.

<FIG> depicts a block diagram illustrating an exemplary data processing system that may perform the methods as described with reference to <FIG>.

Examples of input devices may include, but are not limited to, a keyboard, a pointing device such as a mouse, or the like.

In an unclaimed embodiment, the input and the output devices may be implemented as a combined input/output device (illustrated in <FIG> with a dashed line surrounding the input device <NUM> and the output device <NUM>).

The application <NUM> may be stored in the local memory <NUM>, he one or more bulk storage devices <NUM>, or separate from the local memory and the bulk storage devices.

Various aspects may be implemented as a program product for use with a computer system, where the program(s) of the program product define functions of the embodiments (including the methods described herein).

Claim 1:
A device (<NUM>) for transmitting a preamble and data comprising,
at least one transmitter (<NUM>); and
at least one processor (<NUM>), the device configured to:
- use said at least one transmitter (<NUM>) to transmit a preamble (<NUM>, <NUM>) in a first time interval in a first frequency resource, wherein said preamble indicates that data transmitted in a second time interval requires reliable and urgent reception by a recipient of said data,
- use said at least one transmitter (<NUM>) to transmit a first portion or a first copy of data in said first frequency resource in said second time interval, said second time interval succeeding said first time interval, and
- use said at least one transmitter (<NUM>) to transmit a second portion or second copy of said data in a second frequency resource in said second time interval, said second frequency resource being separate from said first frequency resource.