CN112106438A - Transmission techniques in cellular networks - Google Patents

Abstract

Various transmission techniques and protocols for cellular networks are discussed. In particular, unacknowledged protocols and methods for configuring feedback are described.

Description

Transmission techniques in cellular networks

Technical Field

The following disclosure relates to transmission techniques in cellular networks, and in particular to the minimization of overhead for such transmissions.

Background

Wireless communication systems, such as third generation (3G) mobile telephone standards and technologies are well known. Such 3G standards and techniques are developed by the third generation partnership project (3 GPP). Third generation wireless communications have typically been developed to support macro-handset communications. Communication systems and networks have evolved towards broadband and mobile systems.

In a cellular Radio communication system, a User Equipment (UE) is connected to a Radio Access Network (RAN) via a Radio link. The RAN comprises a set of base stations that provide radio links to UEs located in cells covered by the base stations, and is connected to a Core Network (CN) that provides overall Network control. As will be appreciated, the RAN and CN each perform respective functions for the entire network. For convenience, the term cellular network will be used to refer to the combined RAN and CN, and it will be understood that this term is used to refer to the various systems for performing the disclosed functions.

The third generation partnership project has developed a so-called Long Term Evolution (LTE) system, evolved UMTS terrestrial radio access network (E-UTRAN), as a mobile access network, in which one or more macro cells are covered by base stations called enodebs or enbs (evolved nodebs). Recently, LTE is evolving further towards so-called 5G or NR (new radio) systems, where one or more cells are covered by base stations called gnbs. NR is proposed to utilize Orthogonal Frequency Division Multiplexing (OFDM) physical transmission formats.

The trend in wireless communications is toward providing lower latency and higher reliability services. For example, NR aims to support ultra-reliable and low-latency communication (URLLC). A 1 millisecond user plane delay has been proposed with a reliability of 99.99999%. Other proposed service types include enhanced mobile broadband (eMBB) for high data rate transmission, and large-scale machine type communication (mtc) that supports a large number of devices over a long lifetime through energy-efficient communication channels.

mtc services are typically characterized by a large number of devices, rarely sending small data packets (typically 10-75 bytes). For example, it may be desirable for a cell to support thousands of devices. In this case, control signaling overhead (overhead) must be carefully considered to ensure efficient utilization of resources.

Due to the inherent unreliability of wireless links in cellular communications, well-established protocols are used at the physical layer. The receiver sends an "ACK" signal to the sender to acknowledge receipt. Similarly, the receiving party may send a "NACK" signal to indicate a reception failure. I.e. the receiving party provides feedback to the transmitting party. The transmitting party may clear the buffer with the ACK/NACK signal or initiate retransmission separately. In a variation, the ACK/NACK may be implicit (implicit), e.g., a request for further transmission may implicitly indicate successful reception, or the absence of an ACK signal may indicate failed reception. One particular form of acknowledgement protocol is known as Hybrid Automatic Repeat Request (HARQ). Such an ACK/NACK system is used in the physical layer of all cellular radio systems.

For transmission of small data packets, ACK/NACK signaling may generate significant overhead, thereby reducing resource efficiency.

Therefore, there is a need for a communication protocol having improved resource efficiency for small data sizes.

Disclosure of Invention

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 claims, nor is it intended to be used as an aid in determining the scope of the claimed claims.

There is provided a method of data communication in a cellular network of a physical layer, the method comprising the steps of: transmitting a configuration signal from the base station to the UE, the configuration signal indicating whether the UE should communicate data using an acknowledged or unacknowledged protocol at the physical layer; receiving the configuration signal at the UE, and the UE configuring itself to utilize the indicated protocol; and carrying out data transmission between the UE and the base station according to the indicated protocol.

The configuration signal may be a Radio Resource Control (RRC) signal.

The configuration signal may be Downlink Control Information (DCI).

The configuration signal may be a user-specific (user-specific) signal.

The configuration signal may be part of a configuration for semi-persistent scheduling (semi-persistent scheduling) type data transmission.

The configuration signal may be part of a configured authorized (or unauthorized) configuration.

The default configuration may utilize an acknowledged protocol.

Unacknowledged protocols may be indicated by predefined values of DCI fields that relate to acknowledgement parameters.

