GB2573577A - Transmission techniques in a cellular network - Google Patents

Abstract

Various transmission techniques and protocols are discussed for a cellular network. In particular unacknowledged protocols are described, together with methods for configuring feedback. A method of data communication at the physical layer (layer 1) is disclosed, comprising: transmitting a configuration signal from a base station to a UE indicating whether the UE should utilise an acknowledged or unacknowledged protocol for data communication at the physical layer; receiving the configuration signal at the UE and the UE configuring itself to utilise the indicated protocol; and conducting data transmission between the UE and base station according to the indicated protocol. The configuration signal may be: an RRC signal, a DCI, a user-specific signal, part of the configuration of semi-persistent scheduling type data transmission, part of the configured grant (or grant-free) configuration. The acknowledged protocol may be a Hybrid Automatic Repeat Request (HARQ). For use especially with massive Machine-Type Communication (mMTC) devices in a 5G New Radio, NR, environment, where ACK/NACK signalling for the transmission of small packets of data, may represent a significant overhead and power consumption.

Description

Transmission Techniques in a Cellular Network

Technical Field [1] The following disclosure relates to transmission techniques in a cellular network, and in particular to the minimisation of overheads for such transmissions.

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

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

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

[5] A trend in wireless communications is towards the provision of lower latency and higher reliability services. For example, NR is intended to support Ultra-reliable and low-latency communications (URLLC). A user-plane latency of 1ms has been proposed with a reliability of 99.99999%). Other proposed types of services include enhanced Mobile BroadBand (eMBB) for high data rate transmission, and massive Machine-Type Communication (mMTC) to support a large number of devices over a long life-time with highly energy efficient communication channels.

[6] mMTC services are often characterised by large numbers of devices, transmitting small packets (typically 10-75 bytes) of data infrequently. For example, a cell may be expected to support many thousands of devices. In such situations the control signalling overhead must be carefully considered to ensure resources are utilised efficiently.

[7] Due to the inherent unreliability of the wireless link in cellular communications, an acknowledged protocol is used at the physical layer. A receiver transmits an “ACK” signal to the transmitter to confirm receipt. Similarly, the receiver may transmit a “NACK” signal to indicate failed reception. That is, the receiver provides feedback to the transmitter. The ACK/NACK signals may be utilised by the transmitter to clear buffers, or initiate retransmission respectively. In variations the ACK/NACK may be implicit, for example a request for a further transmission may implicitly indicate successful reception or lack an ACK signal may indicate a failed reception. A particular form of acknowledged protocol is known as Hybrid Automatic Repeat Request (HARQ). Such ACK/NACK systems are used in the physical layer of all cellular wireless systems.

[8] For the transmission of small packets of data, the ACK/NACK signalling may be a significant overhead, thus reducing resource efficiency.

[9] There is therefore a requirement for a communication protocol with improved resource efficiency for small data sizes.

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

[11] There is provided a method of data communication in a cellular network at the physical layer, the method comprising the steps of transmitting a configuration signal from a base station to a UE indicating whether the UE should utilise an acknowledged or unacknowledged protocol for data communication at the physical layer; receiving the configuration signal at the UE and the UE configuring itself to utilise the indicated protocol; and conducting data transmission between the UE and base station according to the indicated protocol.

[12] The configuration signal may be an RRC signal.

[13] The configuration signal may be a DCI.

[14] The configuration signal may be a user-specific signal.

[15] The configuration signal may be part of the configuration of semi-persistent scheduling type data transmission.

[16] The configuration signal may be part of the configured grant (or grant-free) configuration.

[17] A default configuration may utilise an acknowledged protocol.

[18] An unacknowledged protocol may be indicated by predefined values for fields of the DCI relating to acknowledgement parameters.

[19] The predefined fields may be fields relating to PUCCH resource, TPC for PUCCH, HARQ feedback timing indicator.

[20] The selected protocol may not require RACH transmission prior to data transmission.

[21] The data transmission may be an uplink or a downlink data transmission.

[22] For uplink data transmission, the base station gets an estimate of the data content for packets failing the decoding from the successfully decoded data packets received from the neighbouring devices.

[23] For uplink data transmission, the base station gets an estimate of the data content for packets failing the decoding from the successfully decoded data packets received earlier from the same device.

[24] For downlink data transmission, the device gets an estimate of the data content for packets failing the decoding from the successfully decoded data packets received earlier from the base station.

[25] The device have requested acknowledged mode or unacknowledged mode for the data transmission.

