US20140301354A1

US20140301354A1 - Virtual carrier sensing mechanism for long term evolution (lte)

Info

Publication number: US20140301354A1
Application number: US14/141,179
Authority: US
Inventors: Alexei Davydov; Vadim Sergeyev; Gregory Morozov; Apostolos Papathanassiou
Original assignee: Intel IP Corp
Current assignee: Intel IP Corp
Priority date: 2013-04-04
Filing date: 2013-12-26
Publication date: 2014-10-09
Also published as: US9160515B2; US20160021593A1; EP2982178A4; HK1217070A1; TWI532403B; KR20150119889A; EP2982178A1; TW201507501A; US10271314B2; CN110381542A; EP2982058A1; TWI552556B; EP2982154B1; EP2982055A1; US9191178B2; CN105122673A; CN105027469B; CN105009684A; US20140302887A1; TW201446043A

Abstract

Embodiments for providing virtual carrier sensing for LTE are generally described herein. In some embodiments, a first evolved Node B (eNB) sends a notification of subsequent DL transmission to a first UE in a downlink. In the uplink, the first UE sends a confirmation of the received DL notification. A second eNB overhears the confirmation, decodes it and extracts the information of the DL resources that the first eNB is planning to use. If the second eNB is not already transmitting in the indicated DL resources, the second eNB marks the indicated DL resources as busy and refrains from transmitting in those resources. The second eNB may then reschedule its transmission using alternative resources so that interference from the second eNB1 may be avoided.

Description

CLAIM OF PRIORITY

This application claims the benefit of priority to U.S. Provisional Patent Application Ser. No. 61/808,597, filed on Apr. 4, 2013, which is incorporated herein by reference in its entirety.

BACKGROUND

In cellular communication systems working below 10 GHz, and LTE in particular, the main performance limiting factor is interference. In the downlink, the interference results from transmissions of neighboring base stations (BSs)/evolved Node Bs (eNBs). To reduce interference in the downlink, the current approach is to coordinate transmissions of eNBs in several cells so the cells do not affect, or at least have less impact on, the reception of users in neighboring cells.
LTE provides various mechanisms for such coordination in CoMP (Coordinated MultiPoint) specifications. However, this type of coordination uses a backhaul link between the coordinated eNBs. For example, current interference coordination mechanisms that use backhaul connectivity between the coordinating eNBs fail if the connection is absent, if the backhaul link delay presents a problem or if the backhaul link has insufficient throughput performance. In these cases, the CoMP approach fails. The interference problem has even more impact in the deployment with small cells due to very large number of small cell eNBs (SC-eNBs) and the inability of operators to provide a predetermined backhaul connectivity between them.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a wireless network according to an embodiment;

FIG. 2 illustrates a flow chart of a method for provide virtual carrier sensing for LTE according to an embodiment;

FIG. 3 is a message flow diagram illustrating method for providing a notification based on virtual carrier sensing for LTE according to an embodiment;

FIG. 4 is a message flow diagram illustrating method for providing a confirmation to a notification based on virtual carrier sensing for LTE according to an embodiment;

FIG. 5 illustrates an evolved Node B (eNB) according to an embodiment; and

FIG. 6 illustrates a block diagram of an example machine for providing virtual carrier sensing mechanism for LTE according to an embodiment.