The predefined field may be a field related to Physical Uplink Control Channel (PUCCH) resources, Transmit Power Control (TPC) for PUCCH, timing indicator for HARQ feedback.

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

The data transmission may be an uplink or downlink data transmission.

For uplink data transmission, from among successfully decoded data packets received from neighboring devices, the base station obtains an estimate (estimate) of the data content of the data packet whose decoding failed.

For uplink data transmission, from successfully decoded data packets received earlier by the same device, the base station obtains an estimate of the data content of the data packets that failed decoding.

For downlink data transmission, from successfully decoded data packets received earlier by the base station, the device obtains an estimate of the data content of the data packets that failed decoding.

The device has requested an acknowledged mode (acknowledged mode) or an unacknowledged mode (unacknowledged mode) for the data transmission.

The non-transitory computer-readable medium may include at least one of: hard disk, CD-ROM, optical storage devices, magnetic storage devices, read-only memory, programmable read-only memory, erasable memory. Programmable read-only memory, EPROM, electrically erasable programmable read-only memory and flash memory.

Detailed Description

Those skilled in the art will recognize and appreciate that the specifics of the described examples are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.

The conventional communication procedure includes being in an RRC CONNECTED (RRC _ CONNECTED) state for data transmission, synchronizing UL, requesting UL resources through a scheduling grant, receiving a resource grant before data transmission, and performing HARQ response communication after data transmission. For an mtc device with few small data packets, the delay and reliability constraints are relaxed, and these steps impose a large burden on the transmission resources and power consumption of the device. For example, the size of a typical Transport Block (TB) of mMTC is 10-75 bytes. Furthermore, the expected battery life of an mtc device may be 10 years or more. Therefore, it is important to reduce resources and power for transmitting control information.

A particular transmission protocol may have a significant impact on one or both of resource utilization or energy consumption. For example, if a HARQ response to UL data is implied by the next DCI requesting new data, no resources are used for acknowledgement, but the device must remain awake (awake) to maintain power consumption while waiting for the HARQ response.

Since there are a large number of MTC devices in one cell, many devices may periodically transmit a small amount of data. For this type of communication, the overhead of scheduling transmissions and the overhead of data feedback is significant with respect to the size of the information data. To overcome the scheduling/control overhead, a grant-free or semi-persistent communication type has been standardized. This allows a degree of control over the scheduling overhead. On the other hand, HARQ responses (ACK/NAK) sent as feedback to these small packets still consume a lot of system resources. This will also result in the device remaining active longer, consuming more energy. This will consume more power if the device transmits feedback in the UL direction, which may be important if the device happens to be located far away from the base station. In many application scenarios where MTC devices send infrequent data, it may not be important to correctly receive each individual data packet from each individual device. Several such examples are mentioned below:

for devices connected to smart meters (gas, electric), they may be regular (for example every few hours or possiblyOnce a day, etc.) the consumption is sent to the provider company, but the company needs to send a bill to the consumer, in most cases at the end of the month. For this case, the company may use the most recently correctly received consumption value available at the time of sending the bill, or may explicitly request the device to send the value if many past values were not correctly received, the day the company takes the consumption reading of the bill.

Devices for water level sensing in a canal, river or dam where there may be tens of devices transmitting data to aggregation devices through base stations. The aggregator may or may not be co-located with the base station. One aspect in this case relates to the periodicity of the transmitted data, which provides a high correlation value in time. Another aspect relates to the fact that: due to the high correlation in the known geographical location at the aggregator, data for a certain device (water level at a particular device) can be derived from water level values at its neighboring locations. Thus, in this case, even if the data from a particular device is not decodable at a certain instant, the aggregator can exploit the data from the neighboring devices and combine it with knowledge of the location, making it possible to estimate well the data (water level) sent by the device that failed decoding.

Temperature sensors in a forest-where the value of each device is correlated in time and space to adjacent sensors. Thus, the aggregator or central unit may combine information from neighboring devices to obtain a good estimate of the data from the sensor whose packet decoding failed. Another aspect is related to the fact that: in certain seasons of the year, the risk of fire may be very limited, and periodically reliable data from these sensors may not be needed during this period.

Traffic density sensors on highways also have a high correlation with neighboring sensors.