[26] The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a

Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

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

[28] A conventional communication procedure includes being in RRC_CONNECTED state for data transfer, getting UL synchronized, requesting UL resources with a scheduling grant, receiving grant of resources before data transmission, and HARQ response communication following the data transmission. For mMTC devices with infrequent small data packets with relaxed constraints on latency and reliability these steps represent a significant burden on the transmission resources and the power consumption of the device. For example, typical Transport Block (TB) sizes for mMTC are 10-75 bytes. Furthermore, expected battery life for mMTC devices could be 10 years or more. Reducing the resources and power used for transmission of control information is thus important.

[29] The specific transmission protocol can have a significant impact on one or both of resource utilization or energy consumption. For example, if a HARQ response for the UL data is implicit through the next DCI requesting new data, no resources are used for the acknowledgement, but the device must stay awake, thus using power, while waiting for the HARQ response.

With massive number of MTC devices present in a cell, many devices may be communicating small amounts of data periodically. For this type of communication, the overhead of scheduling a transmission and the overhead of the data feedback is huge relative to the size of the information data. To overcome the scheduling/control overhead, grant-free or semi-persistent types of communications have been standardized. So the scheduling overhead can be controlled to certain extent. On the other hand, the HARQ response (ACK/NAK) sent as feedback to these small data packets will still consume a lot of system resources. This would also result in devices staying active longer, consuming more energy. In case of feedback transmitted in the UL direction by the device, that would consumer even more power which can be significant if the device happens to be located far from the base station. In many application scenarios with MTC devices sending infrequent data, the correct reception of every single data packet from every single device may not be vital. Few such examples are noted below:

> For devices connected with smart energy meters (gas, electricity), they may be sending the consumption to the provider company at periodic intervals say every few hours or maybe once per day etc but the company needs to send the bill to the consumer at the end of the month in most cases. For this case, on the day that the company takes the consumption reading for the bill, either the company can use the latest correctly received consumption value available at the time of the sending the bill, or it can explicitly request the device to send the value if the past many values have not been correctly received.

> The devices doing water level sensing in a canal, river or a dam where there could be dozens of devices sending the data to the aggregator device through the base station. This aggregator could be co-localized or not with the base station. In these kind of scenarios, one aspect is related to the periodicity of the data transmitted which provides highly correlated values in time. The other aspect is related to the fact that the data of a certain device (water level at a specific device) may be derived by the water level values at its neighbouring locations due to high correlations in geographic locations which are known at the aggregator. Thus in such cases, even if the data from a specific device is not decodable at a certain instant, the aggregator can make use of the data from the neighbouring devices and combining this with the location knowledge can get a very good estimation of the data (water level) sent by the device which fails decoding.

> Temperature sensors in a forest - here also the value of each devices has correlation in time and in space with neighbouring sensors. Thus, the aggregator or the central unit can combine the information from neighbouring devices to get a good estimate of the data from a sensor whose packet failed decoding. Another aspect is related to the fact that in certain seasons of the years, the fire risk could be very limited and regular reliable data from these sensors may not be required during this time.

> Traffic density sensors on a highway also have high correlation with neighbouring sensors.

[30] This disclosure provides the network with configurable control over the feedback mechanism at the physical layer for acknowledging transmissions. This disclosure proposes communication protocols and devices which communicate without explicit or implicit feedback for data at the physical layer. Further this disclosure proposes that the network can enable/disable data feedback at the physical layer for these devices and the corresponding signalling mechanisms. The disclosure also describes a new transmission protocol without dynamic control information and without data feedback.

[31] This disclosure relates to wireless communication systems with data transmission in UL, DL or in both directions. In a standard mode of transmission, the network sends control information first to schedule transmission resources for a specific user equipment where its relevant downlink or uplink data can be transmitted. The downlink control information (DCI) in PDCCH carries this scheduling and control information relevant for DL data (PDSCH) or UL data (PUSCH). The DCI scheduling the uplink data is typically referred to as the UL grant.

[32] In case of DCI scheduling the DL data (PDSCH) on the physical layer, the UE prepares itself to receive the data on the indicated resources. After data processing, it sends an indication to the base station about the decoding status, sending an ACK in case of correct decoding or sending a NAK in case of decoding failure. Normally the resources used for sending data feedback are also configured in the DCI scheduling the data transmission. Receiving an ACK at the base station lets it know that the data was received at the device and it may proceed to sending the next packets. Upon receiving a NAK at the base station, it utilises a retransmission protocol.

