WO2013086362A1 - Direct communication between wireless transmit/receive units (wtrus) in advanced topology (at) applications - Google Patents
Direct communication between wireless transmit/receive units (wtrus) in advanced topology (at) applications Download PDFInfo
- Publication number
- WO2013086362A1 WO2013086362A1 PCT/US2012/068502 US2012068502W WO2013086362A1 WO 2013086362 A1 WO2013086362 A1 WO 2013086362A1 US 2012068502 W US2012068502 W US 2012068502W WO 2013086362 A1 WO2013086362 A1 WO 2013086362A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- wtru
- cross link
- helper
- radio
- grant
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/02—Selection of wireless resources by user or terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
- H04W76/14—Direct-mode setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
Definitions
- LTE-A Long Term Evolution-Advanced
- LTE-A decode-and-forward relay nodes receive data from a first device, demodulate, decode and error correct the data, and then re-transmit a new signal to a second device. This is different from a traditional repeater, for example, which simply receives and re-broadcasts a signal received from another device.
- the decode-and-relaying scheme while more complex, may enhance signal quality over re-broadcasting, which may degrade signal quality from reduced signal-to-noise ratio (SNR).
- SNR signal-to-noise ratio
- Type-1 relays control their own cells with their own identity.
- a type-1 relay appears to be a normal enhanced NodeB (eNB).
- eNB enhanced NodeB
- Type-2 relays do not have their own cell identity and appear to WTRUs and eNBs as the main eNB in the cell.
- the backhaul link between a type- 1 relay node and a donor eNB and each access link between the type-1 relay node and each WTRU have their own full Layer-2 stacks, including full medium access control (MAC), radio link control (RLC) and packet data control protocol (PDCP) layers, all of which are terminated at the donor eNB, the relay node and the WTRU whose data is being relayed ("terminal WTRU").
- MAC medium access control
- RLC radio link control
- PDCP packet data control protocol
- terminal WTRU Due to, for example, the relative complexity of the type-1 decode-and-forward relay nodes proposed for LTE-A, these nodes may be more powerful than WTRUs and are most likely stationary.
- a method, apparatus and system for direct communication between nodes in advanced topology (AT) applications are disclosed.
- the method includes a first node receiving a cross link grant specifying resources for use by at least the first node for transmission on the radio cross link.
- the first node also performs cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link grant and transmits at least one packet to a second node based on the cross link scheduling grant per TTI.
- TTI transmission time interval
- FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented
- FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;
- WTRU wireless transmit/receive unit
- FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;
- FIG. 2 is a system diagram of an LTE-A relay system
- FIG. 3 is a block diagram of a Layer-2 stack for the LTE-A relay system of FIG. 2;
- FIG. 4 is a diagram of an example cross link (XL) physical layer
- FIG. 5 is a diagram of examples of different possibilities for multiplexing different XL physical channels into different types of XL sub- frames
- FIGs. 6A, 6B, 6C and 6D are diagrams of example channel mappings between logical, transport and physical channels on the XL;
- FIG. 7A is a block diagram of a Layer-2 stack for an AT system
- FIG. 7B is a diagram of an example system architecture for an embodiment where separate data radio bearers (DRBs) are set up to carry data through the direct path and the relay path, respectively;
- DRBs data radio bearers
- FIG. 8 is a flow diagram of a method of discarding stalled data at a helper WTRU on the downlink;
- FIG. 9 is a diagram of a header for a radio link control (RLC) unacknowledged mode (UM) segment that a helper WTRU may use to perform re- segmentation on a first hop RLC UM protocol data unit (PDU);
- RLC radio link control
- UM unacknowledged mode
- FIG. 10 is a diagram of an RLC STATUS PDU that may be used for carrying a highest dropped sequence number (HDSN) over a second hop in RLC acknowledged (AM) mode;
- HDSN highest dropped sequence number
- AM RLC acknowledged
- FIGs. 11 and 12 are diagrams of example RLC PDUs with an extension (E2) bit and an optional LT field;
- FIG. 13 is a diagram of an example procedure for RLC PDU discard at the helper WTRU
- FIGs. 14A and 14B include a diagram of an example procedure for moving the receive (Rx) window at the helper WTRU in RLC AM mode;
- FIGs. 15A and 15B include a diagram of an example procedure for moving the Rx window at the helper WTRU when the HDSN is lost;
- FIG. 16 is a diagram of an example MAC control element for carrying flow information on the traditional radio link (TRL) uplink (UL);
- FIG. 17 is a diagram of an example mapping between logical channels on the XL to logical channels on the TRL;
- FIG. 18 is a diagram showing an example conversion of a buffer status report (BSR) on the cross UL (XUL) shared channel to a UL BSR (TBSR) on the TRL UL-service channel (UL-SCH);
- BSR buffer status report
- XUL cross UL
- TBSR UL BSR
- FIG. 19 is a diagram illustrating example transmission of a UL
- FIG. 20 is a diagram illustrating example transmission of a downlink (DL) BSR in coverage extension mode in AT applications
- FIG. 21 is a flow diagram of a method of a terminal WTRU in radio resource control (RRC) connected mode sending an XUL scheduling request to an eNB using TBSR;
- RRC radio resource control
- FIG. 22 is a flow diagram of a method of a terminal WTRU in RRC connected mode sending an XUL scheduling request to an eNB using an XL scheduling request (XUSR);
- XUSR XL scheduling request
- FIG. 23 is a flow diagram of a method of a helper WTRU relaying an
- FIG. 24 is a flow diagram of a method of a helper WTRU relaying an
- FIG. 25 is a flow diagram of a method of a helper WTRU relaying an
- XUSR to an eNB on the TRUL UL-SCH using an XUSR medium access control (MAC) control element;
- MAC medium access control
- FIG. 26 is a flow diagram of a method of a helper WTRU relaying an
- FIG. 27 is a flow diagram of a method of a helper WTRU relaying an
- FIG. 28 is a flow diagram of a method of a helper WTRU sending an
- XL DL scheduling request (XDSR) to an eNB on the TRL UL-SCH using an XDSR MAC control element
- FIG. 29 is a flow diagram of a method of a helper WTRU sending an
- FIG. 30 is a signal diagram of a method of sending a TBSR to an eNB when a TRL UL grant is available;
- FIG. 31 is a signal diagram of a method of reporting an XL DL BSR
- FIG. 32 is a signal diagram of a method of sending an XL DL power headroom report (XDPHR) and an XUPHR to the eNB on the TRL UL-SCH;
- XDPHR XL DL power headroom report
- FIG. 33A is a diagram of a system of helper WTRUs and terminal
- FIG. 33B is a flow diagram of an example method of radio resource scheduling on a radio XL between a WTRU and another WTRU;
- Fig. 34 is a diagram of a cell where the XLs in the cell are arranged into frequency reuse groups;
- FIGs. 35A and 35B include a signal diagram of an example initial grant acquisition procedure and update XLG operation in a capacity mode
- FIGs. 36A and 36B include a signal diagram of another example initial grant acquisition procedure and update XLG operation in a capacity mode.
- FIGs. 37A and 37B include a signal diagram of an example initial grant acquisition and continued XLG update procedure in coverage mode.
- FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented.
- the communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users.
- the communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth.
- the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.
- CDMA code division multiple access
- TDMA time division multiple access
- FDMA frequency division multiple access
- OFDMA orthogonal FDMA
- SC-FDMA single-carrier FDMA
- the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements.
- WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment.
- the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
- UE user equipment
- PDA personal digital assistant
- smartphone a laptop
- netbook a personal computer
- a wireless sensor consumer electronics, and the like.
- the communications systems 100 may also include a base station
- Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112.
- the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
- the base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc.
- BSC base station controller
- RNC radio network controller
- the base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
- the cell may further be divided into cell sectors.
- the cell associated with the base station 114a may be divided into three sectors.
- the base station 114a may include three transceivers, i.e., one for each sector of the cell.
- the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
- MIMO multiple-input multiple output
- the base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.).
- the air interface 116 may be established using any suitable radio access technology (RAT).
- RAT radio access technology
- the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like.
- the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA).
- WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+).
- HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
- the base station 114a and the WTRUs 102a may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (
- E-UTRA Evolved UMTS Terrestrial Radio Access
- LTE Long Term Evolution
- LTE-A LTE-Advanced
- the base station 114a and the WTRUs 102a are identical to the base station 114a and the WTRUs 102a.
- 102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
- IEEE 802.16 i.e., Worldwide Interoperability for Microwave Access (WiMAX)
- CDMA2000, CDMA2000 IX, CDMA2000 EV-DO Code Division Multiple Access 2000
- IS-95 IS-95
- IS-856 Interim Standard 856
- GSM Global System for Mobile communications
- GSM Global System for Mobile communications
- EDGE Enhanced Data rates for GSM Evolution
- GERAN GSM EDGERAN
- the base station 114b in FIG. 1A may be a wireless router, Home
- Node B, Home eNode B, or access point may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like.
- the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN).
- the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
- WLAN wireless local area network
- WPAN wireless personal area network
- the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.
- a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.
- the base station 114b may have a direct connection to the Internet 110.
- the base station 114b may not be required to access the Internet 110 via the core network 106.
- the RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
- the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.
- the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT.
- the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.
- the core network 106 may also serve as a gateway for the WTRUs
- the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
- POTS plain old telephone service
- the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite.
- the networks 112 may include wired or wireless communications networks owned and/or operated by other service providers.
- the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
- Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.
- the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
- FIG. IB is a system diagram of an example WTRU 102.
- the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138.
- GPS global positioning system
- the processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
- the processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment.
- the processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
- the transmit/receive element 122 may be configured to transmit signals to, or receive signals from, for example, a base station (e.g., the base station 114a) or another WTRU over the air interface 116.
- the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals.
- the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
- the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
- the transmit/receive element 122 is depicted in
- the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
- the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
- the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
- the WTRU 102 may have multi-mode capabilities.
- the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
- the processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit).
- the processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128.
- the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132.
- the non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device.
- the removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
- SIM subscriber identity module
- SD secure digital
- the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
- the processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102.
- the power source 134 may be any suitable device for powering the WTRU 102.
- the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
- the processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
- location information e.g., longitude and latitude
- the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.
- the processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity.
- the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
- the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player
- FIG. 1C is a system diagram of the RAN 104 and the core network
- the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116.
- the RAN 104 may also be in communication with the core network 106.
- the RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment.
- the eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116.
- the eNode-Bs 140a, 140b, 140c may implement MIMO technology.
- the eNode-B 140a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
- Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.
- the core network 106 shown in FIG. 1C may include a mobility management gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
- MME mobility management gateway
- PDN packet data network
- the MME 142 may be connected to each of the eNode-Bs 142a, 142b,
- the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like.
- the MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
- the serving gateway 144 may be connected to each of the eNode Bs
- the serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c.
- the serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
- the serving gateway 144 may also be connected to the PDN gateway
- the WTRU 146 which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
- the core network 106 may facilitate communications with other networks.
- the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.
- the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108.
- IMS IP multimedia subsystem
- the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
- FIG. 2 is a system diagram of an LTE-A relay system 200.
- the illustrated LTE-A relay system includes a donor cell 202, a relay node 204 and a terminal WTRU 206.
- the donor cell 202 and the relay node 204 communicate with one another over a backhaul link 208.
- the relay node 204 and the terminal WTRU 206 communicate with one another over an access link 210.
- the relay node 204 may be configured to relay PDCP service data units (SDUs) between the donor cell 202 and the terminal WTRU 206.
- SDUs PDCP service data units
- the backhaul link 208 and the access link 210 may operate completely independently of one another.
- FIG. 3 is a block diagram of a Layer-2 (L2) stack 300 for the LTE-A relay system 200 of FIG. 2.
- the backhaul link 208 and each access link 210 have their own full L2 stacks, including full MAC, RLC and PDCP layers, all of which are terminated at the donor cell 202, the relay node 204 and the terminal WTRU 206.
- the donor cell 302 includes a MAC layer 314, an RLC layer 312 and a PDCP layer 310
- the terminal WTRU 306 similarly includes a PDCP layer 340, an RLC layer 342 and a MAC layer 344.
- the PDCP layer 310 of the donor cell 302 is in communication with a PDCP layer 320 of the relay node 304
- the RLC layer 312 of the donor cell 302 is in communication with an RLC layer 322 of the relay node 304
- the MAC layer 314 of the donor cell 302 is in communication with a MAC layer 324 of the relay node 304
- the PDCP layer 340 of the terminal WTRU 306 is in communication with a PDCP layer 326 of the relay node 304
- the RLC layer 342 of the terminal WTRU 306 is in communication with the RLC layer 328 of the relay node 304
- the MAC layer 344 of the terminal WTRU 306 is in communication with the MAC layer 330 of the relay node 304.
- a source relay node may forward any unsent PDCP SDUs to a target relay node via source and target donor eNBs in order to achieve a lossless handover.
- Flow control is not applied with the current LTE type-1 relay configuration, with the assumption that most traffic is transmission control protocol (TCP) based, and the TCP protocol should provide enough flow control capability.
- TCP transmission control protocol
- PDCP SDU discard may be used to clear a PDCP SDU if it is in the transmit buffer for too long. This may reduce the delay for subsequent data when the PDCP SDU buffer is full of stalled data caused by, for example, possible physical link errors.
- a discard timer associated with it may be started. When the timer expires, if no segment of an SDU has been mapped to an RLC PDU, the PDCP SDU is discarded.
- the timeout value of the discard timer may be configured by higher layers.
- scheduling is done by the eNB on the network side.
- the UL scheduling decision requires the WTRU to send MAC status reports to the eNB.
- a WTRU may send a UL scheduling request (ULSR) on a condition that the WTRU wants to initiate UL data transmission.
- ULSR UL scheduling request
- BSR buffer status report
- PHR power headroom report
- the ULSR is sent via the physical uplink control channel (PUCCH) or by a random access channel (RACH) procedure.
- PHRs and PHRs are sent through MAC control elements on the UL- service channel (UL-SCH).
- scheduling is channel- dependent and is performed by the eNB to allocate resources for both the UL and the downlink (DL) data channels dynamically on a per-transmission time interval (TTI) basis.
- TTI per-transmission time interval
- the granularity of resource allocation is realized in resource blocks (RBs), which are clusters of twelve contiguous sub-carriers occupying over the period of a TTI.
- RBs resource blocks
- LTE scheduling applies orthogonal multiple access in both the DL and UL to ensure that WTRUs associated with the same cell in any given TTI utilize orthogonal resources without intra-cell interference.
- the UL transmission power of each TTI over the assigned resources is regulated by the UL power control.
- the LTE scheduling algorithm generally takes into account a range of input parameters in an attempt to optimize a set of performance metrics, which may include, for example, maximum/average/minimum throughput, maximum/average/minimum delay, total/per-user spectral efficiency, and outage probability.
- performance metrics may include, for example, maximum/average/minimum throughput, maximum/average/minimum delay, total/per-user spectral efficiency, and outage probability.
- the user experiences are directly affected by the aforementioned performance metrics.
- the typical input parameters include quality of service class identifier (QCI), channel quality indicator (CQI), BSR, acknowledge/non- acknowledge (ACK/NACK) and resource allocation history.
- the scheduling is applied on the traditional downlink (TRDL) and the traditional uplink (TRUL).
- TRDL is the radio access link from the eNB to the WTRU associated with the eNB. It applies to all WTRUs associated with the network and operates in the standardized LTE DL frequency band.
- the physical channels carried on the TRDL include the physical downlink shared channel (PDSCH), the physical broadcast channel (PBCH), the physical multicast channel (PMCH), the physical control format indicator channel (PFICH), and the physical hybrid automatic repeat request (HARQ) indicator channel (PHICH).
- PDSCH physical downlink shared channel
- PBCH physical broadcast channel
- PMCH physical multicast channel
- PFICH physical control format indicator channel
- HARQ physical hybrid automatic repeat request
- the TRDL also carries physical signals, including reference and synchronization signals.
- the TRUL is the radio access link from the WTRU to the serving eNB.
- the TRUL also carries reference signals.
- TRDL/TRUL scheduling information is conveyed to each WTRU with the help of device class identifier (DCI) formats carried in the DL PDCCH in each TTI.
- DCI device class identifier
- DL scheduling takes effect in the same sub-frame in which the DL DCI is received.
- the UL grant takes effect a number of sub-frames following the sub-frame in which the UL DCI is received (e.g., 4 sub-frames in the LTE frequency division duplex (FDD) system).
- FDD frequency division duplex
- An LTE network has complete control of the resource allocation of each TRDL/TRUL pair in each TTI, and the WTRU only provides assistance in transmitting DL channel feedback and UL sounding reference signals in the TRUL.
- an advanced topology (AT) network In contrast to the type-1 relay nodes described above that make use of high power, stationary relay nodes, embodiments of an advanced topology (AT) network are described herein that make use of direct WTRU-to-WTRU communication and/or direct base station- to-base station communication to relay data between a network and a destination entity such as a terminal WTRU or a terminal base station ("AT-relay” or “AT-R” mode) or to transfer data directly between WTRUs or base stations ("AT-local offload” or "AT-LO” mode).
- a smart phone or base station may be configured to function as a mini infrastructure node, in addition to its primary roles, to operate in an AT-R and/or AT-LO mode.
- a terminal WTRU or base station may exchange data with the network through another WTRU or base station referred to as a helper WTRU or a helper base station, respectively.
- any WTRU may act as a terminal WTRU or a helper WTRU at different times, and data may be relayed between the terminal WTRU and an eNB using a two hop setup.
- the first hop may either be between the terminal WTRU and the helper WTRU or the eNB and the helper WTRU, and the second hop may be the hop not taken during the first hop, depending on whether the transmission is in the UL or DL.
- WTRUs in proximity to one another may engage in direct data communications with one another under control of a central network. While all of the embodiments are described herein with respect to the relay entity and the destination entity being WTRUs, all of the embodiments are equally applicable to a relay entity that is any type of node, such as a base station (e.g., an eNB), and/or a destination entity that is any type of node, such as a base station (e.g., an eNB).
- a base station e.g., an eNB
- a destination entity e.g., an eNB
- AT-R embodiments may be used to increase capacity (capacity mode or AT-RCap) and coverage (coverage mode or AT-RCov) in cellular systems.
- a helper WTRU may augment radio link capacity between existing WTRUs and a base station to enhance the capacity of the network and improve data transmission capacity.
- a helper WTRU may be used to provide coverage to WTRUs that are not in coverage and, therefore, do not have a link to the base station.
- WTRU may be considered to be in coverage if it is registered with the network (e.g., it is in an EMM-REGISTERED state), it is able to decode the broadcast channel (BCH) from a suitable cell in the network and read the primary system information (SI), it is able to decode the paging channel (PCH) and read paging messages and secondary SI, it is able to reach the cell using a RACH procedure in IDLE mode or the PUCCH/PUSCH in CONNECTED mode, and it is able to transmit and receive certain minimum data rates over the PUSCH and the PDSCH, respectively. WTRUs that do not satisfy these conditions may be said to be out of coverage and may continue to go through cell reselection until they find a suitable cell.
- BCH broadcast channel
- SI primary system information
- PCH paging channel
- secondary SI secondary SI
- such an out-of-coverage WTRU e.g., a potential terminal WTRU
- a helper WTRU may be provided coverage through a helper WTRU.
- the WTRU In order to take advantage AT-RCov, however, the WTRU must still have network synchronization and timing.
- two close-by WTRUs may initiate a local off-load transmission under control of a central network.
- a group of WTRUs in proximity may be assigned to a cluster with a cluster head designated by the network.
- the cluster head may communicate directly with each cluster member and may be responsible for access control and radio resource management (RRM) of all cross links (XLs) between individual pairs of WTRUs in the cluster.
- RRM radio resource management
- the cluster members may apply direct WTRU-to- WTRU communication.
- WTRU-to-WTRU communications may be applied to many real- world scenarios with significant potential benefits. For example, a user deep inside a building with very poor coverage may obtain coverage and additional capacity through a helper WTRU with good coverage situated at the periphery of the building or outside. For another example, users that are in close proximity and need to exchange data or have a voice conversation may do so directly without routing the data/voice through a base station and a core network. For example, co-workers in an office may have conversations and exchange data in this manner. Direct WTRU-to-WTRU communications may also enable applications related to social networking by providing information about other users belonging to the same social group that are in close proximity.
- One potential application may be to have instantaneous communication of accidents/traffic bottlenecks relayed to vehicles farther behind on the same road so that they may take diversions.
- WTRUs may occur in a dedicated channel referred to as a cross link (XL) as opposed to, for example, traditional eNB to WTRU communication that occurs over a traditional radio link (TRL).
- XL may be used for communications between a pair of WTRUs
- AT-R embodiments the XL may be used for communications between pairs of terminal WTRUs and helper WTRUs.
- RF radio frequency
- the XL resources may be located out-of-band with respect to the TRL.
- the XL channel may use OFDM for its physical layer (PHY) multiplexing, similar to, for example, baseline LTE.
- PHY physical layer
- the helper and terminal WTRUs may communicate with each other using FDD or time-division duplexing (TDD), and the related configuration may be defined by the network.
- the network may provide coarse resource allocation for the XL, and the WTRUs (e.g., one or both of the helper WTRU and the terminal WTRU) may have the freedom to handle the per-TTI resource allocation.
- FIG. 4 is a diagram of an example XL PHY frame structure 400.
- the XL PHY frame structure includes a number of frames (e.g., 440 and 450) and corresponding subframes (e.g., 402, 404, 406, 408 and 410).
- the subframes 402, 404, 406, 408 and 410 include a number of different zones, including a neighbor discovery zone 412, an unscheduled control zone 414, a normal control zone 416 and a data zone 418.
- the neighbor discovery zone 412 occurs twice in every frame, once in each direction, or based on network configuration.
- frame 440 includes an occurrence 412b of the neighbor discovery zone 412 in subframe 402 and an occurrence 412d of the neighbor discovery zone 412 in subframe 406. Only one subframe 410 of frame 450 is illustrated in FIG. 4, and subframe 410 includes an occurrence 412f of the neighbor discovery zone 412. However, frame 450 includes additional subframes (not shown), and one of the additional subframes may include an additional occurrence of the neighbor discovery zone.
- a WTRU may transmit a neighbor discovery initiation transmission (NDIT) 422 and await a neighbor discovery response transmission (NDRT) 420.
- NDIT neighbor discovery initiation transmission
- NDRT neighbor discovery response transmission
- the time- frequency resources may be divided into an unscheduled control zone (UCZ) 414, a normal control zone (NCZ) 416 and a data zone (DZ) 418.
- the neighbor discovery zone may be considered part of the subframe structure, in which case the subframe may also be considered to be the same direction as the neighbor discovery zone (e.g., transmit or receive).
- the UCZ 414 includes a predetermined set of resources that may occur in every frame (once in each direction) or in certain frames that may be calculated based on the cell system frame number (SFN) (e.g., based on network configuration).
- SFN cell system frame number
- all XLs in a cell may have a UCZ in the same frame.
- frame 440 includes an occurrence 414b of the UCZ 414 in subframe 402 and an occurrence 414d of the UCZ 414 in subframe 406. Only one subframe 410 of frame 450 is illustrated in FIG. 4, and it does not include an occurrence of the UCZ. However, frame 450 includes additional subframes (not shown), and some of the additional subframes may include an occurrence of the UCZ.
- a neighbor seeking WTRU may use the UCZ 414a to transmit to a neighbor present WTRU an indication that it has been selected by the neighbor seeking WTRU as the prospective helper WTRU ("helper WTRU select message") (426).
- the UCZ may also be used by the neighbor present WTRU to transmit basic system information to a neighbor seeking WTRU to enable association formation (424). The transmissions may occur prior to association formation and may potentially be transmitted without scheduling resources from the eNB. Thus, multiple neighbor present WTRUs may be transmitting basic system information in the same UCZ, which may provide a diversity benefit.
- Helper WTRU select messages from multiple neighbor seeking WTRUs may overlap in the same WTRU but may be separated using, for example, PHY scrambling mechanisms.
- the NCZ 416 occurs in every subframe.
- each of the subframes 402, 404, 406, 408 and 410 includes a respective NCZ occurrence 416b, 416c, 416d, 416e and 416f.
- Only one subframe 410 of frame 450 is illustrated in FIG. 4.
- frame 450 includes additional subframes (not shown), which may each include an occurrence of the NCZ.
- the NCZ e.g., 416a
- XPDCCH XL physical DL control channel
- XPUCCH XL physical UL control channel
- the DZ 418 occurs in every subframe within a frame.
- each of the subframes 402, 404, 406, 408 and 410 includes a respective DZ 418b, 418c, 418d, 418e and 418f.
- Only one subframe 410 of frame 450 is illustrated in FIG. 4.
- frame 450 includes additional subframes (not shown), which may each include an occurrence of the DZ as well.
- the DZ (e.g., DZ 418a) may be used to transmit data transport blocks (TBs) between the WTRUs, for example, on the cross link DL (XDL) shared channel (XPDSCH) 432 and the XUL shared channel (XPUSCH) 434.
- XDL cross link DL
- XPDSCH cross link DL
- XPUSCH XUL shared channel
- the DZs may also include reference signals that may enable the WTRUs to make measurements of the XL.
- the XL may include a number of physical channels in the XDL and the XUL.
- the XDL is the radio access link from the helper WTRU to the terminal WTRU. It applies to the helper WTRU and the terminal WTRU and operates in the XL frequency band.
- the XUL is the radio access link from the terminal WTRU to the helper WTRU. It applies to the helper WTRU and the terminal WTRU and operates in the XL frequency band.
- the XDL physical channels may include, for example, the XL physical neighbor discovery channel (XPNDCH), the XL physical DL association channel (XPDACH), the XL physical DL shared access channel (XPDSACH), the XL physical grant channel (XPGCH), the XL physical DL feedback channel (XPDFBCH), the XL physical DL data channel (XPDDCH) and the XL physical DL control channel (XPDCCH).
- XPNDCH the XL physical neighbor discovery channel
- XPDACH XL physical DL association channel
- XPDSACH the XL physical DL shared access channel
- XPGCH the XL physical grant channel
- XPDFBCH the XL physical DL feedback channel
- XPDDCH XL physical DL data channel
- XPDCCH XL physical DL control channel
- the XUL physical channels may include, for example, the XL physical neighbor discovery channel (XPNDCH), the XL physical UL association channel (XPUACH), the XL physical UL shared access channel (XPUSACH), the XL physical UL feedback channel (XPUFBCH), the XL physical UL data channel (XPUDCH) and the XL physical UL control channel (XPUCCH).
- the XUL may also carry reference signals including, for example, an XL specific reference signal and a keep alive signal.
- the XL physical channels are presumed to be OFDM based.
- the XPNDCH may carry sequences used for neighbor discovery transmissions, including neighbor discovery initiation transmissions (NDITs) and neighbor discovery response transmissions (NDRTs).
- the XPNDCH may occupy a default and pre-defined symbol and sub-carrier resource location that is not subject to XL grants or scheduling.
- the XPNDCH may apply code division multiple access (CDMA), and the code configuration may be derived by a WTRU, for example, according to pre-defined algorithms.
- CDMA code division multiple access
- the network may allocate additional resources (e.g., sub-carriers) for the channel in order to increase the neighbor discovery capacity.
- the XPDACH may carry PHY control information, including, for example, paging indicators, association transmit/receive (TX/RX) indicators or XL grant (XLG) indicators.
- the XPDACH may occupy a default and pre-defined symbol location, which may not be subject to XL grants (XLGs) or scheduling.
- the XPDACH may apply frequency division multiple access (FDMA) and/or CDMA, and the configuration may be derived by a WTRU based on the code configuration of its preceding associated XPNDCH.
- FDMA frequency division multiple access
- CDMA code configuration of its preceding associated XPNDCH.
- the XPUACH may carry PHY control information, including, for example, XL scheduling requests (XSRs) and XL measurement result indicators.
- XSRs XL scheduling requests
- XL measurement result indicators XL measurement result indicators.
- the XPUACH may occupy a default and pre-defined symbol location, which may not be subject to XLG and scheduling.
- the XPUACH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the code configuration of its preceding associated XPNDCH.
- the XPDSACH may carry higher layer control information, including, for example, basic system information (BSI), initial configuration information (InitConfiguration) (including XLG) and selected helper WTRU information.
- BSI basic system information
- InitialConfiguration initial configuration information
- XLG selected helper WTRU information
- the XPDSACH may occupy a default and predefined symbol location, which may not be subject to XL grants or scheduling.
- the XPDSACH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the configuration of its associated XPDACH.
- the information necessary to decode the channel such as transport format, may be pre-defined.
- the XPUSACH may carry higher layer control information, including, for example, XL measurement results.
- the XPUSACH may occupy a default and pre-defined symbol location, which may not be subject to XLGs or scheduling.
- the XPUSACH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the configuration of its associated XPUACH.
- the information necessary to decode the channel such as transport format, may be pre-defined.
- the XPGCH may carry XLG information, including, for example, sub-carrier allocation, TDD sub-frame duplex scheme, maximum XL power, dedicated XL channel code configuration and reference signal configuration.
- the XPGCH may occupy a default and pre-defined symbol location, which may not be subject to XLGs or scheduling.
- the XPGCH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the configuration of its associated XPDACH.
- This unscheduled version of the XPGCH may exist only in AT-R coverage mode.
- the XLG for the helper WTRU may also specify the complete resource configuration of this channel for XL dedicated use of XLG transmission from helper WTRU to terminal WTRU, and in that case, the XPGCH may apply space, time, frequency or code division multiple access. In an embodiment, this channel may be only applied on the XDL.
- the XPDFBCH may carry channel state information (CSI) of the
- the complete resource allocation of this channel may be determined by the XLG for the helper WTRU.
- the XDFBCH may apply space, time, frequency or code division multiple access.
- the XPDDCH may carry XDL user data received from the MAC layer.
- the complete resource allocation of this channel may be determined by the XLG for the helper WTRU.
- the XPDDCH may apply space, time, frequency, or code division multiple access.
- the XPDCCH may carry data related to control information for the terminal WTRU to decode the XPDDCH in the same TTI.
- the complete resource allocation of this channel may be determined by the XLG for the helper WTRU.
- the XPDCCH may apply space, time, frequency, or code division multiple access.
- the XPUFBCH may carry channel state information of the XDL and the ACK/NACK of the XDL data transmission.
- the complete resource allocation of this channel may be determined by the XLG for the terminal WTRU.
- the XUFBCH may apply space, time, frequency, or code division multiple access.
- the XPUDCH may carry XUL user data received from the MAC layer.
- the complete resource allocation of this channel may be determined by the XLG for the helper WTRU.
- the XPUDCH may apply space, time, frequency, or code division multiple access.
- the XPUCCH may carry necessary control information for the helper WTRU to decode the XPUDCH correctly.
- the complete resource allocation of this channel may be determined by the XLG for the terminal WTRU.
- the XPUCCH may apply space, time, frequency, or code division multiple access.
- the XL physical channels may be partitioned into two groups.
- a first group may be used with no XLG (e.g., any XL may transmit and receive in these channels in connection with a set of pre-defined procedures).
- a second group may include all physical channels dedicated to a specific XL.
- the first group may include the XPNDCH, the XPDACH, the
- a potential helper WTRU may use the XPDSACH to transmit BSI to its potential terminal WTRU in an on-going neighbor association procedure without a network grant.
- the XPDSACH transmission may not require a network grant, it may follow a pre-defined protocol that includes all necessary information required to detect and decode the channel (e.g., when the XPDSACH is transmitted relative to a neighbor discovery procedure, how the XPDSACH is coded and modulated, and what information is included in the MAC PDU).
- the second group may include the XPDFBCH, the XPUFBCH, the
- these channels may be available only after an XLG is received from the network.
- a reason for partitioning the channels into groups may be to allow
- the un-scheduled channels may be specifically used for AT-R coverage embodiments due to the lack of association of the terminal WTRUs with the network.
- no un-scheduled channels, except the XPNDCH may be used, and all XL specific communication may be carried on scheduled channels according to network grants.
- FIG. 5 is a diagram 500 of examples of different possibilities for multiplexing different XL physical channels into different types of XL sub- frames.
- a network assigned XL bandwidth (BW) and a minimum XL BW e.g., 72 sub- carriers
- BW network assigned XL bandwidth
- a minimum XL BW e.g., 72 sub- carriers
- an XPNDCH 504a, a guard period 506a, an XL specific reference signal 508a, an XPDCCH and XPDFBCH 510a and an XPDDCH and demodulation reference signals (DMRS) 512a are multiplexed into an XDL subframe with XPNDCH 502.
- DMRS demodulation reference signals
- an XL specific reference signal 508b, XPDCCH and XPDFBCH 510b and an XPDDCH and DMRS 512b are multiplexed into an XDL data subframe 520.
- an XPNDCH 504b, a guard period 506b, an XL unscheduled reference signal 514, an XL physical access channel (XPACH) 516 and an XL slow access channel (XSACH) 518 are multiplexed into a shared accessible sub-frame with XPNDCH 540.
- the MAC layer may provide services to the RLC in the form of logical channels.
- the type of logical channel may be either a control channel used for transmission of control and configuration information or a traffic channel used for carrying the user data.
- the XL logical channels may include an XL physical control channel (XPCCH), an XL common control channel (XCCCH), an XL dedicated control channel (XDCCH) and an XL dedicated traffic channel (DTCH).
- XPCCH XL physical control channel
- XCCCH XL common control channel
- XDCCH XL dedicated control channel
- DTCH XL dedicated traffic channel
- the PHY may offer services to the MAC in the form of transport channels, and the XL transport channels may include an XL paging channel (XPCH), an XL common channel (XCCH), an XDL scheduling channel (XDL- SCH) and an XUL scheduling channel (XUL-SCH).
- XPCH XL paging channel
- XCCH XL common channel
- XDL- SCH XDL scheduling channel
- XUL-SCH XUL scheduling channel
- FIGs. 6A, 6B, 6C and 6D are diagrams of example channel mappings between logical, transport and physical channels on the XL.
- FIG. 6A is an example channel mapping 600a for an XDL.
- FIG. 6B is an example channel mapping 600b for an XUL. In the example illustrated in FIG.
- mappings for the XCCCH 604, XDCCH 606 and XDTCH 608 UL logical channels, XCCH 612 and XUL-SCH 630 UL transport channels and XPUSACH 632, XPUDCH 634, XPUCCH 636, XPUACH 638, XPUFBCH 640 AND XPNDCH 628 UL physical channels are shown.
- FIG. 6C is an example channel mapping 600c for an XDL. In the example illustrated in FIG.
- FIG. 6C mappings for the PCCH 642, XCCCH 604, DCCH 644 and DTCH 646 DL logical channels, XPCH 610, XCCH 612 and XDL-SCH 614 DL transport channels and XPCDCCH 648, XPDSCH 650, XPACH 652 and XPDCCH 622 DL physical channels are shown.
- FIG. 6D is an example channel mapping 600d for an XUL. In the example illustrated in FIG.
- mappings for the XCCCH 604, DCCH 644 and DTCH 646 UL logical channels, XCCH 612 and XUL-SCH 630 UL transport channels and XPUCCH 654, XPUSCH 656, XPUCCH 636 and XPACH 652 UL physical channels are shown.
- Embodiments are described below that provide for enhancements to features of an AT system to enable a normal WTRU to efficiently act as a helper WTRU to relay data between a terminal WTRU and an eNB and, in some embodiments, to provide for data offload between WTRUs.
- an L2 architecture for a helper WTRU is described for relaying data between a terminal WTRU and an eNB.
- Such an embodiment may include use of a partial RLC at the helper WTRU, which may be transparent to the eNB and the terminal WTRU.
- Such architecture supports scheduling flexibility between the TRL and the XL.
- methods are described for discarding data that is stalled in the buffer of a helper WTRU and notifying the terminal WTRU of discarded data.
- a flow control mechanism may be implemented to prevent the helper WTRU buffer from overflowing because the helper WTRU may have a relatively limited buffer space or to limit the amount of data buffered at the helper WTRU to reduce the delay caused by data buffering.
- data re- segmentation mechanisms are described to enable independent scheduling on the TRL and the XL.
- new MAC status reports for coverage extension mode sent from a helper WTRU to a terminal WTRU are described that may be reported to the eNB to support XL scheduling.
- a two-tier scheduling method is described for the XL, with the first tier being a centralized and semi- static XLG issued by a network and the second tier being distributed and dynamic XL scheduling (XLS) that may be performed by the WTRUs themselves.
- FIG. 7A is a block diagram 700 of an L2 stack 702 for an AT system that includes a MAC layer (718/720) and a partial RLC layer 722 that reside at the helper WTRU 704.
- the L2 stack is shown for an eNB 703, a helper WTRU 704 and a terminal WTRU 706.
- the illustrated eNB 703 includes a PDCP layer 708, an RLC layer 710 and a MAC layer 712
- the illustrated helper WTRU 704 includes a partial RLC layer 722 and a MAC layer 718/720
- the illustrated terminal WTRU 706 includes a PDCP layer 713, an RLC layer 714 and a MAC layer 716.
- the automatic repeat request (ARQ) function in RLC AM mode is terminated only at the eNB 703 and the terminal WTRU 706 and not at the helper WTRU 704. Accordingly, in this embodiment, the helper WTRU 704 does not retransmit data according to an RLC ARQ function. This may enable the RLC to avoid data loss for seamless helper WTRU mobility in an RLC AM mode.
- RLC re- segmentation if required, may be used to re-construct the transport block (TB) for the second hop.
- two independent HARQ entities, one for the XL and another for the TRL, may be included at the helper WTRU. However, other configuration options for HARQ at the helper WTRU may also be possible.
- RLC PDUs arriving at the helper WTRU 704 may be stored in logical channel based queues, which may allow data to be discarded on a per-logical channel basis. Discard timer information for each logical channel may be exchanged as part of the configuration information.
- the partial RLC layer 722 buffers RLC PDUs in logical channel based queues, it may drop an RLC PDU if it is considered to be stalled due to, for example, expiration of its associated discard timer, re- segment an RLC PDU for the second hop when necessary, and send the highest dropped sequence number (HDSN) over the second hop in an RLC AM mode.
- the L2 stack 702 may be applied to both the UL and DL.
- WTRU and an eNB may be done through a direct path in the traditional radio link between the eNB and the terminal WTRU, while data may flow through either the direct path or a relay path (including the traditional radio link between the eNB and a helper WTRU and the XL between the helper WTRU and the terminal WTRU).
- a relay path including the traditional radio link between the eNB and a helper WTRU and the XL between the helper WTRU and the terminal WTRU.
- DRBs data radio bearers
- a common DRB may be used for both the direct path and the relay path.
- PDCP PDUs may be split between the two paths. For RCov modes, data may flow only through the relay path.
- FIG. 7B is a diagram 750 of an example system architecture for an embodiment where separate DRBs are set up to carry data through the direct path and the relay path, respectively.
- an eNB 772 is in communication with a terminal WTRU 770 via a direct path 774 and a relay path.
- the relay path is a path between the eNB 772 and the terminal WTRU 770 that includes the traditional radio link 776 between the eNB 772 and a helper WTRU 778 and the XL 777 between the helper WTRU 778 and the terminal WTRU 770.
- the helper WTRU protocol stack 700 illustrated in FIG. 7B is identical to the helper WTRU protocol stack 700 in FIG. 7A.
- the direct path protocol stack 752 for the eNB 772 and the terminal WTRU 770 includes the same entities that would normally be included in an LTE protocol stack, including PDCP layers 754 and 762, RLC layers 756 and 764, MAC layers 758 and 766 and PHY layers 760 and 768.
- the helper WTRU may be used for both signaling and data transfer. Accordingly, access stratum (AS) security may need to be established via the helper WTRU.
- AS access stratum
- the PDCP layer may be responsible for ciphering and integrity protection.
- the helper WTRU may operate at the MAC/H-ARQ level and may not interpret encrypted terminal WTRU data. Ciphered and/or integrity protected terminal WTRU data may be tunneled through the helper WTRU.
- FIG. 8 is a flow diagram 800 of a method of discarding stalled data at a helper WTRU on the DL.
- the eNB 703 may send a TB per TTI to the helper WTRU 704.
- the MAC layer 718/720 of the helper WTRU 704 may parse the MAC header in the received TB to identify the MAC SDUs and RLC PDUs of each logical channel.
- the helper WTRU 704 may store the received RLC PDUs in logical channel based queues (802) and start a discard timer associated with each RLC PDU stored in the local buffer (804).
- the helper WTRU 704 may then determine whether the discard timer has expired (806).
- the helper WTRU 704 may drop the RLC PDU from the local buffer (808). The helper WTRU 704 may then determine whether an RLC PDU has been dropped (810). In an RLC AM mode, on a condition that at least one RLC PDU has been dropped, the helper WTRU 704 may send the highest sequence number (SN) among the dropped RLC PDUs (the HDSN) to the terminal WTRU 706 using a new type of STATUS PDU to move the receive (Rx) window at the terminal WTRU (812).
- SN sequence number
- the helper WTRU 704 does not expect to receive an ACK/NACK from the terminal WTRU 706 for receipt/non-receipt of the STATUS PDU. Based on an XDL grant, the helper WTRU 704 may build the XL MAC PDUs using the buffered RLC PDUS, applying RLC re- segmentation as necessary (see detailed description of RLC re- segmentation below). The helper WTRU 704 and the eNB 703 may perform flow control on a per-logical channel basis on the TRL to prevent the local buffer from overflowing. A similar embodiment may be applied on the UL.
- helper WTRUs forward data between different radio links
- a helper WTRU may be configured to perform re- segmentation for forwarding data between the two links on a condition that the transport block size (TBS) is different between the TRL and the XL.
- TBS transport block size
- the helper WTRU may perform re-segmentation of a first hop RLC AM PDU using the normal RLC protocol.
- FIG. 9 is a diagram of a header 900 for an RLC unacknowledged mode (UM) segment that a helper WTRU may use to perform re- segmentation on a first hop RLC UM PDU.
- the example header 900 for the RLC UM PDU segment illustrated in FIG. 9 includes the same PDU segment indication (RF) 906, last segment flag (LSF) 916 and segment offset (SO) fields 918 and 920 included in the RLC AM PDU of the normal RLC protocol. However, it also includes Rl fields 902 and 904, a framing information (FI) field 908, an extension bit field 910 and a 10 bit sequence number (SN) 914.
- RF PDU segment indication
- LSF last segment flag
- SO segment offset
- helper WTRU discard of received RLC PDUs are described below with respect to FIGs. 10-15.
- the helper WTRU may send the HDSN to the terminal WTRU.
- the terminal WTRU may update the lower edge of its Rx window to HDSN+1. Accordingly, all RLC PDUs with SN ⁇ HDSN are out of the Rx window. Thus, in this scenario, the terminal WTRU does not require the corresponding RLC PDUs to be retransmitted.
- FIG. 10 is a diagram of an RLC STATUS PDU 1000 that may be used for carrying the HDSN over the second hop in RLC AM mode.
- D/C data control indication
- CPT control PDU type
- H_SN field 1008 for indicating the HDSN and padding 1010.
- the Rx window of the terminal WTRU may be updated with the highest received out-of- window SN from the received RLC PDU. This may prevent the Rx window from stalling after the helper WTRU drops RLC PDUs. Accordingly, in contrast with the AM mode, there may be no need to send the HDSN over the second hop in UM mode.
- the RLC SDU reassembly process at the second hop receiver may be modified in AM mode to accommodate the change in the Rx window in the second hop receiver.
- the RLC in the second hop receiver may assemble the RLC SDU from RLC PDUs with SN ⁇ variable VR(R).
- the second hop receiver may analyze the SNs of these RLC PDUS and, if a segment from an RLC SDU is confirmed missing (e.g., the second hop receiver has not yet received the RLC SDU and the RLC SDU is outside of the current Rx window), then the second hop receiver may discard all other data segments for the same RLC SDU.
- Dropping RLC PDUs on a per-logical channel basis may reduce transfer delays caused by stalled data in helper WTRU queues.
- all RLC PDUs related to a PDCP SDU may be dropped at the moment when the PDCP discard timer expires, regardless of whether the PDU is in the eNB buffer or in the helper WTRU queue (e.g., the helper WTRU drops a buffered RLC PDU at exactly the same time that the original PDCP SDU discard timer for the PDCP SDU to which an RLC PDU belongs expires). Actual discard time may vary from this, however, due to implementation limitations.
- the helper WTRU may set the discard timer period according to any of a number of different methods. For example, in the DL, the helper WTRU may not drop RLC PDUs and may not set a discard timer. The delay caused by helper WTRU buffering may be limited by minimizing the queue length. In this example, tighter flow control may be needed to maintain the queue length. For another example, a timeout value for the discard timer for each logical channel associated with a terminal WTRU may be provided at configuration or reconfiguration of the partial RLC layer. The discard timer value may be set to the same value as that of the corresponding PDCP SDU discard timer.
- total discard time for a segment of a PDCP SDU may be within a window from 1* discardTimer to 2*discardTimer due to two individual discard timers potentially being run in both the eNB and the helper WTRU.
- an RLC PDU header may carry a remaining discard timer timeout value when the eNB sends it out.
- the discard time for all segments of a PDCP SDU may be exactly 1* discardTimer. However, this may require an extension to the RLC header to carry the remaining discard timer timeout value.
- one or a combination of the examples listed above may be implemented.
- an extension may be added to the RLC PDU header to carry the remaining discard timer timeout value from the eNB to the helper WTRU. This may be done, for example, by adding an extension (E2) bit to the normal AMD and UMD PDUs indicating the existence of a time left (LT) field that indicates the time left in the discard timer and an optional 8-bit LT field.
- E2 extension
- LT time left
- the optional LT field may be placed after the SN field.
- FIGs. 11 and 12 are diagrams of example RLC PDUs 1100 and 1200, respectively, with an E2 bit and an optional LT field.
- the E2 bit may take the value of 0 if no LT bit is present in the PDU after the SN field and may take the value of 1 if an LT bit is present in the PDU after the SN field.
- FIG. 11 is a diagram of an example RLC PDU 1100 having a 10 bit
- the E2 bit 1104 takes the third R bit in the UMD PDU after R bits 1108 and 1110.
- FIG. 12 is a diagram of an example RLC PDU 1200 having a 5 bit
- the E2 bit 1204 takes the first bit of the new 4 bit field including bits 1204, 1206, 1208 and 1210 after the first E bit field for an AMD PDU and a UMD PDU.
- FIG. 13 is a diagram 1300 of an example procedure for RLC PDU discard at the helper WTRU. In the illustrated example, congestion occurs on the
- a PDCP PDU/RLC SDU is segmented into RLC PDUs with
- RLC PDUs 1310, 1312, 1313 and 1314 arrive in the helper WTRU 1320.
- RLC PDU 1311 does not reach the helper WTRU 1320 successfully.
- PDU 1315 and later PDUs 1316 and 1317 stay in the eNB 1322.
- the RLC PDU 1311 arrives at the helper WTRU later due to HARQ retransmissions.
- the XL is unavailable, and the TRL stops by flow control as well.
- the helper WTRU 1320 drops PDUs 1310, 1312, 1313 and 1314 because of discard timer expiry.
- PDUs 1315, 1316 and 1317 are sent to the helper WTRU to fill the room in the helper WTRU buffer.
- the helper WTRU may then send the PDUs 1311, 1315, 1316 and 1317 to the terminal WTRU.
- the terminal WTRU may filter out the PDU 1311 because it is out of the Rx window.
- PDU 1315 is filtered out in the re-assembly process because it includes a data segment from an incompletely-received SDU with some segments (e.g., data in the PDUs 1310, 1311, 1312, 1313 and 1314) that were discarded.
- FIGs. 14A and 14B include a diagram 1400A/1400B of an example procedure for moving the Rx window at the helper WTRU in RLC AM mode.
- PDCP PDU/RLC SDUs are segmented into RLC PDUs.
- the RLC SDU boundary is shown.
- RLC PDUs with SNs of 1 (1411), and 2 (1412), 3 (1413) and 4 (1414) are stored in a buffer at the helper WTRU 1404.
- the helper WTRU drops RLC PDUs 1411, 1412 and 1413 because the discard timer expires. Later, the XL resumes.
- the Rx window is moved, and the Tx window in the eNB 1402 is also moved by the ACK.
- RLC PDU 1414 is sent to the terminal WTRU 1406. Since it is in sequence, the Rx window is moved again. The Tx window in the eNB 1402 is also moved by the ACK. RLC PDU 1414 is out of the Rx window. The first data segment in RLC PDU 1414 is the remaining segment of the RLC SDU with a confirmed missing element, so it is dropped. The remaining segment is kept for later re-assembly. At time t5, more data is sent to the helper WTRU 1404 after the Tx window update.
- the helper WTRU 1404 sends more data to the terminal WTRU 1406, and a valid SDU is assembled with data segmented in PDUS 1414, 1415 and 1416. Accordingly, in this example, after the XL resumes from a problem, the XL delay is recovered well by updating the Rx window with the HDSN.
- FIGs. 15A and 15B include a diagram 1500A/1500B of an example procedure for moving the Rx window at the helper WTRU 1522 when the HDSN is lost.
- the parameters for this example are the same as for the example described with respect to FIGs. 14A and 14B.
- the status PDU that carries the HDSN is lost on the XL.
- the Rx window is moved only when the retransmission of the dropped PDUs arrives.
- RLC PDUs with SNs of 1 (1501), 2 (1502), 3 (1503) and 4 (1504) are stored in a buffer at the helper WTRU 1522.
- the helper WTRU 1522 drops RLC PDUs 1501, 1502 and 1503 due to discard timer expiry. Later, the XL resumes.
- the RLC PDUs in the terminal WTRU 1520 are in sequence, and the Rx window is updated.
- the RLC SDUs are delivered.
- the example described with respect to FIGs. 15A and 15B is similar to the situation where the HDSN is not sent to the RLC of the second hop receiver to move the Rx window. Accordingly, even when an HDSN is lost on the XL, the system may eventually recover if retransmission of the dropped RLC PDUs to the helper WTRU is allowed after they are dropped. However, without receiving the HDSN STATUS PDU, it may take a longer time for the data stream to recover (e.g., for re-ordering timer expiration and re-transmission request).
- another embodiment may include an L2 layer where none of the MAC, RLC and PDCP layers are terminated at the helper WTRU.
- MAC TBs may be relayed between the XL and TRL without modification.
- only the MAC layer (and not the RLC or PDCP layers) may be terminated at the helper WTRU.
- scheduling flexibility between the XL and TRL may be achieved by MAC PDU segmentation on the second hop.
- MAC level flow control and MAC level stalled data discard may be applied to improve performance.
- the MAC and RLC layers may be terminated at the helper WTRU.
- the helper WTRU may relay RLC SDUs between the terminal WTRU and the eNB.
- all of the MAC, RLC and PDCP layers may be terminated at the helper WTRU.
- one or more of the L2 embodiments described herein may be combined with the architecture described above.
- flow control on the first hop in coverage extension mode applications may serve the purpose of limiting the buffer depth of the local buffer at the helper WTRU to reduce transfer delay and prevent data overflow by the helper WTRU buffer. If no flow control is applied on the first hop, there is a risk of overflow in the helper WTRU buffer in RLC UM mode because of the possible difference in instantaneous throughput on the first and second hops.
- the RLC Rx/Tx window at the terminal WTRU and eNB may perform flow control between the first and second hops.
- the maximum number of RLC PDUs stored in a helper WTRU buffer may need to be smaller than the window size.
- An example of this may include embodiments where no discard timer is used to drop data at the helper WTRU and, therefore, the delay caused by helper WTRU buffering may be minimized by limiting the maximum number of buffered RLC PDUs at the helper WTRU.
- Flow control may be applied on the MAC level that treats data from different logical channels as a whole or on an RLC level on a per-active logical channel basis.
- the precision of flow control may vary from a binary on/off command to more precise commands with multiple levels of control.
- RLC level flow control may be used to achieve precise control for each active logical channel.
- An Xon/Xoff type of flow control may be used to reduce flow control overhead.
- an Xon/Xoff embodiment when the buffer level is higher than a preset high-water mark, an Xoff command may be sent to the transmitter to stop the incoming data. Once the buffer level is lower than a low- water mark, an Xon command may be sent to the transmitter to resume the incoming data.
- a flow control command may be sent from the helper WTRU to the first hop transmitter to control incoming data to the helper WTRU. For the UL direction, if the helper WTRU is in control of the XUL scheduling jointly with the network, there may be no need to perform flow control on the XUL.
- FIG. 16 is a diagram 1600 of an example MAC control element for carrying flow information on the TRL UL.
- the example MAC control element illustrated in FIG. 16 includes an R field 1602, a logical channel identity (LCID) field 1604 and an On/Off field 1606.
- the LCID field may be used to identify the logical channel instance of the corresponding MAC SDU or the type of corresponding MAC control element or padding for the DL-SCH, UL-SCH and multicast channel (MCH), respectively.
- the flow control MAC control element may be identified by reusing a reserved LCID.
- the On/Off field 1606 may be "1" to indicate that more data may be sent (e.g., resume incoming data) or "0" to indicate that more data may not be sent (e.g., stop incoming data).
- MAC status reports from the terminal WTRU may need to be relayed to the network to assist with XL scheduling. Further, additional MAC status reports from the helper WTRU related to data in the process of being relayed between the network and the terminal WTRU may need to be sent to the network. Accordingly, in an embodiment, it may be necessary to map logical channels on the XL to logical channels on the TRL.
- FIG. 17 is a diagram 1700 of an example mapping between logical channels on the XL to logical channels on the TRL.
- TRL logical channels 1706 and 1708 which belong to logical channel group 1720, are terminated at a helper WTRU 1714 and are not mapped to any XL logical channels.
- TRL logical channels 1702 and 1704 which belong to logical channel group 1718, however, are not terminated at the helper WTRU 1714 and are instead mapped to XL logical channels 1710 and 1712 and terminated at the terminal WTRU 1716.
- Such MAC status reports may include an XUL scheduling request (XUSR) from the terminal WTRU, an XDL scheduling request (XDSR) from the helper WTRU, a UL buffer status (TBSR) from the terminal WTRU, an XDL buffer status (XDBSR) from the helper WTRU, a cross link DL power headroom report (XDPHR) from the helper WTRU and an XUL power headroom report (XUPHR) from the terminal WTRU.
- regular MAC status reports from the helper WTRU such as an SR, BSR or PHR, may be used for embodiments described herein as per baseline LTE.
- a terminal WTRU When a terminal WTRU wants to send data on the XUL but does not have an XUL grant, it may need to send the XUSR to the network to ask for the initial XUL grant.
- the terminal WTRU may send an XUSR to the network in a number of different ways, including, for example, a terminal WTRU that is currently in RRC idle mode that wants to initiate a transition to RRC connected mode sending an XUSR on a UCZ to alter the helper WTRU or a terminal WTRU that is currently in RRC connected mode sending an XUSR on the XUL control channel, XPUCCH.
- a helper WTRU wants to send data on the XDL to the terminal WTRU, but there is no XDL grant available, the helper WTRU may need to send an XDSR to the network to ask for the initial XDL grant.
- the TBSR may indicate the UL buffer status at the terminal WTRU.
- This information may be used to determine the XUL scheduling, which may be done jointly by the network and the helper or terminal WTRU, as described in more detail below.
- Transmission of a TBSR maybe triggered by one or more events at the terminal WTRU, which may include, for example, arrival of data with higher priority than data that is currently in the transmission buffer, periodic triggering controlled by a timer, or when padding would otherwise be used in the MAC header.
- a TBSR may be sent to the helper WTRU first via the XUL, and then may then be relayed to the eNB on the TRL UL.
- the TBSR may be 6 bits.
- the TBSR may be sent on the XUL to the helper WTRU either directly on the XPUCCH or by MAC control elements on the XUL shared data channel.
- a TBSR MAC control element may be used to carry the TBSR.
- a TBSR MAC control element may be in the same format as the BSR defined for traditional LTE MAC including a truncated BSR, short BSR, or long BSR.
- the TBSR MAC control element may be identified by reusing a reserved LCID.
- a MAC control element may be in the form of either a regular BSR MAC control element or a TBSR MAC control element. If a regular BSR MAC control element is used, the helper WTRU may convert the regular BSR MAC control element that it receives from the XUL shared data channel to a TBSR MAC control element on the TRL UL-SCH.
- FIG. 18 is a diagram 1800 showing an example conversion of a BSR
- an XL TB 1802 includes a MAC header 1806 and a BSR 1808.
- a TRL TB 1804 includes a MAC header 1810 and also includes a converted TBSR 1812 with other regular MAC control elements 1814.
- the TBSR may be carried using a TBSR
- the helper WTRU may send it to the eNB by putting the TBSR MAC control element on the TRL UL-SCH.
- the XDBSR is the DL buffer status report for the XL at the helper
- the network may use this information to determine the XDL scheduling jointly with the helper WTRU.
- the XDBSR MAC control elements may be in the same format of the BSRs defined in the traditional LTE MAC. They may be, for example, in the form of a truncated BSR, short BSR, or long BSR.
- the new XDBSR MAC control element may be identified by reusing a reserved LCID.
- Transmission of an XDBSR may be trigged by a number of different events at the helper WTRU, which may include, for example, periodic triggering controlled by a timer, when padding would otherwise be used in the MAC header, the XDL queue depth being over a threshold (this may be replaced by XDL flow control), or when a helper WTRU wants to request an initial XDL grant for sending data to the terminal WTRU if the helper WTRU uses an XDBSR to send an XDSR to the network.
- events at the helper WTRU may include, for example, periodic triggering controlled by a timer, when padding would otherwise be used in the MAC header, the XDL queue depth being over a threshold (this may be replaced by XDL flow control), or when a helper WTRU wants to request an initial XDL grant for sending data to the terminal WTRU if the helper WTRU uses an XDBSR to send an XDSR to the network.
- FIG. 19 is a diagraml900 illustrating an example transmission of a
- TRL logical channels 1902, 1904, 1906 and 1908 are configured to transport data from a respective UL buffer 1914, 1916, 1918 and 1920 at the helper WTRU 1950 to a network eNB (not shown).
- the helper WTRU 1950 may be configured to transport BSR for these logical channels to the network eNB (not shown).
- the XL logical channels 1910 and 1912 may be configured to transport the TBSR of respective UL buffers 1922 and 1924 at the terminal WTRU 1960 to the helper WTRU 1950.
- FIG. 20 is a diagram illustrating example transmission of a DL BSR in coverage extension mode for AT applications.
- TRL logical channels 2002, 2004, 2006 and 2008 are configured to transport data from a network eNB (not shown) to the helper WTRU 2050.
- the XL logical channels 2010 and 2012 may be configured to transport the BSR of respective DL buffers 2014 and 2016 at the helper WTRU 2050 to the terminal WTRU 2060.
- Both the DL and UL power headroom for XL may be used to determine the XL scheduling jointly by the network and a helper WTRU/terminal WTRU pair.
- the XUPHR may be sent from the terminal WTRU and relayed to the network by the helper WTRU.
- the XDPHR may be sent from the helper WTRU and reported directly to the network.
- An XDPHR may be triggered at a helper WTRU by a number of different events, which may include, for example, periodic triggering controlled by a timer, XL path loss change exceeding a threshold, or XDL scheduling being changed by the helper WTRU or terminal WTRU.
- An XUPHR may be triggered at a terminal WTRU by a number of different events, which may include, for example, periodic triggering controlled by a timer, XL path loss change exceeding a threshold, or XUL scheduling being changed by a terminal WTRU or a helper WTRU.
- the XDPHR and XUPHR MAC control elements may be in the same format as the PHR MAC control element defined in the traditional LTE MAC.
- the XDPHR MAC control element and the XUPHR MAC control element may be identified by reusing a reserved LCID.
- the terminal WTRU may initiate an XUL scheduling request and send it to the helper WTRU.
- the helper WTRU may then relay it to the eNB.
- a terminal WTRU may use a different procedure to send the XUSR to the helper WTRU.
- a terminal WTRU in an RRC idle mode may send an XUL scheduling request in a UCZ.
- a terminal WTRU in an RRC connected mode may send an XUL scheduling request to the helper WTRU in the form of either a TBSR or an XUSR, depending on how the control channels are designed on the XL.
- FIG. 21 is a flow diagram 2100 of a method of a terminal WTRU in
- the terminal WTRU may send a TBSR to the helper WTRU via an XUL control channel (2104). If the XPUCCH can carry the TBSR directly, the terminal WTRU may send the TBSR directly on the XPUCCH to the helper WTRU, and no XUSR may be needed.
- FIG. 22 is a flow diagram 2200 of a method of a terminal WTRU in RRC connected mode sending an XUL scheduling request to an eNB using an XUSR.
- the terminal WTRU determines whether it has an XUL grant (2204). On a condition that the terminal WTRU has an XUL grant, the terminal WTRU may determine that there is no need to send an XUSR and, accordingly, may not send one (2208). On a condition that the terminal WTRU does not have an XUL grant, the terminal WTRU may send an XUSR to the helper WTRU via the XPUCCH (2206).
- Sending the XUSR on the XPUCCH may save bandwidth on the
- the XUSR may only be one-bit of information. This bit of information may be carried in the same or a similar manner as the regular SR being carried on the PUCCH.
- there may be no need to have a RACH procedure on the XL because the XPUCCH always exists when both the helper WTRU and the terminal WTRU are in RRC connected mode.
- FIG. 23 is a flow diagram 2300 of a method of a helper WTRU relaying an XUSR to an eNB using both the TRL PUCCH and the TRL UL-SCH.
- a terminal WTRU sends an XUSR to a helper WTRU via the XUSR on the XPUCCH (2302).
- the helper WTRU may relay it to the eNB.
- the helper WTRU may send the received XUSR to the eNB in different ways depending on the TRL UL status.
- the helper WTRU may send an XUSR to the eNB by a new bit on the TRL PUCCH that is dedicated for the XUSR (2308). If not, on a condition that the TRL UL grant for the UL-SCH is available (2306), the helper WTRU may send the XUSR on the UL-SCH using a MAC control element (2312). On a condition that the TRL UL grant for the UL-SCH is not available (2306), the existing LTE-A RACH procedure may be used to obtain the initial UL grant on the TRL (2310) and then send the XUSR may be sent to the eNB via the UL- SCH (2312).
- FIG. 24 is a flow diagram 2400 of a method of a helper WTRU relaying an XUSR to an eNB using the UL-SCH only.
- the helper WTRU may send an XUSR to the eNB on the UL-SCH only by using a MAC control element.
- the terminal WTRU may send an XUSR to the helper WTRU via the XPUCCH (2402).
- the existing LTE-A procedure for UL scheduling requests either by PUCCH or RACH, may be used to obtain an initial UL grant on the TRL UL. (2406).
- the helper WTRU may then send the XUSR to the eNB via the UL-SCH (2408).
- the helper WTRU may simply send the XUSR to the eNB via the UL-SCH (2408).
- the XUSR may either be sent to the eNB with a new type of MAC control element on the UL-SCH or with a minimum TBSR over the TRL UL-SCH.
- the minimum TBSR may represent the size for a short TBSR MAC control element.
- the XUSR MAC control element may have a length of 0 (e.g., it may not have an actual MAC control element body). In this embodiment, only an R/R/E/LCID field with an LCID for the XUSR may be placed in the MAC header. The XUSR MAC control element may be identified by reusing a reserved LCID.
- the helper WTRU may send the XUL scheduling request to the eNB in a number of different ways, examples of which are described with respect to FIGs. 25, 26 and 27 below.
- FIG. 25 is a flow diagram 2500 of a method of a helper WTRU relaying an XUSR to an eNB on the TRL UL-SCH using an XUSR MAC control element.
- an extension to the TRL PDCCH may be needed for carrying the XUL grant from the eNB to the helper WTRU.
- a terminal WTRU 2520 may send an XUSR to a helper WTRU 2530 on the XPUCCH (2502). If the helper WTRU 2530 does not have a TRL UL grant, an LTE-A procedure may be executed to obtain such a grant (2504).
- the helper WTRU 2530 may then send an XUSR to the eNB (2540) using a MAC control element on the TRL UL-SCH (2506).
- an XUL scheduler 2508 at the eNB 2540 may assign an initial XUL grant and send it to the helper WTRU 2530 via the PDCCH on the TRL (2510).
- the helper WTRU 2530 may then send the XUL grant to the terminal WTRU 2520 via the XPDCCH (2512).
- FIG. 26 is a flow diagram 2600 of a method of a helper WTRU 2630 relaying an XUSR to an eNB 2640 on TRL UL-SCH using a minimum TBSR MAC control element.
- an extension to the TRL PDCCH may be needed for carrying the XUL grant from the eNB 2640 to the helper WTRU 2630.
- the terminal WTRU 2620 may send an XUSR to the helper WTRU 2630 (2602) on the XPUCCH.
- an LTE-A procedure may need to be executed to obtain such grant (2604).
- the helper WTRU 2630 may then send a minimum TBSR to the eNB 2640 using a MAC control element on the TRL UL-SCH (2606).
- an XUL scheduler 2608 at the eNB 2640 may assign an initial XUL grant and send it to the helper WTRU via the PDCCH on the TRL (2610).
- the helper WTRU 2630 may then send the initial XUL grant to the terminal WTRU 2620 via the XPDCCH (2710).
- the minimum TBSR may correspond to the size of a short BSR.
- FIG. 27 is a flow diagram of a method of a helper WTRU relaying an
- XUSR to an eNB on the TRL PUCCH may be needed.
- an extension to the TRL PDCCH may be needed for carrying the XUL grant from the eNB 2740 to the helper WTRU 2730.
- the terminal WTRU 2720 may send an XUSR to the helper WTRU 2730 on the XPUCCH (2702).
- the helper WTRU 2730 may use the TRL PUCCH to relay the XUSR to the eNB 2740 (2704).
- an XUL scheduler 2706 at the eNB 2740 may assign an initial XUL grant and send it to the helper WTRU 2730 via the TRL PDCCH (2708).
- the helper WTRU 2730 may send the XUL grant to the terminal WTRU 2720 via the XPDCCH (2710).
- a helper WTRU When a helper WTRU has data to send to the terminal WTRU on the XDL but there is no XDL grant, it may send an XDSR to the network asking for an XDL grant.
- the helper WTRU may send the XDSR to the eNB in a different manner, depending on the TRL UL status at the moment. For example, if the PUCCH exists for the TRL, the helper WTRU may send an XDSR to the eNB using a new bit on the TRL PUCCH dedicated for the XDSR. If the PUCCH does not exist for the TRL, the helper WTRU may send an XDSR on the UL-SCH using a MAC control element.
- the existing LTE-A RACH procedure may be used to obtain the initial UL grant on the TRL.
- the helper WTRU may send an XDSR to the eNB on the UL-SCH only by using a MAC control element.
- the existing LTE-A procedure for UL scheduling requests either by PUCCH or RACH, may be used to obtain the initial UL grant on the TRL UL.
- the XDSR may either be sent on the UL-SCH to the eNB with an XDSR MAC control element or on the TRL UL-SCH to the eNB with a minimum XDBSR MAC control element. If the XDSR is sent on the UL-SCH to the eNB with an XDSR MAC control element, a new type of MAC control element may be used for the XDSR on the TRL UL- SCH.
- the XDSR MAC control element may have a length of 0 (e.g., it does not have an actual MAC control element body).
- only an R/R/E/LCID field with an LCID for the XDSR may be placed in the MAC header.
- the XDSR MAC control element may be identified by reusing a reserved LCID.
- FIG. 28 is a flow diagram 2800 of a method of a helper WTRU 2810 sending an XDSR to an eNB 2820 on the TRL UL-SCH using an XDSR MAC control element.
- an extension to the TRL PDCCH may be needed for carrying the XDL scheduling information from the eNB 2820 to the helper WTRU 2810.
- the helper WTRU 2810 may execute an LTE-A procedure to obtain one (2802).
- the helper WTRU 2804 may send an XDSR to the eNB 2820 using a MAC control element on the TRL UL-SCH (2810).
- an XDL scheduler 2806 at the eNB 2820 may assign an initial XDL grant and send it to the helper WTRU 2810 via the PDCCH on the TRL (2808).
- FIG. 29 is a flow diagram 2900 of a method of a helper WTRU 2910 sending an XDSR to an eNB 2920 on the TRL PUCCH.
- a one-bit extension to the TRL PUCCH may be needed for carrying the XDSR from the helper WTRU 2910 to the eNB 2920.
- an extension to the TRL PDCCH may be needed for carrying the XDL scheduling information from the eNB 2920 to the helper WTRU 2910.
- the helper WTRU 2910 may use the TRL PUCCH to send an XDSR to the eNB 2920 (2902).
- an XDL scheduler 2904 at the eNB 2920 may assign an initial XDL grant and send it to the helper WTRU 2910 via the TRL PDCCH (2906).
- a terminal WTRU may first send the TBSR to the helper WTRU on the XUL, and then helper WTRU may relay it to the eNB on the TRL UL.
- the TBSR may be sent over the XL using any number of different methods, which may include, for example, sending the TBSR on the XUL by the XPUCCH and sending the TBSR on the XUL shared data channel by a regular BSR or a TBSR MAC control element.
- the TBSR MAC control element on the XUL shared data channel it may need an XUL grant to send the TBSR to the helper WTRU.
- the XUL grant may be available from the ongoing XUL transmissions. If there is no XUL grant, the terminal WTRU may use the XUL scheduling request procedure described above to request the XUL grant.
- the WTRU may send it to eNB by a MAC control element on the TRL UL-SCH once it has the TRL UL grant, which it may need if there will be ongoing UL data transmission from the helper WTRU to the eNB. If a TRL UL grant is not available, the helper WTRU may use the existing LTE-A procedure for UL scheduling requests, either by PUCCH or RACH, to request the initial TRL UL grant from the eNB.
- FIG. 30 is a signal diagram 3000 of a method for sending a TBSR to an eNB 3070 when a TRL UL grant is available.
- a terminal WTRU 3050 sends the TBSR(s) to a helper WTRU 3060 using either a regular BSR MAC control element or a TBSR MAC control element on the XUL data channel or using the XPUCCH (3002). If the helper WTRU 3060 does not have a TRL UL grant, it may need to initiate an LTE-A procedure to obtain one (3004).
- the helper WTRU 3060 may put the TBSR into a TBSR MAC control element (3006) or the BSR into a BSR MAC control element (3008) and sent it to the eNB 3070.
- an XUL scheduler 3010 at the eNB 3070 may assign an XUL grant and sent it to the helper WTRU 3060 via the TRL PDCCH (3012).
- a TRL UL scheduler (3010) at the eNB 3070 may assign a TRL UL grant and send it to the helper WTRU 3060 via the TRL PDCCH as well (3014).
- the helper WTRU 3060 may send the XUL grant to the terminal WTRU 3050 via the XPDDCH (3016).
- the terminal WTRU 3050 may then send data with newer TBSRs on the XUL shared channel to the helper WTRU 3060 (3018), which may relay the data to the eNB 3070 (3020).
- the XDBSR may be measured by the helper WTRU.
- the report procedure for XDBSR may be similar to the one used for the helper WTRU to report regular BSRs by using a MAC control element on the TRL UL-SCH.
- a new type of MAC control element may be used for the XDBSR. It may have the same formats as the BSR and may be identified by reusing a reserved LCID field.
- FIG. 31 is a signal diagram 3100 of a method of reporting an
- an extension to the TRL PDCCH may be needed for carrying the XDL scheduling information from an eNB 3120 to a helper WTRU 3110.
- the helper WTRU 3110 may need to initiate an LTE-A procedure to obtain one (3102).
- the helper WTRU 3110 may send an XDBSR to the eNB 3120 using a MAC control element on the TRL UL-SCH (3104).
- an XDL scheduler 3106 at the eNB 3120 may assign the XDL grant and send it to the helper WTRU 3110 via the PDCCH on the TRL (3108).
- New types of MAC control elements for XDPHR and XUPHR may be needed to send an XDPHR and an XUPHR to the eNB on the TRL-SCH.
- the same MAC control element for XUPHR may be used on the XUL shared data channel to carry an XUPHR to the helper WTRU.
- FIG. 32 is a signal diagram 3200 of a method of sending an XDPHR and an XUPHR to an eNB 3240 on the TRL UL-SCH.
- a terminal WTRU 3220 may send an XUPHR to a helper WTRU 3230 using a MAC control element on the XUL shared data channel (3202). If the helper WTRU 3230 does not have a TRL UL grant, it may need to obtain one using an LTE-A procedure (3204).
- the helper WTRU 3230 may relay the XUPHR MAC control element (3206) and/or the XDPHR MAC control element (3208) to the eNB 3240 on the TRL UL-SCH.
- the helper WTRU 3230 may also send the PHR to the eNB 3240 on the UL-SCH (3210).
- LCIDs used on the TRL UL-SCH and the XUL shared data channel may share the same definition, even though they may not always be present on these two channels.
- Table 1 includes a listing of LCID values that are normally used as well as LCID values that may be used for the different embodiments described herein. However, other LCID values and ordering may also be possible.
- the XL may share the frequency band applied on the TRDL/TRUL (in-band configuration) or adopt a different frequency band that is well- separated from the TRDL/TRUL (out-of-band configuration).
- the out-of-band configuration may be less subject to in-device and in-air interference between the XLs and TRLs, since an out-of-band configuration normally applies adequate frequency spectrum isolation between the XL and the TRL and, as a result, a device may operate two radio chains, each with its own baseband processing and independent FFT. While in-device interference may be primarily handled with the physical radio design of a device, in-air interference may need to be coordinated with an XL resource grant and scheduling scheme partially performed by the network and partially performed by the WTRUs.
- FIG. 33A is a diagram 3300 of a system of helper WTRUs 360 and terminal WTRUs 370 within a cell operated by an eNB 3350.
- Each of the helper WTRUs 360a, 360b, 360c, 360d, 360e and 360f is in direct communication with the eNB 3350 via a respective TRL UL/DL pair 3310a, 3310b, 3310d, 3310f, 3310h or 3310i.
- Each of the terminal WTRUs 370a, 370b, 370d and 370e is in communication with one or more helper WTRUs 360a, 360b, 360c, 360d, 360e and 360f via one or more XL UL/DL pair 3320a, 3320b, 3320c, 3320d, 3320e, 3320f or 3320g.
- Some of the terminal WTRUs e.g., the terminal WTRUs 370b, 370d and 370e
- the XLs all potentially interfere with each other.
- different multiple access schemes may be applied on the XL to attempt to mitigate the interference.
- all XLs in the same cell may share a fixed pool of time, frequency, code and power resources, and the network may need new metrics and algorithms to efficiently allocate XL resources.
- the network may perform scheduling dynamically per TTI on the TRL.
- applying a similarly dynamic grant and scheduling scheme on the XL may require the network to have access to dynamic XDL and XUL channel state information.
- the resultant signaling may be significant, especially in an AT-R coverage mode where a helper WTRU may need to relay all terminal WTRU feedback information to the network.
- centralized dynamic grant and scheduling may cause an increase in the HARQ time line because a helper WTRU may need time to decode and forward the grant and scheduling information to a terminal WTRU.
- TRL grant and scheduling does not specify a power level to be used for the scheduled DL or UL transmission.
- the eNB always transmits the DL data channel with full power (i.e., the downlink power is centralized), while the UL transmission may be regulated by the UL power control based on the grant information, such as the assigned modulation and coding scheme (MCS) and physical resource blocks (PRBs) (i.e., the UL power control mechanism is distributed).
- MCS modulation and coding scheme
- PRBs physical resource blocks
- an explicit power allocation may be desirable as one type of resource allocation because the XL transmit power setting of the WTRUs in AT applications may constitute a distribution of a shared resource in the sense that all XLs in a geographical region may be restricted to certain power levels to mitigate mutual interference.
- AT-R coverage mode may pose additional challenges because a helper WTRU may use new procedures to forward the network grant to a terminal WTRU and to relay terminal WTRU measurements to the network as an input to the grant algorithm.
- embodiments are described herein for two-tier scheduling in the XL, with the first tier being a centralized and semi-static XLG issued by a network and the second tier being a distributed and dynamic XLS that may be performed by the WTRUs themselves. These embodiments may be applicable for both AT-R and AT-LO applications, although some embodiments are described with respect to AT-R for ease of explanation.
- FIG. 33B is a flow diagram 3355 of an example method of radio resource scheduling on a radio XL between a WTRU and another WTRU.
- the WTTU receives an XLG specifying resources for use by at least the WTRU for transmission on the radio XL (3360).
- the WTRU may perform XL scheduling per TTI within the resources specified in the XLG (3362).
- the WTRU may transmit at least one packet to the other WTRU based on the XL scheduling per TTI (3364).
- network-controlled XLG may be a channel dependent grant scheme using orthogonal multiple access.
- a channel dependent grant scheme may eliminate intra-cell XL interference while allowing each XL to achieve optimal performance according to its channel conditions.
- a network may not have adequate resources to support orthogonal multiple access when the number of supported XLs per cell are excessive, and dynamic channel-dependent scheduling per TTI may not be practical because of significantly increased signaling overhead and resulting increase in latency.
- dynamic per TTI scheduling per XL may pose high demand for PDCCH/PUCCH capacity.
- the dynamic per-TTI scheduling may be conducted based on the resources specified in the XLG and at least one of an XL ACK/NACK message or a channel quality indicator (CQI), without network involvement.
- CQI channel quality indicator
- Such an embodiment may be desirable because separate HARQ design in some AT applications for TRL and XL may prevent ACK/NACK transmissions from being forwarded to the network.
- the first tier of two-tier scheduling may be referred to as XLG, and the second tier may be referred to as XLS.
- the network may issue a centralized and semi- static scheduling decision to allocate the resource of an XL in terms of maximum allowed power and physical channel time/frequency/code configuration based on both short-term and long-term measurements.
- Such short-term and long-term measurements may include, for example, XL feedback measurements, XL signal and interference measurements and XL power headroom reporting.
- the XLG may not take into consideration the instantaneous channel condition.
- Each grant may be associated with an explicitly signaled validity period.
- the WTRUs in the network may perform distributed and dynamic scheduling decisions within the resources allocated by the XLG and determine the transmission configuration on a per-TTI basis.
- the determined transmission configuration on a per-TTI basis may include, for example, determining the MCS and transmission bandwidth in accordance with the short-term XL channel condition feedback measurements as a result of link adaptation and traffic variation handling.
- the scheduling decision may be factored into the XL power control to calculate the transmit power.
- the sub-carrier resources assigned in an XLG may be applied unchanged during an XLG validity period. In other words, there may be no dynamic frequency scheduling within each XLG validity period.
- the WTRUs may use the same granted sub-carriers (e.g., a sub-carrier group or a sub-band in each TTI) but may apply different power and MCS for link adaptation.
- XL scheduling may explore the frequency selectivity within a granted bandwidth by adjusting sub-carrier resource assignment based on certain SINR feedback specific to each assignable sub-carrier group or sub-band.
- an XLG may not carry any MCS information, it may specify a maximum allowed XL transmit power for WTRUs in the AT application. This may act as a form of slow power control directed by the network to manage interference between XLs and enable efficient power utilization. For example, when two XLs in proximity share identical code, frequency, and time resources, the maximum allowed power (the XLG power) may be set so as to reduce inter-XL interference and optimize the performance of both XLs. However, when orthogonal resource allocation is applied between XLs, the XLG power may be set so as to deliver the maximum MCS on the XL as long as it does not exceed the maximum transmit power that the WTRUs may apply according to device capability.
- Fig. 34 is a diagram 3400 of a cell 3440 where the XLs in the cell are arranged into frequency reuse groups.
- the XLs in the cell 3440 operated by the eNB 3450 are arranged into four frequency reuse groups 3460, 3470, 3480 and 3490.
- the frequency reuse group 3460 includes XLs 3402, 3404, 3406, 3408, 3410, 3412 and 3414.
- the frequency reuse group 3470 includes XLs 3416, 3418, 3420, 3422, 3424, 3426 and 3428.
- the frequency reuse group 3480 includes XLs 3430, 3432, 3434, 3436, 3438, 3440 and 3442.
- the frequency reuse group 3490 does not have any XLs specifically assigned to it.
- One of ordinary skill in the art will recognize, however, that the XLs in a cell may be organized into any number of frequency reuse groups which may include any number of XLs per group.
- an XLG may specify code allocations for physical channels and reference signals for applying CDMA in addition to FDMA.
- two XL specific reference signals may co-exist in the same frequency resource location using two ZC-based sequences.
- the sequences may be derived from the same base sequence with different cyclic shifts in order to provide orthogonality.
- the network may also apply TDMA when the XL employs a TDD duplex scheme.
- two XLs assigned with identical frequency and code resource allocations may be configured with a different TDD XDL/XUL configuration so that the transmission times of the XDL1 and XUL2 coincide.
- the helper WTRU and terminal WTRU transmissions may have different code configurations, XDL1 and XUL2 may not interfere with each other.
- Helper and terminal WTRU XLGs for AT-R applications may include one or more of many different types of information.
- a helper WTRU XLG may grant a helper WTRU permission, restricted by the validity period, to transmit in the XDL to a terminal WTRU according to the accompanied configuration of the transmission.
- a terminal WTRU XLG may grant permission for a terminal WTRU to transmit in the XDL to a helper WTRU in a similar fashion.
- WTRU XLGs may include a duration of the validity period (e.g., in number of TTIs), a maximum allowed helper WTRU transmit power on the XL, a target nominal power at the terminal WTRU applied in XLPC (e.g., in dBm), an XDL/XUL duplex configuration (e.g., for TDD), an XDL assignment index (e.g., for TDD), a sub-carrier resource allocation (e.g., in sub-bands) for all XDL dedicated channels (the multiplexing between these channels within the assigned frequency resource may be pre-defined), and XDL specific reference signal code configurations (e.g., spreading factor/spreading code assignment, or base sequence/cyclic shift).
- a duration of the validity period e.g., in number of TTIs
- a maximum allowed helper WTRU transmit power on the XL e.g., in dBm
- helper WTRU XLGs may include XPDFBCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), XPDCCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPDCCH resource configuration (e.g., spreading factor or channel code assignment), an XPGCH resource configuration (e.g., spreading factor or channel code assignment), XPDDCH demodulation reference code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPDDCH frequency hopping indicator and an XUL CQI and signal measurement request and configuration.
- XPDFBCH specific reference signal code configurations e.g., spreading factor/spreading code assignment or base sequence/cyclic shift
- XPDCCH specific reference signal code configurations e.g., spreading factor/spreading code assignment or base sequence/cyclic shift
- WTRU XLGs may include, for example, a duration of the validity period (e.g., in number of TTIs), an allowed terminal WTRU maximum transmit power on the XL (e.g., in dBm), a target nominal power at the helper WTRU applied in XLPC (e.g., in dBm), an XDL/XUL duplex configuration (e.g., for TDD), an XUL assignment index (e.g., for TDD), a sub-carrier resource allocation (e.g., in sub- bands) for all XUL dedicated channels (the multiplexing between these channels within the assigned frequency resource may be pre-defined), and XUL specific reference signal code configurations (e.g., spreading factor/spreading code assignment, or base sequence/cyclic shift).
- a duration of the validity period e.g., in number of TTIs
- an allowed terminal WTRU maximum transmit power on the XL e.g., in dBm
- information for terminal WTRU XLGs may include XPUFBCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), XPUCCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPUDCH resource configuration (e.g., spreading factor or channel code assignment), XPUDCH demodulation reference code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPUDCH frequency hopping indicator or an XDL CQI and signal measurement request and configuration.
- XPUFBCH specific reference signal code configurations e.g., spreading factor/spreading code assignment or base sequence/cyclic shift
- XPUCCH specific reference signal code configurations e.g., spreading factor/spreading code assignment or base sequence/cyclic shift
- an XPUDCH resource configuration e.g., spreading factor or channel code assignment
- a helper WTRU or a terminal WTRU may need to receive both a helper WTRU XLG and terminal WTRU XLG to operate an XLG.
- certain XLG information may be carried separately from other XLG information. For example, the validity period may be informed in dedicated RRC signaling in a similar manner as an SPS-Config information element.
- a number of information fields may overlap between the helper WTRU XLG and the terminal WTRU XLG.
- one consolidated XLG may be applied and transmitted to both the helper WTRU and the terminal WTRU.
- An XLG may be considered to be an adapted type of Semi-Persistent
- SPS Scheduling
- LTE Long Term Evolution
- PDCCH control signaling overhead is motivated and justified because it is still relatively small compared to the payload carried on the PDSCH/PUSCH.
- control signaling overhead may be reduced with SPS.
- control signaling reduction may be a primary motivation to having an SPS-type of scheduling.
- the second level of scheduling which is dynamic and channel- dependent, may provide fairly adequate handling of large variations in the amount of data traffic with the help of changing power level, MCS and/or sub-carrier assignment per TTI.
- a WTRU may perform XL scheduling per TTI within the resources specified in the grant. If a WTRU cannot adjust the granted transmission bandwidth, it may adjust the MCS and calculate the power level per TTI to perform link adaptation accordingly.
- Table 2 provides a listing of characteristics of SPS-type scheduling versus XLG scheduling.
- SPS-Config including SPS - Dedicated RRC signaling interval, SPS ULPC nominal
- Interference - No intra-cell interference - No inter-XL interference in Management - Inter-cell interference one frequency reuse group coordinated with semi- static - Inter-XL interference inter-cell interference between frequency reuse coordination (ICIC) including groups coordinated with RNTP (TRDL), HII (TRUL) and XLG power adjustment OL (TRUL) or FFR (one-cell - XLG is used as a form of frequency reuse > 1) interference management.
- ICIC frequency reuse coordination
- TRDL RNTP
- TRUL HII
- TRUL XLG power adjustment OL
- FFR one-cell - XLG is used as a form of frequency reuse > 1 interference management.
- a network may derive the XLG based on any number of different inputs. Some inputs may be given more weight for the initial XLG derivation while others may be used for update XLG derivations. Examples of such inputs may include requested spectral efficiency based on QoS, estimated XL signal-to- noise ratio (SINR), buffer status, resource allocation history, XL feedback measurement, XL power headroom, and received signal measurement in the assigned sub-carrier groups.
- SINR estimated XL signal-to- noise ratio
- the network may use QoS to determine an approximate target rate for the XL and the required SINR. This may be used, for example, in admission control when a WTRU requests and establishes its services to evaluate the target power applied in the XLPC.
- the network may estimate an
- One example of an estimate of the resulting SINR based on grant and measurements may be based on:
- N is the number of assigned sub-carrier groups
- BW su b is the bandwidth of each sub-carrier group
- IoT is the total received interference power of assigned sub-carrier groups
- PL is the path loss between the helper WTRU and the terminal WTRU of the XL
- N 0 is thermal power density
- NF is a WTRU noise figure.
- the DL buffer status may be readily available at the eNB, and the UL buffer status may be reported by a WTRU either periodically or when triggered by pre-defined events.
- the buffer status may be applied in the grant algorithm to handle traffic variation.
- previously issued XLGs may be factored in.
- an LTE network scheduler may take channel state information (CSI) into consideration when performing rate prediction for dynamic scheduling.
- CSI channel state information
- a similar approach may be adopted for an AT-R capacity mode and an AT-LO application where both WTRUs may report per-TTI CSI in the TRUL either per request or according to the grant configuration.
- terminal WTRU CSI information may not be applied directly on a per-TTI basis.
- Per-TTI short-term XL CSI feedback may be, for example, multiplied with the PUSCH when a UL grant is available, transmitted in the PUCCH scheduled for the WTRU to carry TRDL CSI, or transmitted in the PUCCH schedule dedicated for the XL.
- an identifier e.g., a one-bit field
- an identifier such as a flag bit
- the XL CSI such as CQI or PMI, may reuse the existing PUCCH format.
- the scheduling of the PUCCH may be implicitly or explicitly signaled in the PDCCH DCI format carrying the XLG.
- long-term achieved rate and channel statistics based on per-TTI CSI may be used. Such statistics may include, for example, average throughput measurements or average XL CQI-equivalent measurements with their standard deviation during the XLG validity period. The averaging and statistical analysis may be performed by the physical layer according to the configuration conveyed in the dedicated RRC signaling.
- the long-term XL CSI feedback may not have a large payload, it may be transmitted similarly to the per-TTI short-term feedback.
- the long-term feedback may not have a high latency requirement, it may also be carried in MAC PDU on the PUSCH when a UL grant is available. Long- term XL CSI feedback reporting may be requested by the eNB with a UL grant for the data transmission.
- short-term or long-term XL feedback may provide the network with channel condition information to help evaluate how well the allocated XL resources are utilized.
- an LTE network may evaluate the UL scheduling decision in order to determine efficient combinations of MCS and bandwidth in the grant with the help of PUSCH power headroom reporting.
- the power headroom may be a measure of difference between the maximum WTRU transmit power and the power-controlled data channel transmit power that would be used assuming there is no limit of the WTRU transmit power.
- the transmit power may be calculated per TTI by a WTRU using the granted MCS, the granted bandwidth, the granted path loss and the received TPC command. Similar to XLFB, a current LTE network approach may be used, and both per-TTI short-term and long-term power headroom reporting may be also considered.
- an average power headroom value and its standard deviation may be reported to the network to determine what power level is required to transmit the target rate over the granted bandwidth given the channel conditions.
- the per TTI short-term power headroom may be calculated as follows based on the granted maximum transmit power level) and not the WTRU maximum transmit power as used in LTE UL power headroom):
- PXLG is the granted XL power
- BWTX is the transmission bandwidth (which may be the same as BWXLG (i.e., the granted bandwidth))
- PNominai is the desired power level at the helper WTRU or the terminal WTRU
- PL is the path loss between the helper WTRU and the terminal WTRU
- ATF is the pre-defined function of the pre-defined transport format of the XPDDCH
- TPC is the predefined function of received TPC bits.
- the sum of the items within parenthesis is the transmit power in subframe i.
- the XLPH there may be another PHR taking into account both TRL and XL transmission, which may require a new procedure in the network.
- the power headroom discussed herein may be limited to the power headroom of the XL.
- the network may configure a number of sub-frames for per-TTI short-term power headroom calculation, and the WTRU may perform averaging or other types of statistical analysis to obtain the long-term power headroom.
- Both the per-TTI short-term and long-term PHR may be transmitted, for example, in one of a new MAC control element dedicated for the XL PHR or the existing MAC control element for PHR with modification to accommodate the cross link PHR (e.g., the extended power headroom MAC control element).
- XL PHR may be requested or triggered by a pre-defined set of events.
- the XL short-term and/or long-term PHR may be reported, for example, when there is a significant change in the XL path loss, a pre-defined number of unidirectional TPC commands are applied or the per-TTI short-term power headroom values over a pre-defined number of sub-frames generate a long- term power headroom exceeding a pre-defined threshold.
- the signal level may be used to evaluate the achieved XL SINR and also to derive the PNominai used in the XL power control.
- the interference calculation may be based on a wide band analogue energy measurement and a code power measurement on all detected XL specific reference signals.
- the XL specific reference signal may be presumed to be transmitted continuously with the granted power without change.
- the two measurements combined may provide the SINR of the XL and identify the major interfering XLs.
- the XL signal measurement may also be reported to the network in the form of a bit map to reduce signaling overhead.
- the signal measurement may require averaging and filtering over a pre-configured period, and the transmission may apply PUSCH in the form of a MAC PDU.
- the network may be required to assign the PUSCH grant associated with the measurement request and/or configuration.
- a WTRU may transmit according to the same UL grant until the SPS is deactivated.
- the transmit power may be regulated only with the TPC commands.
- the XLG may also fix the bandwidth and other transmission configurations with the exception of the MCS.
- WTRUs engaging in the AT-R and AT-LO applications may adjust the MCS based on the channel condition, traffic variation and ACK/NACK reception.
- the MCS may be further applied in calculating the XL transmit power. This may be regarded as a limited degree of WTRU autonomy designated to the WTRUs related to the link adaptation for the benefit of significantly reduced signaling overhead.
- the network may still arguably assert near-full control over the XL transmissions and, therefore, the proposed XLG may be regarded as a functionality that retains network control.
- the XLG procedures described below may outline the sequence of events applicable for WTRUs to acquire initial XLGs, receive updated XLGs and perform and report the measurements for network XLG determination. The procedures may vary between different AT applications and are discussed separately.
- An initial XLG may be triggered by an event listed in the AT-R application, such as a terminal WTRU transmission of XSR/BSR or a network paging a terminal WTRU in RRC IDLE mode for a mobile terminated connection.
- the terminal WTRU transmission of the XSR/BSR event may exist in a number of procedures, including, for example, a mobile originated connection from the terminal WTRU, helper WTRU/terminal WTRU association, or terminal WTRU handover from an active helper WTRU to a back-up helper WTRU.
- a network paging a terminal WTRU in RRC IDLE mode for a mobile terminated connection event may be specific to the AT-R coverage mode.
- the helper WTRU may forward the paging message to the terminal WTRU by alerting the terminal WTRU in the XPDACH about the upcoming paging and prompting the terminal WTRU to read the XLG in the XPDSACH or XPGCH.
- the helper WTRU may send a paging indicator along with XLGs, which the terminal WTRU may use to read the paging message in the XPDDCH.
- an initial XLG may be issued in connection with a local-offload WTRU-to-WTRU call establishment procedure.
- An initial XLG acquisition may follow a neighbor discovery procedure in which a neighbor seeking WTRU may find neighbor candidates among a number of neighbor present WTRUs that are in proximity.
- one of the neighbor present WTRUs may be configured as a helper WTRU.
- an initial and update XLGs may be, for example, transmitted from the network in one of a new device class identifier (DCI) format carried in the PDCCH, a new MAC control element carried in the PDSCH, a new MAC control element carried in the PDSCH or dedicated RRC signaling in the PDSCH.
- DCI device class identifier
- an existing DCI format may be reused.
- Decoding options may include, for example, using the cell radio network temporary identifier (C-RNTI) to decode the PDCCH in the WTRU-specific search space and using a new XL specific RNTI (e.g., AT-RNTI or XL-RNTI) designated to a WTRU when the WTRU engages in an AT applications.
- C-RNTI cell radio network temporary identifier
- a new XL specific RNTI e.g., AT-RNTI or XL-RNTI
- a helper WTRU and a terminal WTRU may receive the helper WTRU XLG and the terminal WTRU XLG, respectively, using its own C-RNTI.
- the AT-RNTI may be per XL.
- the PDCCH transmission may be robust, and, therefore, the XLG may be received with high reliability.
- this option may require more network PDCCH capacity and may increase the WTRU PDCCH decoding effort.
- the new MAC control element carried in the PDSCH the semi- static nature of the XLG may not impose a high requirement on the transmission latency, and the PDSCH may be used for XLG transmission.
- the PDSCH may be subject to higher BLER, and the current MAC control element does not have acknowledgement.
- a new information element (IE) may be used, and an RLC acknowledgement may provide the network with the status as to whether the XLG has been received correctly.
- initial and update XLGs may be transmitted from the helper WTRU to the terminal WTRU, for example, in one of the XPDDCH, the XPDSACH, the XPGCH or a new MAC control element carried in the XPDDCH.
- the XLG may be multiplexed with other control information on the XL.
- the XPDSACH since the physical channel may be unscheduled, the XLG transmission may cause more interference in the system.
- the dedicated physical channel for the XLG transmission may provide a higher reliability at the expense of increased system signaling overhead.
- a WTRU may administer an XLG safeguard mechanism to notify the network about XLG transmission failure and prompt retransmission. For example, when a WTRU does not receive an update XLG before an on- going XLG expires, the WTRU may suspend the XL communication in order to not create uncoordinated interference. However, the network may not have the knowledge that the WTRU is missing an XLG, particularly for an XLG transmission in the form of a MAC control element. In this case, the WTRU may apply a new physical layer type of feedback to indicate the failure of receiving an XLG.
- the feedback may be a one-bit acknowledgement transmitted in the PUCCH.
- the WTRU may send a positive acknowledgement (ACK) and also set a timer to a pre-configured value in terms of sub-frames (which may be derived from the received XLG validity period). If no update XLG is received when the timer expires, the WTRU may send a negative acknowledgement (NACK) to trigger an XLG retransmission from the network.
- ACK positive acknowledgement
- NACK negative acknowledgement
- This XLG retransmission mechanism may not be applied for initial
- the WTRU may retransmit the SR/BSR according to the pre-defined protocol.
- the eNB may, thus, infer from the SR/BSR retransmission that the previous XLG was not properly received by the WTRU and, accordingly, retransmit the XLGs.
- FIGs. 35A and 35B include a signal diagram 3500A/3500B of an example initial grant acquisition procedure and update XLG operation in a capacity mode.
- a neighbor seeking WTRU 3502 may engage in a neighbor discovery procedure.
- one neighbor present WTRU may be selected as a candidate helper WTRU 3510 (3512) for a terminal WTRU 3508.
- Both the terminal WTRU 3508 and the helper WTRU 3510 are in RRC CONNECTED mode 3514/3516.
- the helper WTRU 3510 and the terminal WTRU 3508 may perform XL measurements with a cell specific XL configuration (3519/3520).
- Such XL measurements may include measuring the XL BW assigned to this cell broadcast by the network (the granularity of assignable XL resources may be pre-defined (e.g., sub-carrier group or sub-band configuration)) and measuring the XL specific reference signal code group or base sequence group broadcast by the network.
- the XL measurements may be made on the XUL and XDL by the helper WTRU 3510 and the terminal WTRU 3508, respectively.
- Each pair of XDL/XUL may be characterized, for example, with a sub-carrier group assigned and/or a unique sequence of code assigned for the XL specific reference signal.
- the same sub-carrier group may be assigned to both the XDL and XUL of one XL.
- the sub-carrier groups assigned to the XDL and XUL of one XL may be separated by the duplex distance.
- the same sequence or code may be used for both the XDL and XUL.
- a detected XL specific reference signal at one assigned sub-carrier group may indicate an existing XL, and the network may attempt to avoid issuing an XLG using the same combination of sub-carrier group and reference signal.
- the XDL may be divided into X sub-bands and Y assignable sequences or codes
- a terminal WTRU may need to detail how many sequence codes are detected in each sub-band.
- the sequence implementation is ZC based and is generated from cyclic shifts of a common root sequence
- the commonly used frequency- domain computation of the power delay profile (PDP) of the root sequence may provide, with a single operation, the concatenated PDPs of all signatures derived from the same root sequence. This may reduce the number of measurements per sub-band.
- the XDL measurement result may be used to construct a bit map of size X times Y bits with each bit indicating whether or not the sequence or code is detected in the sub-band.
- the bit map may show what code and frequency resources are occupied by other XDLs near the measuring terminal WTRU.
- the bit map format may reduce the signaling overhead required by the XLG.
- the network may, for example, evaluate what code and sub-band is available for the reporting helper WTRU/terminal WTRU and make an assignment accordingly.
- the initial helper WTRU/terminal WTRU XLGs may be sent, for example, on the PDSCH in the form of a MAC control element (3526/3528).
- the potential problem with data channel transmission of the XLG in general may be the relatively higher error rate compared to the control channel.
- the HARQ re-transmissions may also fail, and the PDU carrying the initial XLGs may not be received. In this case, the XSR retransmission timer may be relied on to trigger another transmission of the XSR/BSR to attempt re- acquisition of the initial XLGs.
- the XLG may also be carried in the PDCCH to the helper WTRU and the terminal WTRU in the WTRU specific search area to achieve high reliability of the XLG transmission. It may require a new DCI format, which may increase the number of WTRU blind decodes.
- the DCI format may have a small pay load or have identical numbers of bits as one of the existing DCI formats with modified fields. Carrying the XLG in the PDCCH may require increased PDCCH capacity in the network.
- XLGs they may apply the XLGs and start synchronous data communication either with the help of a timer, a pre-defined time interval referenced at the reception of XLGs, or a pre-specified start time (3530).
- the helper WTRU 3510 and the terminal WTRU 3508 may start keeping track of the validity period and apply the XLG configurations to follow the duplex configuration if TDD is applied, transmit XL specific reference signals, transmit XPDCCH/XPDDCH and XPUCCH/XPUDCH and/or transmit DMRS for XPDDCH and XPUCCH.
- both the helper WTRU 3510 and the terminal WTRU 3508 may transmit an XL specific reference signal, and the helper WTRU's signal may be used for the terminal WTRU 3508 to synchronize with the helper WTRU 3510 (the helper WTRU's timing and frequency may be the master).
- the helper WTRU reference signal may be used by the terminal WTRU 3508 to perform channel estimation (to decode XPDCCH), determine feedback measurements (e.g., CQI) and/or derive transmission power control (TPC) bits.
- the terminal WTRU reference signal may also be applied for those purposes but may not be used for synchronization purposes.
- Each helper WTRU/terminal WTRU may transmit over the same bandwidth specified in the XLGs and adjust the MCS based on the received ACK/NACK and CQI.
- the CQI may, thus, be measured on the same bandwidth because no frequency selective scheduling may be used on the XL.
- the CQI may provide a recommendation for the MCS.
- the frequency selectivity of the assigned XLG bandwidth may be explored, and the helper WTRU/terminal WTRU may report a further refined CQI of different sub-carrier groups within the granted bandwidth and schedule transmissions dynamically over different bandwidths.
- the XLS information may be transmitted on the XL in a dedicated control channel (e.g., the XPDCCH).
- the schedule information may include, for example, the MCS, the sub-carrier resource (if the transmission bandwidth may be adjusted), a new data indicator, or a redundancy version. These bits may be protected with cyclic redundancy check (CRC) bits that are scrambled with an XL identity, such as an AT-RNTI.
- CRC cyclic redundancy check
- Each helper WTRU/terminal WTRU for each TTI based on the selected MCS and granted bandwidth (which may be a constant during XLG validity period) may calculate the XPDDCH/XPUDCH transmit power, for example, based on:
- PXLG is the granted XL power
- BWTX is the transmission bandwidth (which may be the same as the BWXLG or granted bandwidth)
- PNominai is the desired power level at the helper WTRU or the terminal WTRU
- PL is the path loss between the helper WTRU and the terminal WTRU
- ATF is the pre-defined function of the pre-defined transport format of the XPDDCH
- TPC is the predefined function of received TPC bits.
- the path loss between the helper WTRU and the terminal WTRU may be calculated based on the XL specific reference signal presuming that the signal always applies PXLG, the maximum allowed power specified in the XLGs.
- PNominai may be the desired or target power at a helper WTRU and a terminal WTRU given their interference level.
- the value of PNominai + PL denotes the basic open loop starting point.
- the equivalent parameter in LTE UL control, PCLPUSCH may include components such as, for example, PO_NOMINAL_PUSCH, which may be in the range of -126 and +24 dBm and may be used to derive different BLER operating points to achieve low probability of retransmissions, or PO_UE_PUSCH, which may be in the range of -8 and +7 dB and may be used to compensate systematic offsets in WTRU transmit power due to errors in the estimated path loss.
- PO_NOMINAL_PUSCH which may be in the range of -126 and +24 dBm and may be used to derive different BLER operating points to achieve low probability of retransmissions
- PO_UE_PUSCH which may be in the range of -8 and +7 dB and may be used to compensate systematic offsets in WTRU transmit power due to errors in the estimated path loss.
- PO_NOMINAL_PUSCH may be signaled to a WTRU via network broadcast by and PO_UE_PUSCH via dedicated signaling, so they may also be semi- static in nature.
- PNominai may be included in XLGs and may be updated based on the XL measurement report sent to the network.
- ATF may be a function of the selected MCS, and TPC may be a function of the TPC bits received.
- a distributed power control function may be performed by the WTRU.
- the TPC commands in the XLS may be derived by the helper WTRU and the terminal WTRU using a pre-defined algorithm based on the received quality (e.g., the SINR of the reference symbols and/or the BLER of the data transmission).
- the TPC commands may be transmitted in a dedicated XL control channel or may be multiplexed with other control information in a common control channel.
- the TPC rate may be slower than once per TTI and may be a design parameter.
- An LTE FDD system may apply TPC bits 4 sub-frames after a sub-frame in which the TPC bits are received.
- dedicated control and data channels may be time-multiplexed.
- the XPDCCH may precede the XPDDCH in each TTI, and a terminal WTRU may need to read the XPDCCH to acquire all information necessary to decode the XPDDCH and continue to receive the XPDDCH in the same TTI.
- This may be similar, for example, to the LTE DL where a WTRU may read the PDCCH prior to decoding the PDSCH in the same TTI. However, this may be the case on both the XDL and the XUL when a terminal WTRU schedules a transmission based on the grant received from the network.
- the XL dedicated control channels may have a different power control mechanism than the XL dedicated data channels that may be more tailored to the control channel formats and payloads.
- the XPDCCH of sub-frame i may be calculated based on:
- ATF is a function of the pre-defined transport format of the XPDCCH. Further, the bandwidth applied for the XPDCCH transmission may be predefined and factored into the function.
- the TPC is the distributed power control function performed by the WTRUs as described above.
- the helper WTRU/terminal WTRU may use the calculated transmit power to derive the XLPH. Further, they may continue the XL measurement upon request from the network (3532/3534) with configuration directly related to the issued XLGs. For example, the network may request specific signal strength measurements on certain sub-carrier groups to help optimize the XLG update instead of a bit map reported prior to the initial XLG.
- the measurement result may be the signal strength of the requested XL specific reference signal in the requested sub-carrier groups.
- the result may be quantized in a manner similar to received signal code power (RSCP) measurements in the LTE network and may be considered to be transmitted on a physical channel in the LTE UL.
- RSCP received signal code power
- the result may be transmitted in the PUCCH along with the UL control information bits, such as CQI bits, in a new dedicated physical XL feedback channel in addition to the PUCCH, or in XL RRC measurements carried in the PUSCH.
- the helper WTRU 3510 and the terminal WTRU 3508 may perform the requested XL measurement and send one or more XL measurement reports to the eNB 3506 on the PUSSCH (3536/3538/3540/3542).
- the physical channel transmission may benefit from low latency but may require extra PUCCH resources.
- the measurement result may be multiplexed with the PUSCH when the TRUL grant is available in a similar manner to CQI multiplexing in the PUSCH.
- the XL RRC measurements may be requested, configured and reported in the same way as regular neighbor cell measurements.
- the terminal WTRU may not have an RRC entity, and, therefore, the helper WTRU may need to forward the terminal WTRU measurement to the network in the PUSCH.
- the measurement of a helper WTRU and a terminal WTRU may occur in their receiving sub-frames in the case of an XL with TDD scheme and the designated band in the case of an FDD scheme.
- a measurement gap configuration may be required to suspend the TRL transmission.
- the network may update the XLGs to optimize the resource allocation and coordinate inter-cross-link interference (3548).
- the power control mechanism may be administered before the XLGs are updated to facilitate an efficient utilization of power resource by the adjustment of PXLG while maintaining the QoS (3544).
- a transmitting WTRU may calculate a maximum MCS according to the assigned PXLG and the power control formula when the assigned bandwidth is applied unchanged.
- the subsequent data transmissions may result in a BLER ratio for a pre-defined period measured at the receiving WTRU.
- the receiving WTRU may then generate TPC commands based on the BLER ratio to regulate the power, and a consecutive number of unidirectional TPC commands may trigger a power head room reporting.
- the receiving WTRU may send a number of consecutive DOWN TPC commands, which may be pre-defined as a PHR trigger, and the transmitting WTRU may report the power headroom to the eNB.
- the eNB may then reduce the PXLG in the next grant. Once the XLGs have been updated, data transmission may be resumed (3550).
- FIGs. 36A and 36B include a signal diagram 3600A/3600B of another example initial grant acquisition procedure and update XLG operation in a capacity mode.
- the terminal WTRU 3602 and the helper WTRU 3604 are initially in RRC IDLE mode (3608/3610).
- Each of the terminal WTRU 3602 and the helper WTRU 3604 engages in a paging procedure with the eNB 3606 (3612/3614), after which both the terminal WTRU 3602 and the helper WTRU 3604 are in RRC CONNECTED mode (3616/3618).
- the eNB 3606 when both the helper WTRU 3604 and the terminal WTRU 3602 transition to the RRC CONNECTED mode, the eNB 3606 sends a measurement request and configuration to each of the terminal WTRU 3602 and the helper WTRU 3604 based on the pair's historical XLGs (3620/3622).
- the remaining signaling and procedure illustrated in FIG. 36 is the same as the embodiment illustrated in FIGs. 35A and 35B, and the corresponding signals/procedure have been given the same numbers in FIGs. 35A, 35B, 36A and 36B.
- FIGs. 37A and 37B include a signal diagram 3700A /3700B of an example initial grant acquisition and continued XLG update procedure in a coverage mode.
- the main differences between the XLG procedures in AT-R capacity and coverage mode may be due to the lack of a TRL at the terminal WTRU.
- the XLGs may be transmitted to a terminal WTRU via the XL, all XL measurements from a terminal WTRU are relayed by its helper WTRU to the network, and a new safeguard mechanism may be put in place to guard against lost XLGs on the XL transmission.
- neighbor present WTRU 3704 and an eNB 3706 engage in a neighbor discovery procedure after which the neighbor WTRU 3704 is selected as a candidate helper WTRU (3708).
- the neighbor seeking WTRU 3702 and the selected candidate helper WTRU 3704 may then exchange association messages on the XPDSACH (3710).
- the neighbor seeking WTRU 3702 and the candidate helper WTRU 3704 may then exchange RRC messages.
- the candidate helper WTRU 3704 may transmit its RRC message on the XPDSACH (3710).
- Its RRC message may include basic system information, such as, for example, the candidate helper WTRU's cell ID and temporary mobile subscriber identity (TMSI) or the helper WTRU's C-RNTI (3712).
- the neighbor seeking WTRU 3702 transmits its RRC message on the XPUSACH.
- Its RRC message may include an indication that the candidate helper WTRU 3704 has been selected as the helper WTRU (3714).
- the selected helper WTRU 3704 and the eNB 3706 may then engage in a RACH and RRC connection setup procedure (3715), if necessary, after which the selected helper WTRU 3704 is in RRC CONNECTED mode (3718) and the neighbor seeking WTRU 3702 is now the terminal WTRU 3716.
- the selected helper WTRU 3704 may transmit a selection indicator to the terminal WTRU 3716 on the XPDACH (3720).
- the terminal WTRU 3716 may send an XSR to the selected helper WTRU 3704 on the XPUACH and make an XL measurement on the XPUSACH (3722).
- the selected helper WTRU 3704 may then send an XSR to the eNB 3706 on the PUCCH and make an XL measurement on the PUSCH (3724).
- the selected helper WTRU 3704 may receive initial helper
- the selected helper WTRU 3704 may transmit an initial XLG to the terminal WTRU in the XPDSACH or the XPGCH (3727).
- the XPDACH may indicate the XLGs in the XPDSACH for the terminal WTRU 3716 to read.
- the XPDSACH is a data channel, and the XLGs may be in the form of a MAC control element or a MAC PDU similar to the one used in the RACH access response (RAR) for LTE systems.
- the XPDACH may indicate the XLGs in the XPGCH.
- the XPGCH may be a PHY channel only, and the XLGs may be in the form of control bits.
- the selected helper WTRU 3704 may now be an active helper WTRU 3728.
- the 3706 may begin data transmission following the initial XLGs (3730).
- the eNB 3706 may send an XL measurement request and configuration message to the helper WTRU 3728 on the PDSCH (3732), and the helper WTRU 3728 may forward the XL measurement request and configuration to the terminal WTRU 3716 on the XPDCH (3734).
- the terminal WTRU 3716 may send an XL measurement report to the helper WTRU 3728 on the XPUDCH (3736), and the helper WTRU 3728 may forward the measurement report to the eNB 3706 on the PUSCH (3738). This process may be repeated as necessary (e.g., 3740/3742).
- the eNB 3706 may then engage in a procedure to optimize the grant power levels of each XL (3744).
- the helper WTRU 3728 may receive updated helper WTRU/terminal
- the helper WTRU 3728 may transmit an update XLG to the terminal WTRU 3716 in the XPDSACH/XPGCH, the XPGCH, the XPDDCH or the XPDDCH (3748).
- the helper WTRU 3728 may transmit the update XLG the same way as it does an initial XLG. After the XLGs are updated, normal transmission may be resumed (3750).
- the WTRU may be ensured with an XSR retransmission (e.g., if the initial XLGs are not received, the terminal WTRU may retransmit the XSR according to the timer). However, once the update XLGs are lost, they may not be recovered, and the terminal WTRU may then suspend its transmission. In this case, the helper WTRU may detect radio link failure (RLF) on the XUL. A new handling may thus be required to avoid unnecessary RLFs.
- RLF radio link failure
- helper WTRU may attempt to retransmit the update XLG to see if the reference signal level recovers.
- the terminal WTRU may transmit an indication of the missing update XLG in the XPUCCH if, during the validity period of the on-going XLG, no update XLG is received from the helper WTRU. This may trigger the helper WTRU to retransmit to the terminal WTRU.
- This type of safeguard mechanism against XLG loss may be useful when XLGs are carried in a data channel that has a higher error rate than the physical layer control channel.
- the XLG procedure applied in AT-LO applications may be similar to that discussed in connection with the AT-R capacity mode because all WTRUs participating in an AT-LO application may be associated with the network.
- AT- LO applications may adopt a different set of physical channels including, for example, an XL physical cluster head broadcast channel (XPCHBCH) that may be used to carry the XLG to all cluster members.
- XPCHBCH XL physical cluster head broadcast channel
- the assigned XLG may be per cluster, and the cluster head may perform a more extensive XL scheduling over multiple XLs.
- a cluster head may be required to dynamically schedule resources allocated by the XLG to different XLs in accordance with the channel condition and traffic variation of each XL.
- Each cluster member may provide similar measurements as described above with respect to the cluster head to assist the scheduling decision.
- a method of radio resource scheduling on a radio cross link between a first node and a second node comprising the first node receiving a cross link grant specifying resources for use by at least the first node for transmission on the radio cross link.
- cross link grant is at least one of a maximum allowed cross link transmit power, an assignment of a cross link bandwidth, a provision of cross link power control parameters or a designated code configuration for all physical channels on the cross link.
- cross link grant includes a validity period after which the cross link grant is no longer valid.
- cross link grant is based on at least one of cross link signal and interference measurements, cross link power headroom reporting, or cross link feedback measurements.
- cross link scheduling per TTI is based on the resources specified in the cross link grant and at least one of a cross link acknowledgement/non-acknowledgement
- ACK/NACK ACK/NACK
- CQI channel quality indicator
- a wireless transmit/receive unit comprising: a receiver configured to receive a radio link control (RLC) protocol data unit (PDU); a local buffer; and a partial RLC layer.
- RLC radio link control
- WTRU is configured to relay data between a base station and another WTRU by communicating with the base station via a traditional radio link and communicating with the other WTRU via the radio cross link.
- WTRU is not located within a cell operated by the base station.
- WTRU is configured to relay data between a base station and another WTRU by communicating with the base station and the other WTRU over a relay path that includes a traditional radio link between the WTRU and the base station and the radio cross link between the WTRU and the other WTRU, the base station and other WTRU being configured to communicate with one another over a direct path including the traditional radio link.
- An advanced topology (AT) system comprising a base station configured to operate a wireless cell and a plurality of wireless transmit/receive units (WTRUs) including a first WTRU and a second WTRU configured to communicate with the first WTRU over a first radio cross link.
- WTRUs wireless transmit/receive units
- WTRUs further include a third WTRU and a fourth WTRU configured to communicate with the third WTRU over a second radio cross link.
- [0291] 25 The AT system of embodiment 24, wherein the first WTRU and the second WTRU are configured to negotiate a first cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link grant for transmissions over the first radio cross link and to transmit at least one packet over the first radio cross link based on the first cross link scheduling per TTI.
- TTI transmission time interval
- WTRU and the fourth WTRU are configured to negotiate a second cross link scheduling per TTI within the resources specified in the cross link grant for transmissions over the second radio cross link and to transmit at least one packet over the second radio cross link based on the second cross link scheduling per TTI.
- each radio cross link within the cell is assigned to one of a plurality of frequency reuse groups.
- each radio cross link assigned to a particular one of the plurality of frequency reuse groups is granted a dedicated portion of a cross link bandwidth provided in the cross link grant.
- each of the first and second helper WTRUs includes a partial radio link control (RLC) layer.
- RLC radio link control
- 33 The AT system of embodiment 32, wherein the partial RLC layer is configured to store a received RLC protocol data unit (PDU) in a logical channel based channel queue in a local buffer.
- PDU RLC protocol data unit
- each of the first and second helper WTRUs is configured transmit to the other of the first and second WTRUs a sequence number of an RLC PDU that is the highest of all RLC PDUs dropped by the WTRU (HDSN).
- each of the other of the first and second WTRUs is configured to update a lower edge of a receive window of the other of the first and second WTRUs to HDSN+1 in response to receiving the HDSN from the one of the first and second helper WTRUs.
- each of the first and second helper WTRUs is further configured to transmit to the base station at least one medium access control (MAC) status report selected from the group consisting of a cross link uplink scheduling request for requesting an initial cross link grant for uplink transmissions, a cross link downlink scheduling request requesting an initial cross link grant for downlink transmissions, a terminal- WTRU buffer status report for determining scheduling in the cross link uplink jointly by the base station and one of the WTRU and the other WTRU, a cross link downlink buffer status report for determining scheduling in the cross link downlink jointly by the base station and the WTRU and a cross link power headroom reporting mechanism for determining cross link scheduling jointly by the base station, the WTRU and the other WTRU.
- MAC medium access control
- Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
- ROM read only memory
- RAM random access memory
- register cache memory
- semiconductor memory devices magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
- a processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Direct communication (radio cross link) between nodes (UEs) in advanced topology (LTE) applications. A method includes a first node (user equipment, UE) receiving a cross link grant specifying resources for use by at least the first node (UE) for transmission on the radio cross link (direct link). The first node also performs cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link grant and transmits at least one packet to a second node (second UE) based on the cross link scheduling grant per TTI. In another embodiment, y wireless transmit/receive unit, WTRU (UE), adapted to discard stalled (stored) RLC protocol data units, PDUs, at a helper (assisting, supplemental) WTRU (UE) on the downlink is disclosed, wherein PDUs stored at a logical channel queue or buffer are discarded (dropped) if a discard time set expires. Additionally, a system is claimed in which pairs of WTRU (UEs) are adapted to negotiate a cross link (direct link) scheduling per transmission time interval, TTI, within the resources specified in a cross link grant.
Description
DIRECT COMMUNICATION BETWEEN WIRELESS TRANSMIT/RECEIVE UNITS (WTRUS) IN ADVANCED TOPOLOGY (AT) APPLICATIONS
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Patent
Application No. 61/568,342, which was filed on December 8, 2011, U.S. Provisional Patent Application No. 61/653,512, which was filed on May 31, 2012, and U.S. Provisional Patent Application No. 61/610,754, which was filed on March 14, 2012, the contents of which are hereby incorporated by reference herein.
BACKGROUND
[0002] Long Term Evolution-Advanced (LTE-A) supports a decode-and- forward relaying scheme. Proposed LTE-A decode-and-forward relay nodes receive data from a first device, demodulate, decode and error correct the data, and then re-transmit a new signal to a second device. This is different from a traditional repeater, for example, which simply receives and re-broadcasts a signal received from another device. The decode-and-relaying scheme, while more complex, may enhance signal quality over re-broadcasting, which may degrade signal quality from reduced signal-to-noise ratio (SNR).
[0003] Two major types of LTE-A decode-and-forward relays have been proposed. Type-1 relays control their own cells with their own identity. In other words, from the perspective of a wireless transmit/receive unit (WTRU), a type-1 relay appears to be a normal enhanced NodeB (eNB). From the perspective of a donor eNB, however, a type-1 relay appears to be a normal WTRU, but may identify itself as a relay via subsequent signaling. Type-2 relays, on the other hand, do not have their own cell identity and appear to WTRUs and eNBs as the main eNB in the cell.
[0004] The backhaul link between a type- 1 relay node and a donor eNB and each access link between the type-1 relay node and each WTRU have their own full Layer-2 stacks, including full medium access control (MAC), radio link
control (RLC) and packet data control protocol (PDCP) layers, all of which are terminated at the donor eNB, the relay node and the WTRU whose data is being relayed ("terminal WTRU"). Due to, for example, the relative complexity of the type-1 decode-and-forward relay nodes proposed for LTE-A, these nodes may be more powerful than WTRUs and are most likely stationary.
SUMMARY
[0005] A method, apparatus and system for direct communication between nodes in advanced topology (AT) applications are disclosed. The method includes a first node receiving a cross link grant specifying resources for use by at least the first node for transmission on the radio cross link. The first node also performs cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link grant and transmits at least one packet to a second node based on the cross link scheduling grant per TTI.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
[0007] FIG. 1A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;
[0008] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A;
[0009] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A;
[0010] FIG. 2 is a system diagram of an LTE-A relay system;
[0011] FIG. 3 is a block diagram of a Layer-2 stack for the LTE-A relay system of FIG. 2;
[0012] FIG. 4 is a diagram of an example cross link (XL) physical layer
(PHY) frame structure;
[0013] FIG. 5 is a diagram of examples of different possibilities for multiplexing different XL physical channels into different types of XL sub- frames;
[0014] FIGs. 6A, 6B, 6C and 6D are diagrams of example channel mappings between logical, transport and physical channels on the XL;
[0015] FIG. 7A is a block diagram of a Layer-2 stack for an AT system;
[0016] FIG. 7B is a diagram of an example system architecture for an embodiment where separate data radio bearers (DRBs) are set up to carry data through the direct path and the relay path, respectively;
[0017] FIG. 8 is a flow diagram of a method of discarding stalled data at a helper WTRU on the downlink;
[0018] FIG. 9 is a diagram of a header for a radio link control (RLC) unacknowledged mode (UM) segment that a helper WTRU may use to perform re- segmentation on a first hop RLC UM protocol data unit (PDU);
[0019] FIG. 10 is a diagram of an RLC STATUS PDU that may be used for carrying a highest dropped sequence number (HDSN) over a second hop in RLC acknowledged (AM) mode;
[0020] FIGs. 11 and 12 are diagrams of example RLC PDUs with an extension (E2) bit and an optional LT field;
[0021] FIG. 13 is a diagram of an example procedure for RLC PDU discard at the helper WTRU;
[0022] FIGs. 14A and 14B include a diagram of an example procedure for moving the receive (Rx) window at the helper WTRU in RLC AM mode;
[0023] FIGs. 15A and 15B include a diagram of an example procedure for moving the Rx window at the helper WTRU when the HDSN is lost;
[0024] FIG. 16 is a diagram of an example MAC control element for carrying flow information on the traditional radio link (TRL) uplink (UL);
[0025] FIG. 17 is a diagram of an example mapping between logical channels on the XL to logical channels on the TRL;
[0026] FIG. 18 is a diagram showing an example conversion of a buffer status report (BSR) on the cross UL (XUL) shared channel to a UL BSR (TBSR) on the TRL UL-service channel (UL-SCH);
[0027] FIG. 19 is a diagram illustrating example transmission of a UL
TBSR in coverage extension mode for AT applications;
[0028] FIG. 20 is a diagram illustrating example transmission of a downlink (DL) BSR in coverage extension mode in AT applications;
[0029] FIG. 21 is a flow diagram of a method of a terminal WTRU in radio resource control (RRC) connected mode sending an XUL scheduling request to an eNB using TBSR;
[0030] FIG. 22 is a flow diagram of a method of a terminal WTRU in RRC connected mode sending an XUL scheduling request to an eNB using an XL scheduling request (XUSR);
[0031] FIG. 23 is a flow diagram of a method of a helper WTRU relaying an
XUSR to an eNB using both the TRL physical UL control channel (PUCCH) and the TRL UL-SCH;
[0032] FIG. 24 is a flow diagram of a method of a helper WTRU relaying an
XUSR to an eNB using the UL-SCH only;
[0033] FIG. 25 is a flow diagram of a method of a helper WTRU relaying an
XUSR to an eNB on the TRUL UL-SCH using an XUSR medium access control (MAC) control element;
[0034] FIG. 26 is a flow diagram of a method of a helper WTRU relaying an
XUSR to an eNB on the TRL UL-SCH using a minimum TBSR MAC control element;
[0035] FIG. 27 is a flow diagram of a method of a helper WTRU relaying an
XUSR to an eNB on the TRL PUCCH;
[0036] FIG. 28 is a flow diagram of a method of a helper WTRU sending an
XL DL scheduling request (XDSR) to an eNB on the TRL UL-SCH using an XDSR MAC control element;
[0037] FIG. 29 is a flow diagram of a method of a helper WTRU sending an
XDSR to an eNB on the TRL PUCCH;
[0038] FIG. 30 is a signal diagram of a method of sending a TBSR to an eNB when a TRL UL grant is available;
[0039] FIG. 31 is a signal diagram of a method of reporting an XL DL BSR
(XDBSR);
[0040] FIG. 32 is a signal diagram of a method of sending an XL DL power headroom report (XDPHR) and an XUPHR to the eNB on the TRL UL-SCH;
[0041] FIG. 33A is a diagram of a system of helper WTRUs and terminal
WTRUs within a cell;
[0042] FIG. 33B is a flow diagram of an example method of radio resource scheduling on a radio XL between a WTRU and another WTRU;
[0043] Fig. 34 is a diagram of a cell where the XLs in the cell are arranged into frequency reuse groups;
[0044] FIGs. 35A and 35B include a signal diagram of an example initial grant acquisition procedure and update XLG operation in a capacity mode;
[0045] FIGs. 36A and 36B include a signal diagram of another example initial grant acquisition procedure and update XLG operation in a capacity mode; and
[0046] FIGs. 37A and 37B include a signal diagram of an example initial grant acquisition and continued XLG update procedure in coverage mode.
DETAILED DESCRIPTION
[0047] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple
wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.
[0048] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.
[0049] The communications systems 100 may also include a base station
114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated
that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.
[0050] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
[0051] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).
[0052] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
[0053] In another embodiment, the base station 114a and the WTRUs 102a,
102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
[0054] In other embodiments, the base station 114a and the WTRUs 102a,
102b, 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[0055] The base station 114b in FIG. 1A may be a wireless router, Home
Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106.
[0056] The RAN 104 may be in communication with the core network 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet
connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the core network 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.
[0057] The core network 106 may also serve as a gateway for the WTRUs
102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.
[0058] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
[0059] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a
display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.
[0060] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
[0061] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, for example, a base station (e.g., the base station 114a) or another WTRU over the air interface 116. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
[0062] In addition, although the transmit/receive element 122 is depicted in
FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
[0063] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
[0064] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0065] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one
or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0066] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location- determination method while remaining consistent with an embodiment.
[0067] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
[0068] FIG. 1C is a system diagram of the RAN 104 and the core network
106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 106.
[0069] The RAN 104 may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may
each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
[0070] Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1C, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.
[0071] The core network 106 shown in FIG. 1C may include a mobility management gateway (MME) 142, a serving gateway 144, and a packet data network (PDN) gateway 146. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.
[0072] The MME 142 may be connected to each of the eNode-Bs 142a, 142b,
142c in the RAN 104 via an Si interface and may serve as a control node. For example, the MME 142 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
[0073] The serving gateway 144 may be connected to each of the eNode Bs
140a, 140b, 140c in the RAN 104 via the Si interface. The serving gateway 144 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 144 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when
downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.
[0074] The serving gateway 144 may also be connected to the PDN gateway
146, which may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0075] The core network 106 may facilitate communications with other networks. For example, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 106 and the PSTN 108. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.
[0076] FIG. 2 is a system diagram of an LTE-A relay system 200. The illustrated LTE-A relay system includes a donor cell 202, a relay node 204 and a terminal WTRU 206. The donor cell 202 and the relay node 204 communicate with one another over a backhaul link 208. The relay node 204 and the terminal WTRU 206 communicate with one another over an access link 210. The relay node 204 may be configured to relay PDCP service data units (SDUs) between the donor cell 202 and the terminal WTRU 206. The backhaul link 208 and the access link 210 may operate completely independently of one another.
[0077] FIG. 3 is a block diagram of a Layer-2 (L2) stack 300 for the LTE-A relay system 200 of FIG. 2. As described above, the backhaul link 208 and each access link 210 have their own full L2 stacks, including full MAC, RLC and PDCP layers, all of which are terminated at the donor cell 202, the relay node 204 and the terminal WTRU 206. Accordingly, in the embodiment illustrated in
FIG. 3, the donor cell 302 includes a MAC layer 314, an RLC layer 312 and a PDCP layer 310, and the terminal WTRU 306 similarly includes a PDCP layer 340, an RLC layer 342 and a MAC layer 344. The PDCP layer 310 of the donor cell 302 is in communication with a PDCP layer 320 of the relay node 304, the RLC layer 312 of the donor cell 302 is in communication with an RLC layer 322 of the relay node 304, the MAC layer 314 of the donor cell 302 is in communication with a MAC layer 324 of the relay node 304, the PDCP layer 340 of the terminal WTRU 306 is in communication with a PDCP layer 326 of the relay node 304, the RLC layer 342 of the terminal WTRU 306 is in communication with the RLC layer 328 of the relay node 304, and the MAC layer 344 of the terminal WTRU 306 is in communication with the MAC layer 330 of the relay node 304.
[0078] For handover of a type-1 relay node operating in RLC acknowledged mode (AM), a source relay node may forward any unsent PDCP SDUs to a target relay node via source and target donor eNBs in order to achieve a lossless handover. Flow control is not applied with the current LTE type-1 relay configuration, with the assumption that most traffic is transmission control protocol (TCP) based, and the TCP protocol should provide enough flow control capability.
[0079] In LTE, PDCP SDU discard may be used to clear a PDCP SDU if it is in the transmit buffer for too long. This may reduce the delay for subsequent data when the PDCP SDU buffer is full of stalled data caused by, for example, possible physical link errors. When a PDCP SDU enters the PDCP buffer, a discard timer associated with it may be started. When the timer expires, if no segment of an SDU has been mapped to an RLC PDU, the PDCP SDU is discarded. The timeout value of the discard timer may be configured by higher layers.
[0080] Further, in LTE, scheduling is done by the eNB on the network side.
The UL scheduling decision requires the WTRU to send MAC status reports to the eNB. For example, a WTRU may send a UL scheduling request (ULSR) on a condition that the WTRU wants to initiate UL data transmission. For another
example, a WTRU may also send a buffer status report (BSR) for each logical channel group at the WTRU. For another example, the WTRU may send a power headroom report (PHR) measured at the WTRU. The ULSR is sent via the physical uplink control channel (PUCCH) or by a random access channel (RACH) procedure. BSRs and PHRs are sent through MAC control elements on the UL- service channel (UL-SCH).
[0081] Further, in LTE, scheduling is channel- dependent and is performed by the eNB to allocate resources for both the UL and the downlink (DL) data channels dynamically on a per-transmission time interval (TTI) basis. The granularity of resource allocation is realized in resource blocks (RBs), which are clusters of twelve contiguous sub-carriers occupying over the period of a TTI. LTE scheduling applies orthogonal multiple access in both the DL and UL to ensure that WTRUs associated with the same cell in any given TTI utilize orthogonal resources without intra-cell interference. In addition, the UL transmission power of each TTI over the assigned resources is regulated by the UL power control.
[0082] The LTE scheduling algorithm generally takes into account a range of input parameters in an attempt to optimize a set of performance metrics, which may include, for example, maximum/average/minimum throughput, maximum/average/minimum delay, total/per-user spectral efficiency, and outage probability. The user experiences are directly affected by the aforementioned performance metrics. The typical input parameters include quality of service class identifier (QCI), channel quality indicator (CQI), BSR, acknowledge/non- acknowledge (ACK/NACK) and resource allocation history.
[0083] The scheduling, as described above, is applied on the traditional downlink (TRDL) and the traditional uplink (TRUL). The TRDL is the radio access link from the eNB to the WTRU associated with the eNB. It applies to all WTRUs associated with the network and operates in the standardized LTE DL frequency band. The physical channels carried on the TRDL include the physical downlink shared channel (PDSCH), the physical broadcast channel (PBCH), the
physical multicast channel (PMCH), the physical control format indicator channel (PFICH), and the physical hybrid automatic repeat request (HARQ) indicator channel (PHICH). The TRDL also carries physical signals, including reference and synchronization signals. The TRUL is the radio access link from the WTRU to the serving eNB. It applies to all WTRUs associated with the network and operates in the standardized LTE UL frequency band. The physical channels carried on the TRUL include the physical UL shared channel (PUSCH), the physical UL control channel (PUCCH), and the physical random access channel (PRACH). The TRUL also carries reference signals.
[0084] TRDL/TRUL scheduling information is conveyed to each WTRU with the help of device class identifier (DCI) formats carried in the DL PDCCH in each TTI. DL scheduling takes effect in the same sub-frame in which the DL DCI is received. The UL grant, however, takes effect a number of sub-frames following the sub-frame in which the UL DCI is received (e.g., 4 sub-frames in the LTE frequency division duplex (FDD) system).
[0085] An LTE network has complete control of the resource allocation of each TRDL/TRUL pair in each TTI, and the WTRU only provides assistance in transmitting DL channel feedback and UL sounding reference signals in the TRUL.
[0086] In contrast to the type-1 relay nodes described above that make use of high power, stationary relay nodes, embodiments of an advanced topology (AT) network are described herein that make use of direct WTRU-to-WTRU communication and/or direct base station- to-base station communication to relay data between a network and a destination entity such as a terminal WTRU or a terminal base station ("AT-relay" or "AT-R" mode) or to transfer data directly between WTRUs or base stations ("AT-local offload" or "AT-LO" mode). For example, in an embodiment, a smart phone or base station may be configured to function as a mini infrastructure node, in addition to its primary roles, to operate in an AT-R and/or AT-LO mode. In AT-R embodiments, a terminal WTRU or base station may exchange data with the network through another WTRU or
base station referred to as a helper WTRU or a helper base station, respectively. In AT-R, any WTRU may act as a terminal WTRU or a helper WTRU at different times, and data may be relayed between the terminal WTRU and an eNB using a two hop setup. In the two hop setup, the first hop may either be between the terminal WTRU and the helper WTRU or the eNB and the helper WTRU, and the second hop may be the hop not taken during the first hop, depending on whether the transmission is in the UL or DL. In AT-LO embodiments, WTRUs in proximity to one another may engage in direct data communications with one another under control of a central network. While all of the embodiments are described herein with respect to the relay entity and the destination entity being WTRUs, all of the embodiments are equally applicable to a relay entity that is any type of node, such as a base station (e.g., an eNB), and/or a destination entity that is any type of node, such as a base station (e.g., an eNB).
[0087] AT-R embodiments may be used to increase capacity (capacity mode or AT-RCap) and coverage (coverage mode or AT-RCov) in cellular systems. In AT-RCap, a helper WTRU may augment radio link capacity between existing WTRUs and a base station to enhance the capacity of the network and improve data transmission capacity. In AT-RCov, a helper WTRU may be used to provide coverage to WTRUs that are not in coverage and, therefore, do not have a link to the base station.
[0088] In AT-RCov for a baseline LTE cellular system, for example, a
WTRU may be considered to be in coverage if it is registered with the network (e.g., it is in an EMM-REGISTERED state), it is able to decode the broadcast channel (BCH) from a suitable cell in the network and read the primary system information (SI), it is able to decode the paging channel (PCH) and read paging messages and secondary SI, it is able to reach the cell using a RACH procedure in IDLE mode or the PUCCH/PUSCH in CONNECTED mode, and it is able to transmit and receive certain minimum data rates over the PUSCH and the PDSCH, respectively. WTRUs that do not satisfy these conditions may be said to be out of coverage and may continue to go through cell reselection until they find
a suitable cell. In the meantime, they may camp on any available cell for purposes of making emergency calls, but may not be page-able. In AT-RCov embodiments described herein, such an out-of-coverage WTRU (e.g., a potential terminal WTRU) may be provided coverage through a helper WTRU. In order to take advantage AT-RCov, however, the WTRU must still have network synchronization and timing.
[0089] In AT-LO embodiments, two close-by WTRUs may initiate a local off-load transmission under control of a central network. In an embodiment, a group of WTRUs in proximity may be assigned to a cluster with a cluster head designated by the network. In this embodiment, the cluster head may communicate directly with each cluster member and may be responsible for access control and radio resource management (RRM) of all cross links (XLs) between individual pairs of WTRUs in the cluster. Under coordination and control of the cluster head, the cluster members may apply direct WTRU-to- WTRU communication.
[0090] WTRU-to-WTRU communications may be applied to many real- world scenarios with significant potential benefits. For example, a user deep inside a building with very poor coverage may obtain coverage and additional capacity through a helper WTRU with good coverage situated at the periphery of the building or outside. For another example, users that are in close proximity and need to exchange data or have a voice conversation may do so directly without routing the data/voice through a base station and a core network. For example, co-workers in an office may have conversations and exchange data in this manner. Direct WTRU-to-WTRU communications may also enable applications related to social networking by providing information about other users belonging to the same social group that are in close proximity. It may also enable true wireless gaming experiences with extremely low latencies by connecting the users directly instead of being routed through a network. If multiple users are downloading similar information from a network, the network may transmit the data to a smaller subset of users, who may then relay the data
to the other end users. For example, users in a stadium who wish to see the instant replay of an event on the field may fall under this category. Users who are in different vehicles traveling along a highway may form direct links and transmit information to each other. One potential application may be to have instantaneous communication of accidents/traffic bottlenecks relayed to vehicles farther behind on the same road so that they may take diversions.
[0091] In both AT-R and AT-LO embodiments, communication between
WTRUs may occur in a dedicated channel referred to as a cross link (XL) as opposed to, for example, traditional eNB to WTRU communication that occurs over a traditional radio link (TRL). For AT-LO embodiments, the XL may be used for communications between a pair of WTRUs, and for AT-R embodiments, the XL may be used for communications between pairs of terminal WTRUs and helper WTRUs. In an embodiment, it may be assumed that the XL channels are sufficiently separated from the TRL such that no inter-carrier or adjacent channel interference occurs between the TRL and the XLs. In this embodiment, a separate radio frequency (RF) transceiver chain may be required for the XLs. However, in-band operation of the XL may also be possible. In an embodiment, the XL resources may be located out-of-band with respect to the TRL. The XL channel may use OFDM for its physical layer (PHY) multiplexing, similar to, for example, baseline LTE. The helper and terminal WTRUs may communicate with each other using FDD or time-division duplexing (TDD), and the related configuration may be defined by the network. In an embodiment, the network may provide coarse resource allocation for the XL, and the WTRUs (e.g., one or both of the helper WTRU and the terminal WTRU) may have the freedom to handle the per-TTI resource allocation.
[0092] FIG. 4 is a diagram of an example XL PHY frame structure 400. In the example illustrated in FIG. 4, the XL PHY frame structure includes a number of frames (e.g., 440 and 450) and corresponding subframes (e.g., 402, 404, 406, 408 and 410). The subframes 402, 404, 406, 408 and 410 include a number
of different zones, including a neighbor discovery zone 412, an unscheduled control zone 414, a normal control zone 416 and a data zone 418.
[0093] The neighbor discovery zone 412 occurs twice in every frame, once in each direction, or based on network configuration. For example, frame 440 includes an occurrence 412b of the neighbor discovery zone 412 in subframe 402 and an occurrence 412d of the neighbor discovery zone 412 in subframe 406. Only one subframe 410 of frame 450 is illustrated in FIG. 4, and subframe 410 includes an occurrence 412f of the neighbor discovery zone 412. However, frame 450 includes additional subframes (not shown), and one of the additional subframes may include an additional occurrence of the neighbor discovery zone. During a neighbor discovery zone (e.g., 412a), a WTRU may transmit a neighbor discovery initiation transmission (NDIT) 422 and await a neighbor discovery response transmission (NDRT) 420.
[0094] Within each subframe (e.g., 402, 404, 406, 408 and 410), the time- frequency resources may be divided into an unscheduled control zone (UCZ) 414, a normal control zone (NCZ) 416 and a data zone (DZ) 418. In an alternative embodiment (not shown), the neighbor discovery zone may be considered part of the subframe structure, in which case the subframe may also be considered to be the same direction as the neighbor discovery zone (e.g., transmit or receive).
[0095] The UCZ 414 includes a predetermined set of resources that may occur in every frame (once in each direction) or in certain frames that may be calculated based on the cell system frame number (SFN) (e.g., based on network configuration). Thus, all XLs in a cell may have a UCZ in the same frame. For example, frame 440 includes an occurrence 414b of the UCZ 414 in subframe 402 and an occurrence 414d of the UCZ 414 in subframe 406. Only one subframe 410 of frame 450 is illustrated in FIG. 4, and it does not include an occurrence of the UCZ. However, frame 450 includes additional subframes (not shown), and some of the additional subframes may include an occurrence of the UCZ.
[0096] In the example illustrated in FIG. 4, a neighbor seeking WTRU may use the UCZ 414a to transmit to a neighbor present WTRU an indication that it
has been selected by the neighbor seeking WTRU as the prospective helper WTRU ("helper WTRU select message") (426). The UCZ may also be used by the neighbor present WTRU to transmit basic system information to a neighbor seeking WTRU to enable association formation (424). The transmissions may occur prior to association formation and may potentially be transmitted without scheduling resources from the eNB. Thus, multiple neighbor present WTRUs may be transmitting basic system information in the same UCZ, which may provide a diversity benefit. Helper WTRU select messages from multiple neighbor seeking WTRUs may overlap in the same WTRU but may be separated using, for example, PHY scrambling mechanisms.
[0097] The NCZ 416 occurs in every subframe. In the example illustrated in FIG. 4, each of the subframes 402, 404, 406, 408 and 410 includes a respective NCZ occurrence 416b, 416c, 416d, 416e and 416f. Only one subframe 410 of frame 450 is illustrated in FIG. 4. However, frame 450 includes additional subframes (not shown), which may each include an occurrence of the NCZ. Further, in the example illustrated in FIG. 4, the NCZ (e.g., 416a) may be used for transmission of the XL physical DL control channel (XPDCCH) 428, the XL physical UL control channel (XPUCCH) 430, keep-alive messages and association messages.
[0098] The DZ 418 occurs in every subframe within a frame. In the example illustrated in FIG. 4, each of the subframes 402, 404, 406, 408 and 410 includes a respective DZ 418b, 418c, 418d, 418e and 418f. Only one subframe 410 of frame 450 is illustrated in FIG. 4. However, frame 450 includes additional subframes (not shown), which may each include an occurrence of the DZ as well. The DZ (e.g., DZ 418a) may be used to transmit data transport blocks (TBs) between the WTRUs, for example, on the cross link DL (XDL) shared channel (XPDSCH) 432 and the XUL shared channel (XPUSCH) 434. DZs may also include reference signals that may enable the WTRUs to make measurements of the XL.
[0099] For AT-R embodiments, the XL may include a number of physical channels in the XDL and the XUL. The XDL is the radio access link from the helper WTRU to the terminal WTRU. It applies to the helper WTRU and the terminal WTRU and operates in the XL frequency band. The XUL is the radio access link from the terminal WTRU to the helper WTRU. It applies to the helper WTRU and the terminal WTRU and operates in the XL frequency band. The XDL physical channels may include, for example, the XL physical neighbor discovery channel (XPNDCH), the XL physical DL association channel (XPDACH), the XL physical DL shared access channel (XPDSACH), the XL physical grant channel (XPGCH), the XL physical DL feedback channel (XPDFBCH), the XL physical DL data channel (XPDDCH) and the XL physical DL control channel (XPDCCH). The XUL physical channels may include, for example, the XL physical neighbor discovery channel (XPNDCH), the XL physical UL association channel (XPUACH), the XL physical UL shared access channel (XPUSACH), the XL physical UL feedback channel (XPUFBCH), the XL physical UL data channel (XPUDCH) and the XL physical UL control channel (XPUCCH). The XUL may also carry reference signals including, for example, an XL specific reference signal and a keep alive signal. In an embodiment, the XL physical channels are presumed to be OFDM based.
[0100] The XPNDCH may carry sequences used for neighbor discovery transmissions, including neighbor discovery initiation transmissions (NDITs) and neighbor discovery response transmissions (NDRTs). In an embodiment, the XPNDCH may occupy a default and pre-defined symbol and sub-carrier resource location that is not subject to XL grants or scheduling. The XPNDCH may apply code division multiple access (CDMA), and the code configuration may be derived by a WTRU, for example, according to pre-defined algorithms. When the XL bandwidth is more than the default frequency resource, the network may allocate additional resources (e.g., sub-carriers) for the channel in order to increase the neighbor discovery capacity.
[0101] The XPDACH may carry PHY control information, including, for example, paging indicators, association transmit/receive (TX/RX) indicators or XL grant (XLG) indicators. In an embodiment, the XPDACH may occupy a default and pre-defined symbol location, which may not be subject to XL grants (XLGs) or scheduling. The XPDACH may apply frequency division multiple access (FDMA) and/or CDMA, and the configuration may be derived by a WTRU based on the code configuration of its preceding associated XPNDCH.
[0102] The XPUACH may carry PHY control information, including, for example, XL scheduling requests (XSRs) and XL measurement result indicators. In an embodiment, the XPUACH may occupy a default and pre-defined symbol location, which may not be subject to XLG and scheduling. The XPUACH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the code configuration of its preceding associated XPNDCH.
[0103] The XPDSACH may carry higher layer control information, including, for example, basic system information (BSI), initial configuration information (InitConfiguration) (including XLG) and selected helper WTRU information. In an embodiment, the XPDSACH may occupy a default and predefined symbol location, which may not be subject to XL grants or scheduling. The XPDSACH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the configuration of its associated XPDACH. In an embodiment, the information necessary to decode the channel, such as transport format, may be pre-defined.
[0104] The XPUSACH may carry higher layer control information, including, for example, XL measurement results. In an embodiment, the XPUSACH may occupy a default and pre-defined symbol location, which may not be subject to XLGs or scheduling. The XPUSACH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the configuration of its associated XPUACH. In an embodiment, the information necessary to decode the channel, such as transport format, may be pre-defined.
[0105] The XPGCH may carry XLG information, including, for example, sub-carrier allocation, TDD sub-frame duplex scheme, maximum XL power, dedicated XL channel code configuration and reference signal configuration. In an embodiment, the XPGCH may occupy a default and pre-defined symbol location, which may not be subject to XLGs or scheduling. The XPGCH may apply FDMA and/or CDMA, and the configuration may be derived by a WTRU based on the configuration of its associated XPDACH. This unscheduled version of the XPGCH may exist only in AT-R coverage mode. In both AT-R capacity and coverage modes, the XLG for the helper WTRU may also specify the complete resource configuration of this channel for XL dedicated use of XLG transmission from helper WTRU to terminal WTRU, and in that case, the XPGCH may apply space, time, frequency or code division multiple access. In an embodiment, this channel may be only applied on the XDL.
[0106] The XPDFBCH may carry channel state information (CSI) of the
XUL and the ACK/NACK of the XUL data transmission. In an embodiment, the complete resource allocation of this channel may be determined by the XLG for the helper WTRU. The XDFBCH may apply space, time, frequency or code division multiple access.
[0107] The XPDDCH may carry XDL user data received from the MAC layer. In an embodiment, the complete resource allocation of this channel may be determined by the XLG for the helper WTRU. The XPDDCH may apply space, time, frequency, or code division multiple access.
[0108] The XPDCCH may carry data related to control information for the terminal WTRU to decode the XPDDCH in the same TTI. In an embodiment, the complete resource allocation of this channel may be determined by the XLG for the helper WTRU. The XPDCCH may apply space, time, frequency, or code division multiple access.
[0109] The XPUFBCH may carry channel state information of the XDL and the ACK/NACK of the XDL data transmission. In an embodiment, the complete resource allocation of this channel may be determined by the XLG for
the terminal WTRU. The XUFBCH may apply space, time, frequency, or code division multiple access.
[0110] The XPUDCH may carry XUL user data received from the MAC layer. In an embodiment, the complete resource allocation of this channel may be determined by the XLG for the helper WTRU. The XPUDCH may apply space, time, frequency, or code division multiple access.
[0111] The XPUCCH may carry necessary control information for the helper WTRU to decode the XPUDCH correctly. In an embodiment, the complete resource allocation of this channel may be determined by the XLG for the terminal WTRU. The XPUCCH may apply space, time, frequency, or code division multiple access.
[0112] In an embodiment, the XL physical channels may be partitioned into two groups. A first group may be used with no XLG (e.g., any XL may transmit and receive in these channels in connection with a set of pre-defined procedures). A second group may include all physical channels dedicated to a specific XL.
[0113] The first group may include the XPNDCH, the XPDACH, the
XPUACH, the XPDSACH, the XPDUSACH and the SPGCH. In an embodiment, a potential helper WTRU may use the XPDSACH to transmit BSI to its potential terminal WTRU in an on-going neighbor association procedure without a network grant. Although the XPDSACH transmission may not require a network grant, it may follow a pre-defined protocol that includes all necessary information required to detect and decode the channel (e.g., when the XPDSACH is transmitted relative to a neighbor discovery procedure, how the XPDSACH is coded and modulated, and what information is included in the MAC PDU). The unscheduled nature of this group of channels may subject them to contention. Schemes based on CDMA (e.g., different XPDSACHs spread with different orthogonal sequences) may be used to minimize the probability of contention.
[0114] The second group may include the XPDFBCH, the XPUFBCH, the
XPDCCH, the XPUCCH, the XPDDCH, the XPUDCH and the XPGCH. In an
embodiment, these channels may be available only after an XLG is received from the network.
[0115] A reason for partitioning the channels into groups may be to allow
XL physical layer transmission without network involvement (e.g., when an out- of-coverage WTRU is establishing higher layer signaling in a neighbor association process). Thus, the un-scheduled channels may be specifically used for AT-R coverage embodiments due to the lack of association of the terminal WTRUs with the network. For AT-LO embodiments and AT-R embodiments when the relay is established and the network grant is received, no un-scheduled channels, except the XPNDCH may be used, and all XL specific communication may be carried on scheduled channels according to network grants.
[0116] FIG. 5 is a diagram 500 of examples of different possibilities for multiplexing different XL physical channels into different types of XL sub- frames. For each example subframe 502, 520 and 540 illustrated in FIG. 5, a network assigned XL bandwidth (BW) and a minimum XL BW (e.g., 72 sub- carriers) is shown. In one illustrated example, an XPNDCH 504a, a guard period 506a, an XL specific reference signal 508a, an XPDCCH and XPDFBCH 510a and an XPDDCH and demodulation reference signals (DMRS) 512a are multiplexed into an XDL subframe with XPNDCH 502. In another illustrated example, an XL specific reference signal 508b, XPDCCH and XPDFBCH 510b and an XPDDCH and DMRS 512b are multiplexed into an XDL data subframe 520. In another illustrated example, an XPNDCH 504b, a guard period 506b, an XL unscheduled reference signal 514, an XL physical access channel (XPACH) 516 and an XL slow access channel (XSACH) 518 are multiplexed into a shared accessible sub-frame with XPNDCH 540.
[0117] The MAC layer may provide services to the RLC in the form of logical channels. The type of logical channel may be either a control channel used for transmission of control and configuration information or a traffic channel used for carrying the user data. The XL logical channels may include an XL physical control channel (XPCCH), an XL common control channel (XCCCH),
an XL dedicated control channel (XDCCH) and an XL dedicated traffic channel (DTCH).
[0118] The PHY may offer services to the MAC in the form of transport channels, and the XL transport channels may include an XL paging channel (XPCH), an XL common channel (XCCH), an XDL scheduling channel (XDL- SCH) and an XUL scheduling channel (XUL-SCH). Data on a transport channel may be organized into transport blocks, and, in an embodiment, one transport block of a certain size may be transmitted in each TTI. For embodiments employing special multiplexing (e.g., MIMO), up to two transport blocks may be transmitted in one TTI.
[0119] FIGs. 6A, 6B, 6C and 6D are diagrams of example channel mappings between logical, transport and physical channels on the XL.
[0120] FIG. 6A is an example channel mapping 600a for an XDL. In the example illustrated in FIG. 6A, mappings for the XPCCH 602, XCCCH 604, XDCCH 606 and XDTCH 608 DL logical channels, the XPCH 610, XCCH 612 and XDL-SCH 614 DL transport channels and the XPDSACH 616, XPDDCH 618, XPDACH 620, XPDCCH 622, XPDFBCH 624, XPGCH 626 and XPNDCH 628 DL physical channels are shown. FIG. 6B is an example channel mapping 600b for an XUL. In the example illustrated in FIG. 6B, mappings for the XCCCH 604, XDCCH 606 and XDTCH 608 UL logical channels, XCCH 612 and XUL-SCH 630 UL transport channels and XPUSACH 632, XPUDCH 634, XPUCCH 636, XPUACH 638, XPUFBCH 640 AND XPNDCH 628 UL physical channels are shown. FIG. 6C is an example channel mapping 600c for an XDL. In the example illustrated in FIG. 6C, mappings for the PCCH 642, XCCCH 604, DCCH 644 and DTCH 646 DL logical channels, XPCH 610, XCCH 612 and XDL-SCH 614 DL transport channels and XPCDCCH 648, XPDSCH 650, XPACH 652 and XPDCCH 622 DL physical channels are shown. FIG. 6D is an example channel mapping 600d for an XUL. In the example illustrated in FIG. 6D, mappings for the XCCCH 604, DCCH 644 and DTCH 646 UL logical channels, XCCH 612 and
XUL-SCH 630 UL transport channels and XPUCCH 654, XPUSCH 656, XPUCCH 636 and XPACH 652 UL physical channels are shown.
[0121] Embodiments are described below that provide for enhancements to features of an AT system to enable a normal WTRU to efficiently act as a helper WTRU to relay data between a terminal WTRU and an eNB and, in some embodiments, to provide for data offload between WTRUs. In an embodiment, an L2 architecture for a helper WTRU is described for relaying data between a terminal WTRU and an eNB. Such an embodiment may include use of a partial RLC at the helper WTRU, which may be transparent to the eNB and the terminal WTRU. Such architecture supports scheduling flexibility between the TRL and the XL. In another embodiment, methods are described for discarding data that is stalled in the buffer of a helper WTRU and notifying the terminal WTRU of discarded data. In this embodiment or in alternative embodiments when different L2 architectures are used, a flow control mechanism may be implemented to prevent the helper WTRU buffer from overflowing because the helper WTRU may have a relatively limited buffer space or to limit the amount of data buffered at the helper WTRU to reduce the delay caused by data buffering. In an embodiment, data re- segmentation mechanisms are described to enable independent scheduling on the TRL and the XL. In an embodiment, new MAC status reports for coverage extension mode sent from a helper WTRU to a terminal WTRU are described that may be reported to the eNB to support XL scheduling. In an embodiment, a two-tier scheduling method is described for the XL, with the first tier being a centralized and semi- static XLG issued by a network and the second tier being distributed and dynamic XL scheduling (XLS) that may be performed by the WTRUs themselves.
[0122] FIG. 7A is a block diagram 700 of an L2 stack 702 for an AT system that includes a MAC layer (718/720) and a partial RLC layer 722 that reside at the helper WTRU 704. In the example illustrated in FIG. 7A, the L2 stack is shown for an eNB 703, a helper WTRU 704 and a terminal WTRU 706. The illustrated eNB 703 includes a PDCP layer 708, an RLC layer 710 and a MAC
layer 712, the illustrated helper WTRU 704 includes a partial RLC layer 722 and a MAC layer 718/720, and the illustrated terminal WTRU 706 includes a PDCP layer 713, an RLC layer 714 and a MAC layer 716.
[0123] In an embodiment of a partial RLC layer 722, the automatic repeat request (ARQ) function in RLC AM mode is terminated only at the eNB 703 and the terminal WTRU 706 and not at the helper WTRU 704. Accordingly, in this embodiment, the helper WTRU 704 does not retransmit data according to an RLC ARQ function. This may enable the RLC to avoid data loss for seamless helper WTRU mobility in an RLC AM mode. RLC re- segmentation, if required, may be used to re-construct the transport block (TB) for the second hop. In an embodiment, two independent HARQ entities, one for the XL and another for the TRL, may be included at the helper WTRU. However, other configuration options for HARQ at the helper WTRU may also be possible.
[0124] In an embodiment, RLC PDUs arriving at the helper WTRU 704 may be stored in logical channel based queues, which may allow data to be discarded on a per-logical channel basis. Discard timer information for each logical channel may be exchanged as part of the configuration information. When the partial RLC layer 722 buffers RLC PDUs in logical channel based queues, it may drop an RLC PDU if it is considered to be stalled due to, for example, expiration of its associated discard timer, re- segment an RLC PDU for the second hop when necessary, and send the highest dropped sequence number (HDSN) over the second hop in an RLC AM mode. The L2 stack 702 may be applied to both the UL and DL.
[0125] In an embodiment of RCap mode, all signaling between the terminal
WTRU and an eNB may be done through a direct path in the traditional radio link between the eNB and the terminal WTRU, while data may flow through either the direct path or a relay path (including the traditional radio link between the eNB and a helper WTRU and the XL between the helper WTRU and the terminal WTRU). In an embodiment, separate data radio bearers (DRBs) may be set up to carry the data through the direct path and the relay path,
respectively. In another embodiment, a common DRB may be used for both the direct path and the relay path. In this embodiment, PDCP PDUs may be split between the two paths. For RCov modes, data may flow only through the relay path.
[0126] FIG. 7B is a diagram 750 of an example system architecture for an embodiment where separate DRBs are set up to carry data through the direct path and the relay path, respectively. In the example illustrated in FIG. 7B, an eNB 772 is in communication with a terminal WTRU 770 via a direct path 774 and a relay path. The relay path is a path between the eNB 772 and the terminal WTRU 770 that includes the traditional radio link 776 between the eNB 772 and a helper WTRU 778 and the XL 777 between the helper WTRU 778 and the terminal WTRU 770. The helper WTRU protocol stack 700 illustrated in FIG. 7B is identical to the helper WTRU protocol stack 700 in FIG. 7A. The direct path protocol stack 752 for the eNB 772 and the terminal WTRU 770 includes the same entities that would normally be included in an LTE protocol stack, including PDCP layers 754 and 762, RLC layers 756 and 764, MAC layers 758 and 766 and PHY layers 760 and 768.
[0127] In an embodiment of RCov mode, the helper WTRU may be used for both signaling and data transfer. Accordingly, access stratum (AS) security may need to be established via the helper WTRU. As LTE protocols support mutual authentication and replay protection along with usage of temporary identifiers, establishing AS security via the helper WTRU may not introduce new security concerns. The PDCP layer may be responsible for ciphering and integrity protection. The helper WTRU may operate at the MAC/H-ARQ level and may not interpret encrypted terminal WTRU data. Ciphered and/or integrity protected terminal WTRU data may be tunneled through the helper WTRU.
[0128] FIG. 8 is a flow diagram 800 of a method of discarding stalled data at a helper WTRU on the DL. In an embodiment, the eNB 703 may send a TB per TTI to the helper WTRU 704. The MAC layer 718/720 of the helper WTRU 704 may parse the MAC header in the received TB to identify the MAC SDUs
and RLC PDUs of each logical channel. The helper WTRU 704 may store the received RLC PDUs in logical channel based queues (802) and start a discard timer associated with each RLC PDU stored in the local buffer (804). The helper WTRU 704 may then determine whether the discard timer has expired (806). On a condition that the discard timer expires before the corresponding RLC PDU is sent to the terminal WTRU 706 via the XL, the helper WTRU 704 may drop the RLC PDU from the local buffer (808). The helper WTRU 704 may then determine whether an RLC PDU has been dropped (810). In an RLC AM mode, on a condition that at least one RLC PDU has been dropped, the helper WTRU 704 may send the highest sequence number (SN) among the dropped RLC PDUs (the HDSN) to the terminal WTRU 706 using a new type of STATUS PDU to move the receive (Rx) window at the terminal WTRU (812). The helper WTRU 704 does not expect to receive an ACK/NACK from the terminal WTRU 706 for receipt/non-receipt of the STATUS PDU. Based on an XDL grant, the helper WTRU 704 may build the XL MAC PDUs using the buffered RLC PDUS, applying RLC re- segmentation as necessary (see detailed description of RLC re- segmentation below). The helper WTRU 704 and the eNB 703 may perform flow control on a per-logical channel basis on the TRL to prevent the local buffer from overflowing. A similar embodiment may be applied on the UL.
[0129] Because helper WTRUs forward data between different radio links
(e.g., the TRL and the XL), a helper WTRU may be configured to perform re- segmentation for forwarding data between the two links on a condition that the transport block size (TBS) is different between the TRL and the XL. For an RLC AM mode, the helper WTRU may perform re-segmentation of a first hop RLC AM PDU using the normal RLC protocol.
[0130] FIG. 9 is a diagram of a header 900 for an RLC unacknowledged mode (UM) segment that a helper WTRU may use to perform re- segmentation on a first hop RLC UM PDU. The example header 900 for the RLC UM PDU segment illustrated in FIG. 9 includes the same PDU segment indication (RF) 906, last segment flag (LSF) 916 and segment offset (SO) fields 918 and 920
included in the RLC AM PDU of the normal RLC protocol. However, it also includes Rl fields 902 and 904, a framing information (FI) field 908, an extension bit field 910 and a 10 bit sequence number (SN) 914.
[0131] Examples for helper WTRU discard of received RLC PDUs are described below with respect to FIGs. 10-15.
[0132] For one example, with respect to an RLC AM mode in the DL, when the helper WTRU drops an RLC PDU because the associated discard timer expired, if the terminal WTRU is not notified that the RLC PDU has been dropped, the Rx window at the terminal WTRU will not bypass the dropped SNs until the retransmission of the dropped RLC PDUs arrive at the terminal WTRU. Waiting for the retransmission of the dropped RLC PDUs may be time- consuming and unnecessary because these RLC PDUs may contain stalled data that should be ignored to reduce the delay. For at least this reason, the helper WTRU may send the HDSN to the terminal WTRU. In response to receiving the HDSN, the terminal WTRU may update the lower edge of its Rx window to HDSN+1. Accordingly, all RLC PDUs with SN < HDSN are out of the Rx window. Thus, in this scenario, the terminal WTRU does not require the corresponding RLC PDUs to be retransmitted.
[0133] FIG. 10 is a diagram of an RLC STATUS PDU 1000 that may be used for carrying the HDSN over the second hop in RLC AM mode. The example RLC STATUS PDU 1000 illustrated in FIG. 10 includes a data control indication (D/C) 1002 (e.g., D/C = 0), a control PDU type (CPT) 1004 (e.g., CPT = 001), H_SN field 1008 for indicating the HDSN and padding 1010.
[0134] In an RLC UM mode, the Rx window of the terminal WTRU may be updated with the highest received out-of- window SN from the received RLC PDU. This may prevent the Rx window from stalling after the helper WTRU drops RLC PDUs. Accordingly, in contrast with the AM mode, there may be no need to send the HDSN over the second hop in UM mode.
[0135] The RLC SDU reassembly process at the second hop receiver may be modified in AM mode to accommodate the change in the Rx window in the second
hop receiver. In an embodiment, the RLC in the second hop receiver may assemble the RLC SDU from RLC PDUs with SN < variable VR(R). The second hop receiver may analyze the SNs of these RLC PDUS and, if a segment from an RLC SDU is confirmed missing (e.g., the second hop receiver has not yet received the RLC SDU and the RLC SDU is outside of the current Rx window), then the second hop receiver may discard all other data segments for the same RLC SDU.
[0136] Dropping RLC PDUs on a per-logical channel basis may reduce transfer delays caused by stalled data in helper WTRU queues. In an embodiment, all RLC PDUs related to a PDCP SDU may be dropped at the moment when the PDCP discard timer expires, regardless of whether the PDU is in the eNB buffer or in the helper WTRU queue (e.g., the helper WTRU drops a buffered RLC PDU at exactly the same time that the original PDCP SDU discard timer for the PDCP SDU to which an RLC PDU belongs expires). Actual discard time may vary from this, however, due to implementation limitations.
[0137] The helper WTRU may set the discard timer period according to any of a number of different methods. For example, in the DL, the helper WTRU may not drop RLC PDUs and may not set a discard timer. The delay caused by helper WTRU buffering may be limited by minimizing the queue length. In this example, tighter flow control may be needed to maintain the queue length. For another example, a timeout value for the discard timer for each logical channel associated with a terminal WTRU may be provided at configuration or reconfiguration of the partial RLC layer. The discard timer value may be set to the same value as that of the corresponding PDCP SDU discard timer. In this example, total discard time for a segment of a PDCP SDU may be within a window from 1* discardTimer to 2*discardTimer due to two individual discard timers potentially being run in both the eNB and the helper WTRU. For another example, an RLC PDU header may carry a remaining discard timer timeout value when the eNB sends it out. In this example, the discard time for all segments of a PDCP SDU may be exactly 1* discardTimer. However, this may require an extension to the RLC header to carry the remaining discard timer
timeout value. In an embodiment, one or a combination of the examples listed above may be implemented.
[0138] In an embodiment where an RLC PDU header carries the remaining discard timer timeout value when the eNB sends it out, an extension may be added to the RLC PDU header to carry the remaining discard timer timeout value from the eNB to the helper WTRU. This may be done, for example, by adding an extension (E2) bit to the normal AMD and UMD PDUs indicating the existence of a time left (LT) field that indicates the time left in the discard timer and an optional 8-bit LT field. The optional LT field may be placed after the SN field.
[0139] FIGs. 11 and 12 are diagrams of example RLC PDUs 1100 and 1200, respectively, with an E2 bit and an optional LT field. In the embodiments illustrated in FIGs. 11 and 12, the E2 bit may take the value of 0 if no LT bit is present in the PDU after the SN field and may take the value of 1 if an LT bit is present in the PDU after the SN field.
[0140] FIG. 11 is a diagram of an example RLC PDU 1100 having a 10 bit
SN 1102. For the example RLC PDU 1100 with a 10 bit SN 1102, the E2 bit 1104 takes the third R bit in the UMD PDU after R bits 1108 and 1110.
[0141] FIG. 12 is a diagram of an example RLC PDU 1200 having a 5 bit
SN 1202. For the example RLC PDU 1200 with a 5 bit SN 1202, the E2 bit 1204 takes the first bit of the new 4 bit field including bits 1204, 1206, 1208 and 1210 after the first E bit field for an AMD PDU and a UMD PDU.
[0142] FIG. 13 is a diagram 1300 of an example procedure for RLC PDU discard at the helper WTRU. In the illustrated example, congestion occurs on the
XL at some point in time.
[0143] At 1302, a PDCP PDU/RLC SDU is segmented into RLC PDUs with
SNs of 10 (1310), 11 (1311), 12 (1312), 13 (1313), 14 (1314) and 15 (1315). RLC PDUs 1310, 1312, 1313 and 1314 arrive in the helper WTRU 1320. RLC PDU 1311 does not reach the helper WTRU 1320 successfully. PDU 1315 and later PDUs 1316 and 1317 stay in the eNB 1322. At 1304, the RLC PDU 1311 arrives
at the helper WTRU later due to HARQ retransmissions. The XL is unavailable, and the TRL stops by flow control as well. At 1306, the helper WTRU 1320 drops PDUs 1310, 1312, 1313 and 1314 because of discard timer expiry. At 1308, PDUs 1315, 1316 and 1317 are sent to the helper WTRU to fill the room in the helper WTRU buffer. The XL then resumes, and the HDSN = 14 (corresponding to dropped PDU 1314 with the highest SN) is sent to the terminal WTRU (not shown) to move the Rx window. The helper WTRU may then send the PDUs 1311, 1315, 1316 and 1317 to the terminal WTRU. The terminal WTRU may filter out the PDU 1311 because it is out of the Rx window. PDU 1315 is filtered out in the re-assembly process because it includes a data segment from an incompletely-received SDU with some segments (e.g., data in the PDUs 1310, 1311, 1312, 1313 and 1314) that were discarded.
[0144] FIGs. 14A and 14B include a diagram 1400A/1400B of an example procedure for moving the Rx window at the helper WTRU in RLC AM mode. In the illustrated example, the SN space is [0-7] and the SN window size =4. PDCP PDU/RLC SDUs are segmented into RLC PDUs. The RLC SDU boundary is shown.
[0145] At time tl, the XL is unavailable, RLC PDUs with SNs of 5 (1415), 6
(1416), 7 (1417) and 0 (1410) remain at the eNB 1402, RLC PDUs with SNs of 1 (1411), and 2 (1412), 3 (1413) and 4 (1414) are stored in a buffer at the helper WTRU 1404. At time t2, the helper WTRU drops RLC PDUs 1411, 1412 and 1413 because the discard timer expires. Later, the XL resumes. An HDSN STATUS PDU with the HDSN = 3 (corresponding to dropped RLC PDU 1413 with the highest SN) is sent to the terminal WTRU 1406. At time t3, the Rx window is moved, and the Tx window in the eNB 1402 is also moved by the ACK. At time t4, RLC PDU 1414 is sent to the terminal WTRU 1406. Since it is in sequence, the Rx window is moved again. The Tx window in the eNB 1402 is also moved by the ACK. RLC PDU 1414 is out of the Rx window. The first data segment in RLC PDU 1414 is the remaining segment of the RLC SDU with a confirmed missing element, so it is dropped. The remaining segment is kept for
later re-assembly. At time t5, more data is sent to the helper WTRU 1404 after the Tx window update. At time t6, the helper WTRU 1404 sends more data to the terminal WTRU 1406, and a valid SDU is assembled with data segmented in PDUS 1414, 1415 and 1416. Accordingly, in this example, after the XL resumes from a problem, the XL delay is recovered well by updating the Rx window with the HDSN.
[0146] FIGs. 15A and 15B include a diagram 1500A/1500B of an example procedure for moving the Rx window at the helper WTRU 1522 when the HDSN is lost. The parameters for this example are the same as for the example described with respect to FIGs. 14A and 14B. However, in this example, the status PDU that carries the HDSN is lost on the XL. Here, the Rx window is moved only when the retransmission of the dropped PDUs arrives.
[0147] At time tl, the XL is unavailable, RLC PDUs with SNs of 0 (1510), 5
(1505), 6 (1506) and 7 (1507) remain the eNB 1524, and RLC PDUs with SNs of 1 (1501), 2 (1502), 3 (1503) and 4 (1504) are stored in a buffer at the helper WTRU 1522. At time t2, the helper WTRU 1522 drops RLC PDUs 1501, 1502 and 1503 due to discard timer expiry. Later, the XL resumes. The helper WTRU 1522 sends an HDSN STATUS PDU with highest dropped SN = 3 (corresponding to dropped RLC PDU 1503 with the highest SN) to the terminal WTRU 1520, but it is lost on the XL. Accordingly, there is no update of the Rx window at the terminal WTRU 1520. At time t3, the helper WTRU 1522 sends RLC PDU 1504 to the terminal WTRU 1520. It is not in sequence, so a re-ordering timer starts. At time t4, the re-ordering timer expires, and the terminal WTRU 1520 sends a STATUS PDU with ACK_SN=1/NACK_SN=2 to the eNB 1524. Upon receiving the STATUS PDU, the eNB 1524 retransmits RLC PDUs 1501, 1502 and 1503 to the helper WTRU 1522. At time t5, the helper WTRU 1522 sends RLC PDUs 1501, 1502 and 1503 to the terminal WTRU 1520. At this point, the RLC PDUs in the terminal WTRU 1520 are in sequence, and the Rx window is updated. At time t6, the RLC SDUs are delivered.
[0148] The example described with respect to FIGs. 15A and 15B is similar to the situation where the HDSN is not sent to the RLC of the second hop receiver to move the Rx window. Accordingly, even when an HDSN is lost on the XL, the system may eventually recover if retransmission of the dropped RLC PDUs to the helper WTRU is allowed after they are dropped. However, without receiving the HDSN STATUS PDU, it may take a longer time for the data stream to recover (e.g., for re-ordering timer expiration and re-transmission request).
[0149] In addition to the partial RLC layer described above, another embodiment may include an L2 layer where none of the MAC, RLC and PDCP layers are terminated at the helper WTRU. In this embodiment, MAC TBs may be relayed between the XL and TRL without modification. In another L2 embodiment, only the MAC layer (and not the RLC or PDCP layers) may be terminated at the helper WTRU. In this embodiment, scheduling flexibility between the XL and TRL may be achieved by MAC PDU segmentation on the second hop. MAC level flow control and MAC level stalled data discard may be applied to improve performance. In another L2 embodiment, the MAC and RLC layers may be terminated at the helper WTRU. In this embodiment, the helper WTRU may relay RLC SDUs between the terminal WTRU and the eNB. In another L2 embodiment, all of the MAC, RLC and PDCP layers may be terminated at the helper WTRU. In an embodiment, one or more of the L2 embodiments described herein may be combined with the architecture described above.
[0150] With respect to flow control, flow control on the first hop in coverage extension mode applications may serve the purpose of limiting the buffer depth of the local buffer at the helper WTRU to reduce transfer delay and prevent data overflow by the helper WTRU buffer. If no flow control is applied on the first hop, there is a risk of overflow in the helper WTRU buffer in RLC UM mode because of the possible difference in instantaneous throughput on the first and second hops.
[0151] In RLC AM mode, the RLC Rx/Tx window at the terminal WTRU and eNB may perform flow control between the first and second hops. However, in some embodiments, the maximum number of RLC PDUs stored in a helper WTRU buffer may need to be smaller than the window size. An example of this may include embodiments where no discard timer is used to drop data at the helper WTRU and, therefore, the delay caused by helper WTRU buffering may be minimized by limiting the maximum number of buffered RLC PDUs at the helper WTRU.
[0152] Flow control may be applied on the MAC level that treats data from different logical channels as a whole or on an RLC level on a per-active logical channel basis. The precision of flow control may vary from a binary on/off command to more precise commands with multiple levels of control.
[0153] In embodiments where the MAC layer and a partial RLC layer are terminated at the helper WTRU, RLC level flow control may be used to achieve precise control for each active logical channel. An Xon/Xoff type of flow control may be used to reduce flow control overhead. In an Xon/Xoff embodiment, when the buffer level is higher than a preset high-water mark, an Xoff command may be sent to the transmitter to stop the incoming data. Once the buffer level is lower than a low- water mark, an Xon command may be sent to the transmitter to resume the incoming data. In an embodiment, a flow control command may be sent from the helper WTRU to the first hop transmitter to control incoming data to the helper WTRU. For the UL direction, if the helper WTRU is in control of the XUL scheduling jointly with the network, there may be no need to perform flow control on the XUL.
[0154] FIG. 16 is a diagram 1600 of an example MAC control element for carrying flow information on the TRL UL. The example MAC control element illustrated in FIG. 16 includes an R field 1602, a logical channel identity (LCID) field 1604 and an On/Off field 1606. The LCID field may be used to identify the logical channel instance of the corresponding MAC SDU or the type of corresponding MAC control element or padding for the DL-SCH, UL-SCH and
multicast channel (MCH), respectively. In the embodiment illustrated in FIG. 16, the flow control MAC control element may be identified by reusing a reserved LCID. The On/Off field 1606 may be "1" to indicate that more data may be sent (e.g., resume incoming data) or "0" to indicate that more data may not be sent (e.g., stop incoming data).
[0155] MAC status reports from the terminal WTRU may need to be relayed to the network to assist with XL scheduling. Further, additional MAC status reports from the helper WTRU related to data in the process of being relayed between the network and the terminal WTRU may need to be sent to the network. Accordingly, in an embodiment, it may be necessary to map logical channels on the XL to logical channels on the TRL.
[0156] FIG. 17 is a diagram 1700 of an example mapping between logical channels on the XL to logical channels on the TRL. In the example illustrated in FIG. 1700, TRL logical channels 1706 and 1708, which belong to logical channel group 1720, are terminated at a helper WTRU 1714 and are not mapped to any XL logical channels. TRL logical channels 1702 and 1704, which belong to logical channel group 1718, however, are not terminated at the helper WTRU 1714 and are instead mapped to XL logical channels 1710 and 1712 and terminated at the terminal WTRU 1716.
[0157] Other new MAC status reports may also be used in embodiments.
Such MAC status reports may include an XUL scheduling request (XUSR) from the terminal WTRU, an XDL scheduling request (XDSR) from the helper WTRU, a UL buffer status (TBSR) from the terminal WTRU, an XDL buffer status (XDBSR) from the helper WTRU, a cross link DL power headroom report (XDPHR) from the helper WTRU and an XUL power headroom report (XUPHR) from the terminal WTRU. In addition, regular MAC status reports from the helper WTRU, such as an SR, BSR or PHR, may be used for embodiments described herein as per baseline LTE.
[0158] When a terminal WTRU wants to send data on the XUL but does not have an XUL grant, it may need to send the XUSR to the network to ask for
the initial XUL grant. The terminal WTRU may send an XUSR to the network in a number of different ways, including, for example, a terminal WTRU that is currently in RRC idle mode that wants to initiate a transition to RRC connected mode sending an XUSR on a UCZ to alter the helper WTRU or a terminal WTRU that is currently in RRC connected mode sending an XUSR on the XUL control channel, XPUCCH. When a helper WTRU wants to send data on the XDL to the terminal WTRU, but there is no XDL grant available, the helper WTRU may need to send an XDSR to the network to ask for the initial XDL grant.
[0159] The TBSR may indicate the UL buffer status at the terminal WTRU.
This information may be used to determine the XUL scheduling, which may be done jointly by the network and the helper or terminal WTRU, as described in more detail below.
[0160] Transmission of a TBSR maybe triggered by one or more events at the terminal WTRU, which may include, for example, arrival of data with higher priority than data that is currently in the transmission buffer, periodic triggering controlled by a timer, or when padding would otherwise be used in the MAC header. A TBSR may be sent to the helper WTRU first via the XUL, and then may then be relayed to the eNB on the TRL UL. In an embodiment, the TBSR may be 6 bits.
[0161] Depending on XPUCCH design, the TBSR may be sent on the XUL to the helper WTRU either directly on the XPUCCH or by MAC control elements on the XUL shared data channel. On the TRL, a TBSR MAC control element may be used to carry the TBSR. A TBSR MAC control element may be in the same format as the BSR defined for traditional LTE MAC including a truncated BSR, short BSR, or long BSR. The TBSR MAC control element may be identified by reusing a reserved LCID.
[0162] If a MAC control element is used to carry the TBSR on the XUL shared data channel, it may be in the form of either a regular BSR MAC control element or a TBSR MAC control element. If a regular BSR MAC control element is used, the helper WTRU may convert the regular BSR MAC control element
that it receives from the XUL shared data channel to a TBSR MAC control element on the TRL UL-SCH.
[0163] FIG. 18 is a diagram 1800 showing an example conversion of a BSR
1808 on the XUL-SCH to a TBSR 1812 on the TRL UL-SCH. In the example illustrated in FIG. 18, an XL TB 1802 includes a MAC header 1806 and a BSR 1808. A TRL TB 1804 includes a MAC header 1810 and also includes a converted TBSR 1812 with other regular MAC control elements 1814.
[0164] In another embodiment, the TBSR may be carried using a TBSR
MAC control element on the XUL shared data channel. In this embodiment, the helper WTRU may send it to the eNB by putting the TBSR MAC control element on the TRL UL-SCH.
[0165] The XDBSR is the DL buffer status report for the XL at the helper
WTRU. The network may use this information to determine the XDL scheduling jointly with the helper WTRU. The XDBSR MAC control elements may be in the same format of the BSRs defined in the traditional LTE MAC. They may be, for example, in the form of a truncated BSR, short BSR, or long BSR. The new XDBSR MAC control element may be identified by reusing a reserved LCID. Transmission of an XDBSR may be trigged by a number of different events at the helper WTRU, which may include, for example, periodic triggering controlled by a timer, when padding would otherwise be used in the MAC header, the XDL queue depth being over a threshold (this may be replaced by XDL flow control), or when a helper WTRU wants to request an initial XDL grant for sending data to the terminal WTRU if the helper WTRU uses an XDBSR to send an XDSR to the network.
[0166] FIG. 19 is a diagraml900 illustrating an example transmission of a
UL TBSR in a coverage extension mode for AT applications. In the example illustrated in FIG. 19, TRL logical channels 1902, 1904, 1906 and 1908 are configured to transport data from a respective UL buffer 1914, 1916, 1918 and 1920 at the helper WTRU 1950 to a network eNB (not shown). In an embodiment, the helper WTRU 1950 may be configured to transport BSR for
these logical channels to the network eNB (not shown). The XL logical channels 1910 and 1912 may be configured to transport the TBSR of respective UL buffers 1922 and 1924 at the terminal WTRU 1960 to the helper WTRU 1950.
[0167] FIG. 20 is a diagram illustrating example transmission of a DL BSR in coverage extension mode for AT applications. In the example illustrated in FIG. 20, TRL logical channels 2002, 2004, 2006 and 2008 are configured to transport data from a network eNB (not shown) to the helper WTRU 2050. The XL logical channels 2010 and 2012 may be configured to transport the BSR of respective DL buffers 2014 and 2016 at the helper WTRU 2050 to the terminal WTRU 2060.
[0168] Both the DL and UL power headroom for XL (XDPHR and XUPHR) may be used to determine the XL scheduling jointly by the network and a helper WTRU/terminal WTRU pair. The XUPHR may be sent from the terminal WTRU and relayed to the network by the helper WTRU. The XDPHR may be sent from the helper WTRU and reported directly to the network. An XDPHR may be triggered at a helper WTRU by a number of different events, which may include, for example, periodic triggering controlled by a timer, XL path loss change exceeding a threshold, or XDL scheduling being changed by the helper WTRU or terminal WTRU. An XUPHR may be triggered at a terminal WTRU by a number of different events, which may include, for example, periodic triggering controlled by a timer, XL path loss change exceeding a threshold, or XUL scheduling being changed by a terminal WTRU or a helper WTRU. The XDPHR and XUPHR MAC control elements may be in the same format as the PHR MAC control element defined in the traditional LTE MAC. The XDPHR MAC control element and the XUPHR MAC control element may be identified by reusing a reserved LCID.
[0169] The terminal WTRU may initiate an XUL scheduling request and send it to the helper WTRU. The helper WTRU may then relay it to the eNB. Depending on the RRC mode, a terminal WTRU may use a different procedure to send the XUSR to the helper WTRU. A terminal WTRU in an RRC idle mode
may send an XUL scheduling request in a UCZ. A terminal WTRU in an RRC connected mode may send an XUL scheduling request to the helper WTRU in the form of either a TBSR or an XUSR, depending on how the control channels are designed on the XL.
[0170] FIG. 21 is a flow diagram 2100 of a method of a terminal WTRU in
RRC connected mode sending an XUL scheduling request to an eNB using a TBSR. In the example illustrated in FIG. 21, on a condition that the terminal WTRU has UL data to send (2102), the terminal WTRU may send a TBSR to the helper WTRU via an XUL control channel (2104). If the XPUCCH can carry the TBSR directly, the terminal WTRU may send the TBSR directly on the XPUCCH to the helper WTRU, and no XUSR may be needed.
[0171] If the XPUCCH does not carry the TBSR, the terminal WTRU may send the XUSR on the XPUCCH. FIG. 22 is a flow diagram 2200 of a method of a terminal WTRU in RRC connected mode sending an XUL scheduling request to an eNB using an XUSR. In the example illustrated in FIG. 22, on a condition that a terminal WTRU has UL data to send (2202), the terminal WTRU determines whether it has an XUL grant (2204). On a condition that the terminal WTRU has an XUL grant, the terminal WTRU may determine that there is no need to send an XUSR and, accordingly, may not send one (2208). On a condition that the terminal WTRU does not have an XUL grant, the terminal WTRU may send an XUSR to the helper WTRU via the XPUCCH (2206).
[0172] Sending the XUSR on the XPUCCH may save bandwidth on the
XPUCCH because the XUSR may only be one-bit of information. This bit of information may be carried in the same or a similar manner as the regular SR being carried on the PUCCH. In this embodiment, there may be no need to have a RACH procedure on the XL because the XPUCCH always exists when both the helper WTRU and the terminal WTRU are in RRC connected mode.
[0173] FIG. 23 is a flow diagram 2300 of a method of a helper WTRU relaying an XUSR to an eNB using both the TRL PUCCH and the TRL UL-SCH. In the example illustrated in FIG. 23, a terminal WTRU sends an XUSR to a
helper WTRU via the XUSR on the XPUCCH (2302). Upon receiving the XUL scheduling request, the helper WTRU may relay it to the eNB. In the illustrated embodiment, the helper WTRU may send the received XUSR to the eNB in different ways depending on the TRL UL status. On a condition that TRL PUCCH exists (2304), the helper WTRU may send an XUSR to the eNB by a new bit on the TRL PUCCH that is dedicated for the XUSR (2308). If not, on a condition that the TRL UL grant for the UL-SCH is available (2306), the helper WTRU may send the XUSR on the UL-SCH using a MAC control element (2312). On a condition that the TRL UL grant for the UL-SCH is not available (2306), the existing LTE-A RACH procedure may be used to obtain the initial UL grant on the TRL (2310) and then send the XUSR may be sent to the eNB via the UL- SCH (2312).
[0174] FIG. 24 is a flow diagram 2400 of a method of a helper WTRU relaying an XUSR to an eNB using the UL-SCH only. In the example illustrated in FIG. 24, the helper WTRU may send an XUSR to the eNB on the UL-SCH only by using a MAC control element. The terminal WTRU may send an XUSR to the helper WTRU via the XPUCCH (2402). On a condition that the TRL UL grant for UL-SCH is not available (2404), the existing LTE-A procedure for UL scheduling requests, either by PUCCH or RACH, may be used to obtain an initial UL grant on the TRL UL. (2406). The helper WTRU may then send the XUSR to the eNB via the UL-SCH (2408). On a condition that the TRL UL grant for UL- SCH is available (2404), the helper WTRU may simply send the XUSR to the eNB via the UL-SCH (2408).
[0175] If the XUSR is sent over the TRL UL-SCH, the XUSR may either be sent to the eNB with a new type of MAC control element on the UL-SCH or with a minimum TBSR over the TRL UL-SCH. The minimum TBSR may represent the size for a short TBSR MAC control element.
[0176] For an embodiment where the XUSR is sent with the new type of
MAC control element on the UL-SCH to the eNB, the XUSR MAC control element may have a length of 0 (e.g., it may not have an actual MAC control
element body). In this embodiment, only an R/R/E/LCID field with an LCID for the XUSR may be placed in the MAC header. The XUSR MAC control element may be identified by reusing a reserved LCID. The helper WTRU may send the XUL scheduling request to the eNB in a number of different ways, examples of which are described with respect to FIGs. 25, 26 and 27 below.
[0177] FIG. 25 is a flow diagram 2500 of a method of a helper WTRU relaying an XUSR to an eNB on the TRL UL-SCH using an XUSR MAC control element. In the example illustrated in FIG. 25, an extension to the TRL PDCCH may be needed for carrying the XUL grant from the eNB to the helper WTRU. A terminal WTRU 2520 may send an XUSR to a helper WTRU 2530 on the XPUCCH (2502). If the helper WTRU 2530 does not have a TRL UL grant, an LTE-A procedure may be executed to obtain such a grant (2504). The helper WTRU 2530 may then send an XUSR to the eNB (2540) using a MAC control element on the TRL UL-SCH (2506). Upon receiving the XUSR, an XUL scheduler 2508 at the eNB 2540 may assign an initial XUL grant and send it to the helper WTRU 2530 via the PDCCH on the TRL (2510). The helper WTRU 2530 may then send the XUL grant to the terminal WTRU 2520 via the XPDCCH (2512).
[0178] FIG. 26 is a flow diagram 2600 of a method of a helper WTRU 2630 relaying an XUSR to an eNB 2640 on TRL UL-SCH using a minimum TBSR MAC control element. In the example illustrated in FIG. 26, an extension to the TRL PDCCH may be needed for carrying the XUL grant from the eNB 2640 to the helper WTRU 2630. The terminal WTRU 2620 may send an XUSR to the helper WTRU 2630 (2602) on the XPUCCH. In an embodiment, if a TRL UL grant is not available, an LTE-A procedure may need to be executed to obtain such grant (2604). The helper WTRU 2630 may then send a minimum TBSR to the eNB 2640 using a MAC control element on the TRL UL-SCH (2606). Upon receiving the TBSR, an XUL scheduler 2608 at the eNB 2640 may assign an initial XUL grant and send it to the helper WTRU via the PDCCH on the TRL (2610). The helper WTRU 2630 may then send the initial XUL grant to the
terminal WTRU 2620 via the XPDCCH (2710). In this embodiment, the minimum TBSR may correspond to the size of a short BSR.
[0179] FIG. 27 is a flow diagram of a method of a helper WTRU relaying an
XUSR to an eNB on the TRL PUCCH. In the example illustrated in FIG. 27, a one-bit extension on the TRL PUCCH for carrying an XUSR from the helper WTRU 2730 to the eNB 2740 may be needed. Also, an extension to the TRL PDCCH may be needed for carrying the XUL grant from the eNB 2740 to the helper WTRU 2730. The terminal WTRU 2720 may send an XUSR to the helper WTRU 2730 on the XPUCCH (2702). The helper WTRU 2730 may use the TRL PUCCH to relay the XUSR to the eNB 2740 (2704). Upon receiving the XUSR, an XUL scheduler 2706 at the eNB 2740 may assign an initial XUL grant and send it to the helper WTRU 2730 via the TRL PDCCH (2708). The helper WTRU 2730 may send the XUL grant to the terminal WTRU 2720 via the XPDCCH (2710).
[0180] When a helper WTRU has data to send to the terminal WTRU on the XDL but there is no XDL grant, it may send an XDSR to the network asking for an XDL grant. In one embodiment, the helper WTRU may send the XDSR to the eNB in a different manner, depending on the TRL UL status at the moment. For example, if the PUCCH exists for the TRL, the helper WTRU may send an XDSR to the eNB using a new bit on the TRL PUCCH dedicated for the XDSR. If the PUCCH does not exist for the TRL, the helper WTRU may send an XDSR on the UL-SCH using a MAC control element. If the TRL UL grant for the UL-SCH is not available, the existing LTE-A RACH procedure may be used to obtain the initial UL grant on the TRL. For another example, the helper WTRU may send an XDSR to the eNB on the UL-SCH only by using a MAC control element. If the TRL UL grant for the UL-SCH is not available, the existing LTE-A procedure for UL scheduling requests, either by PUCCH or RACH, may be used to obtain the initial UL grant on the TRL UL.
[0181] If the XDSR is sent over the TRL UL-SCH, the XDSR may either be sent on the UL-SCH to the eNB with an XDSR MAC control element or on the
TRL UL-SCH to the eNB with a minimum XDBSR MAC control element. If the XDSR is sent on the UL-SCH to the eNB with an XDSR MAC control element, a new type of MAC control element may be used for the XDSR on the TRL UL- SCH. In an embodiment, the XDSR MAC control element may have a length of 0 (e.g., it does not have an actual MAC control element body). In this embodiment, only an R/R/E/LCID field with an LCID for the XDSR may be placed in the MAC header. The XDSR MAC control element may be identified by reusing a reserved LCID. Detailed procedures for how a helper WTRU may send the XDL scheduling request to an eNB with different options are described with respect to FIGs. 28 and 29 below.
[0182] FIG. 28 is a flow diagram 2800 of a method of a helper WTRU 2810 sending an XDSR to an eNB 2820 on the TRL UL-SCH using an XDSR MAC control element. In the example illustrated in FIG. 28, an extension to the TRL PDCCH may be needed for carrying the XDL scheduling information from the eNB 2820 to the helper WTRU 2810. If the helper WTRU 2810 does not have a TRL UL grant, the helper WTRU may execute an LTE-A procedure to obtain one (2802). The helper WTRU 2804 may send an XDSR to the eNB 2820 using a MAC control element on the TRL UL-SCH (2810). Upon receiving the XDSR, an XDL scheduler 2806 at the eNB 2820 may assign an initial XDL grant and send it to the helper WTRU 2810 via the PDCCH on the TRL (2808).
[0183] FIG. 29 is a flow diagram 2900 of a method of a helper WTRU 2910 sending an XDSR to an eNB 2920 on the TRL PUCCH. In the example illustrated in FIG. 29, a one-bit extension to the TRL PUCCH may be needed for carrying the XDSR from the helper WTRU 2910 to the eNB 2920. Also, an extension to the TRL PDCCH may be needed for carrying the XDL scheduling information from the eNB 2920 to the helper WTRU 2910. The helper WTRU 2910 may use the TRL PUCCH to send an XDSR to the eNB 2920 (2902). Upon receiving the XDSR, an XDL scheduler 2904 at the eNB 2920 may assign an initial XDL grant and send it to the helper WTRU 2910 via the TRL PDCCH (2906).
[0184] In an embodiment, a terminal WTRU may first send the TBSR to the helper WTRU on the XUL, and then helper WTRU may relay it to the eNB on the TRL UL. The TBSR may be sent over the XL using any number of different methods, which may include, for example, sending the TBSR on the XUL by the XPUCCH and sending the TBSR on the XUL shared data channel by a regular BSR or a TBSR MAC control element.
[0185] If the terminal WTRU sends the TBSR using a regular BSR or
TBSR MAC control element on the XUL shared data channel, it may need an XUL grant to send the TBSR to the helper WTRU. In an embodiment, the XUL grant may be available from the ongoing XUL transmissions. If there is no XUL grant, the terminal WTRU may use the XUL scheduling request procedure described above to request the XUL grant.
[0186] After receiving the TBSR from the terminal WTRU, the helper
WTRU may send it to eNB by a MAC control element on the TRL UL-SCH once it has the TRL UL grant, which it may need if there will be ongoing UL data transmission from the helper WTRU to the eNB. If a TRL UL grant is not available, the helper WTRU may use the existing LTE-A procedure for UL scheduling requests, either by PUCCH or RACH, to request the initial TRL UL grant from the eNB.
[0187] FIG. 30 is a signal diagram 3000 of a method for sending a TBSR to an eNB 3070 when a TRL UL grant is available. In the example illustrated in FIG. 30, a terminal WTRU 3050 sends the TBSR(s) to a helper WTRU 3060 using either a regular BSR MAC control element or a TBSR MAC control element on the XUL data channel or using the XPUCCH (3002). If the helper WTRU 3060 does not have a TRL UL grant, it may need to initiate an LTE-A procedure to obtain one (3004). The helper WTRU 3060 may put the TBSR into a TBSR MAC control element (3006) or the BSR into a BSR MAC control element (3008) and sent it to the eNB 3070. Upon receiving the TBSR/BSR, an XUL scheduler 3010 at the eNB 3070 may assign an XUL grant and sent it to the helper WTRU 3060 via the TRL PDCCH (3012). A TRL UL scheduler (3010) at the eNB 3070 may
assign a TRL UL grant and send it to the helper WTRU 3060 via the TRL PDCCH as well (3014). The helper WTRU 3060 may send the XUL grant to the terminal WTRU 3050 via the XPDDCH (3016). The terminal WTRU 3050 may then send data with newer TBSRs on the XUL shared channel to the helper WTRU 3060 (3018), which may relay the data to the eNB 3070 (3020).
[0188] The XDBSR may be measured by the helper WTRU. The report procedure for XDBSR may be similar to the one used for the helper WTRU to report regular BSRs by using a MAC control element on the TRL UL-SCH. A new type of MAC control element may be used for the XDBSR. It may have the same formats as the BSR and may be identified by reusing a reserved LCID field.
[0189] FIG. 31 is a signal diagram 3100 of a method of reporting an
XDBSR. In the example illustrated in FIG. 31, an extension to the TRL PDCCH may be needed for carrying the XDL scheduling information from an eNB 3120 to a helper WTRU 3110. If the helper WTRU 3110 does not have a TRL UL grant, the helper WTRU 3110 may need to initiate an LTE-A procedure to obtain one (3102). The helper WTRU 3110 may send an XDBSR to the eNB 3120 using a MAC control element on the TRL UL-SCH (3104). Upon receiving the TBSR, an XDL scheduler 3106 at the eNB 3120 may assign the XDL grant and send it to the helper WTRU 3110 via the PDCCH on the TRL (3108).
[0190] New types of MAC control elements for XDPHR and XUPHR may be needed to send an XDPHR and an XUPHR to the eNB on the TRL-SCH. The same MAC control element for XUPHR may be used on the XUL shared data channel to carry an XUPHR to the helper WTRU.
[0191] FIG. 32 is a signal diagram 3200 of a method of sending an XDPHR and an XUPHR to an eNB 3240 on the TRL UL-SCH. A terminal WTRU 3220 may send an XUPHR to a helper WTRU 3230 using a MAC control element on the XUL shared data channel (3202). If the helper WTRU 3230 does not have a TRL UL grant, it may need to obtain one using an LTE-A procedure (3204). The helper WTRU 3230 may relay the XUPHR MAC control element (3206) and/or the XDPHR MAC control element (3208) to the eNB 3240 on the TRL UL-SCH.
The helper WTRU 3230 may also send the PHR to the eNB 3240 on the UL-SCH (3210).
[0192] LCIDs used on the TRL UL-SCH and the XUL shared data channel may share the same definition, even though they may not always be present on these two channels. Table 1 includes a listing of LCID values that are normally used as well as LCID values that may be used for the different embodiments described herein. However, other LCID values and ordering may also be possible.
Table 1
[0193] With respect to XL resource grants and scheduling, the XL may share the frequency band applied on the TRDL/TRUL (in-band configuration) or adopt a different frequency band that is well- separated from the TRDL/TRUL
(out-of-band configuration). The out-of-band configuration may be less subject to in-device and in-air interference between the XLs and TRLs, since an out-of-band configuration normally applies adequate frequency spectrum isolation between the XL and the TRL and, as a result, a device may operate two radio chains, each with its own baseband processing and independent FFT. While in-device interference may be primarily handled with the physical radio design of a device, in-air interference may need to be coordinated with an XL resource grant and scheduling scheme partially performed by the network and partially performed by the WTRUs.
[0194] FIG. 33A is a diagram 3300 of a system of helper WTRUs 360 and terminal WTRUs 370 within a cell operated by an eNB 3350. Each of the helper WTRUs 360a, 360b, 360c, 360d, 360e and 360f is in direct communication with the eNB 3350 via a respective TRL UL/DL pair 3310a, 3310b, 3310d, 3310f, 3310h or 3310i. Each of the terminal WTRUs 370a, 370b, 370d and 370e is in communication with one or more helper WTRUs 360a, 360b, 360c, 360d, 360e and 360f via one or more XL UL/DL pair 3320a, 3320b, 3320c, 3320d, 3320e, 3320f or 3320g. Some of the terminal WTRUs (e.g., the terminal WTRUs 370b, 370d and 370e) may also be in direct communication with the eNB 3350 via a respective TRL UL/DL pair 3310c, 3310e or 3310g.
[0195] In the example system illustrated in FIG. 33A, the XLs all potentially interfere with each other. In an embodiment, different multiple access schemes may be applied on the XL to attempt to mitigate the interference. However, all XLs in the same cell may share a fixed pool of time, frequency, code and power resources, and the network may need new metrics and algorithms to efficiently allocate XL resources.
[0196] In order to support high mobility in an LTE system and deal with a resulting short channel coherence time, the network may perform scheduling dynamically per TTI on the TRL. However, applying a similarly dynamic grant and scheduling scheme on the XL may require the network to have access to dynamic XDL and XUL channel state information. The resultant signaling may
be significant, especially in an AT-R coverage mode where a helper WTRU may need to relay all terminal WTRU feedback information to the network. In addition, centralized dynamic grant and scheduling may cause an increase in the HARQ time line because a helper WTRU may need time to decode and forward the grant and scheduling information to a terminal WTRU.
[0197] Further, TRL grant and scheduling does not specify a power level to be used for the scheduled DL or UL transmission. For TRL grant and scheduling, the eNB always transmits the DL data channel with full power (i.e., the downlink power is centralized), while the UL transmission may be regulated by the UL power control based on the grant information, such as the assigned modulation and coding scheme (MCS) and physical resource blocks (PRBs) (i.e., the UL power control mechanism is distributed). For the XL, however, an explicit power allocation may be desirable as one type of resource allocation because the XL transmit power setting of the WTRUs in AT applications may constitute a distribution of a shared resource in the sense that all XLs in a geographical region may be restricted to certain power levels to mitigate mutual interference.
[0198] AT-R coverage mode may pose additional challenges because a helper WTRU may use new procedures to forward the network grant to a terminal WTRU and to relay terminal WTRU measurements to the network as an input to the grant algorithm.
[0199] Accordingly, as described briefly above, embodiments are described herein for two-tier scheduling in the XL, with the first tier being a centralized and semi-static XLG issued by a network and the second tier being a distributed and dynamic XLS that may be performed by the WTRUs themselves. These embodiments may be applicable for both AT-R and AT-LO applications, although some embodiments are described with respect to AT-R for ease of explanation.
[0200] FIG. 33B is a flow diagram 3355 of an example method of radio resource scheduling on a radio XL between a WTRU and another WTRU. In the example illustrated in FIG. 33B, the WTTU receives an XLG specifying resources
for use by at least the WTRU for transmission on the radio XL (3360). The WTRU may perform XL scheduling per TTI within the resources specified in the XLG (3362). The WTRU may transmit at least one packet to the other WTRU based on the XL scheduling per TTI (3364).
[0201] In an embodiment, network-controlled XLG may be a channel dependent grant scheme using orthogonal multiple access. Such a channel dependent grant scheme may eliminate intra-cell XL interference while allowing each XL to achieve optimal performance according to its channel conditions. However, in some embodiments, a network may not have adequate resources to support orthogonal multiple access when the number of supported XLs per cell are excessive, and dynamic channel-dependent scheduling per TTI may not be practical because of significantly increased signaling overhead and resulting increase in latency. For example, dynamic per TTI scheduling per XL may pose high demand for PDCCH/PUCCH capacity.
[0202] In an embodiment, the dynamic per-TTI scheduling may be conducted based on the resources specified in the XLG and at least one of an XL ACK/NACK message or a channel quality indicator (CQI), without network involvement. Such an embodiment may be desirable because separate HARQ design in some AT applications for TRL and XL may prevent ACK/NACK transmissions from being forwarded to the network.
[0203] The first tier of two-tier scheduling may be referred to as XLG, and the second tier may be referred to as XLS. With respect to the XLG, the network may issue a centralized and semi- static scheduling decision to allocate the resource of an XL in terms of maximum allowed power and physical channel time/frequency/code configuration based on both short-term and long-term measurements. Such short-term and long-term measurements may include, for example, XL feedback measurements, XL signal and interference measurements and XL power headroom reporting. The XLG may not take into consideration the instantaneous channel condition. Each grant may be associated with an explicitly signaled validity period. With respect to XLS, the WTRUs in the
network may perform distributed and dynamic scheduling decisions within the resources allocated by the XLG and determine the transmission configuration on a per-TTI basis. The determined transmission configuration on a per-TTI basis may include, for example, determining the MCS and transmission bandwidth in accordance with the short-term XL channel condition feedback measurements as a result of link adaptation and traffic variation handling. The scheduling decision may be factored into the XL power control to calculate the transmit power.
[0204] The sub-carrier resources assigned in an XLG may be applied unchanged during an XLG validity period. In other words, there may be no dynamic frequency scheduling within each XLG validity period. The WTRUs may use the same granted sub-carriers (e.g., a sub-carrier group or a sub-band in each TTI) but may apply different power and MCS for link adaptation. Alternatively, XL scheduling may explore the frequency selectivity within a granted bandwidth by adjusting sub-carrier resource assignment based on certain SINR feedback specific to each assignable sub-carrier group or sub-band.
[0205] While, in an embodiment, an XLG may not carry any MCS information, it may specify a maximum allowed XL transmit power for WTRUs in the AT application. This may act as a form of slow power control directed by the network to manage interference between XLs and enable efficient power utilization. For example, when two XLs in proximity share identical code, frequency, and time resources, the maximum allowed power (the XLG power) may be set so as to reduce inter-XL interference and optimize the performance of both XLs. However, when orthogonal resource allocation is applied between XLs, the XLG power may be set so as to deliver the maximum MCS on the XL as long as it does not exceed the maximum transmit power that the WTRUs may apply according to device capability.
[0206] When a large XL BW is assigned in a network, each XL within a cell may first be assigned into a frequency reuse group, in which each assigned XL may be granted with a dedicated portion of the XL BW.
[0207] Fig. 34 is a diagram 3400 of a cell 3440 where the XLs in the cell are arranged into frequency reuse groups. In the example illustrated in FIG. 34, the XLs in the cell 3440 operated by the eNB 3450 are arranged into four frequency reuse groups 3460, 3470, 3480 and 3490. The frequency reuse group 3460 includes XLs 3402, 3404, 3406, 3408, 3410, 3412 and 3414. The frequency reuse group 3470 includes XLs 3416, 3418, 3420, 3422, 3424, 3426 and 3428. The frequency reuse group 3480 includes XLs 3430, 3432, 3434, 3436, 3438, 3440 and 3442. The frequency reuse group 3490 does not have any XLs specifically assigned to it. One of ordinary skill in the art will recognize, however, that the XLs in a cell may be organized into any number of frequency reuse groups which may include any number of XLs per group.
[0208] In an embodiment, an XLG may specify code allocations for physical channels and reference signals for applying CDMA in addition to FDMA. For example, two XL specific reference signals may co-exist in the same frequency resource location using two ZC-based sequences. The sequences may be derived from the same base sequence with different cyclic shifts in order to provide orthogonality.
[0209] The network may also apply TDMA when the XL employs a TDD duplex scheme. For example, two XLs assigned with identical frequency and code resource allocations may be configured with a different TDD XDL/XUL configuration so that the transmission times of the XDL1 and XUL2 coincide. Because the helper WTRU and terminal WTRU transmissions may have different code configurations, XDL1 and XUL2 may not interfere with each other.
[0210] Helper and terminal WTRU XLGs for AT-R applications may include one or more of many different types of information. For example, a helper WTRU XLG may grant a helper WTRU permission, restricted by the validity period, to transmit in the XDL to a terminal WTRU according to the accompanied configuration of the transmission. A terminal WTRU XLG may grant permission for a terminal WTRU to transmit in the XDL to a helper WTRU in a similar fashion.
[0211] Specific examples of information that may be included in helper
WTRU XLGs may include a duration of the validity period (e.g., in number of TTIs), a maximum allowed helper WTRU transmit power on the XL, a target nominal power at the terminal WTRU applied in XLPC (e.g., in dBm), an XDL/XUL duplex configuration (e.g., for TDD), an XDL assignment index (e.g., for TDD), a sub-carrier resource allocation (e.g., in sub-bands) for all XDL dedicated channels (the multiplexing between these channels within the assigned frequency resource may be pre-defined), and XDL specific reference signal code configurations (e.g., spreading factor/spreading code assignment, or base sequence/cyclic shift). Other examples of information for helper WTRU XLGs may include XPDFBCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), XPDCCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPDCCH resource configuration (e.g., spreading factor or channel code assignment), an XPGCH resource configuration (e.g., spreading factor or channel code assignment), XPDDCH demodulation reference code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPDDCH frequency hopping indicator and an XUL CQI and signal measurement request and configuration.
[0212] Specific examples of information that may be included in terminal
WTRU XLGs may include, for example, a duration of the validity period (e.g., in number of TTIs), an allowed terminal WTRU maximum transmit power on the XL (e.g., in dBm), a target nominal power at the helper WTRU applied in XLPC (e.g., in dBm), an XDL/XUL duplex configuration (e.g., for TDD), an XUL assignment index (e.g., for TDD), a sub-carrier resource allocation (e.g., in sub- bands) for all XUL dedicated channels (the multiplexing between these channels within the assigned frequency resource may be pre-defined), and XUL specific reference signal code configurations (e.g., spreading factor/spreading code assignment, or base sequence/cyclic shift). Other examples of information for
terminal WTRU XLGs may include XPUFBCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), XPUCCH specific reference signal code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPUDCH resource configuration (e.g., spreading factor or channel code assignment), XPUDCH demodulation reference code configurations (e.g., spreading factor/spreading code assignment or base sequence/cyclic shift), an XPUDCH frequency hopping indicator or an XDL CQI and signal measurement request and configuration.
[0213] A helper WTRU or a terminal WTRU may need to receive both a helper WTRU XLG and terminal WTRU XLG to operate an XLG. Additionally, certain XLG information may be carried separately from other XLG information. For example, the validity period may be informed in dedicated RRC signaling in a similar manner as an SPS-Config information element.
[0214] In an embodiment, a number of information fields may overlap between the helper WTRU XLG and the terminal WTRU XLG. Alternatively, one consolidated XLG may be applied and transmitted to both the helper WTRU and the terminal WTRU.
[0215] An XLG may be considered to be an adapted type of Semi-Persistent
Scheduling (SPS), which is used in LTE systems, particularly for low-rate service such as voice-over IP. In LTE, the PDCCH control signaling overhead is motivated and justified because it is still relatively small compared to the payload carried on the PDSCH/PUSCH. However, for some services with small payloads, such as voice over IP, control signaling overhead may be reduced with SPS.
[0216] In AT applications (e.g., AT-R coverage mode), control signaling reduction may be a primary motivation to having an SPS-type of scheduling. Although AT applications are not limited to low-rate service, the second level of scheduling, which is dynamic and channel- dependent, may provide fairly adequate handling of large variations in the amount of data traffic with the help
of changing power level, MCS and/or sub-carrier assignment per TTI. After receiving an XLG, a WTRU may perform XL scheduling per TTI within the resources specified in the grant. If a WTRU cannot adjust the granted transmission bandwidth, it may adjust the MCS and calculate the power level per TTI to perform link adaptation accordingly. Table 2 provides a listing of characteristics of SPS-type scheduling versus XLG scheduling.
Table 2
activation and release (no SPS PDCCH carrying XLG dedicated DCI format) information
- Dedicated RRC signalling IE - New MAC control element SPS-Config including SPS - Dedicated RRC signaling interval, SPS ULPC nominal
power value, etc. - XPGCH
- XPDSACH
Validity period - Sub-frame based on SPS - Sub-frame based on XLG interval signaled in IE SPS- validity period signaled in Config options listed above
- Valid in TRDL sub-frames: - May not be periodic (10 * SFN + subframe) = [(10 *
SFNstart time + subframestart
time) + N *
semiPersistSchedlntervalDL]
modulo 10240, for all N>0
- Valid in TRUL sub-frames:
(10 * SFN + subframe) = [(10 *
SFNstart time + subframestart
time) + N *
semiPersistSchedlntervalUL +
Subframe_Offset * (N modulo 2)]
modulo 10240, for all N>0
- Implicit release according to
parameter implicitReleaseAfter
in IE SPS-Config (TRUL only)
- Strictly periodic
Interference - No intra-cell interference - No inter-XL interference in Management - Inter-cell interference one frequency reuse group coordinated with semi- static - Inter-XL interference inter-cell interference between frequency reuse coordination (ICIC) including groups coordinated with RNTP (TRDL), HII (TRUL) and XLG power adjustment OL (TRUL) or FFR (one-cell - XLG is used as a form of frequency reuse > 1) interference management.
- SPS is not used as a form of
interference management
Retransmission - Applicable for only initial Applicable for all
transmission in TRDL transmissions and
- TRDL retransmission explicitly retransmissions on XDL and scheduled XUL
- Can be applicable for TRUL
retransmission
Precedence Can be overridden if explicit Can be overridden if explicit dynamic scheduling is detected grant is detected in PDCCH in PDCCH
[0217] A network may derive the XLG based on any number of different inputs. Some inputs may be given more weight for the initial XLG derivation while others may be used for update XLG derivations. Examples of such inputs may include requested spectral efficiency based on QoS, estimated XL signal-to- noise ratio (SINR), buffer status, resource allocation history, XL feedback measurement, XL power headroom, and received signal measurement in the assigned sub-carrier groups.
[0218] With respect to requested spectral efficiency based on QoS, the network may use QoS to determine an approximate target rate for the XL and the required SINR. This may be used, for example, in admission control when a WTRU requests and establishes its services to evaluate the target power applied in the XLPC.
[0219] With respect to estimated XL SINR, the network may estimate an
XL SINR based on the grant and measurements reported on the XL and compare it with the requested SINR calculated based on the QoS to determine an initial XLG. One example of an estimate of the resulting SINR based on grant and measurements may be based on:
PL * -f- N *S¾ *=¾ * NF}
where N is the number of assigned sub-carrier groups, BWsub is the bandwidth of each sub-carrier group, IoT is the total received interference power of assigned sub-carrier groups, PL is the path loss between the helper WTRU and the terminal WTRU of the XL, N0 is thermal power density and NF is a WTRU noise figure.
[0220] With respect to buffer status, the DL buffer status may be readily available at the eNB, and the UL buffer status may be reported by a WTRU either periodically or when triggered by pre-defined events. The buffer status
may be applied in the grant algorithm to handle traffic variation. With respect to resource allocation history, previously issued XLGs may be factored in.
[0221] With respect to XL feedback measurement (XLFB), an LTE network scheduler may take channel state information (CSI) into consideration when performing rate prediction for dynamic scheduling. A similar approach may be adopted for an AT-R capacity mode and an AT-LO application where both WTRUs may report per-TTI CSI in the TRUL either per request or according to the grant configuration. However, in an AT-R coverage mode, due to the lack of direct links between the terminal WTRU and the eNB, terminal WTRU CSI information may not be applied directly on a per-TTI basis.
[0222] Per-TTI short-term XL CSI feedback may be, for example, multiplied with the PUSCH when a UL grant is available, transmitted in the PUCCH scheduled for the WTRU to carry TRDL CSI, or transmitted in the PUCCH schedule dedicated for the XL. With respect to multiplexing the per-TTI short-term XL CSI feedback with the PUSCH, an identifier (e.g., a one-bit field) may be added in order for the eNB to distinguish whether the multiplexed CSI information is specific for the TRDL or XL. With respect to transmitting the per- TTI short-term XL CSI feedback in the PUCCH scheduled for the WTRU to carry TRDL CSI, an identifier, such as a flag bit, may also be considered to indicate that the PUCCH is carrying XL CSI. The XL CSI, such as CQI or PMI, may reuse the existing PUCCH format. With respect to transmitting the per-TTI short-term XL CSI feedback in the PUCCH schedule dedicated for the XL, the scheduling of the PUCCH may be implicitly or explicitly signaled in the PDCCH DCI format carrying the XLG.
[0223] In another embodiment, long-term achieved rate and channel statistics based on per-TTI CSI may be used. Such statistics may include, for example, average throughput measurements or average XL CQI-equivalent measurements with their standard deviation during the XLG validity period. The averaging and statistical analysis may be performed by the physical layer according to the configuration conveyed in the dedicated RRC signaling.
[0224] Since the long-term XL CSI feedback may not have a large payload, it may be transmitted similarly to the per-TTI short-term feedback. In addition, because the long-term feedback may not have a high latency requirement, it may also be carried in MAC PDU on the PUSCH when a UL grant is available. Long- term XL CSI feedback reporting may be requested by the eNB with a UL grant for the data transmission.
[0225] Overall, short-term or long-term XL feedback may provide the network with channel condition information to help evaluate how well the allocated XL resources are utilized.
[0226] With respect to XL power headroom (XLPH), an LTE network may evaluate the UL scheduling decision in order to determine efficient combinations of MCS and bandwidth in the grant with the help of PUSCH power headroom reporting. The power headroom may be a measure of difference between the maximum WTRU transmit power and the power-controlled data channel transmit power that would be used assuming there is no limit of the WTRU transmit power. The transmit power may be calculated per TTI by a WTRU using the granted MCS, the granted bandwidth, the granted path loss and the received TPC command. Similar to XLFB, a current LTE network approach may be used, and both per-TTI short-term and long-term power headroom reporting may be also considered. For example, in each XLG validity period, an average power headroom value and its standard deviation may be reported to the network to determine what power level is required to transmit the target rate over the granted bandwidth given the channel conditions. The per TTI short-term power headroom may be calculated as follows based on the granted maximum transmit power level) and not the WTRU maximum transmit power as used in LTE UL power headroom):
where PXLG is the granted XL power, BWTX is the transmission bandwidth (which may be the same as BWXLG (i.e., the granted bandwidth)), PNominai is the desired power level at the helper WTRU or the terminal WTRU, PL is the path loss
between the helper WTRU and the terminal WTRU, ATF is the pre-defined function of the pre-defined transport format of the XPDDCH and TPC is the predefined function of received TPC bits.
[0227] In the above example, the sum of the items within parenthesis is the transmit power in subframe i. Further, in addition to the XLPH, there may be another PHR taking into account both TRL and XL transmission, which may require a new procedure in the network. The power headroom discussed herein may be limited to the power headroom of the XL.
[0228] During the XLG validity period, the network, for example, may configure a number of sub-frames for per-TTI short-term power headroom calculation, and the WTRU may perform averaging or other types of statistical analysis to obtain the long-term power headroom. Both the per-TTI short-term and long-term PHR may be transmitted, for example, in one of a new MAC control element dedicated for the XL PHR or the existing MAC control element for PHR with modification to accommodate the cross link PHR (e.g., the extended power headroom MAC control element).
[0229] XL PHR may be requested or triggered by a pre-defined set of events. For example, the XL short-term and/or long-term PHR may be reported, for example, when there is a significant change in the XL path loss, a pre-defined number of unidirectional TPC commands are applied or the per-TTI short-term power headroom values over a pre-defined number of sub-frames generate a long- term power headroom exceeding a pre-defined threshold.
[0230] With respect to received signal measurements in the assigned sub- carrier groups, the signal level may be used to evaluate the achieved XL SINR and also to derive the PNominai used in the XL power control. The interference calculation may be based on a wide band analogue energy measurement and a code power measurement on all detected XL specific reference signals. The XL specific reference signal may be presumed to be transmitted continuously with the granted power without change. Thus, the two measurements combined may provide the SINR of the XL and identify the major interfering XLs. In the rare
case where two helper WTRUs are assigned the same specific reference signal, neither terminal WTRU will be able to distinguish these two reference signals and, as a result, the terminal WTRUs may see a good SINR of the reference signals but suffer deteriorated XPDCCH/XPDDCH block error rate (BLER) performance. The XL signal measurement may also be reported to the network in the form of a bit map to reduce signaling overhead. The signal measurement may require averaging and filtering over a pre-configured period, and the transmission may apply PUSCH in the form of a MAC PDU.
[0231] When the related XL feedback, power headroom and measurement reporting are carried in the PUSCH, the network may be required to assign the PUSCH grant associated with the measurement request and/or configuration.
[0232] When applying SPS in the LTE UL, a WTRU may transmit according to the same UL grant until the SPS is deactivated. With frequency assignment and MCS fixed, the transmit power may be regulated only with the TPC commands. As one option, the XLG may also fix the bandwidth and other transmission configurations with the exception of the MCS. WTRUs engaging in the AT-R and AT-LO applications may adjust the MCS based on the channel condition, traffic variation and ACK/NACK reception. The MCS may be further applied in calculating the XL transmit power. This may be regarded as a limited degree of WTRU autonomy designated to the WTRUs related to the link adaptation for the benefit of significantly reduced signaling overhead. The network may still arguably assert near-full control over the XL transmissions and, therefore, the proposed XLG may be regarded as a functionality that retains network control.
[0233] The XLG procedures described below may outline the sequence of events applicable for WTRUs to acquire initial XLGs, receive updated XLGs and perform and report the measurements for network XLG determination. The procedures may vary between different AT applications and are discussed separately.
[0234] An initial XLG may be triggered by an event listed in the AT-R application, such as a terminal WTRU transmission of XSR/BSR or a network paging a terminal WTRU in RRC IDLE mode for a mobile terminated connection. The terminal WTRU transmission of the XSR/BSR event may exist in a number of procedures, including, for example, a mobile originated connection from the terminal WTRU, helper WTRU/terminal WTRU association, or terminal WTRU handover from an active helper WTRU to a back-up helper WTRU. A network paging a terminal WTRU in RRC IDLE mode for a mobile terminated connection event may be specific to the AT-R coverage mode. When the network pages a terminal WTRU in RRC IDLE mode in the coverage mode, the helper WTRU may forward the paging message to the terminal WTRU by alerting the terminal WTRU in the XPDACH about the upcoming paging and prompting the terminal WTRU to read the XLG in the XPDSACH or XPGCH. In other words, the helper WTRU may send a paging indicator along with XLGs, which the terminal WTRU may use to read the paging message in the XPDDCH.
[0235] In an AT-LO application, an initial XLG may be issued in connection with a local-offload WTRU-to-WTRU call establishment procedure. An initial XLG acquisition may follow a neighbor discovery procedure in which a neighbor seeking WTRU may find neighbor candidates among a number of neighbor present WTRUs that are in proximity. In the case of an AT-R application, one of the neighbor present WTRUs may be configured as a helper WTRU.
[0236] On the TRDL, an initial and update XLGs may be, for example, transmitted from the network in one of a new device class identifier (DCI) format carried in the PDCCH, a new MAC control element carried in the PDSCH, a new MAC control element carried in the PDSCH or dedicated RRC signaling in the PDSCH. With respect to the new DCI format carried in the PDCCH, to reduce the impact on DPCCH blind decoding effort, an existing DCI format may be reused. Decoding options may include, for example, using the cell radio network temporary identifier (C-RNTI) to decode the PDCCH in the WTRU-specific search space and using a new XL specific RNTI (e.g., AT-RNTI or XL-RNTI) designated
to a WTRU when the WTRU engages in an AT applications. With respect to using the C-RNTI to decode the PDCCH in the WTRU-specific search space, in an AT-R application, for example, a helper WTRU and a terminal WTRU may receive the helper WTRU XLG and the terminal WTRU XLG, respectively, using its own C-RNTI. With respect to using a new XL specific RNTI, the AT-RNTI may be per XL. The PDCCH transmission may be robust, and, therefore, the XLG may be received with high reliability. However, this option may require more network PDCCH capacity and may increase the WTRU PDCCH decoding effort. With respect to the new MAC control element carried in the PDSCH, the semi- static nature of the XLG may not impose a high requirement on the transmission latency, and the PDSCH may be used for XLG transmission. However, the PDSCH may be subject to higher BLER, and the current MAC control element does not have acknowledgement. With respect to the dedicated RRC signaling in the PDSCH, a new information element (IE) may be used, and an RLC acknowledgement may provide the network with the status as to whether the XLG has been received correctly.
[0237] On the XL in an AT-R coverage mode, initial and update XLGs may be transmitted from the helper WTRU to the terminal WTRU, for example, in one of the XPDDCH, the XPDSACH, the XPGCH or a new MAC control element carried in the XPDDCH. With respect to the XPDCCH, the XLG may be multiplexed with other control information on the XL. With respect to the XPDSACH, since the physical channel may be unscheduled, the XLG transmission may cause more interference in the system. With respect to the XPGCH, the dedicated physical channel for the XLG transmission may provide a higher reliability at the expense of increased system signaling overhead.
[0238] Both physical control and data XLG transmissions may experience errors, and, therefore, the XLGs may get lost. To ensure reliable XLG transmission, a WTRU may administer an XLG safeguard mechanism to notify the network about XLG transmission failure and prompt retransmission. For example, when a WTRU does not receive an update XLG before an on- going XLG
expires, the WTRU may suspend the XL communication in order to not create uncoordinated interference. However, the network may not have the knowledge that the WTRU is missing an XLG, particularly for an XLG transmission in the form of a MAC control element. In this case, the WTRU may apply a new physical layer type of feedback to indicate the failure of receiving an XLG. The feedback may be a one-bit acknowledgement transmitted in the PUCCH. When an update XLG is received, the WTRU may send a positive acknowledgement (ACK) and also set a timer to a pre-configured value in terms of sub-frames (which may be derived from the received XLG validity period). If no update XLG is received when the timer expires, the WTRU may send a negative acknowledgement (NACK) to trigger an XLG retransmission from the network.
[0239] This XLG retransmission mechanism may not be applied for initial
XLG transmissions. If the initial XLG transmission fails, the WTRU may retransmit the SR/BSR according to the pre-defined protocol. The eNB may, thus, infer from the SR/BSR retransmission that the previous XLG was not properly received by the WTRU and, accordingly, retransmit the XLGs.
[0240] FIGs. 35A and 35B include a signal diagram 3500A/3500B of an example initial grant acquisition procedure and update XLG operation in a capacity mode. In the example illustrated in FIGs. 35A and 35B, a neighbor seeking WTRU 3502, a neighbor present WTRU 3504 and an eNB 3506 may engage in a neighbor discovery procedure. Once the neighbor discovery procedure is completed, one neighbor present WTRU may be selected as a candidate helper WTRU 3510 (3512) for a terminal WTRU 3508. Both the terminal WTRU 3508 and the helper WTRU 3510 are in RRC CONNECTED mode 3514/3516.
[0241] When both the helper WTRU 3510 and the terminal WTRU 3508 receive an association message from the eNB 3506 (3517/3518), the helper WTRU 3510 and the terminal WTRU 3508 may perform XL measurements with a cell specific XL configuration (3519/3520). Such XL measurements may include measuring the XL BW assigned to this cell broadcast by the network (the
granularity of assignable XL resources may be pre-defined (e.g., sub-carrier group or sub-band configuration)) and measuring the XL specific reference signal code group or base sequence group broadcast by the network. The XL measurements may be made on the XUL and XDL by the helper WTRU 3510 and the terminal WTRU 3508, respectively. Each pair of XDL/XUL may be characterized, for example, with a sub-carrier group assigned and/or a unique sequence of code assigned for the XL specific reference signal.
[0242] When the XL applies a TDD scheme, the same sub-carrier group may be assigned to both the XDL and XUL of one XL. With an FDD scheme, the sub-carrier groups assigned to the XDL and XUL of one XL may be separated by the duplex distance. In both duplex cases, the same sequence or code may be used for both the XDL and XUL. A detected XL specific reference signal at one assigned sub-carrier group may indicate an existing XL, and the network may attempt to avoid issuing an XLG using the same combination of sub-carrier group and reference signal.
[0243] For example, if the XDL may be divided into X sub-bands and Y assignable sequences or codes, then to provide the network with a thorough picture of resource utilization, a terminal WTRU may need to detail how many sequence codes are detected in each sub-band. If the sequence implementation is ZC based and is generated from cyclic shifts of a common root sequence, the commonly used frequency- domain computation of the power delay profile (PDP) of the root sequence may provide, with a single operation, the concatenated PDPs of all signatures derived from the same root sequence. This may reduce the number of measurements per sub-band. The XDL measurement result may be used to construct a bit map of size X times Y bits with each bit indicating whether or not the sequence or code is detected in the sub-band. In other words, the bit map may show what code and frequency resources are occupied by other XDLs near the measuring terminal WTRU. The bit map format may reduce the signaling overhead required by the XLG.
[0244] Because the helper WTRU and the terminal WTRU in an AT-R capacity mode both have TRUL connections, the XL measurement report may be sent on the PUSCH to the eNB as input to the XLG derivation (3522/3524). The terminal WTRU may also transmit an XL SR via the PUCCH or an XL BSR via the PUSCH. The network may, for example, evaluate what code and sub-band is available for the reporting helper WTRU/terminal WTRU and make an assignment accordingly. The initial helper WTRU/terminal WTRU XLGs may be sent, for example, on the PDSCH in the form of a MAC control element (3526/3528). The potential problem with data channel transmission of the XLG in general may be the relatively higher error rate compared to the control channel. The HARQ re-transmissions may also fail, and the PDU carrying the initial XLGs may not be received. In this case, the XSR retransmission timer may be relied on to trigger another transmission of the XSR/BSR to attempt re- acquisition of the initial XLGs. The XLG may also be carried in the PDCCH to the helper WTRU and the terminal WTRU in the WTRU specific search area to achieve high reliability of the XLG transmission. It may require a new DCI format, which may increase the number of WTRU blind decodes. The DCI format may have a small pay load or have identical numbers of bits as one of the existing DCI formats with modified fields. Carrying the XLG in the PDCCH may require increased PDCCH capacity in the network.
[0245] When the helper WTRU 3510 and terminal WTRU 3508 receive the
XLGs, they may apply the XLGs and start synchronous data communication either with the help of a timer, a pre-defined time interval referenced at the reception of XLGs, or a pre-specified start time (3530). The helper WTRU 3510 and the terminal WTRU 3508 may start keeping track of the validity period and apply the XLG configurations to follow the duplex configuration if TDD is applied, transmit XL specific reference signals, transmit XPDCCH/XPDDCH and XPUCCH/XPUDCH and/or transmit DMRS for XPDDCH and XPUCCH. With respect to transmitting XL specific reference signals, both the helper WTRU 3510 and the terminal WTRU 3508 may transmit an XL specific reference signal, and
the helper WTRU's signal may be used for the terminal WTRU 3508 to synchronize with the helper WTRU 3510 (the helper WTRU's timing and frequency may be the master). In addition, the helper WTRU reference signal may be used by the terminal WTRU 3508 to perform channel estimation (to decode XPDCCH), determine feedback measurements (e.g., CQI) and/or derive transmission power control (TPC) bits. The terminal WTRU reference signal may also be applied for those purposes but may not be used for synchronization purposes.
[0246] Each helper WTRU/terminal WTRU may transmit over the same bandwidth specified in the XLGs and adjust the MCS based on the received ACK/NACK and CQI. The CQI may, thus, be measured on the same bandwidth because no frequency selective scheduling may be used on the XL. The CQI may provide a recommendation for the MCS. Alternatively, the frequency selectivity of the assigned XLG bandwidth may be explored, and the helper WTRU/terminal WTRU may report a further refined CQI of different sub-carrier groups within the granted bandwidth and schedule transmissions dynamically over different bandwidths. The XLS information may be transmitted on the XL in a dedicated control channel (e.g., the XPDCCH). The schedule information may include, for example, the MCS, the sub-carrier resource (if the transmission bandwidth may be adjusted), a new data indicator, or a redundancy version. These bits may be protected with cyclic redundancy check (CRC) bits that are scrambled with an XL identity, such as an AT-RNTI.
[0247] Each helper WTRU/terminal WTRU for each TTI based on the selected MCS and granted bandwidth (which may be a constant during XLG validity period) may calculate the XPDDCH/XPUDCH transmit power, for example, based on:
= stasis * i# Wtx>* + i¾ + Fi j Sml where PXLG is the granted XL power, BWTX is the transmission bandwidth (which may be the same as the BWXLG or granted bandwidth), PNominai is the desired
power level at the helper WTRU or the terminal WTRU, PL is the path loss between the helper WTRU and the terminal WTRU, ATF is the pre-defined function of the pre-defined transport format of the XPDDCH, and TPC is the predefined function of received TPC bits.
[0248] The path loss between the helper WTRU and the terminal WTRU may be calculated based on the XL specific reference signal presuming that the signal always applies PXLG, the maximum allowed power specified in the XLGs. Also, PNominai may be the desired or target power at a helper WTRU and a terminal WTRU given their interference level. Thus, the value of PNominai + PL denotes the basic open loop starting point. The equivalent parameter in LTE UL control, PCLPUSCH, may include components such as, for example, PO_NOMINAL_PUSCH, which may be in the range of -126 and +24 dBm and may be used to derive different BLER operating points to achieve low probability of retransmissions, or PO_UE_PUSCH, which may be in the range of -8 and +7 dB and may be used to compensate systematic offsets in WTRU transmit power due to errors in the estimated path loss.
[0249] PO_NOMINAL_PUSCH may be signaled to a WTRU via network broadcast by and PO_UE_PUSCH via dedicated signaling, so they may also be semi- static in nature. For the XL, PNominai may be included in XLGs and may be updated based on the XL measurement report sent to the network. ATF may be a function of the selected MCS, and TPC may be a function of the TPC bits received.
[0250] In connection with two-tier scheduling, a distributed power control function may be performed by the WTRU. In other words, the TPC commands in the XLS may be derived by the helper WTRU and the terminal WTRU using a pre-defined algorithm based on the received quality (e.g., the SINR of the reference symbols and/or the BLER of the data transmission). The TPC commands may be transmitted in a dedicated XL control channel or may be multiplexed with other control information in a common control channel. The TPC rate may be slower than once per TTI and may be a design parameter. An
LTE FDD system may apply TPC bits 4 sub-frames after a sub-frame in which the TPC bits are received.
[0251] In an embodiment, dedicated control and data channels may be time-multiplexed. For example, in the XDL, the XPDCCH may precede the XPDDCH in each TTI, and a terminal WTRU may need to read the XPDCCH to acquire all information necessary to decode the XPDDCH and continue to receive the XPDDCH in the same TTI. This may be similar, for example, to the LTE DL where a WTRU may read the PDCCH prior to decoding the PDSCH in the same TTI. However, this may be the case on both the XDL and the XUL when a terminal WTRU schedules a transmission based on the grant received from the network. One benefit may be reduced radio requirements if the dedicated control and data channel are not multiplexed in the frequency domain, in which case the helper WTRU/terminal WTRU transmit power may be the same on all sub- carriers. This may also imply that the XL dedicated control channels may have a different power control mechanism than the XL dedicated data channels that may be more tailored to the control channel formats and payloads. For example, the XPDCCH of sub-frame i may be calculated based on:
where ATF is a function of the pre-defined transport format of the XPDCCH. Further, the bandwidth applied for the XPDCCH transmission may be predefined and factored into the function. The TPC is the distributed power control function performed by the WTRUs as described above.
[0252] For each transmission, the helper WTRU/terminal WTRU may use the calculated transmit power to derive the XLPH. Further, they may continue the XL measurement upon request from the network (3532/3534) with configuration directly related to the issued XLGs. For example, the network may request specific signal strength measurements on certain sub-carrier groups to help optimize the XLG update instead of a bit map reported prior to the initial XLG. In this case, the measurement result may be the signal strength of the requested XL specific reference signal in the requested sub-carrier groups. The
result may be quantized in a manner similar to received signal code power (RSCP) measurements in the LTE network and may be considered to be transmitted on a physical channel in the LTE UL. For example, the result may be transmitted in the PUCCH along with the UL control information bits, such as CQI bits, in a new dedicated physical XL feedback channel in addition to the PUCCH, or in XL RRC measurements carried in the PUSCH.
[0253] With reference to FIGs. 35A and 35B, the helper WTRU 3510 and the terminal WTRU 3508 may perform the requested XL measurement and send one or more XL measurement reports to the eNB 3506 on the PUSSCH (3536/3538/3540/3542).
[0254] The physical channel transmission may benefit from low latency but may require extra PUCCH resources. Alternatively, the measurement result may be multiplexed with the PUSCH when the TRUL grant is available in a similar manner to CQI multiplexing in the PUSCH. In the AT-R capacity mode, the XL RRC measurements may be requested, configured and reported in the same way as regular neighbor cell measurements. In an AT-R coverage mode, the terminal WTRU may not have an RRC entity, and, therefore, the helper WTRU may need to forward the terminal WTRU measurement to the network in the PUSCH.
[0255] The measurement of a helper WTRU and a terminal WTRU may occur in their receiving sub-frames in the case of an XL with TDD scheme and the designated band in the case of an FDD scheme. A measurement gap configuration may be required to suspend the TRL transmission. Upon receiving all the XL measurements, the network may update the XLGs to optimize the resource allocation and coordinate inter-cross-link interference (3548).
[0256] In an embodiment, the power control mechanism may be administered before the XLGs are updated to facilitate an efficient utilization of power resource by the adjustment of PXLG while maintaining the QoS (3544). For example, a transmitting WTRU may calculate a maximum MCS according to the assigned PXLG and the power control formula when the assigned bandwidth is
applied unchanged. The subsequent data transmissions may result in a BLER ratio for a pre-defined period measured at the receiving WTRU. The receiving WTRU may then generate TPC commands based on the BLER ratio to regulate the power, and a consecutive number of unidirectional TPC commands may trigger a power head room reporting. For example, when the power is more than required to deliver the MCS, the receiving WTRU may send a number of consecutive DOWN TPC commands, which may be pre-defined as a PHR trigger, and the transmitting WTRU may report the power headroom to the eNB. The eNB may then reduce the PXLG in the next grant. Once the XLGs have been updated, data transmission may be resumed (3550).
[0257] FIGs. 36A and 36B include a signal diagram 3600A/3600B of another example initial grant acquisition procedure and update XLG operation in a capacity mode. In the example illustrated in FIGs. 36A and 36B, however, the terminal WTRU 3602 and the helper WTRU 3604 are initially in RRC IDLE mode (3608/3610). Each of the terminal WTRU 3602 and the helper WTRU 3604 engages in a paging procedure with the eNB 3606 (3612/3614), after which both the terminal WTRU 3602 and the helper WTRU 3604 are in RRC CONNECTED mode (3616/3618). In the illustrated example, when both the helper WTRU 3604 and the terminal WTRU 3602 transition to the RRC CONNECTED mode, the eNB 3606 sends a measurement request and configuration to each of the terminal WTRU 3602 and the helper WTRU 3604 based on the pair's historical XLGs (3620/3622). The remaining signaling and procedure illustrated in FIG. 36 is the same as the embodiment illustrated in FIGs. 35A and 35B, and the corresponding signals/procedure have been given the same numbers in FIGs. 35A, 35B, 36A and 36B.
[0258] FIGs. 37A and 37B include a signal diagram 3700A /3700B of an example initial grant acquisition and continued XLG update procedure in a coverage mode. The main differences between the XLG procedures in AT-R capacity and coverage mode may be due to the lack of a TRL at the terminal WTRU. For example, in an AT-R coverage mode, the XLGs may be transmitted
to a terminal WTRU via the XL, all XL measurements from a terminal WTRU are relayed by its helper WTRU to the network, and a new safeguard mechanism may be put in place to guard against lost XLGs on the XL transmission.
[0259] In the example illustrated in FIGs. 37A and 37B, a neighbor seeking
WTRU 3702, neighbor present WTRU 3704 and an eNB 3706 engage in a neighbor discovery procedure after which the neighbor WTRU 3704 is selected as a candidate helper WTRU (3708). The neighbor seeking WTRU 3702 and the selected candidate helper WTRU 3704 may then exchange association messages on the XPDSACH (3710). The neighbor seeking WTRU 3702 and the candidate helper WTRU 3704 may then exchange RRC messages. However, the candidate helper WTRU 3704 may transmit its RRC message on the XPDSACH (3710). Its RRC message may include basic system information, such as, for example, the candidate helper WTRU's cell ID and temporary mobile subscriber identity (TMSI) or the helper WTRU's C-RNTI (3712). The neighbor seeking WTRU 3702 transmits its RRC message on the XPUSACH. Its RRC message may include an indication that the candidate helper WTRU 3704 has been selected as the helper WTRU (3714). The selected helper WTRU 3704 and the eNB 3706 may then engage in a RACH and RRC connection setup procedure (3715), if necessary, after which the selected helper WTRU 3704 is in RRC CONNECTED mode (3718) and the neighbor seeking WTRU 3702 is now the terminal WTRU 3716.
[0260] The selected helper WTRU 3704 may transmit a selection indicator to the terminal WTRU 3716 on the XPDACH (3720). In response, the terminal WTRU 3716 may send an XSR to the selected helper WTRU 3704 on the XPUACH and make an XL measurement on the XPUSACH (3722). The selected helper WTRU 3704 may then send an XSR to the eNB 3706 on the PUCCH and make an XL measurement on the PUSCH (3724).
[0261] The selected helper WTRU 3704 may receive initial helper
WTRU/terminal WTRU XLGs from the eNB 3706 (3726). In order to forward XLGs to the terminal WTRU 3716, the selected helper WTRU 3704 may transmit an initial XLG to the terminal WTRU in the XPDSACH or the XPGCH (3727).
With respect to the XPDSACH, the XPDACH may indicate the XLGs in the XPDSACH for the terminal WTRU 3716 to read. The XPDSACH is a data channel, and the XLGs may be in the form of a MAC control element or a MAC PDU similar to the one used in the RACH access response (RAR) for LTE systems. With respect to the XPGCH, the XPDACH may indicate the XLGs in the XPGCH. The XPGCH may be a PHY channel only, and the XLGs may be in the form of control bits. The selected helper WTRU 3704 may now be an active helper WTRU 3728.
[0262] The terminal WTRU 3716, the helper WTRU 3728 and the eNB
3706 may begin data transmission following the initial XLGs (3730). The eNB 3706 may send an XL measurement request and configuration message to the helper WTRU 3728 on the PDSCH (3732), and the helper WTRU 3728 may forward the XL measurement request and configuration to the terminal WTRU 3716 on the XPDCH (3734). In response, the terminal WTRU 3716 may send an XL measurement report to the helper WTRU 3728 on the XPUDCH (3736), and the helper WTRU 3728 may forward the measurement report to the eNB 3706 on the PUSCH (3738). This process may be repeated as necessary (e.g., 3740/3742). The eNB 3706 may then engage in a procedure to optimize the grant power levels of each XL (3744).
[0263] The helper WTRU 3728 may receive updated helper WTRU/terminal
WTRU XLGs from the eNB 3706 on the PDSCH (3746). In order to forward the updated XLGs to the terminal WTRU 3716, the helper WTRU 3728 may transmit an update XLG to the terminal WTRU 3716 in the XPDSACH/XPGCH, the XPGCH, the XPDDCH or the XPDDCH (3748). With respect to the XPDSACH/XPGCH (unscheduled PHY channel), the helper WTRU 3728 may transmit the update XLG the same way as it does an initial XLG. After the XLGs are updated, normal transmission may be resumed (3750).
[0264] In an embodiment, the initial XLG transmission to a terminal
WTRU, as in the AT-R capacity mode, may be ensured with an XSR retransmission (e.g., if the initial XLGs are not received, the terminal WTRU
may retransmit the XSR according to the timer). However, once the update XLGs are lost, they may not be recovered, and the terminal WTRU may then suspend its transmission. In this case, the helper WTRU may detect radio link failure (RLF) on the XUL. A new handling may thus be required to avoid unnecessary RLFs. For example, when a helper WTRU detects an abrupt XUL specific reference signal measurement degradation coupled with an update XLG validity period start, the helper WTRU may attempt to retransmit the update XLG to see if the reference signal level recovers. Alternatively, the terminal WTRU may transmit an indication of the missing update XLG in the XPUCCH if, during the validity period of the on-going XLG, no update XLG is received from the helper WTRU. This may trigger the helper WTRU to retransmit to the terminal WTRU. This type of safeguard mechanism against XLG loss may be useful when XLGs are carried in a data channel that has a higher error rate than the physical layer control channel.
[0265] The XLG procedure applied in AT-LO applications may be similar to that discussed in connection with the AT-R capacity mode because all WTRUs participating in an AT-LO application may be associated with the network. AT- LO applications may adopt a different set of physical channels including, for example, an XL physical cluster head broadcast channel (XPCHBCH) that may be used to carry the XLG to all cluster members. In addition, the assigned XLG may be per cluster, and the cluster head may perform a more extensive XL scheduling over multiple XLs. For example, a cluster head may be required to dynamically schedule resources allocated by the XLG to different XLs in accordance with the channel condition and traffic variation of each XL. Each cluster member may provide similar measurements as described above with respect to the cluster head to assist the scheduling decision.
[0266] EMBODIMENTS
[0267] 1. A method of radio resource scheduling on a radio cross link between a first node and a second node, the method comprising the first node
receiving a cross link grant specifying resources for use by at least the first node for transmission on the radio cross link.
[0268] 2. The method of embodiment 1, further comprising the first node performing cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link grant.
[0269] 3. The method of embodiment 2, further comprising the first node transmitting at least one packet to the second node based on the cross link scheduling per TTI.
[0270] 4. The method of any one of embodiments 1-3, wherein the cross link grant is at least one of a maximum allowed cross link transmit power, an assignment of a cross link bandwidth, a provision of cross link power control parameters or a designated code configuration for all physical channels on the cross link.
[0271] 5. The method of any one of embodiments 2-4, wherein the first node performing cross link scheduling per TTI includes adjusting a modulation and coding scheme used over a bandwidth specified in the cross link grant dynamically based on channel condition feedback.
[0272] 6. The method of any one of embodiments 2-5, wherein the first node performing cross link scheduling per TTI includes calculating a corresponding required transmit power based on a modulation and coding scheme specified in the cross link grant, a cross link bandwidth assigned in the cross link grant, a cross link path loss specified in the cross link grant and transmit power control commands provided in the cross link grant.
[0273] 7. The method of any one of embodiments 1-6, wherein the cross link grant includes a validity period after which the cross link grant is no longer valid.
[0274] 8. The method of any one of embodiments 1-7, wherein the cross link grant is based on at least one of cross link signal and interference measurements, cross link power headroom reporting, or cross link feedback measurements.
[0275] 9. The method of any one of embodiments 2-8, wherein the cross link scheduling per TTI is based on the resources specified in the cross link grant and at least one of a cross link acknowledgement/non-acknowledgement
(ACK/NACK) message or a channel quality indicator (CQI).
[0276] 10. The method of any one of embodiments 1-9, wherein the first and second nodes are wireless transmit/receive units (WTRUs).
[0277] 11. The method of any one of embodiments 1-9, wherein the first and second nodes are enhanced NodeBs (eNBs).
[0278] 12. A wireless transmit/receive unit (WTRU) comprising: a receiver configured to receive a radio link control (RLC) protocol data unit (PDU); a local buffer; and a partial RLC layer.
[0279] 13. The WTRU of embodiment 12, wherein the partial RLC layer is configured to store the received RLC PDU in a logical channel based channel queue in the local buffer.
[0280] 14. The WTRU of embodiment 13, wherein the partial RLC layer is further configured to set a discard timer for the received RLC PDU stored in the logical channel based channel queue.
[0281] 15. The WTRU of embodiment 14, wherein the partial RLC layer is further configured to drop the received RLC PDU from the local buffer on a condition that the discard timer expires before the WTRU relays the RLC PDU via the radio cross link.
[0282] 16. The WTRU of any one of embodiments 12-15, wherein the
WTRU is configured to relay data between a base station and another WTRU by communicating with the base station via a traditional radio link and communicating with the other WTRU via the radio cross link.
[0283] 17. The WTRU of any one of embodiments 12-16, wherein the other
WTRU is not located within a cell operated by the base station.
[0284] 18. The WTRU of embodiment 16 orl7, further comprising a transmitter configured to transmit to the other WTRU a sequence number of an
RLC PDU that is the highest of all RLC PDUs dropped by the WTRU.
[0285] 19. The WTRU of any one of embodiments 16-18, further comprising a processor configured to perform RLC re- segmentation for relaying data between the traditional radio link and the radio cross link on a condition that a transport block size is different between the traditional radio link and the radio cross link.
[0286] 20. The WTRU of any one of embodiments 12-19, wherein the
WTRU is configured to relay data between a base station and another WTRU by communicating with the base station and the other WTRU over a relay path that includes a traditional radio link between the WTRU and the base station and the radio cross link between the WTRU and the other WTRU, the base station and other WTRU being configured to communicate with one another over a direct path including the traditional radio link.
[0287] 21. The WTRU of embodiment 20, wherein separate data radio bearers (DRBs) are set up to carry data through the direct path and the relay path, respectively.
[0288] 22. An advanced topology (AT) system comprising a base station configured to operate a wireless cell and a plurality of wireless transmit/receive units (WTRUs) including a first WTRU and a second WTRU configured to communicate with the first WTRU over a first radio cross link.
[0289] 23. The AT system of embodiment 22, wherein the plurality of
WTRUs further include a third WTRU and a fourth WTRU configured to communicate with the third WTRU over a second radio cross link.
[0290] 24. The AT system of embodiment 23, wherein the first WTRU, the second WTRU, the third WTRU and the fourth WTRU are configured to receive a cross link grant specifying resources for use by the first WTRU, the second WTRU, the third WTRU and the fourth WTRU for transmissions over the first radio cross link and the second radio cross link.
[0291] 25. The AT system of embodiment 24, wherein the first WTRU and the second WTRU are configured to negotiate a first cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link
grant for transmissions over the first radio cross link and to transmit at least one packet over the first radio cross link based on the first cross link scheduling per TTI.
[0292] 26. The AT system of embodiment 24 or 25, wherein the third
WTRU and the fourth WTRU are configured to negotiate a second cross link scheduling per TTI within the resources specified in the cross link grant for transmissions over the second radio cross link and to transmit at least one packet over the second radio cross link based on the second cross link scheduling per TTI.
[0293] 27. The AT system of any one of embodiments 22-26, wherein the plurality of WTRUs further include a plurality of other WTRU pairs, each of the plurality of other WTRU pairs being configured to communicate within themselves via a respective radio cross link.
[0294] 28. The AT system of embodiment 27, wherein each radio cross link within the cell is assigned to one of a plurality of frequency reuse groups.
[0295] 29. The AT system of embodiment 28, wherein each radio cross link assigned to a particular one of the plurality of frequency reuse groups is granted a dedicated portion of a cross link bandwidth provided in the cross link grant.
[0296] 30. The AT system of any one of embodiments 22-29, wherein one of the first WTRU and the second WTRU is configured as a first helper WTRU to relay data between the base station and the other one of the first WTRU and the second WTRU.
[0297] 31. The AT system of any one of embodiments 23-30, wherein one of the third WTRU and the fourth WTRU is configured as a second helper WTRU to relay data between the base station and the other one of the third WTRU and the fourth WTRU.
[0298] 32. The AT system of any one of embodiments 22-31, wherein each of the first and second helper WTRUs includes a partial radio link control (RLC) layer.
[0299] 33. The AT system of embodiment 32, wherein the partial RLC layer is configured to store a received RLC protocol data unit (PDU) in a logical channel based channel queue in a local buffer.
[0300] 34. The AT system of embodiment 33, wherein the partial RLC layer is further configured to set a discard timer for the received RLC PDU stored in the logical channel based channel queue.
[0301] 35. The AT system of embodiment 34, wherein the partial RLC layer is further configured to drop the received RLC PDU from the local buffer on a condition that the discard timer expires before the RLC PDU is relayed via the respective first or second radio cross link.
[0302] 36. The AT system of any one of embodiments 32-35, wherein each of the first and second helper WTRUs is configured transmit to the other of the first and second WTRUs a sequence number of an RLC PDU that is the highest of all RLC PDUs dropped by the WTRU (HDSN).
[0303] 37. The AT system of embodiment 36, wherein each of the other of the first and second WTRUs is configured to update a lower edge of a receive window of the other of the first and second WTRUs to HDSN+1 in response to receiving the HDSN from the one of the first and second helper WTRUs.
[0304] 38. The AT system of any one of embodiments 30-37, wherein each of the first and second helper WTRUs is further configured to transmit to the base station at least one medium access control (MAC) status report selected from the group consisting of a cross link uplink scheduling request for requesting an initial cross link grant for uplink transmissions, a cross link downlink scheduling request requesting an initial cross link grant for downlink transmissions, a terminal- WTRU buffer status report for determining scheduling in the cross link uplink jointly by the base station and one of the WTRU and the other WTRU, a cross link downlink buffer status report for determining scheduling in the cross link downlink jointly by the base station and the WTRU and a cross link power headroom reporting mechanism for determining cross link scheduling jointly by the base station, the WTRU and the other WTRU.
[0305] 39. The AT system of any one of embodiments 22-38, wherein each of the first WTRU, the second WTRU, the third WTRU and the fourth WTRU is located within the wireless cell.
[0306] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
" " "
Claims
1. A method of radio resource scheduling on a radio cross link between a first node and a second node, the method comprising:
the first node receiving a cross link grant specifying resources for use by at least the first node for transmission on the radio cross link;
the first node performing cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link grant; and
the first node transmitting at least one packet to the second node based on the cross link scheduling per TTI.
2. The method of claim 1, wherein the cross link grant is at least one of a maximum allowed cross link transmit power, an assignment of a cross link bandwidth, a provision of cross link power control parameters or a designated code configuration for all physical channels on the cross link.
3. The method of claim 1, wherein the first node performing cross link scheduling per TTI includes at least one of:
adjusting a modulation and coding scheme used over a bandwidth specified in the cross link grant dynamically based on channel condition feedback, or calculating a corresponding required transmit power based on a modulation and coding scheme specified in the cross link grant, a cross link bandwidth assigned in the cross link grant, a cross link path loss specified in the cross link grant and transmit power control commands provided in the cross link grant.
4. The method of claim 1, wherein the cross link grant includes a validity period after which the cross link grant is no longer valid.
5. The method of claim 1, wherein the cross link grant is based on at least one of cross link signal and interference measurements, cross link power headroom reporting, or cross link feedback measurements.
6. The method of claim 1, wherein the cross link scheduling per TTI is based on the resources specified in the cross link grant and at least one of a cross link acknowledgement/non-acknowledgement (ACK/NACK) message or a channel quality indicator (CQI).
7. The method of claim 1, wherein the first and second nodes are wireless transmit/receive units (WTRUs).
8. The method of claim 1, wherein the first and second nodes are enhanced NodeBs (eNBs).
9. A wireless transmit/receive unit (WTRU) comprising:
a receiver configured to receive a radio link control (RLC) protocol data unit (PDU);
a local buffer; and
a partial RLC layer configured to:
store the received RLC PDU in a logical channel based channel queue in the local buffer,
set a discard timer for the received RLC PDU stored in the logical channel based channel queue, and
on a condition that the discard timer expires before the WTRU relays the RLC PDU via the radio cross link, drop the received RLC PDU from the local buffer.
10. The WTRU of claim 9, wherein:
the WTRU is configured to relay data between a base station and another WTRU by communicating with the base station via a traditional radio link and communicating with the other WTRU via the radio cross link, and
the other WTRU is not located within a cell operated by the base station.
11. The WTRU of claim 10, further comprising a transmitter configured to transmit to the other WTRU a sequence number of an RLC PDU that is the highest of all RLC PDUs dropped by the WTRU.
12. The WTRU of claim 10, further comprising a processor configured to perform RLC re-segmentation for relaying data between the traditional radio link and the radio cross link on a condition that a transport block size is different between the traditional radio link and the radio cross link.
13. The WTRU of claim 9, wherein:
the WTRU is configured to relay data between a base station and another WTRU by communicating with the base station and the other WTRU over a relay path that includes a traditional radio link between the WTRU and the base station and the radio cross link between the WTRU and the other WTRU, the base station and the other WTRU being configured to communicate with one another over a direct path including the traditional radio link, and
separate data radio bearers (DRBs) are set up to carry data through the direct path and the relay path, respectively.
14. An advanced topology (AT) system comprising:
a base station configured to operate a wireless cell; and
a plurality of wireless transmit/receive units (WTRUs) including:
a first WTRU and a second WTRU configured to communicate with the first WTRU over a first radio cross link, and a third WTRU and a fourth WTRU configured to communicate with the third WTRU over a second radio cross link, wherein:
the first WTRU, the second WTRU, the third WTRU and the fourth WTRU are configured to receive a cross link grant specifying resources for use by the first WTRU, the second WTRU, the third WTRU and the fourth WTRU for transmissions over the first radio cross link and the second radio cross link, the first WTRU and the second WTRU are configured to negotiate a first cross link scheduling per transmission time interval (TTI) within the resources specified in the cross link grant for transmissions over the first radio cross link and to transmit at least one packet over the first radio cross link based on the first cross link scheduling per TTI, and
the third WTRU and the fourth WTRU are configured to negotiate a second cross link scheduling per TTI within the resources specified in the cross link grant for transmissions over the second radio cross link and to transmit at least one packet over the second radio cross link based on the second cross link scheduling per TTI.
15. The AT system of claim 14, wherein the plurality of WTRUs further include a plurality of other WTRU pairs, each of the plurality of other WTRU pairs being configured to communicate within themselves via a respective radio cross link, wherein:
each radio cross link within the cell is assigned to one of a plurality of frequency reuse groups, and
each radio cross link assigned to a particular one of the plurality of frequency reuse groups is granted a dedicated portion of a cross link bandwidth provided in the cross link grant.
16. The AT system of claim 14, wherein:
one of the first WTRU and the second WTRU is configured as a first helper WTRU to relay data between the base station and the other one of the first WTRU and the second WTRU, and
one of the third WTRU and the fourth WTRU is configured as a second helper WTRU to relay data between the base station and the other one of the third WTRU and the fourth WTRU.
17. The AT system of claim 16, wherein each of the first and second helper WTRUs includes a partial radio link control (RLC) layer, the partial RLC layer being configured to:
store a received RLC protocol data unit (PDU) in a logical channel based channel queue in a local buffer,
set a discard timer for the received RLC PDU stored in the logical channel based channel queue, and
on a condition that the discard timer expires before the RLC PDU is relayed via the respective first or second radio cross link, drop the received RLC PDU from the local buffer.
18. The AT system of claim 16, wherein:
each of the first and second helper WTRUs is configured transmit to the other of the first and second WTRUs a sequence number of an RLC PDU that is the highest of all RLC PDUs dropped by the WTRU (HDSN), and
each of the other of the first and second WTRUs is configured to update a lower edge of a receive window of the other of the first and second WTRUs to HDSN+1 in response to receiving the HDSN from the one of the first and second helper WTRUs.
19. The AT system of claim 16, wherein each of the first and second helper WTRUs is further configured to transmit to the base station at least one medium access control (MAC) status report selected from the group consisting of a cross link uplink scheduling request for requesting an initial cross link grant for uplink transmissions, a cross link downlink scheduling request requesting an initial cross link grant for downlink transmissions, a terminal-WTRU buffer status report for determining scheduling in the cross link uplink jointly by the base station and one of the WTRU and the other WTRU, a cross link downlink buffer status report for determining scheduling in the cross link downlink jointly by the base station and the WTRU and a cross link power headroom reporting mechanism for determining cross link scheduling jointly by the base station, the WTRU and the other WTRU.
20. The AT system of claim 14, wherein each of the first WTRU, the second WTRU, the third WTRU and the fourth WTRU is located within the wireless cell.
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161568342P | 2011-12-08 | 2011-12-08 | |
US61/568,342 | 2011-12-08 | ||
US201261610754P | 2012-03-14 | 2012-03-14 | |
US61/610,754 | 2012-03-14 | ||
US201261653512P | 2012-05-31 | 2012-05-31 | |
US61/653,512 | 2012-05-31 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2013086362A1 true WO2013086362A1 (en) | 2013-06-13 |
Family
ID=47430105
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2012/068502 WO2013086362A1 (en) | 2011-12-08 | 2012-12-07 | Direct communication between wireless transmit/receive units (wtrus) in advanced topology (at) applications |
Country Status (2)
Country | Link |
---|---|
TW (1) | TW201338437A (en) |
WO (1) | WO2013086362A1 (en) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015142425A1 (en) * | 2014-03-19 | 2015-09-24 | Qualcomm Incorporated | Scheduling of device-to-device communications |
WO2016043376A1 (en) * | 2014-09-19 | 2016-03-24 | 엘지전자 주식회사 | Method for reporting buffer status of terminal and apparatus therefor in system in which heterogeneous wireless communication technologies are utilized |
US9357459B2 (en) | 2011-12-08 | 2016-05-31 | Interdigital Patent Holdings, Inc. | Method and apparatus for cross link establishment |
WO2017037343A1 (en) * | 2015-09-04 | 2017-03-09 | Nokia Technologies Oy | Threshold for reduced latency mechanisms |
EP3136798A4 (en) * | 2014-04-20 | 2017-11-22 | LG Electronics Inc. | Method for determining transmit power for direct device to device communication in wireless communication system and apparatus therefor |
EP3221990A4 (en) * | 2014-11-20 | 2017-11-22 | Telefonaktiebolaget LM Ericsson (publ) | First network node, second network node and methods for transmitting and receiving a protocol data unit |
CN107409370A (en) * | 2014-12-23 | 2017-11-28 | Idac控股公司 | Delay in LTE system reduces |
WO2018125718A1 (en) | 2016-12-29 | 2018-07-05 | Hughes Network Systems, Llc | Hierarchical link quality metrics for a beam in a satellite network |
CN109391973A (en) * | 2017-08-14 | 2019-02-26 | 中国移动通信有限公司研究院 | A kind of cross link interference detecting method, equipment and computer readable storage medium |
US10477420B2 (en) | 2017-01-13 | 2019-11-12 | At&T Intellectual Property I, L.P. | Cross link interference measurement for wireless communications in 5G or other next generation network |
CN113630894A (en) * | 2016-02-02 | 2021-11-09 | 日本电气株式会社 | Method and apparatus for communication with carrier aggregation |
CN113708896A (en) * | 2014-09-26 | 2021-11-26 | 高通股份有限公司 | Ultra-low delay LTE uplink frame structure |
US11259279B2 (en) * | 2014-09-02 | 2022-02-22 | Zte Corporation | Data transmission method and device |
US11576056B1 (en) | 2021-05-10 | 2023-02-07 | T-Mobile Innovations Llc | Unified data repository (UDR) messaging in a wireless communication network |
WO2023239365A1 (en) * | 2022-06-09 | 2023-12-14 | Zeku Technology (Shanghai) Corp. , Ltd. | Apparatus and method for service data unit segment reassembly |
US11985084B2 (en) | 2014-09-26 | 2024-05-14 | Qualcomm Incorporated | Ultra-low latency LTE reference signal transmission |
US11991102B2 (en) | 2014-03-20 | 2024-05-21 | Interdigital Patent Holdings, Inc. | Method and apparatus for non-orthogonal access in LTE systems |
TWI845666B (en) * | 2019-05-03 | 2024-06-21 | 美商高通公司 | Method and apparatus for wireless communications |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TWI616078B (en) * | 2016-03-30 | 2018-02-21 | 財團法人工業技術研究院 | Communication system, communication device and method thereof for d2d communications |
US10021596B2 (en) | 2016-03-30 | 2018-07-10 | Industrial Technology Research Institute | Communication system, communication device, base station and method thereof for D2D communications |
CN111565098B (en) * | 2019-02-13 | 2022-02-11 | 华为技术有限公司 | Method, device and system for determining HARQ feedback resources |
CN115001986B (en) * | 2022-05-06 | 2023-10-27 | 河北华万电子科技有限公司 | New energy control based PLC communication time delay and interruption probability estimation method |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011050519A1 (en) * | 2009-10-28 | 2011-05-05 | Nokia Corporation | An interference suppression mechanism in communication networks |
US20110105136A1 (en) * | 2009-11-05 | 2011-05-05 | Infineon Technologies Ag | Radio base stations, radio communication devices, methods for controlling a radio base station and methods for controlling a radio communication device |
-
2012
- 2012-12-07 TW TW101146131A patent/TW201338437A/en unknown
- 2012-12-07 WO PCT/US2012/068502 patent/WO2013086362A1/en active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011050519A1 (en) * | 2009-10-28 | 2011-05-05 | Nokia Corporation | An interference suppression mechanism in communication networks |
US20110105136A1 (en) * | 2009-11-05 | 2011-05-05 | Infineon Technologies Ag | Radio base stations, radio communication devices, methods for controlling a radio base station and methods for controlling a radio communication device |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9357459B2 (en) | 2011-12-08 | 2016-05-31 | Interdigital Patent Holdings, Inc. | Method and apparatus for cross link establishment |
US9883513B2 (en) | 2014-03-19 | 2018-01-30 | Qualcomm Incorporated | Scheduling of device-to-device scheduling assignment for mode1 |
WO2015142425A1 (en) * | 2014-03-19 | 2015-09-24 | Qualcomm Incorporated | Scheduling of device-to-device communications |
US11991102B2 (en) | 2014-03-20 | 2024-05-21 | Interdigital Patent Holdings, Inc. | Method and apparatus for non-orthogonal access in LTE systems |
US10405285B2 (en) | 2014-04-20 | 2019-09-03 | Lg Electronics Inc. | Method for determining transmit power for direct device to device communication in wireless communication system and apparatus therefor |
EP3136798A4 (en) * | 2014-04-20 | 2017-11-22 | LG Electronics Inc. | Method for determining transmit power for direct device to device communication in wireless communication system and apparatus therefor |
US11259279B2 (en) * | 2014-09-02 | 2022-02-22 | Zte Corporation | Data transmission method and device |
US10237778B2 (en) | 2014-09-19 | 2019-03-19 | Lg Electronics Inc. | Method for reporting buffer status of terminal and apparatus therefor in system in which heterogeneous wireless communication technologies are utilized |
WO2016043376A1 (en) * | 2014-09-19 | 2016-03-24 | 엘지전자 주식회사 | Method for reporting buffer status of terminal and apparatus therefor in system in which heterogeneous wireless communication technologies are utilized |
CN113708896B (en) * | 2014-09-26 | 2024-05-28 | 高通股份有限公司 | Ultra-low delay LTE uplink frame structure |
CN113708896A (en) * | 2014-09-26 | 2021-11-26 | 高通股份有限公司 | Ultra-low delay LTE uplink frame structure |
US11985084B2 (en) | 2014-09-26 | 2024-05-14 | Qualcomm Incorporated | Ultra-low latency LTE reference signal transmission |
EP3221990A4 (en) * | 2014-11-20 | 2017-11-22 | Telefonaktiebolaget LM Ericsson (publ) | First network node, second network node and methods for transmitting and receiving a protocol data unit |
US10396931B2 (en) | 2014-11-20 | 2019-08-27 | Telefonaktiebolaget Lm Ericsson (Publ) | First network node, second network node and methods for transmitting and receiving a protocol data unit |
CN107409370A (en) * | 2014-12-23 | 2017-11-28 | Idac控股公司 | Delay in LTE system reduces |
US12069595B2 (en) | 2014-12-23 | 2024-08-20 | Interdigital Patent Holdings, Inc. | Latency reduction in LTE systems |
CN107409370B (en) * | 2014-12-23 | 2020-08-21 | Idac控股公司 | Method for communicating data performed by WTRU and WTRU |
US10594612B2 (en) | 2015-09-04 | 2020-03-17 | Nokia Technologies Oy | Threshold for reduced latency mechanisms |
WO2017037343A1 (en) * | 2015-09-04 | 2017-03-09 | Nokia Technologies Oy | Threshold for reduced latency mechanisms |
CN113630894A (en) * | 2016-02-02 | 2021-11-09 | 日本电气株式会社 | Method and apparatus for communication with carrier aggregation |
EP3563591A4 (en) * | 2016-12-29 | 2020-06-10 | Hughes Network Systems, LLC | Hierarchical link quality metrics for a beam in a satellite network |
WO2018125718A1 (en) | 2016-12-29 | 2018-07-05 | Hughes Network Systems, Llc | Hierarchical link quality metrics for a beam in a satellite network |
US11129037B2 (en) | 2017-01-13 | 2021-09-21 | At&T Intellectual Property I, L.P. | Cross link interference measurement for wireless communications in 5G or other next generation network |
US10477420B2 (en) | 2017-01-13 | 2019-11-12 | At&T Intellectual Property I, L.P. | Cross link interference measurement for wireless communications in 5G or other next generation network |
CN109391973B (en) * | 2017-08-14 | 2022-06-07 | 中国移动通信有限公司研究院 | Cross link interference measurement method, device and computer readable storage medium |
CN109391973A (en) * | 2017-08-14 | 2019-02-26 | 中国移动通信有限公司研究院 | A kind of cross link interference detecting method, equipment and computer readable storage medium |
TWI845666B (en) * | 2019-05-03 | 2024-06-21 | 美商高通公司 | Method and apparatus for wireless communications |
US11576056B1 (en) | 2021-05-10 | 2023-02-07 | T-Mobile Innovations Llc | Unified data repository (UDR) messaging in a wireless communication network |
US11910205B2 (en) | 2021-05-10 | 2024-02-20 | T-Mobile Innovations Llc | Messaging in a wireless communication network |
WO2023239365A1 (en) * | 2022-06-09 | 2023-12-14 | Zeku Technology (Shanghai) Corp. , Ltd. | Apparatus and method for service data unit segment reassembly |
Also Published As
Publication number | Publication date |
---|---|
TW201338437A (en) | 2013-09-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2013086362A1 (en) | Direct communication between wireless transmit/receive units (wtrus) in advanced topology (at) applications | |
JP6908555B2 (en) | Providing physical layer resources to different serving sites | |
JP6482612B2 (en) | Method and apparatus for improving cell edge user performance and signaling radio link failure conditions via downlink cooperative component carriers | |
US10667119B2 (en) | Uplink HARQ operation for prose-enabled UEs participating in sidelink discovery operation | |
TWI752016B (en) | Apparatus and methods for resource requests and uplink transmission grants for logical channels | |
CN111788858B (en) | Method and apparatus for retransmitting uplink data configured in discontinuous reception in wireless communication system | |
CN107431591B (en) | Method and apparatus for uplink operation of LTE in unlicensed frequency bands | |
US20180270815A1 (en) | Dynamic parameter adjustment for lte coexistence | |
TWI695604B (en) | A wireless transmit/receive unit, a method implemented therein and a network node | |
US20190229853A1 (en) | Method for determining retransmission numbers of sidelink data in wireless communication system and a device therefor | |
JP2018186506A (en) | Method and apparatus for requesting resource for control element transmission in wireless communication system | |
JP2019527999A (en) | Timing advance and throughput in a reduced latency system | |
JP2016519507A (en) | Method and apparatus for controlling uplink transmit power based on accumulated transmit power control commands and corresponding uplink subframe sets | |
TW201412170A (en) | Methods to enable scheduling and control of direct link communication in cellular communication systems | |
JP2010114943A (en) | Mobile station device, base station device, and communication control method | |
CN114451003A (en) | File delivery failure feedback and application feedback | |
WO2011146653A1 (en) | Method and apparatus for wireless transmit/receive unit cooperation | |
WO2015120698A1 (en) | Method and device for reducing number of ue releases, and base station | |
JP2024509908A (en) | Methods, architectures, apparatus, and systems for performing discontinuous reception on sidelinks | |
WO2023071664A1 (en) | Communication method and apparatus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 12806272 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 12806272 Country of ref document: EP Kind code of ref document: A1 |