The present disclosure provides the network with configurable control of the feedback mechanism on the physical layer to acknowledge the transmission. The present disclosure proposes communication protocols and devices that communicate without explicit (explicit) or implicit feedback of data to the physical layer. Further, the present disclosure proposes that the network can enable/disable (disable) data feedback on the physical layer for these devices and corresponding signaling mechanisms. The present disclosure also describes a new transmission protocol without dynamic control information and without data feedback.

The present disclosure relates to wireless communication systems with data transmission in the UL, DL or both directions. In a standard transmission mode, the network first sends control information to schedule transmission resources for a particular user equipment in which its associated downlink or uplink data may be transmitted. Downlink Control Information (DCI) in the PDCCH carries the scheduling and control information related to DL data (PDSCH) or UL data (PUSCH). The DCI scheduling uplink data is generally referred to as a UL grant.

In case that the DCI schedules DL data (PDSCH) on the physical layer, the UE prepares itself to receive data on the indicated resources. After data processing it sends an indication to the base station about the decoding status, ACK if the decoding is correct, NAK if the decoding fails. In general, resources for transmitting data feedback are also configured in DCI scheduling data transmission. Receiving the ACK at the base station will let it know that the device has received the data and can continue to send the next data packet. After the base station receives the NAK, it will use the retransmission protocol.

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

According to the present disclosure, the physical layer protocol does not require implicit or explicit feedback of data transmission. This reduces control overhead for transmission, thereby improving resource efficiency. However, in many cases, reliability may be more important than resource efficiency. To ensure that the preferred protocol is selected, the network may configure whether to use feedback for each device. The network may use RRC signaling to configure activation (activation) or deactivation (de-activation) of feedback. The RRC signaling may be user specific.

A user specific RRC parameter is provided that controls the activation/deactivation of data feedback on the physical layer. As if the MTC device entered the network, it initially needs to synchronize and register with the network. Thus, the default values for data feedback are active at device activation (registration), so that the device is reliably registered on the network, and both the device and the network can exchange important system and registration information.

Once the initial configuration is completed and the device begins to function properly, the network may disable data feedback at the physical layer. This may be part of the initial configuration, for example, or the network may disable feedback to the device later through RRC signaling.

When physical layer communications have been configured without feedback, the DCI for DL data need not convey a resource indication for the feedback, in which case the indication is invalid. This would allow the size of DCI to be reduced, where fields related to feedback have been deleted. The reduction of DCI size is positive because it results in improved resource efficiency for a given reliability or improved reliability for a given resource utilization.

If the communication is configured in a semi-persistent or other unlicensed or configured licensed manner, the configuration will not require allocation and reservation of feedback resources in case the feedback of a particular user is not valid. This will improve the resource efficiency of the communication.

In another approach, some dynamic control may be required for the activation/deactivation of physical layer feedback, which may be part of the DCI. One way to achieve this is to utilize existing DCIs that have certain fields to indicate feedback resources. A fixed set of values may be selected for these feedback fields that indicate that feedback has been disabled when transmitted. These values should be chosen carefully so that they have no meaning or value allowed to be used for these fields and should be known to both the sender and the receiver. This approach is advantageous from the perspective that no additional DCI design is required.

Thus, the network may disable physical layer data feedback in DCI. The network may send a specific combination of values assigned to the fields related to physical layer feedback, which means that the currently transmitted feedback is deactivated. Currently in DCI scheduling DL data, there are some fields indicating resources, timing and power control for HARQ response. These fields are Physical Uplink Control Channel (PUCCH) resources, Transmit Power Control (TPC) of PUCCH, PDSCH-to-HARQ feedback timing indicator. Thus, a fixed combination of values assigned to these fields, or a subset of these fields, may indicate deactivation of the UE's feedback for the transmission.

Another way to do this could be to introduce a flag in the DCI scheduling the transmission, which indicates the activation or deactivation of the HARQ physical layer feedback. This is useful, for example, for UL communication with asynchronous (asynchronous) HARQ using implicit feedback. Since no explicit ACK/NAK is sent, there is no field in the DCI that is associated with the ACK/NAK. In this case, the device will typically wait a period of time to see if there is DCI and reschedule the earlier transmitted packet before assuming an implicit ACK. Thus, to allow configurability when a device does not need to wait for the next DCI and goes to sleep immediately after transmission, such a protocol would require special encoding of some existing fields or addition of a new field to provide an indication of whether a HARQ response (although implicit here) is valid.