[33] In case of DCI scheduling the UL data (PUSCH), the UE will prepare the data and transmit this data packet in the UL direction on the indicated resources. After the processing of received data, the base station will send an indication about the correct or incorrect detection of the packet. In case the user receives a NAK (explicit HARQ response), or it receives a scheduling request for the earlier transmitted packet (implicit HARQ response), the retransmissions follow the scheduling command (UL grant) or the configuration of the retransmission protocol.

[34] According to the current disclosure, the physical layer protocol does not require either implicit or explicit feedback of data transmissions. This reduces the control overhead for a transmission, thus improving resource efficiency. However, in many situations reliability may be more important than resource efficiency. In order to ensure the preferred protocol is selected the network may configure whether feedback is utilised for each device. The network may configure the activation or de-activation of feedback using RRC signalling. The RRC signalling may be user-specific.

[35] A user-specific RRC parameter which controls the activation/de-activation of data feedback at the physical layer is provided. As when an MTC device comes in the network, in the beginning, it needs to synchronize and register to the network. Thus, the default value for the data feedback upon device activation (registration) is active so that device gets registered on the network reliably and both the device and the network are able to exchange important system and registration information.

[36] Once initial configuration is done and the device is starting its usual operation, the network can disable the data feedback at the physical layer. This could, for example, be part of the initial configuration or the network can disable the feedback later through RRC signalling to the device.

[37] When the physical layer communication has been configured to be without feedback, DCI for DL data does not need to convey the resource indication for the feedback which is not active in this case. This would allow to shrink the size of the DCI where the fields relevant to the feedback have been removed. The reduction of DCI size is positive as it results in resource efficiency for a given reliability or improved reliability for a given amount of resource utilization.

[38] If the communication is configured through semi-persistent manner or other grant-free or configured grant manners, the configuration will not require allocation and reservation of feedback resources in case feedback is not active for a specific user. This will improve the resource efficiency for the communication.

[39] In another method, where some dynamic control may be necessary over activation/deactivation of the physical layer feedback, the activation/de-activation can be part of the DCI. One way to do this is by making use of existing DCIs which have certain fields to indicate feedback resources. A fixed set of values for these feedback fields can be selected which when transmitted indicate the de-activation of the feedback. These values should be selected with care such that they are not meaningful or allowed values for these fields and should be known to both the transmitter and the receiver. This method is advantageous from the perspective that no additional DCI design is required.

[40] Therefore, the network can disable the physical layer data feedback in the DCI. The networks can send a specific combination of the values assigned to the fields related to physical layer feedback which imply de-activation of the feedback for the present transmission. Currently in the DCI scheduling the DL data, there are some fields indicating the resource, timing and the power control for HARQ response. These fields are physical uplink control channel (PUCCH) resource, transmit power control (TPC) for PUCCH, PDSCH-to-HARQ feedback timing indicator. Thus, fixed combination of values assigned to these fields or a subset of these fields could indicate the UE de-activation of the feedback for the transmission.

[41] The other way to do this could be to introduce a flag in the DCI scheduling the transmission which indicates the activation or de-activation of the HARQ physical layer feedback. This could for example be useful for UL communication with asynchronous HARQ which uses implicit feedback. As there is no explicit ACK/NAK transmitted, there are no ACK/NAK related fields in the DCI. Here normally the device will wait for a certain time to see if there is a DCI rescheduling the earlier transmitted packet before assuming an implicit ACK. Thus, to allow the configurability when the devices don’t need to wait for the next DCI and they may go to sleep right after the transmission, such protocols will either need special encoding of some existing fields or addition of a new field which provides an indicating of HARQ response (although implicit here) being active or not.

[42] In case the communication is happening without dynamic grants, for example following semi-persistent, configured grant or grant-free types of protocols etc, the activation or deactivation of physical layer data feedback can be part of the configuration of these protocols.

Currently semi-persistent scheduling may configure regular resource for devices for uplink, or downlink or both directions. Thus, part of the initial configuration for semi-persistent scheduling may also have a parameter enabling or disabling the HARQ feedback. 5G NR has standardized two types of configured grant or grant-free communication for the UL data transmission. Here the devices are configured with periodic resources and other transmission relevant parameters. To avoid signalling the activation/de-activation of physical layer HARQ feedback separately, it would be beneficial to signal this along with the configuration of “configured-grant”.