DETAILED DESCRIPTION

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass available equivalents of those claims.
According to an embodiment, a mechanism is provided to coordinate interference from neighboring eNBs when there is poor connectivity between the eNBs. Potential downlink transmissions are detected in the neighboring cell similar to virtual carrier sensing used in WiFi. Interference mitigation according to an embodiment may be implemented with coordinating eNBs that do not have backhaul link. Therefore, the interference mitigation according to an embodiment is more robust and provides system performance improvement even for simple deployments.
In Wi-Fi® networks, radio frame collisions may occur when simultaneous transmissions from several stations to the same or different stations interfere with each other thus becoming impossible to decode. To reduce the number of radio frame collisions in Wi-Fi® networks, an exchange of short control frames is used prior to sending the large frame with the data payload. These are Request to Send (RTS) and Clear to Send (CTS) frames that are sent, respectively, by initiator and recipient of the intended transmission. Each of these frames contains an indication of a time interval that the transmission would occupy. Thus stations around the initiator and recipient become aware of the intended transmission and keep silent for the indicated period, which allows the communication to be successfully sent.
FIG. 1 illustrates a wireless network 100 according to an embodiment. In FIG. 1, evolved Node B one, i.e., eNB1 110, is the home cell, and eNB2 120 is the interfering cell. UE 2 122 experiences interference 114 from eNB 1 110 and UE 1 112 experiences interference 124 from eNB2 120. The interference problem is even more of a problem in networks with small cells due to very large number of small cell eNBs (SC-eNBs). Those skilled in the art will recognize the term eNB may be used to refer to base transceiver stations (BTSs), evolved node Bs (eNBs), small cell evolved node Bs (SC-eNBs), etc. Base transceiver station (BTS) may also refer to radio base station (RBS), node B (in third generation (3G) networks, or base station (BS). However, to provide clarity, eNB will be used herein. LTE uses a backhaul link 130 between the coordinated eNBs 110, 120 to provide coordination between eNBs 110, 120 using CoMP (Coordinated MultiPoint) specifications. The eNBs 110, 120 may be connected over the backhaul link 130 to a radio network controller (RNC) 140. However, those skilled in the art will recognize that the eNBs, i.e., eNB1 110 and eNB2 120, may include a controller and thus the RNC 140 may not be provided. The connectivity provided by the backhaul link 130 between the coordinating eNBs 110, 120 may fail if the connection is absent, if delay associated with the backhaul link 130 presents a problem or if the backhaul link 130 has insufficient throughput performance. In these cases, the CoMP approach fails. The interference 114, 124 has even more impact in the deployment with small cells due to use of a very large number of small cell eNBs (SC-eNBs) and the inability of operators to provide a predetermined backhaul connectivity between them.
FIG. 2 illustrates a flow chart 200 of a method for provide virtual carrier sensing for LTE according to an embodiment. Enabling downlink interference coordination, in LTE for example, involves interfering eNB2 being aware of potential downlink transmission from eNB 1 to UE 1 in the home cell, the cell provided by eNB 1. To achieve this, eNB 1 sends a notification of subsequent DL transmission to the UE 1 in the downlink 210. The notification includes information of how many subframes will be used by the subsequent transmission, and which frequency resources, physical resource blocks (PRBs), will be used. The notification may be transmitted in the Downlink Control Information (DCI) field in order to enable the UE 1 to process the notification quickly, e.g., within up to 4 subframes. The eNB2 cannot hear this notification because the eNB2 is also transmitting in the same time-frequency resources. In the uplink, UE 1 sends a confirmation of the received DL notification 220. In this confirmation, the UE 1 includes information of the DL frame resources that eNB1 plans to use when sending data to UE 1.
Since UE 1 sends its confirmation in the uplink resources, eNB2 can overhear the confirmation, decode it and extract the information of the DL resources that eNB 1 is planning to use 230. A determination is made whether eNB2 is already transmitting in the indicated DL resources 240. If not 242, eNB2 marks the indicated DL resources as busy and refrains from transmitting in those resources 250. If yes 244, a determination is made whether the eNB2 was going to occupy these resources itself to transmit data to UE 2 260. If not 262, the eNB2 does not reschedule the transmission to alternative resources 270. If yes 264, the eNB2 reschedules the transmission using alternative resources so that interference with eNB1 to UE 1 transmission is avoided 280.
FIG. 3 is a message flow diagram 300 illustrating method for providing a notification based on virtual carrier sensing for LTE according to an embodiment. In FIG. 3, two eNBs are shown: eNB1 310 and eNB2 320. The eNB1 310 and eNB2 320 may operate in accordance with a Third Generation Partnership Project (3GPP) LTE/LTE-A (Long Term Evolution/Long Term Evolution-Advanced) or other suitable wireless wide area network (WWAN) protocol, and may include a configuration to provide wireless network communications in operation with an evolved packet core (EPC) 360, for communication of data to an Internet Protocol (IP) network 370. Both eNB1 310 and eNB2 320 plan to transmit to their respective UEs, UE 1 312 and UE 2 322, and, in accordance with their plans, transmissions are going to overlap in frequency. The eNB1 310 sends a notification 330 to UE 1 312. The potential eNB1/UE 1 transmission 340 is shown overlapping with the planned eNB2/UE 2 transmission 350.
FIG. 4 is a message flow diagram 400 illustrating method for providing a confirmation to a notification based on virtual carrier sensing for LTE according to an embodiment. In FIG. 4, UE 1 412 sends a confirmation 460 to eNB1 410. The eNB1 410 and eNB2 420 may again provide wireless network communications in operation with an evolved packet core (EPC) 460, for communication of data to an Internet Protocol (IP) network 470. However, eNB2 420 overhears the confirmation 480 sent by UE 1 412. The eNB2 420 may thus reschedule its planned transmission to the UE 2 422. The reschedule eNB2/UE 2 transmission 450 does not overlap with the potential eNB1/UE 1 transmission 440.
FIG. 5 illustrates an evolved Node B (eNB) 500 according to an embodiment. The eNB 500 contains at least one radio transmitter 510, receiver 512, an antenna system 514, a control section 516, memory 518 and a power supply 520. The control section 516 of the eNB 500 may include a controller 530. The controller may be arranged to provide resource management and logic control functions for allowing eNBs to directly communicate with each other.
The controller 530 of the eNB 500 may also provide functions including radio resource management (RRM), radio bearer control, radio admission control (access control), connection mobility management, resource scheduling between UEs and eNB radios, scheduling and transmitting messages (incoming calls and connection requests), broadcast information coordination (system information), and measurement reporting (to assist in handover decisions). The controller 530 is further arranged to transmit PDSCH data and DM-RS to the UE(s). Upon receiving CQI feedback from the UE(s), the controller 530 is arranged to apply and/or adjust the MCS and include the applied and/or adjusted MCS to the next PDSCH.
In alternative embodiments, the eNB 500 may operate as a standalone device or may be connected (e.g., networked) to other machines. The controller 530 may be capable of executing instructions (sequential or otherwise) that specify actions to be taken by the eNB 500. Further, while a single controller 530 is illustrated, the term “controller” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. In an example, at least a part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more controller 530 may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on at least one machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
At least one machine readable medium 580 may be used to store one or more sets of data structures or instructions 582 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 582 may also reside, at least partially, on additional machine readable memories such as memory 518, or within the controller 530 during execution thereof by the eNB 500. In an example, one or any combination of the controller 530, the memory 518, etc. may constitute machine readable media. While the machine readable medium 580 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that configured to store the one or more instructions 582.
The term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the eNB 500 and that cause the eNB 500 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The instructions 582, may further be transmitted or received over bus 552 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.).
FIG. 6 illustrates a block diagram of an example machine 600 for providing virtual carrier sensing mechanism for LTE according to an embodiment upon which any one or more of the techniques (e.g., methodologies) discussed herein may perform. In alternative embodiments, the machine 600 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 600 may operate in the capacity of a server machine and/or a client machine in server-client network environments. In an example, the machine 600 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine 600 may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.
Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, at least a part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors 602 may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on at least one machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
Accordingly, the term “module” is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform at least part of any operation described herein. Considering examples in which modules are temporarily configured, a module need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor 602 configured using software; the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. The term “application,” or variants thereof, is used expansively herein to include routines, program modules, programs, components, and the like, and may be implemented on various system configurations, including single-processor or multiprocessor systems, microprocessor-based electronics, single-core or multi-core systems, combinations thereof, and the like. Thus, the term application may be used to refer to an embodiment of software or to hardware arranged to perform at least part of any operation described herein.
Machine (e.g., computer system) 600 may include a hardware processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 604 and a static memory 606, at least some of which may communicate with others via an interlink (e.g., bus) 608. The machine 600 may further include a display unit 610, an alphanumeric input device 612 (e.g., a keyboard), and a user interface (UI) navigation device 614 (e.g., a mouse). In an example, the display unit 610, input device 612 and UI navigation device 614 may be a touch screen display. The machine 600 may additionally include a storage device (e.g., drive unit) 616, a signal generation device 618 (e.g., a speaker), a network interface device 620, and one or more sensors 621, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine 600 may include an output controller 628, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR)) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
The storage device 616 may include at least one machine readable medium 622 on which is stored one or more sets of data structures or instructions 624 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 624 may also reside, at least partially, additional machine readable memories such as main memory 604, static memory 606, or within the hardware processor 602 during execution thereof by the machine 600. In an example, one or any combination of the hardware processor 602, the main memory 604, the static memory 606, or the storage device 616 may constitute machine readable media.
While the machine readable medium 622 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that configured to store the one or more instructions 624.
The term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine 600 and that cause the machine 600 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
The instructions 624 may further be transmitted or received over a communications network 626 using a transmission medium via the network interface device 620 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks ((e.g., channel access methods including Code Division Multiple Access (CDMA), Time-division multiple access (TDMA), Frequency-division multiple access (FDMA), and Orthogonal Frequency Division Multiple Access (OFDMA) and cellular networks such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), CDMA 2000 1x* standards and Long Term Evolution (LTE)), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802 family of standards including IEEE 802.11 standards (WiFi), IEEE 802.16 standards (WiMax®) and others), peer-to-peer (P2P) networks, or other protocols now known or later developed.
For example, the network interface device 620 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 626. In an example, the network interface device 620 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 600, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to those shown or described. However, also contemplated are examples that include the elements shown or described. Moreover, also contemplate are examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.
Publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) are supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to suggest a numerical order for their objects. The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with others. Other embodiments may be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure, for example, to comply with 37 C.F.R. §1.72(b) in the United States of America. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. However, the claims may not set forth features disclosed herein because embodiments may include a subset of said features. Further, embodiments may include fewer features than those disclosed in a particular example. Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate embodiment. The scope of the embodiments disclosed herein is to be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