If the communication occurs without dynamic authorization, such as following a semi-persistent, configured grant or un-grant type protocol, etc., the activation or deactivation of physical layer data feedback may be part of the configuration of these protocols. Currently, semi-persistent scheduling can configure a device with conventional resources for uplink, downlink, or bi-directional. Thus, a portion of the initial configuration for semi-persistent scheduling may also have parameters that enable or disable HARQ feedback. The 5G NR standardizes two types of configured grant (configured grant) or unlicensed communication for UL data transmission. Here, the device is configured with periodic resources and other transmission related parameters. To avoid signaling activation/deactivation of physical layer HARQ feedback separately, it would be beneficial to signal it together with the configuration of the "configured grant".

For devices that are not configured with physical layer data feedback, there may be situations where feedback may be needed. One example might be data related to system information changes. Although most MTC devices will be static, some MTC devices may be moving, as may be installed on some moving vehicles. Thus, in some cases, system information, data related to measurements or other important data may require feedback. Therefore, these devices should be able to send/receive physical layer HARQ feedback for some packets and not for others.

In one example, a device is configured not to send/receive physical layer HARQ feedback through RRC signaling, then if there are some other DCI commands (e.g., for system information changes, measurements, etc.), then the HARQ ACK/NAK field in the DCI provides a meaningful value, the device will send a HARQ response for data scheduled through this particular DCI, while the no data feedback protocol will still continue to be maintained for other data communications that receive no feedback configuration through RRC signaling.

The reader will understand that the no-data feedback may also already be part of the configured grant, the unlicensed grant, or the semi-persistent configuration, and it will continue to perform the above example while still sending physical layer HARQ feedback for the dynamically configured packet, indicating that the physical layer HARQ feedback is implicitly or explicitly active.

In some cases, the devices may run different services, and it is possible that they know the surrounding devices. In certain situations, the device may also be located far from the base station. Therefore, even if the DL packet can be successfully decoded, it takes much effort in transmitting HARQ feedback to the base station. We can also imagine smart devices (possibly sensors) that do not want to send feedback in the UL direction when the battery is exhausted, or do not want to stay awake to receive DL feedback for a long time. Therefore, in this case, it may be beneficial for the device to request the network to enable/disable physical layer HARQ feedback.

Typical data transmission in most advanced wireless systems (e.g., LTE and evolved LTE) is divided into three steps:

step 1: control information is transmitted from the network to provide scheduling and control information.

Step 2: and carrying out data transmission in the UL or DL direction according to the control information of the step 1.

And step 3: implicit or explicit HARQ response (data feedback) for the data transmitted in step 2.

Even step 1 has the prerequisite that the UE is in RRC connected state, and furthermore, in case of UL data transmission it has issued a request by sending SR in UL direction.

Although to better accommodate different types of traffic, for example, the regular control information (step 1) may be skipped using semi-persistent scheduling, which has been standardized in 5G NR using the terminology of unlicensed or configured-licensed transmission. Such transmissions provide a periodic configuration of resources that the UE can use for UL or DL transmission of data without scheduling for each individual interval.

The communication protocol follows an explicit physical layer HARQ response, where the receiver will send the ACK or NAK status of the data to the sender. An implicit method of physical layer HARQ response in the DL direction (for UL data) may be an indication in the control (step 1) by using a subsequent data packet. For example, a field "New Data Indicator (NDI)" may be used to indicate whether newly scheduled Data is New Data or previously transmitted Data. LTE utilizes NDI in combination with HARQ process Identification (ID) to obtain retransmission of previously scheduled/transmitted data. The HARQ ID with the non-toggled NDI field refers to the retransmission, which actually becomes a NAK for a previously transmitted UL packet, and if NDI is toggled, it refers to a new transmission, thus acknowledging the previously transmitted packet.

In order to accommodate a large number of devices in a network, especially those with small data packets and machine type communications, it is important that the communications use resources as efficiently as possible. This is in fact a way to support hundreds of thousands of devices on a limited number of transmission resources. For this purpose, it is proposed to remove the dynamic scheduling and physical layer data feedback parts from the data transmission. This means that step 1 and step 3 are not part of the data transmission process and the data transmission is done without dynamic scheduling from the base station and data feedback from the receiving side.