[43] For the devices configured with no physical layer data feedback, there could be situations which may require feedback. One example could be the data related to the change of system information. Although most of the MTC devices will be static but some may be moving probably due to being installed on some moving vehicles. Thus, there could be situations when system information, measurement relevant or other important data may need feedback. Thus, these devices should be capable of transmitting/receiving physical layer HARQ feedback for some packets and not transmitting/receiving physical layer HARQ feedback for the other packets.

[44] In one example, the devices are configured not to transmit/receive physical layer HARQ feedback through RRC signalling and then if there is some other DCI command (say for system information change, measurement etc) and the HARQ ACK/NAK fields in the DCI provide meaningful values, the device would transmit the HARQ response for the data scheduled through this specific DCI, while still continuing no data feedback protocol for the other data communication for which it received the no feedback configuration through RRC signalling.

[45] The reader would appreciate that the no data feedback may have been the part of the configured-grant, grant-free or semi-persistent configuration as well and it would continue as for the above example while still sending the physical layer HARQ feedback for the packet configured dynamically with indication of physical layer HARQ feedback being active implicitly or explicitly.

[46] In certain cases, the devices may be running different services and it’s also possible that they are aware of their surrounding devices. In a specific situation, it is also possible that the device is quite far from the base station. So even if it is able to decode the DL packets successfully, it is spending a lot of energy in sending HARQ feedback to the base station. We can also envisage intelligent devices (maybe sensors) which when battery power is running out, don’t want to transmit feedback in the UL direction or don’t want to stay awake longer to receive DL feedback. So, in such situations, it might be beneficial that the device can request the network to enable/disable the physical layer HARQ feedback.

[47] The typical data transmission in most of the advanced wireless systems (for example LTE and LTE-Advanced) happens in three steps:

[48] Step 1: Transmission of Control information from the network giving scheduling and control information.

[49] Step 2: Data transmission in UL or DL direction as per the control information of Step 1.

[50] Step 3: Implicit or Explicit HARQ response (data feedback) for the data transmitted in Step 2.

[51] Even the step 1 has the pre-requisite that the UE is in RRC_CONNECTED state and furthermore in case of UL data transfer, it has made a request by transmitting a SR in the UL direction.

[52] Although to better accommodate different types of traffic, the regular control information (Step 1) can be skipped for example by using semi-persistent scheduling, which has been standardized in 5G NR with the terminology of grant-free or configured grant transmission. Such transmissions provide a periodic configuration of resources which the UEs may use for UL or DL transmission of data without having the need to be scheduled for every single interval.

[53] The communication protocols follow the explicit physical layer HARQ response where the receiver will send ACK or NAK status of the data to the transmitter. One implicit method of physical layer HARQ response in the DL direction (for the UL data) could be through the use of an indication in the control (Step 1) of the subsequent packet. For example, the field “New Data Indicator (NDI)” could be used to indicate if the newly scheduled data is new data or the previously transmitted data. LTE makes use of NDI combined with the HARQ process identity (ID) to get retransmission for the previously scheduled/transmitted data. The HARQ ID with the NDI field un-toggled refers to a retransmission which becomes effectively NAK for the previously transmitted UL packet and if NDI is toggled, it refers to new transmission, thus acknowledging the previously transmitted data packet.

[54] To accommodate large numbers of devices in the network, particularly those with small data packets and of machine type communication, it’s important to make the communication as resource efficient as possible. This is how practically hundred and thousands of devices can be supported on limited amount of transmission resources. To make this possible, the proposal would be to remove the dynamic scheduling and physical layer data feedback part from the data transmission. This means that Step 1 and Step 3 are not part of the data transmission procedure and data transmission is done without dynamic scheduling from the base station and data feedback from the receiver side.

[55] Thus, the network can configure users for physical layer data transmission protocols without dynamic control information and data feedback.

[56] To avoid transmitting scheduling and control information (Step 1) before each data transmission, the base station can configure the user with a set of configuration parameters which allows it to transmit/receive data infrequently when it arrives from higher layers, where the resources, periodicity and the transmission parameters are part of the configuration for this transmission with which the user is configured prior to start of such transmissions. Semipersistent scheduling, configured-grant and grant-free are examples of such transmission schemes.

[57] The configuration for such transmissions without the dynamic control information can schedule the users over non-orthogonal resources which would allow the co-existence of even larger number of devices for a given amount of transmission resources, thus making the communication even more efficient. In this vein, various non-orthogonal multiple access (NOMA) methods are under study for 5G standardization. These methods allow multiple users scheduled over the same transmission resources, and separated by one or a combination of the spreading codes, scrambling codes, sparse code, interleaving patterns etc.