What is claimed is:

1. A method for providing virtual carrier sensing for long term evolution (LTE), comprising:

receiving in a first downlink transmission from an evolved Node B (eNB) a notification of a subsequent downlink (DL) transmission, the notification including information identifying DL frame resources the eNB plans to use in a subsequent DL transmission; and

sending a confirmation of the received DL notification in an uplink, wherein the confirmation includes the information identifying DL frame resources the eNB plans to use in the subsequent DL transmission.

2. The method of claim 1, wherein the receiving the notification including information identifying DL frame resources the eNB plans to use in the subsequent DL transmission comprises receiving the notification including information identifying how many subframes will be used by the subsequent transmission, and which frequency associated with physical resource blocks (PRBs) will be used; and

3. The method of claim 1, wherein receiving the notification further comprises receiving the notification in a Downlink Control Information (DCI) field.

4. The method of claim 3, wherein the receiving the notification in the Downlink Control Information (DCI) field comprises receiving the notification using a same time-frequency resource.

5. The method of claim 1, wherein the sending the confirmation in the uplink comprises sending the confirmation in an uplink received by at least a second eNB for allowing the at least second eNB to reschedule its transmissions using a time-frequency resources different than time-frequency resources used in the subsequent transmission of the eNB.

6. The method of claim 1 further comprises operating in accordance with a Third Generation Partnership Project (3GPP) LTE/LTE-A (Long Term Evolution/Long Term Evolution-Advanced).