Thus, the network can configure the physical layer data transport protocol for the user without dynamic control information and data feedback.

To avoid sending scheduling and control information before each data transmission (step 1), the base station may configure a set of configuration parameters for the user such that it sends/receives data infrequently when it arrives from higher layers, where the resources, periodicity and transmission parameters are part of the configuration of the transmission, which the user has configured before starting such a transmission. Semi-persistent scheduling, configured grant and unlicensed grant are examples of such transmission schemes.

The configuration of such transmission without dynamic control information may schedule users on non-orthogonal (non-orthogonal) resources, which would allow even a larger number of devices to co-exist for a given number of transmission resources, making the communication more efficient. In this case, various non-orthogonal multiple access (NOMA) methods are being studied to achieve 5G standardization. These methods allow multiple users to schedule on the same transmission resource and are separated by one or a combination of spreading codes (spreading codes), scrambling codes (scrambling codes), sparse codes (sparse codes), interleaving patterns (interleaving patterns), etc.

In another approach, suitable for devices without dynamic scheduling/control to operate, there is an indication related to the activation/deactivation of physical layer HARQ responses as part of the initial transmission configuration. Thus, the base station sends a configuration indication to the UE indicating the resource, periodicity, transmission parameters and indication of activation/deactivation of HARQ response. Thus, for certain devices that may not require a physical layer HARQ response for transmission, the base station may deactivate the transmission when it is configured. For other devices that happen to need physical layer HARQ responses for communication (in case of fire, etc., fire sensors in the forest, etc.), the base station may activate HARQ responses in an initial configuration of periodic or semi-periodic transmissions. In case of activating physical layer HARQ response, the base station may indicate other HARQ related parameters, i.e. HARQ timeline, HARQ resources and potentially sequences for HARQ etc.

For transmissions without dynamic grants (configured by semi-persistent scheduling, configured grant or grant-less manner, etc.), the initial configuration may include an indication of activation/deactivation of data feedback (HARQ response).

mtc devices have many applications, such as metering and sensors, which rarely transmit data. Furthermore, most of these devices will be physically installed in fixed geographical locations. This provides more opportunities for improving the communication protocols of these devices.

In a typical UL/DL communication, when a device is in RRC connected state but not UL synchronized, it will initiate a RACH procedure to keep itself synchronized in the UL direction when communication in the UL direction (arrival of data packets from higher layers) or DL direction (indication from the network) is required. This may be required for mobile devices and devices with high throughput requirements. Since many MTC devices will be static, the Timing Advance (TA) parameters related to UL synchronization will not change. Thus, in many cases, the TA value obtained by the device during initial configuration will be valid for a long period of time. Therefore, even in the deep sleep mode, these devices do not need a RACH procedure before data communication.

Thus, the device can start a new UL/DL information exchange without first transmitting a RACH preamble to acquire synchronization.

For devices with medium mobility, if the cell sizes are small to medium, their distance will result in a time lag within the cyclic prefix (cyclic prefix) and data can be decoded at the base station without PRACH transmission. Another way for these devices to maintain UL synchronization status is to use a larger cyclic prefix for MTC communications. A larger cyclic prefix will absorb changes in device location within its timing constraints. Thus, even for MTC devices with mobility, no RACH transmission may be useful, resulting in more efficient communication. Furthermore, some preamble sequences may be made part of the data transmission, which enables the base station to correctly detect the timing of the UL data.

Another way to avoid sending the PRACH preamble before almost every infrequent data exchange is to relax the threshold of the timer value and control the UE synchronization status. A relaxed timer value for UL synchronization would mean that the device would remain in UL synchronization state even after a long period of inactivity and would not need to transmit PRACH preamble if UL/DL data transmission is required.

That is, the threshold of the timer value controlling UL synchronization may be a large device compared to the typical inactivity time between two active periods, for avoiding frequent PRACH transmissions. This timer in LTE and 5G NR is called "time alignment timer". For 5G NR, 3GPP TS38.331 defines the following values for this timer:

time alignment timer: : enumerating { ms500, ms750, ms1280, ms1920, ms2560, ms5120, ms10240, infinity }