[58] In another method which is suitable for devices operating without dynamic scheduling/control is to have the indication related to activation/de-activation of physical layer HARQ response as part of the initial transmission configuration. Thus, the base station sends the configuration indication to the UE which indicates the resources, periodicity, transmission parameters and the indication of activation/de-activation of HARQ response. Thus, for some devices where physical layer HARQ response may not be required for transmission, the base station may de-activate it when it configures the transmissions. For other devices which happen to be in communication requiring physical layer HARQ response (fire sensors in the forest during fire-risk days etc), the base station can activate the HARQ response in the initial configuration of periodic or semi-periodic transmissions. In case of activation of physical layer HARQ response, the base station may indicate the other HARQ related parameters, namely the HARQ timeline, HARQ resource and potentially the sequence used for HARQ etc.

[59] For transmissions without dynamic grant (configured through semi-persistent scheduling, configured-grant or grant-free manner etc), the initial configuration may include the indication of activation/de-activation of data feedback (HARQ response).

[60] There are many applications of mMTC devices, for example metering and sensors which have very infrequent data transmissions. Furthermore, most of these devices will be physically installed on fixed geographic locations. This provides further opportunities to improve the communication protocols for these devices.

[61] In typical UL/DL communication, when the device is in RRC_CONNECTED state but not UL synchronized, upon the need to communicate in the UL direction (packet arrives from higher layers) or DL direction (indication from the network), it will start RACH procedure to get itself synchronized in the UL direction. This may be required for mobile devices and for the devices with high throughput requirements. As many of the MTC devices will be static, the timing advanced (TA) parameter related to UL synchronization will not change. Thus, in many cases, the TA value that the devices obtained during initial configuration will be valid for a long time. So, these devices don’t need RACH procedure before data communication even after being in deep sleep mode.

[62] Devices may therefore start a new UL/DL information exchange without first transmitting a RACH preamble to acquire synchronization.

[63] For devices with moderate mobility, if the cell sizes are small to moderate, their distance would lead to time lag within the cyclic prefix and the data would be decodable at the base station without PRACH transmission. Another method for these devices to stay in UL synchronized state is to use larger cyclic prefix for MTC communication. The larger cyclic prefixes would absorb the change in device location within its timing limits. Thus, no RACH transmission may be useful even for MTC devices with mobility, resulting in more efficient communication. Furthermore, some preamble sequences can be made part of the data transmission which let the base station correctly detect the timing of the UL data.

[64] Another way to avoid sending the PRACH preambles before almost every infrequent data exchange is to relax the threshold of the timer value, controlling the UE synchronization status. A relaxed timer value for UL synchronization would imply that the device would stay in UL synchronized state even after long periods of inactivity and need not to transmit PRACH preambles in case it needs UL/DL data transmission.

[65] That is, devices for which the threshold of the timer value controlling the UL synchronization may be very large compared to typical inactive time between two active periods to avoid frequent PRACH transmissions. This timer in LTE and 5G NR is termed as “timeAlignmentTimer¹’. For 5G NR, 3GPP TS38.331 defines the following values for this timer:

[66] TimeAlignmentTimer ::= ENUMERATED {ms500, ms750, ms1280, ms1920, ms2560, ms5120, ms10240, infinity} [67] Thus, this timer may be set to infinity, and the devices will stay in UL synchronized state as long as they are in RRC_CONNECTED state. A better way to stay synchronized longer would be to add new possible values for this timer which suit the MTC devices. In the current settings, the largest value smaller than infinity is only 10.24 seconds which is clearly a very small time between two information exchange events for most of the MTC devices. Thus, the new values giving time alignment in a range of minutes and up to few hours may be a better choice for MTC devices and the network can configure the value suitable for MTC device location, attributes and application.

[68] If a device has to transmit small data packets very infrequently, the overhead (resource, power) of moving the device from a state where it cannot transmit data to a state where it can transmit data (RRC_CONNECTED for example) could be much larger than that of the information data itself. In LTE, there were only two states for RRC, RRCJDLE and RRC_CONNECTED where the information data exchanges happen only in RRC_CONNECTED state. In 5G NR, an additional state RRCJNACTIVE has been added where the UEs keep the context and can quickly move to RRC_CONNECTED if UL/DL data transfer is required but still the data transfer happens in RRC_CONNECTED state. For MTC applications with infrequent data transmissions, the proposal would be to allow the devices transmit data without exchanging RRC messages needed for change of RRC state. Thus, these devices may transmit data without having to change their state.