7. A method for providing virtual carrier sensing for long term evolution (LTE), comprising:

monitoring an uplink for an uplink transmission from a user equipment (UE);

receiving a confirmation of a DL notification in an uplink transmission; and

processing the confirmation in the uplink transmission to identify DL frame resources at least a second eNB plans to use in a subsequent DL transmission by the at least second eNB.

8. The method of claim 7, wherein the receiving the confirmation further comprises receiving a confirmation from the UE in response to the UE receiving a notification including information identifying how many subframes will be used by the subsequent transmission, and which frequency associated with physical resource blocks (PRBs) will be used.

9. The method of claim 7 further comprises decoding the confirmation, extracting information from the decoded confirmation associated with the information identifying how many subframes will be used by the subsequent transmission, and which frequency associated with physical resource blocks (PRBs) will be used.

10. The method of claim 9 further comprising rescheduling transmissions based on the extracted information to uses a time-frequency resources different than time-frequency resources used in the subsequent transmission of the at least second eNB.

11. The method of claim 7 further comprising marking DL frame resources the at least second eNB plans to use in a subsequent DL transmission as busy and refraining from using the marked DL frame resources.

12. An evolved Node B (eNB), comprising:

a transceiver for receiving and transmitting signals; and

a controller, coupled to the transceivers, the controller arranged to provide virtual carrier sensing for long term evolution (LTE) by:

13. The eNB of claim 12, wherein the controller further receives the notification including information identifying how many subframes will be used by the subsequent transmission, and which frequency associated with physical resource blocks (PRBs) will be used.

14. The eNB of claim 12, wherein the controller further receives the notification in a Downlink Control Information (DCI) field.

15. The eNB of claim 14, wherein the controller further receives the notification in the Downlink Control Information (DCI) field using a same time-frequency resource.

16. The eNB of claim 12, wherein the controller further sends the confirmation in an uplink received by at least a second eNB for allowing the at least second eNB to reschedule its transmissions using a time-frequency resources different than time-frequency resources used in the subsequent transmission of the eNB.

17. The eNB of claim 12, wherein the controller further operates in accordance with a Third Generation Partnership Project (3GPP) LTE/LTE-A (Long Term Evolution/Long Term Evolution-Advanced).

18. An evolved Node B (eNB) for providing virtual carrier sensing for long term evolution (LTE), comprising:

a transceiver for receiving and transmitting signals; and

monitoring an uplink for an uplink transmission from a user equipment (UE);

receiving a confirmation of a DL notification in an uplink transmission; and

19. The eNB of claim 18, wherein the controller further receives a confirmation from the UE in response to the UE receiving a notification including information identifying how many subframes will be used by the subsequent transmission, and which frequency associated with physical resource blocks (PRBs) will be used.

20. The eNB of claim 18, wherein the controller further decodes the confirmation and extracts information from the decoded confirmation associated with the information identifying how many subframes will be used by the subsequent transmission, and which frequency associated with physical resource blocks (PRBs) will be used.

21. The eNB of claim 20, wherein the controller further reschedules transmissions based on the extracted information to uses a time-frequency resources different than time-frequency resources used in the subsequent transmission of the at least second eNB.

22. The eNB of claim 18, wherein the controller further marks DL frame resources the at least second eNB plans to use in a subsequent DL transmission as busy and refrains from using the marked DL frame resources.