Therefore, this timer can be set to infinity and the devices will remain in UL synchronization state as long as they are in RRC connected state. A better way to keep the synchronization time longer is to add a new possible value for this timer that is suitable for MTC devices. In the current setting, the maximum value of less than infinity is only 10.24 seconds, which is clearly a small time between two information exchange events for most MTC devices. Thus, providing new values for time alignment in the range of minutes to hours may be a better choice for MTC devices, and the network may configure values that are appropriate for MTC device location, attributes and applications.

If a device must send small packets very infrequently, the overhead (resources, power) to move the device from a state in which it cannot send data to a state in which it can send data (e.g., RRC connected) may be much greater than the overhead of the information data itself. In LTE, RRC has only two states: RRC IDLE (RRC IDLE) and RRC connected, where information data exchange occurs only in the RRC connected state. In 5G NR, an additional state RRC INACTIVE (RRC _ INACTIVE) is added, where the UE maintains context and if UL/DL data transmission is required, the UE can quickly move to RRC connected but still perform data transmission in RRC connected state. For MTC applications where data transmission is infrequent, the proposal is to allow devices to send data without exchanging RRC messages required to change the RRC state. Thus, these devices can transmit data without having to change their state.

Thus, devices can exchange data after deep sleep without having to exchange messages required for RRC state change procedures.

If the UE can move itself from RRC inactive to RRC connected when the UE has UL data to send, the UE may remain in RRC inactive for a long period of time (increasing the timer value it can remain in RRC inactive state).

If it is not feasible to move the UE from RRC inactive to RRC connected without message exchange with the network, the following options are available to avoid message/state exchange when MTC devices have to transmit data:

1. data transmission may be allowed in RRC inactivity when required by the UE.

The UE may remain inactive for a longer duration in RRC connected.

Another possibility is to define a new lightweight RRC state suitable for MTC applications, in which the UE can stay in almost deep sleep for a longer duration, but can send infrequent UL packets.

In summary, there is provided: -

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

The network may choose to enable or disable data feedback indicating the status of the data transfer.

The network enables or disables feedback using user-specific RRC signaling.

For devices supporting a configurable HARQ feedback protocol, data feedback is active by default if the network does not provide any explicit values.

V. the network may disable data feedback using DCI. The network may send a specific combination of values assigned to fields related to feedback, which means that feedback is disabled for the current transmission.

The network can configure the data transfer protocol for the user without dynamic control information and data feedback.

For transmissions without dynamic grant (configured by semi-persistent scheduling, configured grant or grant-free approach, etc.), the initial configuration may include an indication of activation/deactivation of data feedback (HARQ response).

Before starting a new UL/DL information exchange, the device may operate without transmitting a RACH preamble to acquire UL synchronization.

IX. devices can exchange data after sleep without having to exchange messages required for the RRC state change procedure.

Although not shown in detail, any device or apparatus forming part of a network may comprise at least a processor, a memory unit, and a communication interface, wherein the processor unit, the memory unit, and the communication interface are configured to perform the method of any aspect of the invention. Further options and choices are described below.

The signal processing functions of embodiments of the present invention, particularly the gNB and the UE, may be implemented using computing systems or architectures known to those skilled in the art. Computing systems such as desktop, laptop or notebook computers, handheld computing devices (PDAs, cell phones, palmtop computers, etc.), mainframes, servers, clients, or any other type of special or general purpose computing device as may be desirable or appropriate for a given application or environment may be used. A computing system may include one or more processors, which may be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control module.

The computing system may also include a main Memory, such as a Random Access Memory (RAM) or other dynamic Memory, for storing information and instructions to be executed by the processor. Such main memory may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system may also include a Read Only Memory (ROM) or other static storage device for storing static information and instructions for the processor.

The computing system may also include an information storage system that 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), a read or write Drive (R or RW), or other removable or fixed media Drive. The 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 a media drive. The storage media may include a computer-readable storage medium having stored therein particular computer software or data.

In alternative embodiments, the information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. These components may include, for example, removable storage units and interfaces, such as program cartridges and cartridge interfaces, removable memory (e.g., flash memory or other removable memory modules) and memory slots, and other removable storage units, as well as interfaces that allow software and data to be transferred from the removable storage unit to the computing system.