[69] Devices may thus exchange data after deep sleep without having to exchange messages required for RRC state change procedures.

[70] If a UE can move from RRCJNACTIVE to RRC_CONNECTED on its own when it has UL data to transmit, the UE may remain in RRCJNACTIVE for a very long time (increase the timer value for which UE can stay in RRCJNACTIVE state).

[71] If moving the UE from RRCJNACTIVE to RRC_CONNECTED is not feasible without message exchanges with the network, the following options can be used to avoid message/state exchanges when MTC devices have to transfer data:

1. Data transmission in RRCJNACTIVE may be permitted when needed by the UE.

2. The UEs may stay in RRC_CONNECTED for longer time durations without being active.

[72] Another possibility is to define a new light RRC state suitable for MTC applications where the UEs can stay for longer durations in almost deep sleep but capable of transmitting infrequent UL packets.

In summary there is provided :-

I. Device may use a communication protocol without implicit or explicit data feedback.

II. The network can choose to enable or disable data feedback indicating the status of data delivery.

III. The network uses user-specific RRC signalling to enable or disable the feedback.

IV. For the devices supporting the protocol of configurable HARQ feedback, the data feedback is active by default if no explicit value is provided by the network.

V. The network can disable data feedback using DCI. The networks can send a specific combination of the values assigned to the fields related to feedback which imply deactivation of the feedback for the present transmission.

VI. The network can configure users for data transmission protocols without dynamic control information and data feedback.

VII. For transmissions without dynamic grant (configured through semi-persistent scheduling, configured-grant or grant-free manner etc), the initial configuration may include the indication of activation/de-activation of data feedback (HARQ response).

VIII. Devices may operate without transmitting a RACH preamble to acquire UL synchronization before starting a new UL/DL information exchange.

IX. Devices may exchange data after sleep without having to exchange messages required for RRC state change procedures.

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

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

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

[76] The computing system may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RW), or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.

[77] In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. Such components may include, for example, a removable storage unit and an interface , such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.

[78] The computing system can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a universal serial bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium.

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

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

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

[82] It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organisation.

[83] Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as FPGA devices.

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

[85] Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.

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

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

Claims (16)

1. A method of data communication in a cellular network at the physical layer, the method comprising the steps of transmitting a configuration signal from a base station to a UE indicating whether the UE should utilise an acknowledged or unacknowledged protocol for data communication at the physical layer;

receiving the configuration signal at the UE and the UE configuring itself to utilise the indicated protocol; and conducting data transmission between the UE and base station according to the indicated protocol.

2. A method according to claim 1, wherein the configuration signal is an RRC signal.

3. A method according to claim 1, wherein the configuration signal is a DCI.

4. A method according to any preceding claim, wherein the configuration signal is a user- specific signal.

5. A method according to any preceding claim wherein the configuration signal is part of the configuration of semi-persistent scheduling type data transmission.

6. A method according to any preceding claim wherein the configuration signal is part of the configured grant (or grant-free) configuration.

7. A method according to any preceding claim, wherein a default configuration utilises an acknowledged protocol.

8. A method according to claim 3, wherein an unacknowledged protocol is indicated by predefined values for fields of the DCI relating to acknowledgement parameters.

9. A method according to claim 8, wherein the predefined fields are fields relating to PUCCH resource, TPC for PUCCH, HARQ feedback timing indicator.

10. A method according to any preceding claim, wherein the selected protocol does not require RACH transmission prior to data transmission.

11. A method according to any preceding claim, wherein the data transmission is an uplink data transmission.

12. A method according to any preceding claim, wherein the data transmission is a downlink data transmission.

13. A method according to any preceding claim, wherein for the case of uplink data transmission, the base station gets an estimate of the data content for packets failing the decoding from the successfully decoded data packets received from the neighbouring devices.

14. A method according to any preceding claim, wherein for the case of uplink data transmission, the base station gets an estimate of the data content for packets failing the decoding from the successfully decoded data packets received earlier from the same device.

15. A method according to any preceding claim, wherein for the case of downlink data transmission, the device gets an estimate of the data content for packets failing the decoding from the successfully decoded data packets received earlier from the base station.

16. A method according to claim 1, wherein the device has requested acknowledged mode or unacknowledged mode for the data transmission.