The computing system may also include a communications interface. Such communication interfaces may be used to allow software and data to be transferred between the computing system and external devices. Examples of a communication interface may include a modem, a network interface (e.g., an ethernet or other NIC card), a communication port (e.g., a Universal Serial Bus (USB) port), a PCMCIA slot and card, etc. Software and data transferred via the communications interface are in the form of signals which may be electronic, electromagnetic, optical or other signals capable of being received by the communications interface medium.

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 memory, storage devices, or storage units. These and other forms of computer-readable media may store one or more instructions for use by a processor comprising a computer system, to cause the processor to perform specified operations. Such instructions, generally 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 the processor to perform specified operations, be compiled to perform specified operations, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to perform the specified operations.

The non-transitory computer readable medium may comprise at least one of the group of: hard disks, CD-ROMs, optical storage devices, magnetic storage devices, read-only memories, programmable read-only memories, erasable programmable read-only memories, EPROMs, electrically erasable programmable read-only memories, and flash memories. In embodiments where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system using, for example, a removable storage drive. When executed by a processor in a computer system, the control module (in this embodiment, software instructions or executable computer program code) causes the processor to perform the functions of the invention as described herein.

Furthermore, the concepts of the present invention are applicable to any circuit for performing signal processing functions within a network element. It is further contemplated that, for example, a semiconductor manufacturer may employ the inventive concepts in designing a stand-alone device, such as a microcontroller of a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), and/or any other subsystem component.

It will be appreciated that the above description, for clarity, describes embodiments of the invention with reference to a single processing logic. The inventive concept may, however, also be implemented by means of a number of different functional units and processors in order to provide signal processing functions. Hence, 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 organization.

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 or as configurable modular components, such as FPGA devices, running on one or more data processors and/or digital signal processors.

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 invention is limited only by the attached claims. In addition, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the word "comprising" does not exclude the presence of other elements or steps.

Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by e.g. a single unit or processor. Furthermore, 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. Furthermore, 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.

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. Furthermore, singular references do not exclude a plurality. Thus, references to "a", "an", "first", "second", etc., do not preclude a plurality.

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 invention is limited only by the attached claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize 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.

Claims (16)

1. A method of data communication in a cellular network of the physical layer, characterized in that it comprises the steps of: transmitting a configuration signal from a base station to a user equipment, the configuration signal indicating whether the user equipment should communicate data at a physical layer using an acknowledged or unacknowledged protocol; receiving the configuration signal at the user equipment and the user equipment configuring itself to utilize the indicated protocol; and carrying out data transmission between the user equipment and the base station according to the indicated protocol.

2. The method of claim 1, wherein the configuration signal is a radio resource control signal.

3. The method of claim 1, wherein the configuration signal is downlink control information.

4. A method according to any of claims 1 to 3, wherein the configuration signal is a user-specific signal.

5. The method according to any of claims 1 to 4, wherein said configuration signal is part of a configuration for semi-persistent scheduling type data transmission.

6. The method according to any of claims 1 to 5, wherein the configuration signal is part of a configured authorized (or unauthorized) configuration.

7. The method according to any of claims 1 to 6, wherein the default configuration utilizes an acknowledged protocol.

8. The method according to claim 3, wherein the unacknowledged protocol is indicated by a predefined value of a field of the downlink control information, the field of the downlink control information relating to an acknowledgement parameter.

9. The method of claim 8, wherein the predefined field is a field related to physical uplink control channel resources, transmit power control for the physical uplink control channel, and timing indicators for hybrid automatic repeat request feedback.

10. The method according to any of claims 1 to 9, characterized in that the selected protocol does not require random access channel transmission prior to data transmission.

11. The method according to any of claims 1 to 10, wherein the data transmission is an uplink data transmission.

12. The method according to any of claims 1 to 11, wherein the data transmission is a downlink data transmission.

13. The method according to any of claims 1 to 12, wherein for said uplink data transmission, the base station obtains an estimate of the data content of the data packets that failed decoding from the successfully decoded data packets received from the neighboring devices.

14. The method according to any of claims 1 to 13, characterized in that for said uplink data transmission, said base station obtains an estimate of the data content of a data packet that failed decoding from successfully decoded data packets received earlier by the same device.

15. A method according to any one of claims 1 to 14, wherein for said downlink data transmission, said device obtains an estimate of the data content of a data packet that failed to decode from a successfully decoded data packet received earlier by said base station.

16. The method of claim 1, wherein the device has requested an acknowledged mode or an unacknowledged mode for the data transmission.