TW201338437A

TW201338437A - Method, apparatus and system for direct communication between wireless transmit/receive units (WTRUs) in advanced topology (AT) applications

Info

Publication number: TW201338437A
Application number: TW101146131A
Authority: TW
Inventors: Zhuo-Rong Deng; Ravikumar V Pragada; Gregory S Sternberg; Balaji Raghothaman; Tao Deng; Kiran K Vanganuru; Hong-San Sheng; Steven Ferrante
Original assignee: Interdigital Patent Holdings
Priority date: 2011-12-08
Filing date: 2012-12-07
Publication date: 2013-09-16
Also published as: WO2013086362A1

Abstract

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.

Description

在進階拓撲（AT）應用中無線傳送/接收單元（WTRUs)間直接通訊方法、裝置及系統Direct communication method, device and system between wireless transmit/receive units (WTRUs) in advanced topology (AT) applications

相關申請的交叉引用
本申請要求2011年12月8日申請的美國臨時專利申請No. 61/568,342和2012年5月31日申請的美國臨時申請No. 61/653,512的權益，上述申請的內容以引用的方式結合於此。

CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to U.S. Provisional Application Serial No. 61/568, 342, filed on Dec. The manner of citation is incorporated herein.

高級長期演進（LTE-A）支持解碼和轉發中繼方案。提議的LTE-A解碼和轉發中繼節點從第一裝置接收資料，解調變、解碼並差錯糾正該資料，然後將新的信號重新傳輸給第二裝置。這與例如簡單接收和重廣播從另一個裝置接收的信號的傳統中繼器不同。解碼和中繼方案，雖然更複雜，但可增強在由於減少的信噪比（SNR）而降低信號品質的重新廣播上的信號品質。
已提議了兩種主要類型的LTE-A解碼和轉發中繼。類型1中繼使用它們自己的識別來控制它們自己的胞元。換句話說，從無線傳輸/接收單元（WTRU）的角度，類型1中繼仿佛是普通的增強節點B（eNB）。然而，從供應eNB（donor eNB）的角度，類型1中繼仿佛是普通的WTRU，但是可經由後續的信令將它本身識別為中繼。在另一方面，類型2中繼沒有它們自己的胞元標識，似乎以WTRU和eNB作為胞元中的主eNB。
類型1中繼節點和供應eNB之間的回載鏈路以及類型1中繼節點和每個WTRU之間的每個存取鏈路具有它們自己的全層2堆疊，包括完整的媒體存取控制（MAC）、無線電鏈路控制（RLC）和封包資料控制協議（PDCP）層，其所有在供應eNB、中繼節點和正中繼其資料的WTRU（“終端WTRU”）處終止。由於例如為LTE-A提議的類型1解碼和轉發中繼節點的相對複雜性，這些節點可比WTRU更強大，並且最可能是靜止的。

Advanced Long Term Evolution (LTE-A) supports decoding and forwarding relay schemes. The proposed LTE-A decoding and forwarding relay node receives data from the first device, demodulates, decodes, and corrects the data by error, and then retransmits the new signal to the second device. This is different from, for example, a conventional repeater that simply receives and rebroadcasts signals received from another device. The decoding and relaying scheme, while more complex, enhances the signal quality on re-broadcasting that reduces signal quality due to reduced signal-to-noise ratio (SNR).
Two main types of LTE-A decoding and forwarding relays have been proposed. Type 1 relays use their own identification to control their own cells. In other words, from the perspective of a WTRU, the Type 1 relay appears to be a normal Enhanced Node B (eNB). However, from the perspective of the donor eNB, the Type 1 relay appears to be a normal WTRU, but it can be identified as a relay via subsequent signaling. On the other hand, Type 2 relays do not have their own cell identity, and it appears that the WTRU and eNB are the primary eNBs in the cell.
The backhaul link between the Type 1 relay node and the Provisioning eNB and each access link between the Type 1 Relay Node and each WTRU have their own full layer 2 stack, including complete media access control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers, all of which terminate at the serving eNB, the relay node, and the WTRU ("terminal WTRU") that is relaying its data. Due to the relative complexity of Type 1 decoding and forwarding relay nodes, such as proposed for LTE-A, these nodes may be more powerful than WTRUs and are most likely to be stationary.

公開了一種用於在高級拓撲（AT）應用中節點間直接通訊的方法、裝置和系統。該方法包括第一節點接收指定由至少第一節點用於在無線電交叉鏈路上傳輸的資源的交叉鏈路授權。第一節點也在交叉鏈路授權中指定的資源中執行每傳輸時間間隔（TTI）的交叉鏈路排程，並基於每TTI的交叉鏈路排程授權將至少一個封包傳送給第二節點。

A method, apparatus and system for direct communication between nodes in a high level topology (AT) application is disclosed. The method includes the first node receiving a cross-link grant specifying a resource used by at least a first node for transmission over a radio cross-link. The first node also performs a cross-link schedule per transmission time interval (TTI) in the resources specified in the cross-link grant and transmits at least one packet to the second node based on the cross-link scheduling grant per TTI.

100．．．通訊系統100. . . Communication system

102，102a，102b，102c，102d．．．WTRU102, 102a, 102b, 102c, 102d. . . WTRU

104．．．RAN104. . . RAN

106．．．核心網路106. . . Core network

108．．．PSTN108. . . PSTN

110．．．網際網路110. . . Internet

112．．．其他網路112. . . Other network

114a，114b．．．基地台114a, 114b. . . Base station

116．．．空氣介面116. . . Air interface

118．．．處理器118. . . processor

120．．．收發器120. . . transceiver

122．．．傳輸/接收元件122. . . Transmission/reception component

124．．．揚聲器/麥克風124. . . Speaker/microphone

126．．．鍵盤126. . . keyboard

128．．．顯示器/觸控板128. . . Display/trackpad

130．．．不可移除記憶體130. . . Non-removable memory

132．．．可移除記憶體132. . . Removable memory

134．．．電源134. . . power supply

136．．．GPS晶片組136. . . GPS chipset

138．．．其他週邊裝置138. . . Other peripheral devices

140a，140b，140c，703，772，1322，1402，1524，2540，2640，2740，2820，2920，3070，3120，3240，3350，3450，3506，3606，3706．．．e節點B140a, 140b, 140c, 703, 772, 1322, 1402, 1524, 2540, 2640, 2740, 2820, 2920, 3070, 3120, 3240, 3350, 3450, 3506, 3606, 3706. . . eNodeB

142．．．MME142. . . MME

144．．．服務閘道144. . . Service gateway

146．．．PDN閘道146. . . PDN gateway

200．．．LTE-A中繼系統200. . . LTE-A relay system

202，302．．．供應胞元202,302. . . Supply cell

204，304．．．中繼節點204,304. . . Relay node

206，370，370A，370B，370D，370E，706，770，1406，1520，1716，1960，2060，2520，2620，2720，3050，3110，3220，3508，3602．．．終端WTRU206,370,370A,370B,370D,370E,706,770,1406,1520,1716,1960,2060,2520,2620,2720,3050,3110,3220,3508,3602. . . Terminal WTRU

208．．．回載鏈路208. . . Return link

210．．．存取鏈路210. . . Access link

300，702，752．．．堆疊300,702,752. . . Stacking

310，320，326，340，708，713，754，762．．．PDCP層310,320,326,340,708,713,754,762. . . PDCP layer

312，322，328，342，710，714，756，764．．．RLC層312,322,328,342,710,714,756,764. . . RLC layer

314，324，330，344，712，716，718，720，758，766．．．MAC層314,324,330,344,712,716,718,720,758,766. . . MAC layer

400．．．XL PHY訊框結構400. . . XL PHY frame structure

402，404，406，408，410，502，520，540．．．子訊框402, 404, 406, 408, 410, 502, 520, 540. . . Child frame

412A．．．鄰居發現區412A. . . Neighbor discovery area

412B，412D，412F，414B，414D．．．出現412B, 412D, 412F, 414B, 414D. . . appear

414A．．．UCZ414A. . . UCZ

416A，416B，416C，416D，416E，416F．．．NCZ416A, 416B, 416C, 416D, 416E, 416F. . . NCZ

418A，418C，418D，418E，418F．．．DZ418A, 418C, 418D, 418E, 418F. . . DZ

420．．．NDRT420. . . NDRT

422．．．NDIT422. . . NDIT

428，622．．．XPDCCH428,622. . . XPDCCH

430，636，654．．．XPUCCH430,636,654. . . XPUCCH

432，650．．．XPDSCH432,650. . . XPDSCH

434，632，656．．．XPUSCH434,632,656. . . XPUSCH

440，450．．．訊框440,450. . . Frame

504A，504B，628．．．XPNDCH504A, 504B, 628. . . XPNDCH

506A，506B．．．保護期間506A, 506B. . . Period of protection

508A，508B．．．XL特定參考信號508A, 508B. . . XL specific reference signal

510A，510B，624．．．XPDFBCH510A, 510B, 624. . . XPDFBCH

512A，512B．．．DMRS512A, 512B. . . DMRS

514．．．XL未排程參考信號514. . . XL unscheduled reference signal

516，652．．．XPACH516,652. . . XPACH

518．．．XSACH518. . . XSACH

600A，600B，600C，600D．．．頻道映射600A, 600B, 600C, 600D. . . Channel mapping

602．．．XPCCH602. . . XPCCH

604．．．XCCCH604. . . XCCCH

606．．．XDCCH606. . . XDCCH

608．．．XDTCH608. . . XDTCH

610．．．XPCH610. . . XPCH

612．．．XCCH612. . . XCCH

614，630．．．XDL-SCH614,630. . . XDL-SCH

616．．．XPDSACH616. . . XPDSACH

618．．．XPDDCH618. . . XPDDCH

620．．．XPDACH620. . . XPDACH

626．．．XPGCH626. . . XPGCH

634．．．XPUDCH634. . . XPUDCH

638．．．XPUACH638. . . XPUACH

640．．．XPUFBCH640. . . XPUFBCH

642．．．PCCH642. . . PCCH

644．．．DCCH644. . . DCCH

646．．．DTCH646. . . DTCH

648．．．XPCDCCH648. . . XPCDCCH

700．．．方塊圖700. . . Block diagram

360，360A，360B，360C，360E，360F，704，778，1320，1404，1522，1714，1950，2050，2430，2530，2630，2730，2810，2910，3060，3110，3230，3510，3604．．．助手WTRU360, 360A, 360B, 360C, 360E, 360F, 704, 778, 1320, 1404, 1522, 1714, 1950, 2050, 2430, 2530, 2630, 2730, 2810, 2910, 3060, 3110, 3230, 3510, 3604. . . Assistant WTRU

722．．．部分RLC722. . . Partial RLC

760，768．．．PHY760,768. . . PHY

774．．．直接路徑774. . . Direct path

776．．．傳統無線電鏈路776. . . Traditional radio link

777，3402，3404，3406，3408，3410，3412，3414，3416，3418，3420，3424，3426，3428，3430，3432，3434，3436，3438，3440，3442．．．XL777, 3402, 3404, 3406, 3408, 3410, 3412, 3414, 3416, 3418, 3420, 3424, 3426, 3428, 3430, 3432, 3434, 3436, 3438, 3440, 3442. . . XL

800，3355．．．流程圖800,3355. . . flow chart

900．．．標頭900. . . Header

902，904，1108，1110．．．R1欄位902,904,1108,1110. . . R1 field

906．．．RF906. . . RF

908．．．FI欄位908. . . FI field

910．．．擴展位元欄位910. . . Extended bit field

914，1102，1202．．．SN914, 1102, 1202. . . SN

916．．．LSF916. . . LSF

918，920．．．SO欄位918,920. . . SO field

1000．．．RLC STATUS PDU1000. . . RLC STATUS PDU

1002．．．D/C1002. . . D/C

1004．．．CPT1004. . . CPT

1008．．．H_SN欄位1008. . . H_SN field

1010．．．填充1010. . . filling

1100，1200，1411，1412，1413，1414，1501，1502，1503．．．RLC PDU1100, 1200, 1411, 1412, 1413, 1414, 1501, 1502, 1503. . . RLC PDU

1104．．．E2位元1104. . . E2 bit

1204，1206，1208，1210．．．位元1204, 1206, 1208, 1210. . . Bit

1310，1311，1312，1313，1314，1315，1316，1317，1415，1416．．．PDU1310, 1311, 1312, 1313, 1314, 1315, 1316, 1317, 1415, 1416. . . PDU

1602．．．R欄位1602. . . R field

1604．．．LCID欄位1604. . . LCID field

1606．．．開/關欄位1606. . . On/off field

1702，1704，1706，1708，1902，1904，1906，1908，2002，2004，2006，2008．．．TRL邏輯頻道1702, 1704, 1706, 1708, 1902, 1904, 1906, 1908, 2002, 2004, 2006, 2008. . . TRL logical channel

1710，1712，1910，1912，2010，2012．．．XL邏輯頻道1710, 1712, 1910, 1912, 2010, 2012. . . XL logical channel

1718，1720．．．邏輯頻道組1718, 1720. . . Logical channel group

1802．．．XL TB1802. . . XL TB

1804．．．TRL TB1804. . . TRL TB

1806，1810．．．MAC標頭1806, 1810. . . MAC header

1808．．．BSR1808. . . BSR

1812．．．TBSR1812. . . TBSR

1814．．．MAC控制元素1814. . . MAC control element

1914，1916，1918，1920，1922，1924．．．UL緩衝器1914, 1916, 1918, 1920, 1922, 1924. . . UL buffer

2014，2016．．．DL緩衝器2014, 2016. . . DL buffer

2508，2608，2706，3010．．．XUL排程器2508, 2608, 2706, 3010. . . XUL scheduler

2806，2904，3106．．．XDL排程器2806, 2904, 3106. . . XDL scheduler

3440．．．胞元3440. . . Cell

3460，3470，3480，3490．．．頻率重新使用組3460, 3470, 3480, 3490. . . Frequency reuse group

3500A，3500B，3600A，3600B．．．信號圖3500A, 3500B, 3600A, 3600B. . . Signal diagram

3502，3702．．．鄰居搜索WTRU3502,3702. . . Neighbor search WTRU

3504，3704．．．鄰居存在WTRU3504, 3704. . . Neighbor presence WTRU

3514，3516．．．RRC連接3514, 3516. . . RRC connection

BSR．．．緩衝器狀態報告BSR. . . Buffer status report

BW．．．資源分配BW. . . Resource allocation

C-RNTI．．．胞元無線電網路臨時識別字C-RNTI. . . Cell radio network temporary identification word

CPT．．．控制PDU類型CPT. . . Control PDU type

D/C．．．資料控制指示D/C. . . Data control instruction

DL．．．下鏈DL. . . Down chain

DMRS．．．解調變參考信號DMRS. . . Demodulation variable reference signal

DZ．．．資料區DZ. . . Data area

FI．．．成框資訊FI. . . Framed information

GPS．．．全球定位系統GPS. . . Global Positioning System

HDSN，SN．．．序列號HDSN, SN. . . serial number

ID．．．胞元ID. . . Cell

LCID．．．邏輯頻道識別LCID. . . Logical channel identification

LSF．．．最後分段標誌LSF. . . Final segmentation flag

LTE-A．．．高級長期演進LTE-A. . . Advanced long-term evolution

MAC．．．媒體存取控制MAC. . . Media access control

MME．．．行動性管理閘道MME. . . Mobile management gateway

NCZ．．．普通控制區NCZ. . . Ordinary control area

NDIT．．．鄰居發現初始傳輸NDIT. . . Neighbor discovery initial transmission

NDRT．．．鄰居發現響應傳輸NDRT. . . Neighbor discovery response transmission

PDN．．．封包資料網路PDN. . . Packet data network

PDCP．．．封包資料控制協議PDCP. . . Packet data control protocol

PDSCH．．．實體下鏈共用頻道PDSCH. . . Physical downlink shared channel

PDU．．．協定資料單元PDU. . . Agreement data unit

PHR．．．功率餘量報告PHR. . . Power headroom report

PHY．．．實體層PHY. . . Physical layer

PUCCH．．．實體UL控制頻道PUCCH. . . Physical UL Control Channel

PUSCG．．．實體UL共用頻道PUSCG. . . Entity UL shared channel

PSTN．．．公共交換電話網路PSTN. . . Public switched telephone network

RAN．．．無線電存取網路RAN. . . Radio access network

RACH．．．隨機存取頻道RACH. . . Random access channel

RF．．．分段指示RF. . . Segmentation indication

RLC．．．無線電鏈路控制RLC. . . Radio link control

S1，X2．．．介面S1, X2. . . interface

SO．．．分段偏移SO. . . Segment offset

TB．．．資料傳輸塊TB. . . Data transfer block

TBSR．．．UL BSRTBSR. . . UL BSR

TMSI．．．臨時行動用戶識別TMSI. . . Temporary action user identification

TRL．．．傳統無線電鏈路TRL. . . Traditional radio link

TTI．．．傳輸時間間隔TTI. . . Transmission time interval

UCZ．．．末排程控制區UCZ. . . Terminal scheduling area

UL．．．上鏈UL. . . Winding

UL-SCH．．．UL服務頻道UL-SCH. . . UL Service Channel

WTRU．．．無線傳輸/接收單元WTRU. . . Wireless transmission/reception unit

XCCCH．．．XL通用控制頻道XCCCH. . . XL Universal Control Channel

XCCH．．．XL通用頻道XCCH. . . XL Universal Channel

XDBSR．．．XL DL BSRXDBSR. . . XL DL BSR

XDCCH．．．XL專用控制頻道XDCCH. . . XL dedicated control channel

XDL．．．交叉鏈路DLXDL. . . Cross link DL

XDL-SCH．．．XDL排程頻道XDL-SCH. . . XDL scheduling channel

XDPHR．．．DL功率餘量報告XDPHR. . . DL power headroom report

XDSR．．．XDL排程請求XDSR. . . XDL scheduling request

XDTCH．．．XL專用業務頻道XDTCH. . . XL dedicated business channel

XL．．．交叉鏈路XL. . . Cross link

XLG．．．XL授權XLG. . . XL authorization

XPACH．．．XL實體存取頻道XPACH. . . XL entity access channel

XPCCH．．．XL實體控制頻道XPCCH. . . XL entity control channel

XPCH．．．XL傳呼頻道XPCH. . . XL paging channel

XPDACH．．．XL實體DL關聯頻道XPDACH. . . XL entity DL associated channel

XPDCCH．．．XL實體DL控制頻道XPDCCH. . . XL entity DL control channel

XPDDCH．．．XL實體DL資料頻道XPDDCH. . . XL entity DL data channel

XPDFBCH．．．XL實體DL回饋頻道XPDFBCH. . . XL entity DL feedback channel

XPDSACH．．．XL實體DL共用存取頻道XPDSACH. . . XL entity DL shared access channel

XPDSCH．．．XDL共用頻道XPDSCH. . . XDL shared channel

XPGCH．．．XL實體授權頻道XPGCH. . . XL entity authorized channel

XPNDCH．．．XL實體鄰居發現頻道XPNDCH. . . XL entity neighbor discovery channel

XPUACH．．．XL實體UL關聯頻道XPUACH. . . XL entity UL associated channel

XPUCCH．．．XL實體UL控制頻道XPUCCH. . . XL entity UL control channel

XPUDCH．．．XL實體UL資料頻道XPUDCH. . . XL entity UL data channel

XPUFBCH．．．XL實體UL回饋頻道XPUFBCH. . . XL entity UL feedback channel

XPUSCH．．．XUL共用頻道XPUSCH. . . XUL shared channel

XSACH．．．XL慢存取頻道XSACH. . . XL slow access channel

XSR．．．XL排程請求XSR. . . XL schedule request

XUL．．．交叉ULXUL. . . Cross UL

XUL-SCH．．．XUL排程頻道XUL-SCH. . . XUL scheduling channel

XUPHR．．．XUL功率餘量報告XUPHR. . . XUL Power Headroom Report

XUSR．．．XUL排程請求XUSR. . . XUL scheduling request

可以從下述結合附圖以示例的方式給出的詳細描述中得到更詳細的理解，其中：
第1A圖是在其中一個或多個公開的實施方式可得以實現的示例通訊系統的系統圖；
第1B圖是可在第1A圖所示的通訊系統中使用的示例無線傳輸/接收單元（WTRU）的系統圖；
第1C圖是可在第1A圖所示的通訊系統中使用的示例無線電存取網路和示例核心網路的系統圖；
第2圖是LTE-A中繼系統的系統圖；
第3圖是用於第2圖的LTE-A中繼系統的層2堆疊的方塊圖；
第4圖是示例交叉鏈路（XL）實體層（PHY）訊框結構的圖；
第5圖是將不同XL實體頻道多工為不同類型的XL子訊框的不同可能性的示例的圖；
第6A圖、第6B圖、第6C圖和第6D圖是在XL上邏輯、傳輸和實體頻道之間的示例頻道映射的圖；
第7A圖是用於AT系統的層2堆疊的方塊圖；
第7B圖是用於其中分開的資料無線電承載（DRB）被設定以分別藉由直接路徑和中繼路徑攜帶資料的實施方式的示例系統架構的圖；
第8圖是丟棄在下鏈上助手WTRU（helper WTRU）處延誤（stalled）資料的方法的流程圖；
第9圖是助手WTRU可用來在第一躍程（hop）無線電鏈路控制（RLC）未應答模式（UM）協定資料單元（PDU）上執行重新分段的RLC UM分段的標頭的圖；
第10圖是可被用來在RLC應答（AM）模式中在第二躍程上攜帶最高丟棄序列號（HDSN）的RLC STATUS PDU的圖；
第11圖和第12圖是具有擴展（E2）位元和可選LT欄位的示例RLC PDU的圖；
第13圖是在助手WTRU處RLC PDU丟棄的示例程序的圖；
第14A圖和第14B圖包括在RLC AM模式中助手WTRU處行動接收（Rx）視窗的示例程序的圖；
第15A圖和第15B圖包括當HDSN丟失時在助手WTRU處行動Rx視窗的示例程序的圖；
第16圖是用於在傳統無線電鏈路（TRL）上鏈（UL）上攜帶流量資訊的示例MAC控制元素的圖；
第17圖是在XL上邏輯頻道至TRL上邏輯頻道之間的示例映射的圖；
第18圖是顯示交叉UL（XUL）共用頻道上緩衝器狀態報告（BSR）到TRL UL服務頻道（UL-SCH）上的UL BSR（TBSR）的示例轉換的圖；
第19圖是圖示在用於AT應用的覆蓋擴展模式中UL TBSR的示例傳輸的圖；
第20圖是圖示在AT應用中覆蓋擴展模式中下鏈（DL）BSR的示例傳輸的圖；
第21圖是在無線電資源控制（RRC）連接模式中的終端WTRU使用TBSR將XUL排程請求發送給eNB的方法的流程圖；
第22圖是在RRC連接模式中的終端WTRU使用XL排程請求（XUSR）將XUL排程請求發送給eNB的方法的流程圖；
第23圖是助手WTRU使用TRL實體UL控制頻道（PUCCH）和TRL UL-SCH兩者將XUSR中繼給eNB的方法的流程圖；
第24圖是助手WTRU僅使用UL-SCH將XUSR中繼給eNB的方法的流程圖；
第25圖是助手WTRU使用XUSR媒體存取控制（MAC）控制元素在TRUL UL-SCH上將XUSR中繼給eNB的方法的流程圖；
第26圖是助手WTRU使用最小TBSR MAC控制元素在TRL UL-SCH上將XUSR中繼給eNB的方法的流程圖；
第27圖是助手WTRU在TRL PUCCH上將XUSR中繼給eNB的方法的流程圖；
第28圖是助手WTRU使用XDSR MAC控制元素在TRL UL-SCH上將XL DL排程請求（XDSR）發送給eNB的方法的流程圖；
第29圖是助手WTRU在TRL PUCCH上將XDSR發送給eNB的方法的流程圖；
第30圖是當TRL UL授權可用時將TBSR發送給eNB的方法的信號圖；
第31圖是報告XL DL BSR（XDBSR）的方法的信號圖；
第32圖是在TRL UL-SCH上將XL DL功率餘量報告（XDPHR）和XUPHR發送給eNB的方法的信號圖；
第33A圖是在胞元中助手WTRU和終端WTRU的系統的圖；
第33B圖是在WTRU和另一個WTRU間無線電XL上無線電資源排程的示例方法的流程圖；
第34圖是其中在胞元中的XL被佈置為頻率重新使用組的胞元的圖；
第35A圖和第35B圖包括在容量模式中示例初始授權獲取程序和更新XLG操作的信號圖；
第36A圖和第36B圖包括在容量模式中另一個示例初始授權獲取程序和更新XLG操作的信號圖；以及
第37A圖和第37B圖包括在覆蓋模式中示例初始授權獲取和繼續XLG更新程序的信號圖。

A more detailed understanding can be obtained from the detailed description given below by way of example with reference to the accompanying drawings, in which:
1A is a system diagram of an example communication system in which one or more of the disclosed embodiments can be implemented;
Figure 1B is a system diagram of an example wireless transmit/receive unit (WTRU) that can be used in the communication system shown in Figure 1A;
1C is a system diagram of an example radio access network and an example core network that can be used in the communication system shown in FIG. 1A;
Figure 2 is a system diagram of the LTE-A relay system;
Figure 3 is a block diagram of a layer 2 stack for the LTE-A relay system of Figure 2;
Figure 4 is a diagram of an example cross-link (XL) physical layer (PHY) frame structure;
Figure 5 is a diagram of an example of different possibilities for multiplexing different XL physical channels into different types of XL subframes;
6A, 6B, 6C, and 6D are diagrams of example channel mappings between logic, transmission, and physical channels on the XL;
Figure 7A is a block diagram of a layer 2 stack for an AT system;
Figure 7B is a diagram of an example system architecture for an embodiment in which separate data radio bearers (DRBs) are set to carry data by direct path and relay path, respectively;
Figure 8 is a flow diagram of a method of discarding stalled data at a helper WTRU at the downlink;
Figure 9 is a diagram of a header of a RLC UM segment that the helper WTRU may use to perform re-segmentation on a first hop Radio Link Control (RLC) Unacknowledged Mode (UM) Protocol Data Unit (PDU). ;
Figure 10 is a diagram of an RLC STATUS PDU that can be used to carry the highest dropped sequence number (HDSN) on the second hop in the RLC Answer (AM) mode;
11 and 12 are diagrams of example RLC PDUs with extended (E2) bits and optional LT fields;
Figure 13 is a diagram of an example procedure for RLC PDU dropping at the assistant WTRU;
14A and 14B include diagrams of example procedures for an action receiving (Rx) window at the assistant WTRU in the RLC AM mode;
15A and 15B include diagrams of example programs that act on the Rx window at the assistant WTRU when the HDSN is lost;
Figure 16 is a diagram of an example MAC control element for carrying traffic information on a legacy radio link (TRL) uplink (UL);
Figure 17 is a diagram of an example mapping between logical channels on a XL and logical channels on a TRL;
Figure 18 is a diagram showing an example transition of a UL BSR (TBSR) on a cross-UL (XUL) shared channel buffer status report (BSR) to a TRL UL service channel (UL-SCH);
Figure 19 is a diagram illustrating an example transmission of a UL TBSR in a coverage extension mode for an AT application;
20 is a diagram illustrating an example transmission of a lower-chain (DL) BSR in an extended mode in an AT application;
21 is a flowchart of a method for a terminal WTRU to transmit a XUL scheduling request to an eNB using a TBSR in a Radio Resource Control (RRC) connected mode;
Figure 22 is a flowchart of a method for a terminal WTRU to transmit a XUL scheduling request to an eNB using an XL Scheduling Request (XUSR) in an RRC connected mode;
Figure 23 is a flow diagram of a method for a facilitating WTRU to relay XUSR to an eNB using both a TRL entity UL Control Channel (PUCCH) and a TRL UL-SCH;
Figure 24 is a flow diagram of a method for a facilitating WTRU to relay XUSR to an eNB using only UL-SCH;
Figure 25 is a flow diagram of a method for a facilitating WTRU to relay XUSR to an eNB on a TRUL UL-SCH using a XUSR Medium Access Control (MAC) control element;
Figure 26 is a flow diagram of a method for a facilitating WTRU to relay XUSR to an eNB on a TRL UL-SCH using a minimum TBSR MAC Control Element;
Figure 27 is a flow diagram of a method for a facilitating WTRU to relay XUSR to an eNB on a TRL PUCCH;
Figure 28 is a flow diagram of a method for a facilitating WTRU to send an XL DL Scheduling Request (XDSR) to an eNB on a TRL UL-SCH using an XDSR MAC Control Element;
Figure 29 is a flow diagram of a method for a facilitating WTRU to transmit an XDSR to an eNB on a TRL PUCCH;
Figure 30 is a signal diagram of a method of transmitting a TBSR to an eNB when a TRL UL grant is available;
Figure 31 is a signal diagram of a method of reporting an XL DL BSR (XDBSR);
Figure 32 is a signal diagram of a method of transmitting an XL DL Power Headroom Report (XDPHR) and XUPHR to an eNB on a TRL UL-SCH;
Figure 33A is a diagram of a system of assistant WTRUs and terminal WTRUs in a cell;
Figure 33B is a flow diagram of an example method of radio resource scheduling on a radio XL between a WTRU and another WTRU;
Figure 34 is a diagram in which the XL in the cell is arranged as a cell of the frequency reuse group;
35A and 35B include signal diagrams illustrating an initial authorization acquisition procedure and an update XLG operation in a capacity mode;
36A and 36B include signal diagrams of another example initial authorization acquisition procedure and update XLG operation in capacity mode; and 37A and 37B include example initial authorization acquisition and continuation XLG update procedures in overlay mode Signal map.

於第1A圖在其中一個或多個公開的實施方式可得以實施的示例通訊系統100的圖。通訊系統100可以是向多個無線使用者提供諸如語音、資料、視訊、消息、廣播等這樣的內容的多存取系統。通訊系統100可使多個無線使用者能夠藉由共用包括無線帶寬的系統資源來存取這樣的內容。例如，通訊系統100可採用一個或多個頻道存取方法，例如分碼多重存取（CDMA）、分時多重存取（TDMA）、分頻多重存取（FDMA）、正交FDMA（OFDMA）、單載波FDMA（SC-FDMA）等。
如第1A圖所示，通訊系統100可包括無線傳輸/接收單元（WTRU）102a、102b、102c、102d、無線電存取網路（RAN）104、核心網路106、公共交換電話網路（PSTN）108、網際網路110和其他網路112，但是將理解公開的實施方式設想任意數目的WTRU、基地台、網路和/或網路元件。WTRU 102a、102b、102c、102d的每一個可以是任意類型的、被配置為在無線環境中操作和/或通訊的裝置。以示例的方式，WTRU 102a、102b、102c、102d可被配置為發送和/或接收無線信號，並且可包括使用者裝置（UE）、行動站、固定或行動使用者單元、傳呼機、蜂巢式電話、個人數位助理（PDA）、智慧型電話、膝上型電腦、隨身型易網機、個人電腦、無線感測器、消費電子產品等。
通訊系統100還可包括基地台114a和基地台114b。基地台114a、114b的每一個可以是任意類型的、被配置為與WTRU 102a、102b、102c、102d的至少一個形成無線介面以便於存取一個或多個諸如核心網路106、網際網路110和/或網路112這樣的通訊網路的裝置。以示例的方式，基地台114a、114b可以是基地台收發器站（BTS）、節點B、e節點B、家用節點B、家用e節點B、站點控制器、存取點（AP）、無線路由器等。雖然基地台114a、114b每一個被描繪為單一元件，應理解基地台114a、114b可包括任意數目的互連基地台和/或網路元件。
基地台114a可以是RAN 104的一部分，RAN 104還可包括其他基地台和/或網路元件（未顯示），例如基地台控制器（BSC）、無線電網路控制器（RNC）、中繼節點等。基地台114a和/或基地台114b可被配置為在可被稱為胞元（未顯示）的特定地理區域內發送和/或接收無線信號。胞元可進一步被劃分為胞元扇區。例如，與基地台114a相關聯的胞元可被劃分為3個扇區。因此，在一個實施方式中，基地台114a可包括3個收發器，即胞元的每個扇區一個。在另一個實施方式中，基地台114a可採用多輸入多輸出（MIMO）技術，因此可為胞元的每個扇區使用多個收發器。
基地台114a、114b可藉由空氣介面116與WTRU 102a、102b、102c、102d的一個或多個通訊，空氣介面116可以是任意適當的無線通訊鏈路（例如無線電頻率（RF）、微波、紅外線（IR）、紫外線（UV）、可見光等）。空氣介面116可使用任意適當的無線電存取技術（RAT）來建立。
更具體地，如上所述，通訊系統100可以是多存取系統，並且可採用一個或多個頻道存取方案，例如CDMA、TDMA、FDMA、OFDMA、SC-FDMA等。例如，RAN 104中的基地台114a和WTRU 102a、102b、102c可實現諸如通用行動通訊系統（UMTS）陸地無線電存取（UTRA）這樣的無線電技術，其可使用寬頻CDMA（WCDMA）來建立空氣介面116。WCDMA可包括諸如高速封包存取（HSPA）和/或演進型HSPA（HSPA+）這樣的通訊協議。HSPA可包括高速下鏈封包存取（HSDPA）和/或高速上鏈封包存取（HSUPA）。
在另一個實施方式中，基地台114a和WTRU 102a、102b、102c可實現諸如演進UMTS陸地無線電存取（E-UTRA）這樣的無線電技術，其可使用長期演進（LTE）和/或高級LTE（LTE-A）來建立空氣介面116。
在其他實施方式中，基地台114a和WTRU 102a、102b、102c可實現諸如IEEE 802.16（即全球互通微波存取（WiMAX））、CDMA2000、CDMA2000 1X、CDMA2000 EV-DO、臨時標準2000（IS-2000）、臨時標準95（IS-95）、臨時標準856（IS-856）、全球行動通訊系統（GSM）、增強型資料速率GSM演進技術（EDGE）、GSM EDGE（GERAN）等這樣的無線電技術。
第1A圖中的基地台114b可以是例如無線路由器、家用節點B、家用e節點B或存取點，並且可使用任意適當的RAT以促進局部區域中的無線連接性，例如商業地點、家庭、車輛、校園等。在一個實施方式中，基地台114b和WTRU 102c、102d可實現諸如IEEE 802.11這樣的無線電技術，以建立無線局域網路（WLAN）。在另一個實施方式中，基地台114b和WTRU 102c、102d可實現諸如IEEE 802.15這樣的無線電技術，以建立無線個人區域網路（WPAN）。仍然在另一個實施方式中，基地台114b和WTRU 102c、102d可使用基於胞元的RAT（例如WCDMA、CDMA2000、GSM、LTE、LTE-A等）來建立微微胞元（picocell）或毫微微胞元（femtocell）。如第1A圖所示，基地台114b可與網際網路110有直接連接。因此，基地台114b不需要經由核心網路106存取網際網路110。
RAN 104可與核心網路106通訊，核心網路106可以是任意類型的、被配置為向WTRU 102a、102b、102c、102d的一個或多個提供語音、資料、應用和/或藉由網際協定的語音（VoIP）服務的網路。例如，核心網路106可提供呼叫控制、計費服務、基於行動位置的服務、預付費呼叫、網際網路連接、視訊發佈等，和/或執行諸如使用者認證這樣的高級安全功能。雖然未在第1A圖中顯示，應理解RAN 104和/或核心網路106可與採用與RAN 104相同RAT或不同RAT的其他RAN直接或間接通訊。例如，除了與可採用E-UTRA無線電技術的RAN 104連接之外，核心網路106還可與採用GSM無線電技術的另一個RAN（未顯示）通訊。
核心網路106還可作為閘道，用於WTRU 102a、102b、102c、102d存取PSTN 108、網際網路110和/或其他網路112。PSTN 108可包括提供普通老式電話服務（POTS）的電路交換電話網路。網際網路110可包括使用通用通訊協定的互連電腦網路和裝置的全球系統，例如TCP/IP網際協定族中的傳輸控制協定（TCP）、使用者資料報協定（UDP）和網際協定（IP）。網路112可包括由其他服務供應商所有和/或操作的有線或無線通訊網路。例如，網路112可包括與可採用與RAN 104相同RAT或不同RAT的一個或多個RAN相連接的另一個核心網路。
在通訊系統100中的WTRU 102a、102b、102c、102d的一些或所有可包括多模式能力，即WTRU 102a、102b、102c、102d可包括用於藉由不同無線鏈路與不同無線網路通訊的多個收發器。例如，第1A圖中顯示的WTRU 102c可被配置為與可採用基於胞元的無線電技術的基地台114a和與可採用IEEE 802無線電技術的基地台114b通訊。
第1B圖是示例WTRU 102的系統圖。如第1B圖所示，WTRU 102可包括處理器118、收發器120、傳輸/接收元件122、揚聲器/麥克風124、鍵盤126、顯示器/觸控板128、不可移除記憶體130、可移除記憶體132、電源134、全球定位系統（GPS）晶片組136和其他週邊裝置138。應理解，WTRU 102可包括前述元件的任意子組合，而與實施方式保持一致。
處理器118可以是通用處理器、專用處理器、常規處理器、數位信號處理器（DSP）、多個微處理器、與DSP核心相關聯的一個或多個微處理器、控制器、微控制器、專用積體電路（ASIC）、現場可程式化閘陣列（FPGA）電路、任意其他類型的積體電路（IC）、狀態器等。處理器118可執行信號編碼、資料處理、功率控制、輸入/輸出處理和/或使WTRU 102能夠在無線環境中操作的任意其他功能。處理器118可與收發器120相耦合，收發器120可與傳輸/接收元件122相耦合。雖然第1B圖將處理器118和收發器120圖示為分開的部件，將理解處理器118和收發器120可一起集成在電子封裝或晶片中。
傳輸/接收元件122可被配置為藉由空氣介面116向基地台（例如基地台114a）發送或從基地台接收信號。例如，在一個實施方式中，傳輸/接收元件122可以是被配置為發送和/或接收RF信號的天線。在另一個實施方式中，傳輸/接收元件122可以是被配置為例如發送和/或接收IR、UV或可見光信號的傳輸器/偵測器。在另一個其他實施方式中，傳輸/接收元件122可以被配置為發送和接收RF和光信號兩者。將理解，傳輸/接收元件122可被配置為發送和/或接收無線信號的任意組合。
此外，雖然傳輸/接收元件122在第1B圖中被描繪為單一元件，WTRU 102可包括任意數目的傳輸/接收元件122。更具體地，WTRU 102可採用MIMO技術。因此，在一個實施方式中，WTRU 102可包括兩個或更多個用於藉由空氣介面116發送和接收無線信號的傳輸/接收元件122（例如多個天線）。
收發器120可被配置為調變即將由傳輸/接收元件122發送的信號並解調變由傳輸/接收元件122接收的信號。如上所述，WTRU 102可具有多模式能力。因此，收發器120可包括例如用於使WTRU 102能夠經由諸如UTRA和IEEE 802.11這樣的多個RAT通訊的多個收發器。
WTRU 102的處理器118可與揚聲器/麥克風124、鍵盤126和/或顯示器/觸控板128（例如液晶顯示（LCD）顯示單元或有機發光二極體（OLED）顯示單元）相耦合，並可從它們接收使用者輸入資料。處理器118還可以向揚聲器/麥克風124、鍵盤126和/或顯示器/觸控板128輸出使用者資料。此外，處理器118可從諸如不可移除記憶體130和/或可移除記憶體132這樣的任意類型的適當記憶體存取資訊，並將資料儲存在其中。不可移除記憶體130可包括隨機存取記憶體（RAM）、唯讀記憶體（ROM）、硬碟或任意其他類型的記憶體裝置。可移除記憶體132可包括使用者身份模組（SIM）卡、記憶棒、安全數位（SD）記憶卡等。在其他實施方式中，處理器118可從實體上不位於WTRU 102上（例如在伺服器或家用電腦（未示出）上）的記憶體存取資訊，並將資料儲存在其中。
處理器118可從電源134接收電力，並可被配置為分配和/或控制給WTRU 102中其他元件的電力。電源134可以是任意適當的用於向WTRU 102供電的裝置。例如，電源134可包括一個或多個乾電池（鎳鎘（NiCd）、鎳鋅（NiZn）、鎳金屬氫化物（NiMH）、鋰離子（Li-ion）等）、太陽能電池、燃料電池等。
處理器118還可以與可被配置為提供關於WTRU 102目前位置的位置資訊（例如經度和緯度）的GPS晶片組136相耦合。附加於或替代來自GPS晶片組136的資訊，WTRU 102可藉由空氣介面116從基地台（例如基地台114a、114b）接收位置資訊，和/或基於信號從兩個或更多個附近基地台接收的定時來確定它的位置。將理解，WTRU 102可借助任何適當的位置確定方法來獲取位置資訊而與實施方式保持一致。
處理器118可進一步與其他週邊裝置138相耦合，其他週邊裝置138可包括提供附加特徵、功能和/或有線或無線連接的一個或多個軟體和/或硬體模組。例如，週邊裝置138可包括加速計、電子羅盤、衛星收發器、數位照相機（用於相片或視訊）、通用串列匯流排（USB）埠、振動裝置、電視收發器、免持耳機、藍芽R模組、調頻（FM）無線電單元、數位音樂播放器、媒體播放器、電視遊樂器模組、網際網路瀏覽器等。
第1C圖是根據實施方式的RAN 104和核心網路106的系統圖。如上所述，RAN 104可採用E-UTRA無線電技術來藉由空氣介面116與WTRU 102a、102b、102c通訊。RAN 104還與核心網路106通訊。
RAN 104可包括e節點B 140a、140b、140c，但將理解RAN 104可包括任意數目的e節點B而與實施方式保持一致。e節點B 140a、140b、140c每一個可包括用於藉由空氣介面116與WTRU 102a、102b、102c通訊的一個或多個收發器。在一個實施方式中，e節點B 140a、140b、140c可實施MIMO技術。因此e節點B 140a例如可使用多個天線來向WTRU 102a發送無線信號並從它接收無線信號。
e節點B 140a、140b、140c的每一個可與特定的胞元（未顯示）相關聯，並且可被配置為處理無線電資源管理決策、切換決策、在上鏈和/或下鏈中的使用者排程等。如第1C圖所示，e節點B 140a、140b、140c可在X2介面上互相通訊。
第1C圖中顯示的核心網路106可包括行動性管理閘道（MME）142、服務閘道144和封包資料網路（PDN）閘道146。雖然上述元件每一個被圖示為核心網路106的一部分，但將理解這些元件的任意一個可由除核心網路操作者以外的實體所有和/或操作。
MME 142可經由S1介面與RAN 104中的e節點B 142a、142b、142c的每一個相連接，並且可作為控制節點。例如，MME 142可負責認證WTRU 102a、102b、102c的使用者、承載啟動/去啟動、在WTRU 102a、102b、102c初始附著期間選取特定的服務閘道等。MME 142還可提供用於在RAN 104和採用諸如GSM或WCDMA這樣的其他無線電技術的其他RAN（未顯示）之間切換的控制平面功能。
服務閘道144可經由S1介面與RAN 104中的e節點B 140a、140b、140c的每一個相連接。服務閘道144一般地可路由和轉發至/來自WTRU 102a、102b、102c的使用者資料封包。服務閘道144還可以執行其他功能，例如在e節點B間切換期間錨定使用者平面、當下鏈資料對WTRU 102a、102b、102c可用時觸發傳呼、管理和儲存WTRU 102a、102b、102c的上下文等。
服務閘道144還可與PDN閘道146相連接，PDN閘道146可向WTRU 102a、102b、102c提供到諸如網際網路110這樣的封包交換網路的存取，以便於WTRU 102a、102b、102c和IP啟動裝置之間的通訊。
核心網路106可便於與其他網路的通訊。例如，核心網路106可向WTRU 102a、102b、102c提供到諸如PSTN 108這樣的電路交換網路的存取，以便於WTRU 102a、102b、102c和傳統陸線通訊裝置之間的通訊。例如，核心網路106可包括作為核心網路106和PSTN 108之間的介面的IP閘道（例如IP多媒體子系統（IMS）伺服器）或與之通訊。此外，核心網路106可向WTRU 102a、102b、102c提供到網路112的存取，網路112可包括由其他服務供應商所有和/或操作的其他有線或無線網路。
第2圖是LTE-A中繼系統200的系統圖。圖示的LTE-A中繼系統包括供應胞元202、中繼節點204和終端WTRU 206。供應胞元202和中繼節點204藉由回載鏈路208互相通訊。中繼節點204和終端WTRU 206藉由存取鏈路210互相通訊。中繼節點204可被配置為在供應胞元202和終端WTRU 206之間中繼PDCP服務資料單元（SDU）。回載鏈路208和存取鏈路210可完全互相獨立地操作。
第3圖是用於第2圖的LTE-A中繼系統200的層2（L2）堆疊300的方塊圖。如上所述，回載鏈路208和每個存取鏈路210具有它們自己的完整L2堆疊，包括完整的MAC、RLC和PDCP層，其全部在供應胞元202、中繼節點204和終端WTRU 206處終止。因此，在第3圖所示的實施方式中，供應胞元302包括MAC層314、RLC層312和PDCP層310，並且終端WTRU 306類似地包括PDCP層340、RLC層342和MAC層344。供應胞元302的PDCP層310與中繼節點304的PDCP層320通訊，供應胞元302的RLC層312與中繼節點304的RLC層322通訊，供應胞元302的MAC層314與中繼節點304的MAC層324通訊，終端WTRU 306的PDCP層340與中繼節點304的PDCP層326通訊，終端WTRU 306的RLC層342與中繼節點304的RLC層328通訊，並且終端WTRU 306的MAC層344與中繼節點304的MAC層330通訊。
為了操作在RLC應答模式（AM）中的類型1中繼節點的切換，源中繼節點可經由源和目標供應eNB將任意未發送的PDCP SDU轉發給目標中繼節點，以便實現無損切換。假設大多數業務量是基於傳輸控制協議（TCP）的並且TCP協議應當提供足夠的流量控制能力，流量控制不能與目前的LTE類型1中繼配置一起應用。
在LTE中，如果PDCP SDU在傳送緩衝器中太長時間，則PDCP SDU丟棄可被用來清除PDCP SDU。這可減少當PDCP SDU緩衝器裝滿由例如可能的實體鏈路錯誤引起的延誤資料時後續資料的延遲。當PDCP SDU進入PDCP緩衝器時，與它相關聯的丟棄計時器可開始。當該計時器期滿時，如果沒有SDU的片段已映射到RLC PDU，該PDCP SDU被丟棄。丟棄計時器的超時值可由較高層來配置。
另外，在LTE中，排程由在網路側的eNB來完成。UL排程決策要求WTRU向eNB發送MAC狀態報告。例如，WTRU可在該WTRU想要發起UL資料傳輸的情況下發送UL排程請求（ULSR）。另一個示例，WTRU還可為在該WTRU處的每個邏輯頻道組發送緩衝器狀態報告（BSR）。另一個示例，WTRU可發送在該WTRU處測量的功率餘量報告（PHR）。ULSR經由實體上鏈控制頻道（PUCCH）或藉由隨機存取頻道（RACH）程序發送。BSR和PHR在UL服務頻道（UL-SCH）上藉由MAC控制元素發送。
另外，在LTE中，排程是依賴於頻道的，並且由eNB執行，以便以每傳輸時間間隔（TTI）為基礎為UL和下鏈（DL）資料頻道動態地分配資源。資源分配的粒度（granularity）實現於資源塊（RB），資源塊是佔用一個TTI期間的12個連續子載波的叢集。LTE排程在DL和UL兩者中應用正交多址以確保與相同胞元相關聯的WTRU在任意給定TTI中無胞元內干擾地使用正交資源。此外，在指派的資源上每個TTI的UL傳輸功率藉由UL功率控制來調整。
在嘗試最佳化性能度量集合中，LTE排程演算法通常考慮輸入參數的範圍，該集合可包括例如最大/平均/最小吞吐量、最大/平均/最小延遲、總/每使用者頻譜效率和中斷概率（outage probability）。使用者體驗直接地受上述性能度量的影響。典型的輸入參數包括服務類型識別字的品質（QCI）、頻道品質指示符（CQI）、BSR、應答/非應答（ACK/NACK）和資源分配歷史。
如上所述，排程被應用在傳統下鏈（TRDL）和傳統上鏈（TRUL）上。TRDL是從eNB到與該eNB相關聯的WTRU的無線電存取鏈路。它應用於與網路相關聯的所有WTRU，並在標準化LTE DL頻帶中操作。在TRDL上攜帶的實體頻道包括實體下鏈共用頻道（PDSCH）、實體廣播頻道（PBCH）、實體多播頻道（PMCH）、實體控制格式指示符頻道（PFICH）和實體混合自動重複請求（HARQ）指示符頻道（PHICH）。TRDL還攜帶包括參考和同步信號的實體信號。TRUL是從WTRU到服務eNB的無線電存取鏈路。它應用於與網路相關聯的所有WTRU，並且在標準化的LTE UL頻帶中操作。在TRUL上攜帶的實體頻道包括實體UL共用頻道（PUSCH）、實體UL控制頻道（PUCCH）和實體隨機存取頻道（PRACH）。TRUL還攜帶參考信號。
TRDL/TRUL排程資訊在攜帶在每個TTI的DL PDCCH中的裝置類型識別字（DCI）格式的幫助下被傳輸給每個WTRU。DL排程在接收到DL DCI的相同子訊框中生效。然而，UL授權在接收到UL DCI的子訊框後的若干子訊框中生效（例如在LTE頻分雙工（FDD）系統中是4個子訊框）。
LTE網路具有對每個TTI中每個TRDL/TRUL對的資源分配的完全控制，並且WTRU僅提供在TRUL中傳輸DL頻道回饋和UL探測參考信號的幫助。
與使用高功率、靜止的中繼節點的上述類型1中繼節點相對照，在此描述了使用直接WTRU到WTRU通訊和/或直接基地台到基地台通訊來在網路和諸如終端WTRU或終端基地台的目的地實體之間中繼資料（“AT中繼”或“AT-R”模式）或來在WTRU或基地台之間直接傳輸資料（“AT本地卸載”或“AT-LO”模式）的高級拓撲（AT）網路的實施方式。例如，在一個實施方式中，智慧型手機或基地台可被配置為除了其主要角色外還作為你基礎設施節點，以在AT-R和/或AT-LO模式中操作。在AT-R實施方式中，終端WTRU或基地台可分別藉由被稱為助手WTRU或助手基地台的另一個WTRU或基地台來與網路交換資料。在AT-R中，任意WTRU在不同的時間可作為終端WTRU或助手WTRU，並且可使用2躍程設定來在終端WTRU和eNB間中繼資料。在2躍程設定中，第一躍程可在終端WTRU和助手WTRU之間或eNB和助手WTRU之間，並且依據傳輸在UL還是DL中，第二躍程可以是在第一躍程期間未採用的躍程。在AT-LO實施方式中，互相鄰近的WTRU可在中央網路的控制下參與彼此的直接資料通訊。雖然所有實施方式在此是關於為WTRU的中繼實體和目的地實體來描述，但是所有實施方式等同地可應用於是任意類型節點的中繼實體，例如基地台（例如eNB），和/或是任意類型的節點的目的地實體，例如基地台（例如eNB）。
AT-R實施方式可被用來增加蜂窩系統中的容量（容量模式或AT-RCap）和覆蓋（覆蓋模式或AT-RCov）。在AT-RCap中，助手WTRU可增加現有WTRU和基地台之間的無線電鏈路容量以增強網路的容量並提高資料傳輸的容量。在AT-RCov中，助手WTRU可被用來提供對不在覆蓋區中並且因此沒有到基地台的鏈路的WTRU的覆蓋。
在用於基線LTE蜂窩系統的AT-RCov中，例如，如果WTRU註冊到網路（例如它處於EMM-REGISTERED狀態），它能解碼來自網路中適當胞元的廣播頻道（BCH）並讀取主系統資訊（SI），它能解碼傳呼頻道（PCH）並讀取傳呼消息和次SI，它能使用IDLE模式中的RACH程序或CONNECTED模式中的PUCCH/PUSCH來到達胞元，並且它能分別藉由PUSCH和PDSCH傳送和接收特定最小資料速率，則它可被認為在覆蓋區中。不滿足這些條件的WTRU可被認為在覆蓋區之外，並且可繼續經歷胞元重選直到它們找到適當的胞元。同時，出於緊急呼叫的目的，它們可預占（camp on）任意可用的胞元，但是不可被傳呼。在在此描述的AT-RCov實施方式中，這樣的不在覆蓋區的WTRU（例如潛在終端WTRU）可藉由助手WTRU被提供覆蓋。然而為了利用AT-RCov，WTRU仍然必須具有網路同步和定時。
在AT-LO實施方式中，兩個鄰近的WTRU在中央網路的控制下可發起本地卸載傳輸。在一個實施方式中，鄰近的一組WTRU可被指派至具有由網路指定的叢集頭的叢集。在該實施方式中，叢集頭可與每個叢集成員直接通訊，並且可負責在該叢集中各個WTRU對之間所有交叉鏈路（XL）的存取控制和無線電資源管理（RRM）。在叢集頭的協調和控制下，叢集成員可應用直接WTRU對WTRU通訊。
WTRU對WTRU通訊可應用於許多具有顯著潛在利益的現實場景。例如，在建築物內處具有非常差覆蓋的使用者可藉由位於該建築物週邊或之外的具有良好覆蓋的助手WTRU獲得覆蓋和附加的容量。另一個示例，離得很近並且需要交換資料或具有語音會話的使用者可直接這樣做，而不需要藉由基地台和核心網路由資料/語音。例如，在辦公室中的同事可以以此方式進行會話和交換資料。直接WTRU對WTRU通訊還可藉由提供關於屬於離得很近的相同社交組的其他使用者的資訊來實現與社交聯網路相關的應用。它還可藉由直接連接使用者而不是藉由網路路由來實現具有極其低等待時間（latency）的真實無線遊戲體驗。如果多個使用者正在從網路下載類似的資訊，網路可將資料傳送給較小的使用者子集，這些使用者之後可將該資料中繼給其他終端使用者。例如，在體育場中希望觀看場地上事件的即時重播的使用者可落入該類別。在沿著高速路行駛的不同車輛中的使用者可形成直接鏈路並互相傳送資訊。一個潛在的應用可以是使事故/交通擁堵的即時通訊被中繼給在相同道路上後方更遠的車輛，以便它們可改道。
在AT-R和AT-LO實施方式中，相對於例如在傳統無線電鏈路（TRL）上發生的傳統eNB到WTRU通訊，WTRU間的通訊可發生在被稱為交叉鏈路（XL）的專用頻道中。對於AT-LO實施方式，XL可被用於一對WTRU之間的通訊，並且對於AT-R實施方式，XL可被用於助手WTRU和終端WTRU對之間的通訊。在一個實施方式中，可假設XL頻道充分地與TRL分開，使得在TRL和XL之間沒有載波間或鄰近頻道干擾發生。在此實施方式中，XL可要求分開的無線電頻率（RF）收發器鏈。然而，XL的帶內操作也是可能的。在一個實施方式中，XL資源可相對於TRL帶外地設定。類似於例如基線LTE，XL頻道可將OFDM用於它的實體層（PHY）多工處理。助手和終端WTRU可使用FDD或分時多工處理（TDD）來互相通訊，並且相關的配置可由網路來定義。在一個實施方式中，網路可為XL提供粗略的資源分配，並且WTRU（例如助手WTRU和終端WTRU的其中之一或兩者）可具有處理每TTI資源分配的自由。
第4圖是示例XL PHY訊框結構400的圖。在第4圖顯示的示例中，XL PHY訊框結構包括若干訊框（例如440和450）和相應的子訊框（例如402、404、406、408和410）。子訊框402、404、406、408和410包括若干不同的區域，包括鄰居發現區412、未排程控制區414、普通控制區416和資料區418。
鄰居發現區412在每個訊框中出現兩次，在每個方向上出現一次，或基於網路配置出現。例如，訊框440在子訊框402中包括鄰居發現區412的出現412b和在子訊框406中鄰居發現區412的出現412d。僅訊框450的一個子訊框410在第4圖中示出，並且子訊框410包括鄰居發現區412的出現412f。然而，訊框450包括附加的子訊框（未顯示），並且附加子訊框的其中之一可包括鄰居發現區的附加出現。在鄰居發現區（例如412a）期間，WTRU可傳送鄰居發現初始傳輸（NDIT）422並等待鄰居發現響應傳輸（NDRT）420。
在每個子訊框（例如402、404、406、408和410）中，時間-頻率資源可被劃分為未排程控制區（UCZ）414、普通控制區（NCZ）416和資料區（DZ）418。在一個可替換實施方式（未顯示）中，鄰居發現區可被認為是子訊框結構的一部分，在該情況下，子訊框也可被認為是與鄰居發現區相同的方向（例如傳送或接收）。
UCZ 414包括可在每個訊框中出現（在每個方向上一次）或在可基於胞元系統訊框號（SFN）（例如基於網路配置）計算的特定訊框中出現的預定資源集合。因此，在胞元中的所有XL可具有在相同的訊框中的UCZ。例如，訊框440包括在子訊框402中的UCZ 414的出現414b和在子訊框406中UCZ 414的出現414d。第4圖中僅顯示訊框450的一個子訊框410，並且它不包括UCZ的出現。然而，訊框450包括附加子訊框（未顯示），並且附加子訊框的一些可包括UCZ的出現。
在第4圖顯示的示例中，鄰居尋找WTRU可使用UCZ 414a向鄰居存在WTRU傳送它已被鄰居尋找WTRU選取為預期助手WTRU的指示（“助手WTRU選取消息”）（426）。該UCZ還可被鄰居存在WTRU用來向鄰居尋找WTRU傳送基本系統資訊以使關聯形成（424）。這些傳輸可在關聯形成之前發生，並且可潛在地在沒有來自eNB的排程資源的情況下被傳送。因此，多個鄰居存在WTRU可在相同的UCZ中傳送基本系統資訊，這可提供分集益處。來自多個鄰居尋找WRTU的助手WTRU選取消息可在相同的WTRU處重疊，但是可使用例如PHY擾碼機制來分離。
NCZ 416在每個子訊框中出現。在第4圖顯示的示例中，子訊框402、404、406、408和410的每一個包括個別的NCZ出現416b、416c、416d、416e和416f。第4圖中僅顯示訊框450的一個子訊框410。然而，訊框450包括附加的子訊框（未顯示），其每一個可包括NCZ的出現。另外，在第4圖顯示的示例中，NCZ（例如416a）可被用於XL實體DL控制頻道（XPDCCH）428、XL實體UL控制頻道（XPUCCH）430、保活（keep-alive）消息和關聯消息的傳輸。
DZ 418在訊框中的每個子訊框中出現。在第4圖顯示的示例中，子訊框402、404、406、408和410的每一個包括個別的DZ 418b、418c、418d、418e和418f。第4圖中僅顯示訊框450的一個子訊框410。然而，訊框450包括附加的子訊框（未顯示），其每一個也可包括DZ的出現。DZ（例如DZ 418a）可被用來例如在交叉鏈路DL（XDL）共用頻道（XPDSCH）432和XUL共用頻道（XPUSCH）434上傳送WTRU間的資料傳輸塊（TB）。DZ還可包括可使WTRU能夠作出XL的測量的參考信號。
對於AT-R實施方式，XL在XDL和XUL中可包括若干實體頻道。XDL是從助手WTRU到終端WTRU的無線電存取鏈路。它應用於助手WTRU和終端WTRU並在XL頻帶中操作。XUL是從終端WTRU到助手WTRU的無線電存取鏈路。它應用於助手WTRU和終端WTRU，並在XL頻帶中操作。XDL實體頻道可包括例如XL實體鄰居發現頻道（XPNDCH）、XL實體DL關聯頻道（XPDACH）、XL實體DL共用存取頻道（XPDSACH）、XL實體授權頻道（XPGCH）、XL實體DL回饋頻道（XPDFBCH）、XL實體DL資料頻道（XPDDCH）和XL實體DL控制頻道（XPDCCH）。XUL實體頻道可包括例如XL實體鄰居發現頻道（XPNDCH）、XL實體UL關聯頻道（XPUACH）、XL實體UL共用存取頻道（XPUSACH）、XL實體UL回饋頻道（XPUFBCH）、XL實體UL資料頻道（XPUDCH）和XL實體UL控制頻道（XPUCCH）。XUL還可攜帶包括例如XL特定參考信號和保活信號的參考信號。在一個實施方式中，XL實體頻道被假定為基於OFDM的。
XPNDCH可攜帶用於包括鄰居發現初始傳輸（NDIT）和鄰居發現響應傳輸（NDRT）的鄰居發現傳輸的序列。在一個實施方式中，XPNDCH可佔用預設和預定義的符號和子載波資源位置，其不受XL授權或排程控制。XPNDCH可應用分碼多重存取（CDMA），並且碼配置可由WTRU例如根據預定義的演算法導出。當XL帶寬多於預設頻率資源時，網路可為該頻道分配額外的資源（例如子載波），以便增加鄰居發現容量。
XPDACH可攜帶包括例如傳呼指示符、關聯傳輸/接收（TX/RX）指示符或XL授權（XLG）指示符的PHY控制資訊。在一個實施方式中，XPDACH可佔用預設和預定義的符號位置，其可不受XL授權（XLG）或排程控制。XPDACH可應用頻分多址（FDMA）和/或CDMA，並且配置可由WTRU基於它在前關聯的XPNDCH的碼配置導出。
XPUACH可攜帶包括例如XL排程請求（XSR）和XL測量結果指示符的PHY控制資訊。在一個實施方式中，XPUACH可佔用預設和預定義的符號位置，其可不受XLG和排程控制。XPUACH可應用FDMA和/或CDMA，並且配置可由WTRU基於它在前關聯的XPNDCH的碼配置導出。
XPDSACH可攜帶包括例如基本系統資訊（BSI）、初始配置資訊（InitConfiguration）（包括XLG）和經選取的助手WTRU資訊的較高層控制資訊。在一個實施方式中，XPDSACH可佔用預設和預定義的符號位置，其可不受XL授權或排程控制。XPDSACH可應用FDMA和/或CDMA，並且配置可由WTRU基於它關聯的XPDACH的配置導出。在一個實施方式中，解碼頻道必需的資訊，例如傳輸格式，可以被預定義。
XPUSACH可攜帶包括例如XL測量結果的較高層控制資訊。在一個實施方式中，XPUSACH可佔用預設和預定義的符號位置，其可不受XLG或排程控制。XPUSACH可應用FDMA和/或CDMA，並且配置可由WTRU基於它關聯的XPUACH的配置導出。在一個實施方式中，解碼頻道必需的資訊，例如傳輸格式，可以被預定義。
XPGCH可攜帶包括例如子載波分配、TDD子訊框雙工方案、最大XL功率、專用XL頻道碼配置和參考信號配置的XLG資訊。在一個實施方式中，XPGCH可佔用預設和預定義符號位置，其可不受XLG或排程控制。XPGCH可應用FDMA和/或CDMA，並且配置可由WTRU基於它關聯的XPDACH的配置導出。XPGCH的這個未經排程的版本可僅在AT-R覆蓋模式中存在。在AT-R容量模式和覆蓋模式中，用於助手WTRU的XLG還可為專用於從助手WTRU到終端WTRU的XLG傳輸的XL指定此該頻道的完整資源配置，並且在該情況下，XPGCH可應用空間、時間、頻率或分碼多重存取。在一個實施方式中，該頻道可僅應用在XDL上。
XPDFBCH可攜帶XUL的頻道狀態資訊（CSI）和XUL資料傳輸的ACK/NACK。在一個實施方式中，該頻道的完整資源分配可由助手WTRU的XLG來確定。XDFBCH可應用空間、時間、頻率或分碼多重存取。
XPDDCH可攜帶從MAC層接收的XDL使用者資料。在一個實施方式中，此頻道的完整資源分配可由助手WTRU的XLG來確定。XPDDCH可應用空間、時間、頻率或分碼多重存取。
XPDCCH可攜帶與終端WTRU解碼在相同TTI中的XPDDCH的控制資訊相關的資料。在一個實施方式中，此頻道的完整資源分配可由助手WTRU的XLG來確定。XPDCCH可應用空間、時間、頻率或分碼多重存取。
XPUFBCH可攜帶XDL的頻道狀態資訊和XDL資料傳輸的ACK/NACK。在一個實施方式中，此頻道的完整資源分配可由終端WTRU的XLG來確定。XUFBCH可應用空間、時間、頻率或分碼多重存取。
XPUDCH可攜帶從MAC層接收的XUL使用者資料。在一個實施方式中，此頻道的完整資源分配可由助手WTRU的XLG來確定。XPUDCH可應用空間、時間、頻率或分碼多重存取。
XPUCCH可攜帶助手WTRU正確解碼XPUDCH必需的控制資訊。在一個實施方式中，此頻道的完整資源分配可由終端WTRU的XLG來確定。XPUCCH可應用空間、時間、頻率或分碼多重存取。
在一個實施方式中，XL實體頻道可被劃分為兩組。第一組可無XLG地使用（例如，任意XL可與預定義程序的集合相關地在這些頻道中傳送和接收）。第二組可包括專用於特定XL的所有實體頻道。
第一組可包括XPNDCH、XPDACH、XPUACH、XPDSACH、XPDUSACH和SPGCH。在一個實施方式中，潛在的助手WTRU可使用XPDSACH在正在進行的鄰居關聯程序中不用網路授權向它的潛在終端WTRU傳送BSI。雖然XPDSACH傳輸可不需要網路授權，但它可遵循包括偵測和解碼頻道所需的所有必需資訊（例如何時傳輸與鄰居發現程序相關的XPDSACH、如何編碼和調變、XPDSACH以及在MAC PDU中包括什麼資訊）的預定義協定。該頻道組的未排程屬性可使它們遭受競爭。基於CDMA的方案（例如使用不同正交序列擴頻的不同XPDSACH）可被用來最小化競爭概率。
第二組可包括XPDFBCH、XPUFBCH、XPDCCH、XPUCCH、XPDDCH、XPUDCH和XPGCH。在一個實施方式中，這些頻道僅在從網路接收到XLG後可用。
將頻道劃分為組的原因可以是不需網路介入而允許XL實體層傳輸（例如當覆蓋之外的WTRU正在鄰居關聯程序中建立較高層信令時）。因此，由於缺乏終端WTRU與網路的關聯，未經排程的頻道可特定地被用於AT-R覆蓋實施方式。對於AT-LO實施方式和AT-R實施方式，當中繼已建立並且網路授權被接收時，除了可使用XPNDCH外，沒有未經排程的頻道可被使用，且根據網路授權，所有XL特定通訊可被攜帶在經排程的頻道上。
第5圖是用於將不同XL實體頻道多工為不同類型的XL子訊框的不同可能性的示例的圖500。對於第5圖所示的每個示例子訊框502、520和540，網路指派的XL帶寬（BW）和最小XL BW（例如72個子載波）被顯示。在一個圖示的示例中，XPNDCH 504A、保護期間506A、XL特定參考信號508A、XPDCCH和XPDFBCH 510A和XPDDCH和解調變參考信號（DMRS）512A藉由XPNDCH被多工到XDL子訊框502中。在另一個圖示的示例中，XL特定參考信號508B、XPDCCH和XPDFBCH 510B和XPDDCH和DMRS 512B被多工在XDL資料子訊框520中。在另一個圖示的示例中，XPNDCH 504b、保護期間506B、XL未排程參考信號514、XL實體存取頻道（XPACH）516和XL慢存取頻道（XSACH）518藉由XPNDCH被多工在共用可存取子訊框540中。
MAC層可以邏輯頻道的形式來向RLC提供服務。邏輯頻道的類型可以是用於控制和配置資訊的傳輸的控制頻道或用於攜帶使用者資料的業務（traffic）頻道。XL邏輯頻道可包括XL實體控制頻道（XPCCH）、XL通用控制頻道（XCCCH）、XL專用控制頻道（XDCCH）和XL專用業務頻道（XDTCH）。
PHY可以傳輸頻道的形式向MAC提供服務，並且XL傳輸頻道可包括XL傳呼頻道（XPCH）、XL通用頻道（XCCH）、XDL排程頻道（XDL-SCH）和XUL排程頻道（XUL-SCH）。在傳輸頻道上的資料可被組織為傳輸塊，並且在一個實施方式中，特定大小的一個傳輸塊可在每個TTI中被傳送。對於採用特殊多工（例如MIMO）的實施方式，多達2個傳輸塊可在一個TTI中傳輸。
第6A圖、第6B圖、第6C圖和第6D圖是在XL上邏輯、傳輸和實體頻道之間的示例頻道映射的圖。
第6A圖是XDL的示例頻道映射600A。在第6A圖所示的示例中，顯示了用於XPCCH 602、XCCCH 604、XDCCH 606和XDTCH 608 DL邏輯頻道，XPCH 610、XCCH 612和XDL-SCH 614 DL傳輸頻道以及XPDSACH 616、XPDDCH 618、XPDACH 620、XPDCCH 622、XPDFBCH 624、XPGCH 626和XPNDCH 628 DL實體頻道的映射。第6B圖是用於XUL的示例頻道映射600B。在第6B圖所示的示例中，顯示了用於XCCCH 604、XDCCH 606和XDTCH 608 UL邏輯頻道、XCCH 612和XUL-SCH 630 UL傳輸頻道以及XPUSACH 632、XPUDCH 634、XPUCCH 636、XPUACH 638、XPUFBCH 640和XPNDCH 628 UL實體頻道的映射。第6C圖是用於XDL的示例頻道映射600C。在第6C圖顯示的示例中，顯示了用於PCCH 642、XCCCH 604、DCCH 644和DTCH 646 DL邏輯頻道、XPCH 610、XCCH 612和XDL-SCH 614 DL傳輸頻道以及XPCDCCH 648、XPDSCH 650、XPACH 652和XPDCCH 622 DL實體頻道的映射。第6D圖是用於XUL的示例頻道映射600D。在第6D圖顯示的示例中，顯示了用於XCCCH 604、DCCH 644和DTCH 646 UL邏輯頻道、XCCH 612和XUL-SCH 630 UL傳輸頻道以及XPUCCH 654、XPUSCH 656、XPUCCH 636和XPACH 652 UL實體頻道的映射。
以下描述的實施方式提供對AT系統的特徵的增強，以使普通WTRU能夠有效地作為在終端WTRU和eNB之間中繼資料的助手WTRU，並且在一些實施方式中在WTRU間提供資料卸載。在一個實施方式中，用於助手WTRU的L2架構被描述用於在終端WTRU和eNB之間中繼資料。這樣的實施方式可包括在助手WTRU處使用對eNB和終端WTRU可是透明的部分RLC。這樣的架構支持在TRL和XL之間的排程靈活性。在另一個實施方式中，描述了用於丟棄在助手WTRU的緩衝器中延誤的資料並將丟棄的資料通知給終端WTRU的方法。在該實施方式中或在當使用不同L2架構時的可替換實施方式中，可實施流量控制機制以防止助手WTRU緩衝器溢出，因為助手WTRU可具有相對有限的緩衝空間，或者限制在助手WTRU處緩衝的資料量以減少由資料緩衝引起的延遲。在一個實施方式中，描述了資料重新分段機制以啟動在TRL和XL上的獨立排程。在一個實施方式中，描述了可被報告給eNB以支持XL排程的、從助手WTRU發送到終端WTRU的用於覆蓋擴展模式的新MAC狀態報告。在一個實施方式中，針對XL描述了兩級排程方法，其中第一級是集中的並且半靜態XLG由網路發佈，第二級是分散式的並且動態XL排程（XLS）可由WTRU自己執行。
第7A圖是用於AT系統的L2堆疊702的方塊圖700，包括MAC層（718/720）和位在助手WTRU 704處的部分RLC層 722。在第7A圖顯示的示例中，顯示了用於eNB 703、助手WTRU 704和終端WTRU 706的L2堆疊。顯示的eNB 703包括PDCP層708、RLC層710和MAC層712，顯示的助手WTRU 704包括部分RLC層722和MAC層718/720，並且顯示的終端WTRU 706包括PDCP層713、RLC層714和MAC層716。
在部分RLC層722的實施方式中，在RLC AM模式中的自動重複請求（ARQ）功能僅在eNB 703和終端WTRU 706處、而不在助手WTRU 704處終止。因此，在此實施方式中，助手WTRU 704不根據RLC ARQ功能重新傳輸資料。這可使RLC對於RLC AM模式中的無縫助手WTRU行動能夠避免資料丟失。如果需要的話，RLC重新分段可被用來重新建造用於第二躍程的傳輸塊（TB）。在一個實施方式中，兩個獨立的HARQ實體，一個用於XL並且另一個用於TRL，可包括在助手WTRU處。然而，在助手WTRU處用於HARQ的其他配置選擇也是可能的。
在一個實施方式中，到達助手WTRU 704的RLC PDU可被儲存在基於邏輯頻道的佇列中，這可允許資料以每邏輯頻道為基礎被丟棄。用於每個邏輯頻道的丟棄計時器資訊可作為配置資訊的一部分而被交換。當部分RLC層722在基於邏輯頻道的佇列中緩衝RLC PDU時，如果RLC PDU由於例如其相關聯的丟棄計時器期滿而被認為延誤，部分RLC層722可丟棄RLC PDU，當必須時為第二躍程重新分段RLC PDU，並且在RLC AM模式中藉由第二躍程發送最高丟棄序列號（HDSN）。L2堆疊702可被應用於UL和DL兩者。
在RCap模式的實施方式中，終端WTRU和eNB之間的所有信令可藉由在eNB和終端WTRU之間的傳統無線電鏈路中的直接路徑來完成，而資料可流經直接路徑或中繼路徑（包括eNB和助手WTRU之間的傳統無線電鏈路和助手WTRU和終端WTRU之間的XL）。在一個實施方式中，可建立分開的資料無線電承載（DRB）來分別藉由直接路徑和中繼路徑攜帶資料。在另一個實施方式中，通用DRB可被用於直接路徑和中繼路徑兩者。在此實施方式中，PDCP PDU可在兩個路徑間***。對於RCov模式，資料可僅流經中繼路徑。
第7B圖是用於其中建立分開的DRB來分別藉由直接路徑和中繼路徑攜帶資料的實施方式的示例系統架構的圖750。在第7B圖顯示的示例中，eNB 772經由直接路徑774和中繼路徑與終端WTRU 770通訊。中繼路徑是包括eNB 772和助手WTRU 778之間的傳統無線電鏈路776以及助手WTRU 778和終端WTRU 770之間的XL 777的eNB 772和終端WTRU 770之間的路徑。第7B圖顯示的助手WTRU協議堆疊700與第7A圖中的助手WTRU協議堆疊700相同。用於eNB 772和終端WTRU 770的直接路徑協定堆疊752包括通常可包括在LTE協定堆疊中的相同實體，包括PDCP層754和762、RLC層756和764、MAC層758和766以及PHY層760和768。
在RCov模式的實施例方式中，助手WTRU可被用於信令和資料傳遞兩者。因此，存取層（access stratum，AS）安全可需要藉由助手WTRU來建立。由於LTE協定隨著使用臨時識別符支持相互認證和中繼保護，藉由助手WTRU建立AS安全可不引起新的安全考量。PDCP層可負責加密和完整性保護。助手WTRU可在MAC/H-ARQ級操作，並可不解譯經加密的終端WTRU資料。加密和/或完整性保護的終端WTRU資料可藉由助手WTRU被隧道發送。
第8圖是在DL上的助手WTRU處丟棄延誤資料的方法的流程圖800。在一個實施方式中，eNB 703可向助手WTRU 704發送每TTI的TB。助手WTRU 704的MAC層718/720可解析所接收的TB中的MAC標頭，以識別每個邏輯頻道的MAC SDU和RLC PDU。助手WTRU 704可將接收的RLC PDU儲存在基於邏輯頻道的佇列中（802）並開啟與儲存在本地緩衝器中的每個RLC PDU相關聯的丟棄計時器（804）。助手WTRU 704然後可確定丟棄計時器是否已期滿（806）。在丟棄計時器在相應的RLC PDU經由XL被發送給終端WTRU 706之前期滿的情況下，助手WTRU 704可從本地緩衝器中丟棄RLC PDU（808）。助手WTRU 704然後可確定RLC PDU是否已被丟棄（810）。在RLC AM模式中，在至少一個RLC PDU已被丟棄的情況下，助手WTRU 704可使用新類型的STATUS PDU向終端WTRU 706發送在丟棄的RLC PDU中最高的序列號（SN）（HDSN），以行動終端WTRU處的接收（Rx）視窗（812）。助手WTRU 704不期望從終端WTRU 706接收用於接收/非接收STATUS PDU的ACK/NACK。基於XDL授權，助手WTRU 704可使用緩衝的RLC PDU，必要時應用RLC重新分段（參見下文RLC重新分段的詳細描述）來建立XL MAC PDU。助手WTRU 704和eNB 703可在TRL上以每邏輯頻道為基礎執行流量控制，以防止本地緩衝器溢出。類似的實施方式可在UL上應用。
因為助手WTRU在不同的無線電鏈路（例如TRL和XL）間轉發資料，助手WTRU可被配置為在傳輸塊大小（TBS）在TRL和XL間不同的情況下執行重新分段以便在兩個鏈路間轉發資料。對於RLC AM模式，助手WTRU可使用普通RLC協議執行第一躍程RLC AM PDU的重新分段。
第9圖是助手WTRU可用來在第一躍程RLC UM PDU上執行重新分段的用於RLC未應答模式（UM）分段的標頭900的圖。第9圖顯示的用於RLC UM PDU分段的示例標頭900包括與包括在普通RLC協議的RLC AM PDU中相同的PDU分段指示（RF）906、最後分段標誌（LSF）916和分段偏移（SO）欄位918和920。然而，它還包括R1欄位902和904、成框資訊（FI）欄位908、擴展位元欄位910和10位元的序列號（SN）914。
助手WTRU丟棄接收的RLC PDU的示例在下文參考第10圖至第15圖來描述。
一個示例，參考在DL中RLC AM模式，當助手WTRU因為相關聯的丟棄計時器期滿而丟棄RLC PDU時，如果未通知終端WTRU該RLC PDU已被丟棄，在終端WTRU處的Rx視窗將不繞過丟棄的SN，直到丟棄的RLC PDU的重新傳輸到達終端WTRU。等待丟棄的RLC PDU的重新傳輸可能是消耗時間並且不必要的，因為這些RLC PDU可包含應當被忽視以減少延遲的延誤資料。出於至少該原因，助手WTRU可向終端WTRU發送HDSN。響應於接收到HDSN，終端WTRU可將它的Rx視窗的下邊緣更新為HDSN+1。因此，所有具有SN<HDSN的RLC PDU在Rx視窗之外。因此，在該情景下，終端WTRU不要求相應的RLC PDU被重新傳輸。
第10圖是可被用於在RLC AM模式中的第二躍程上攜帶HDSN的RLC STATUS PDU 1000的圖。第10圖顯示的示例RLC STATUS PDU 1000包括資料控制指示（D/C）1002（例如D/C = 0）、控制PDU類型（CPT）1004（例如CPT = 001）、用於指示HDSN的H_SN欄位1008和填充1010。
在RLC UM模式中，終端WTRU的Rx視窗可使用來自於接收的RLC PDU的最高接收窗外SN來更新。這可防止在助手WTRU丟棄RLC PDU後Rx視窗延誤。因此，與AM模式相比，在UM模式中不需要在第二躍程上發送HDSN。
在第二躍程接收器處的RLC SDU重組程序可在AM模式中被修改以適應第二躍程接收器中Rx視窗的改變。在一個實施方式中，第二躍程接收器中的RLC可將具有SN<變數VR(R)的RLC PDU組裝為RLC SDU。第二躍程接收器可分析這些RLC PDU的SN，如果來自RLC SDU的分段確定丟失（例如第二躍程接收器還未接收到該RLC SDU並且該RLC SDU在目前Rx視窗之外），則第二躍程接收器可丟棄用於相同RLC SDU的所有其他資料段。
以每邏輯頻道為基礎丟棄RLC PDU可減少由助手WTRU佇列中延誤資料引起的傳遞延遲。在一個實施方式中，無論該PDU是在eNB緩衝器中還是在助手WTRU佇列中，與PDCP SDU相關的所有RLC PDU可在PDCP丟棄計時器期滿的時刻被丟棄（例如助手WTRU在用於RLC PDU所屬的PDCP SDU的原始PDCP SDU丟棄計時器期滿時完全相同的時刻丟棄緩衝的RLC PDU）。然而，由於實施限制，實際的丟棄時間可與此不同。
助手WTRU可根據若干不同方法的任一個來設定丟棄計時器週期。例如，在DL中，助手WTRU可不丟棄RLC PDU並且可不設定丟棄計時器。由助手WTRU緩衝引起的延遲可藉由最小化佇列長度來限制。在該示例中，可能需要更緊的流量控制來維持佇列長度。對於另一個示例，用於與終端WTRU相關聯的每個邏輯頻道的丟棄計時器的超時值可在部分RLC層的配置或重配置時被提供。丟棄計時器值可被設定為與相應PDCP SDU丟棄計時器的值相同的值。在此示例中，用於PDCP SDU段的總丟棄時間可在從1*丟棄計時器到2*丟棄計時器的視窗內（由於兩個單獨的丟棄計時器潛在地在eNB和助手WTRU兩者中操作）。對於另一個示例，RLC PDU標頭可在eNB將它發出時攜帶剩餘的丟棄計時器超時值。在此示例中，用於PDCP SDU所有段的丟棄時間可準確地為1*丟棄計時器。然而，這可能需要對RLC標頭的擴展，以攜帶剩餘丟棄計時器超時值。在一個實施方式中可實施以上列出的示例的其中之一或組合。
在RLC PDU標頭在eNB將它發出時攜帶剩餘丟棄計時器超時值的實施方式中，可將擴展加至RLC PDU標頭以將該剩餘丟棄計時器超時值從eNB攜帶至助手WTRU。例如，這可藉由將擴展(E2)位元加至普通AMD和指出剩餘時間（LT）欄位的存在和可選的8位元LT欄位的UMD PDU來完成，該LT欄位指出在丟棄計時器中剩餘的時間。可選的LT欄位可被放置在SN欄位之後。
第11圖和第12圖分別是具有E2位元和可選LT欄位的示例RLC PDU 1100和1200的圖。在第11圖和第12圖所示的實施方式中，如果在SN欄位之後在PDU中沒有LT位元存在，E2位元可取0值，並且如果在SN欄位之後在PDU中存在LT位元，E2位元可取1值。
第11圖是具有10位元SN 1102的示例RLC PDU 1100的圖。對於具有10位元SN 1102的示例RLC PDU 1100，E2位元1104在R位元1108和1110之後在UMD PDU中佔用第三個R位元。
第12圖是具有5位元SN 1202的示例RLC PDU 1200的圖。對於具有5位元SN 1202的示例RLC PDU 1200，E2位元在用於AMD PDU和UMD PDU的第一E位元欄位後佔用包括位元1204、1206、1208和1210的新的4位元欄位的第一個位元。
第13圖是用於在助手WTRU處丟棄的RLC PDU的示例程序的圖1300。在圖示的示例中，在某些時間點在XL上發生擁塞。
在1302，PDCP PDU/RLC SDU被劃分為具有SN為10（1310）、11（1311）、12（1312）、13（1313）、14（1314）和15（1315）的RLC PDU。RLC PDU 1310、1312、1313和1314到達助手WTRU 1320。RLC PDU 1311沒有成功地到達助手WTRU 1320。PDU 1315和隨後的PDU 1316和1317停留在eNB 1322中。在1304，RLC PDU 1311由於HARQ重新傳輸較晚到達助手WTRU。XL不可用，並且TRL也被流量控制停止。在1306，由於丟棄計時器期滿，助手WTRU 1320丟棄PDU 1310、1312、1313和1314。在1308，PDU 1315、1316和1317被發送給助手WTRU以填滿助手WTRU緩衝器中的空間。然後XL恢復，HDSN = 14（對應於具有最高SN的丟棄的PDU 1314）被發送給終端WTRU（未顯示）以行動Rx視窗。助手WTRU然後可以向終端WTRU發送PDU 1311、1315、1316和1317。終端WTRU可濾出PDU 1311，因為它在Rx視窗之外。PDU 1315在重組程序中被濾出，因為它包括來自於具有某些丟棄段（例如在PDU 1310、1311、1312、1313和1314中的資料）的未完全接收的SDU的資料段。
第14A圖和第14B圖包括用於行動在RLC AM模式中助手WTRU處Rx視窗的示例程序的圖1400A/1400B。在圖示的示例中，SN空間為[0-7]，並且SN窗口大小 = 4。PDCP PDU/RLC SDU被分段為RLC PDU。RLC SDU的邊界被顯示。
在時間t1，XL不可用，具有SN為5（1415）、6（1416）、7（1417）和0（1410）的RLC PDU停留在eNB 1402處，具有SN為1（1411）和2（1412）、3（1413）和4（1414）的RLC PDU被儲存在助手WTRU 1404處的緩衝器中。在時間t2，因為丟棄計時器期滿，助手WTRU丟棄RLC PDU 1411、1412和1413。隨後，XL恢復。HDSN = 3的HDSN STATUS PDU（對應於具有最高SN的被丟棄RLC PDU 1413）被發送給終端WTRU 1406。在時間t3，Rx視窗被移動，並且在eNB 1402中的Tx視窗也被ACK移動。在時間t4，RLC PDU 1414被發送給終端WTRU 1406。由於它是按順序的，Rx視窗再次移動。在eNB 1402中的Tx視窗也被ACK移動。RLC PDU 1414在Rx窗口之外。在RLC PDU 1414中的第一資料段是具有確認丟失成分的RLC SDU的剩餘段，因此它被丟棄。保存剩餘段以便隨後重組。在時間t5，在Tx視窗更新後更多的資料被發送至助手WTRU 1404。在時間t6，助手WTRU 1404向終端WTRU 1406發送更多的資料，並且用在PDU 1414、1415和1416中分段的資料組合有效的SDU。因此，在此示例中，在XL從問題恢復後，XL延遲藉由使用HDSN來更新Rx視窗得以很好地恢復。
第15A圖和第15B圖包括用於在丟失HDSN時在助手WTRU 1522處移動Rx視窗的示例程序的圖1500A/1500B。用於該示例的參數與用於參考第14A圖和第14B圖描述的示例相同。然而，在該示例中，攜帶HDSN的狀態PDU在XL丟失。在此，Rx視窗僅在丟棄的PDU的重新傳輸到達時被移動。
在時間t1，XL不可用，具有SN為0（1510）、5（1505）、6（1506）和7（1507）的RLC PDU停留在eNB 1524中，並且具有SN為1（1501）、2（1502）、3（1503）和4（1504）的RLC PDU被儲存在助手WTRU 1522處的緩衝器中。在時間t2，由於丟棄計時器期滿，助手WTRU 1522丟棄RLC PDU 1501、1502和1503。隨後，XL恢復。助手WTRU 1522向終端WTRU 1520發送具有最高丟棄SN = 3的HDSN STATUS PDU（對應於具有最高SN的丟棄RLC PDU 1503），但是它在XL上丟失了。因此，沒有更新在終端WTRU 1520處的Rx窗口。在時間t3，助手WTRU 1522向終端WTRU 1520發送RLC PDU 1504。它不是按順序的，所以重排序計時器啟動。在時間t4，重排序計時器期滿，並且終端WTRU 1520向eNB 1524發送具有ACK_SN=1/NACK_SN=2的STATUS PDU。一接收到該STATUS PDU，eNB 1524向助手WTRU 1522重新傳輸RLC PDU 1501、1502和1503。在時間t5，助手WTRU 1522向終端WTRU 1520發送RLC PDU 1501、1502和1503。在該點，在終端WTRU 1520中的RLC PDU是按順序的，並且Rx視窗被更新。在時間t6，RLC SDU被傳遞。
參考第15A圖和第15B圖描述的示例類似於沒有向第二躍程接收器的RLC發送HDSN以行動Rx視窗的情況。因此，即使當HDSN在XL上丟失時，如果向助手WTRU重新傳輸丟失的RLC PDU在它們被丟棄後是允許的，系統可最終恢復。然而，沒有接收到HDSN STATUS PDU，資料串流可花較長的時間恢復（例如重排序計時器期滿及重新傳輸請求）。
除了上述的部分RLC層，另一個實施方式可包括其中MAC、RLC和PDCP層都不在助手WTRU處終止的L2層。在該實施方式中，MAC TB可在XL和TRL間中繼而不需修改。在另一個L2實施方式中，僅MAC層（並且不是RLC或PDCP層）可在助手WTRU處終止。在該實施方式中，在XL和TRL間的排程靈活性可藉由在第二躍程上的MAC PDU分段來實現。MAC級流量控制和MAC級延誤資料丟棄可被應用以改善性能。在另一個L2實施方式中，MAC和RLC層可在助手WTRU處終止。在該實施方式中，助手WTRU可在終端WTRU和eNB之間中繼RLC SDU。在另一個L2實施方式中，MAC、RLC和PDCP層都可在助手WTRU處終止。在一個實施方式中，在此描述的一個或多個L2實施方式可與上述架構相結合。
參考流量控制，在覆蓋擴展模式應用中的第一躍程上的流量控制可作為限制在助手WTRU處本地緩衝器的緩衝深度的目的，以減少傳輸延遲和藉由助手WTRU緩衝器來防止資料溢出。如果在第一躍程上不應用流量控制，由於在第一躍程和第二躍程上的即時吞吐量可能不同，在RLC UM模式中在助手WTRU緩衝器中有溢出的風險。
在RLC AM模式中，在終端WTRU和eNB處的RLC Rx/Tx視窗可在第一躍程和第二躍程之間進行流量控制。然而，在一些實施方式中，儲存在助手WTRU緩衝器中的RLC PDU的最大數目可能需要小於視窗大小。這的一個示例可包括其中在助手WTRU不使用丟棄計時器來丟棄資料的實施方式，因此由助手WTRU緩衝引起的延遲可藉由限制助手WTRU處緩衝的RLC PDU的最大數目而被最小化。
流量控制可被應用在將來自於不同邏輯頻道的資料作為整體處理的MAC級上或在以每活動邏輯頻道為基礎的RLC級上。流量控制的精確度可從二進位開/關（on/off）命令變化到使用多級控制的更精確的命令。
在MAC層和部分RLC層在助手WTRU處終止的實施方式中，RLC級流量控制可被用來實現對每個活動邏輯頻道的精確控制。Xon/Xoff類型的流量控制可被用來減少流量控制負擔。在Xon/Xoff實施方式中，當緩衝級別高於預設的高水位標誌時，Xoff命令可被發送給傳輸器以停止進入資料。一旦緩衝等級低於低水位標誌時，Xon命令可被發送給傳輸器以恢復進入資料。在一個實施方式中，流量控制命令可從助手WTRU發送給第一躍程傳輸器以控制進入助手WTRU的資料。對於UL方向，如果助手WTRU與網路聯合在XUL排程的控制下，可不需要在XUL上進行流量控制。
第16圖是用於在TRL UL上攜帶流量資訊的示例MAC控制元素的圖1600。第16圖顯示的示例MAC控制元素包括R欄位1602、邏輯頻道識別（LCID）欄位1604和開/關欄位1606。LCID欄位可被用來識別相應MAC SDU的邏輯頻道實例或相應MAC控制元素或分別用於DL-SCH、UL-SCH和多播頻道（MCH）的填充的類型。在第16圖顯示的實施方式中，流量控制MAC控制元素可藉由重新使用保留的LCID被識別。開/關欄位1606可以是“1”以指示可發送更多的資料（例如恢復進入資料）或“0”以指示不可發送更多的資料（例如停止進入資料）。
來自終端WTRU的MAC狀態報告可能需要被中繼到網路以幫助XL排程。另外，來自助手WTRU與正在網路和終端WTRU間中繼的流程中的資料相關的附加MAC狀態報告可能需要被發送給網路。因此，在一個實施方式中，將在XL上的邏輯頻道映射到TRL上的邏輯頻道是必需的。
第17圖是XL上的邏輯頻道到TRL上的邏輯頻道間的示例映射的圖1700。在圖1700顯示的示例中，屬於邏輯頻道組1720的TRL邏輯頻道1706和1708在助手WTRU 1714處終止，並且未被映射到任何XL邏輯頻道。然而，屬於邏輯頻道組1718的TRL邏輯頻道1702和1704未在助手WTRU 1714處終止，並且替代地映射到XL邏輯頻道1710和1712並在終端WTRU 1716處終止。
在實施方式中還可使用其他新的MAC狀態報告。這樣的MAC狀態報告可包括來自終端WTRU的XUL排程請求（XUSR）、來自助手WTRU的XDL排程請求（XDSR）、來自終端WTRU的UL緩衝狀態（TBSR）、來自助手WTRU的XDL緩衝狀態（XDBSR）、來自助手WTRU的交叉鏈路DL功率餘量報告（XDPHR）和來自終端WTRU的XUL功率餘量報告（XUPHR）。此外，來自助手WTRU的常規MAC狀態報告，例如SR、BSR或PHR，可按照基線LTE被用於在此描述的實施方式。
當終端WTRU想在XUL上發送資料但沒有XUL授權時，它可能需要向網路發送XUSR以要求初始XUL授權。終端WTRU可以若干不同的方式向網路發送XUSR，包括例如目前處於RRC空閒模式中、想發起到RRC連接模式的轉換的終端WTRU在UCZ上發送XUSR以改變助手WTRU，或目前處於RRC連接模式中的終端WTRU在XUL控制頻道XPUCCH上發送XUSR。當助手WTRU想在XDL上向終端WTRU發送資料但沒有XDL授權可用時，助手WTRU可能需要向網路發送XDSR以要求初始XDL授權。
TBSR可指示終端WTRU處的UL緩衝狀態。該資訊可被用來確定XUL排程，這可由網路和助手或終端WTRU聯合實現，如下文更詳細描述的那樣。
TBSR的傳輸可由終端WTRU處的一個或多個事件觸發，其可包括例如具有比目前在傳輸緩衝器中的資料高的優先順序的資料的到達、由計時器控制的週期觸發或當填充在MAC標頭中使用時。TBSR可經由XUL首先被發送給助手WTRU，然後可在TRL UL上被中繼給eNB。在一個實施方式中，TBSR可以是6位元。
取決於XPUCCH設計，TBSR可直接在XPUCCH上或藉由XUL共用資料頻道上的MAC控制元素在XUL上被發送給助手WTRU。在TRL上，TBSR MAC控制元素可被用來攜帶TBSR。TBSR MAC控制元素可以是與為傳統LTE MAC定義的BSR（包括截斷（truncated）BSR、短BSR或長BSR）相同的格式。TBSR MAC控制元素可藉由重新使用保留的LCID被識別。
如果MAC控制元素被用來在XUL共用資料頻道上攜帶TBSR，它可以是常規BSR MAC控制元素或TBSR MAC控制元素的形式。如果使用了常規BSR MAC控制元素，助手WTRU可將它從XUL共用資料頻道接收的常規BSR MAC控制元素轉換為在TRL UL-SCH上的TBSR MAC控制元素。
第18圖是顯示在XUL-SCH上BSR 1808到在TRL UL-SCH上TBSR 1812的示例轉換的圖1800。在第18圖顯示的示例中，XL TB 1802包括MAC標頭1806和BSR 1808。TRL TB 1804包括MAC標頭1810，並且還包括具有其他常規MAC控制元素1814的經轉換的TBSR 1812。
在另一個實施方式中，TBSR可使用在XUL共用資料頻道上的TBSR MAC控制元素來攜帶。在該實施方式中，助手WTRU可藉由在TRL UL-SCH上放置TBSR MAC控制元素來將它發送給eNB。
XDBSR是用於助手WTRU處的XL的DL緩衝狀態報告。網路可使用該資訊來與助手WTRU聯合確定XDL排程。XDBSR MAC控制元素可以是與在傳統LTE MAC中定義的BSR相同的格式。它們可以例如是截斷BSR、短BSR或長BSR的形式。新的XDBSR MAC控制元素可藉由重新使用保留的LCID來識別。XDBSR的傳輸可由助手WTRU處的若干不同事件來觸發，其可包括例如由計時器控制的週期觸發、否則當填充在MAC標頭中被使用時、XDL佇列深度超過閾值（這可藉由XDL流量控制來替代）、或如果助手WTRU使用XDBSR向網路發送XDSR，當助手WTRU想請求用於向終端WTRU發送資料初始XDL授權時。
第19圖是圖示用於AT應用的在覆蓋擴展模式中UL TBSR的示例傳輸的圖1900。在第19圖顯示的示例中，TRL邏輯頻道1902、1904、1906和1908被配置為從助手WTRU 1950處的各個UL緩衝器1914、1916、1918和1920傳輸資料到網路eNB（未顯示）。在一個實施方式中，助手WTRU 1950可被配置為向網路eNB（未顯示）傳輸用於這些邏輯頻道的BSR。XL邏輯頻道1910和1912可被配置為向助手WTRU 1950傳輸在終端WTRU 1960處各個UL緩衝器1922和1924的TBSR。
第20圖是圖示用於AT應用的在覆蓋擴展模式中DL BSR的示例傳輸的圖。在第20圖顯示的示例中，TRL邏輯頻道2002、2004、2006和2008被配置為從網路eNB（未顯示）傳輸資料到助手WTRU 2050。XL邏輯頻道2010和2012可被配置為向終端WTRU 2060傳輸助手WTRU 2050處各個DL緩衝器2014和2016的BSR。
用於XL的DL和UL功率餘量（XDPHR和XUPHR）兩者被用來由網路和助手WTRU/終端WTRU聯合確定XL排程。XUPHR可從終端WTRU被發送，並由助手WTRU中繼給網路。XDPHR可從助手WTRU被發送，並直接被報告給網路。XDPHR可藉由若干不同事件在助手WTRU處被觸發，其可包括例如由計時器控制的週期觸發、XL路徑損耗改變超過閾值、或XDL排程由助手WTRU或終端WTRU改變。XUPHR可藉由若干不同的事件在終端WTRU處被觸發，其可包括例如由計時器控制的週期觸發、XL路徑損耗改變超過閾值、或XUL排程由終端WTRU或助手WTRU改變。XDPHR和XUPHR MAC控制元素可以是與在傳統LTE MAC中定義的PHR MAC控制元素相同的格式。XDPHR MAC控制元素和XUPHR MAC控制元素可藉由重新使用保留的LCID來識別。
終端WTRU可發起XUL排程請求並將它發送給助手WTRU。助手WTRU然後可將它中繼給eNB。取決於RRC模式，終端WTRU可使用不同的程序來將XUSR發送給助手WTRU。在RRC空閒模式中的終端WTRU可在UCZ中發送XUL排程請求。取決於在XL上如何設計控制頻道，在RRC連接模式中的終端WTRU可以TBSR或XUSR的形式將XUL排程請求發送給助手WTRU。
第21圖是在RRC連接模式中的終端WTRU使用TBSR向eNB發送XUL排程請求的方法的流程圖2100。在第21圖顯示的示例中，在終端WTRU有UL資料發送的情況下（2102），終端WTRU可經由XUL控制頻道向助手WTRU發送TBSR（2104）。如果XPUCCH可直接攜帶TBSR，終端WTRU可直接在XPUCCH上向助手WTRU發送TBSR，可不需要XUSR。
如果XPUCCH不攜帶TBSR，終端WTRU可在XPUCCH上發送XUSR。第22圖是在RRC連接模式中終端WTRU使用XUSR向eNB發送XUL排程請求的方法的流程圖2200。在第22圖顯示的示例中，在終端WTRU有UL資料要發送的情況下（2202），終端WTRU確定它是否有XUL授權（2204）。在終端WTRU有XUL授權的情況下，終端WTRU可確定不需要發送XUSR，並且因此可不發送XUSR（2208）。在終端WTRU沒有XUL授權的情況下，終端WTRU可經由XPUCCH向助手WTRU發送XUSR（2206）。
在XPUCCH上發送XUSR可節約在XPUCCH上的帶寬，因為XUSR可以僅是1位元的資訊。該位元的資訊可以與在PUCCH上攜帶的常規SR相同或類似的方式來攜帶。在該實施方式中，可能不需要在XL上有RACH程序，因為當助手WTRU和終端WTRU兩者都在RRC連接模式中時，XPUCCH總是存在。
第23圖是助手WTRU使用TRL PUCCH和TRL UL-SCH兩者向eNB中繼XUSR的方法的流程圖2300。在第23圖顯示的示例中，終端WTRU經由在XPUCCH上的XUSR向助手WTRU發送XUSR（2302）。一接收到XUL排程請求，助手WTRU可將它中繼給eNB。在圖示的實施方式中，助手WTRU可依據TRL UL狀態以不同的方式將接收的XUSR發送給eNB。在TRL PUCCH存在的情況下（2304），助手WTRU可藉由在TRL PUCCH上專用於XUSR的新位元來向eNB發送XUSR（2308）。如果不存在，在用於UL-SCH的TRL UL授權可用的情況下（2306），助手WTRU可使用MAC控制元素在UL-SCH上發送XUSR（2312）。在用於UL-SCH的TRL UL授權不可用的情況下（2306），已有的LTE-A RACH程序可被用來獲得在TRL上的初始UL授權（2310）並且然後可經由UL-SCH向eNB發送XUSR（2312）。
第24圖是助手WTRU僅使用UL-SCH向eNB中繼XUSR的方法的流程圖2400。在第24圖顯示的示例中，助手WTRU可藉由使用MAC控制元素僅在UL-SCH上向eNB發送XUSR。終端WTRU可經由XPUCCH向助手WTRU發送XUSR（2402）。在用於UL-SCH的TRL UL授權不可用的情況下（2404），藉由PUCCH或RACH的用於UL排程請求的現有LTE-A程序可被用來獲得在TRL UL上的初始UL授權（2406）。然後助手WTRU可經由UL-SCH向eNB發送XUSR（2408）。在用於UL-SCH的TRL UL授權可用的情況下（2404），助手WTRU可簡單地經由UL-SCH向eNB發送XUSR（2408）。
如果XUSR在TRL UL-SCH上被發送，XUSR可使用在UL-SCH上的新類型的MAC控制元素或使用在TRL UL-SCH上的最小TBSR被發送給eNB。最小TBSR可表示用於短TBSR MAC控制元素的大小。
對於其中使用在UL-SCH上的新類型MAC控制元素向eNB發送XUSR的實施方式，XUSR MAC控制元素可具有長度0（例如，它可能沒有真正的MAC控制元素體）。在該實施方式中，在MAC標頭中僅放置具有用於XUSR的LCID的R/R/E/LCID欄位。XUSR MAC控制元素可藉由重新使用保留的LCID來識別。助手WTRU可以若干不同的方式來向eNB發送XUL排程請求，其示例描述在下文參考第25圖、第26圖和第27圖。
第25圖是助手WTRU使用XUSR MAC控制元素在TRL UL-SCH上向eNB中繼XUSR的方法的流程圖2500。在第25圖顯示的示例中，對TRL PDCCH的擴展可能需要用於從eNB攜帶XUL授權到助手WTRU。終端WTRU 2520可在XPUCCH上向助手WTRU 2530發送XUSR（2502）。如果助手WTRU 2530沒有TRL UL授權，可執行LTE-A程序以獲得這樣的授權（2504）。然後助手WTRU 2530可使用在TRL UL-SCH上的MAC控制元素向eNB（2540）發送XUSR（2506）。一接收到XUSR，在eNB 2540處的XUL排程器2508可指派初始XUL授權並將它經由在TRL上的PDCCH發送給助手WTRU 2430（2510）。然後助手WTRU 2530可經由XPDCCH向終端WTRU 2520發送XUL授權（2512）。
第26圖是助手WTRU 2630使用最小TBSR MAC控制元素在TRL UL-SCH上向eNB 2640中繼XUSR的方法的流程圖2600。在第26圖顯示的示例中，對TRL PDCCH的擴展可能需要用於從eNB 2640攜帶XUL授權到助手WTRU 2630。終端WTRU 2620可在XPUCCH上向助手WTRU 2630發送XUSR（2602）。在一個實施方式中，如果TRL UL授權不可用，可能需要執行LTE-A程序以獲得這樣的授權（2604）。助手WTRU 2630然後可使用在TRL UL-SCH上的MAC控制元素向eNB 2640發送最小TBSR（2606）。一接收到TBSR，在eNB 2640處的XUL排程器2608可指派初始XUL授權並將它經由在TRL上的PDCCH發送給助手WTRU（2610）。助手WTRU 2630然後可經由XPDCCH向終端WTRU 2620發送初始XUL授權（2710）。在該實施方式中，最小TBSR可對應於短BSR的大小。
第27圖是助手WTRU在TRL PUCCH上向eNB中繼XUSR的方法的流程圖。在第27圖顯示的示例中，可能需要在TRL PUCCH上用於將XUSR從助手WTRU 2730攜帶到eNB 2740的1位元擴展。同樣地，可需要用於將XUL授權從eNB 2740攜帶到助手WTRU 2730的對TRL PDCCH的擴展。終端WTRU 2720可在XPUCCH上向助手WTRU 2730發送XUSR（2702）。助手WTRU 2730可使用TRL PUCCH向eNB 2740中繼XUSR（2704）。一接收到XUSR，在eNB 2740處的XUL排程器2706可指派初始XUL授權，並將它經由TRL PDCCH發送給助手WTRU 2730（2708）。助手WTRU 2730可經由XPDCCH向終端WTRU 2720發送XUL授權（2710）。
當助手WTRU有資料在XDL上發送給終端WTRU但沒有XDL授權時，它可向網路發送要求XDL授權的XDSR。在一個實施方式中，助手WTRU可依據此時的TRL UL狀態以不同的方式向eNB發送XDSR。例如，如果存在用於TRL的PUCCH，助手WTRU可使用在TRL PUCCH上專用於XDSR的新位元向eNB發送XDSR。如果不存在用於TRL的PUCCH，助手WTRU可使用MAC控制元素在UL-SCH上發送XDSR。如果用於UL-SCH的TRL UL授權是不可用的，現有LTE-A RACH程序可被用來獲得在TRL上的初始UL授權。對於另一個示例，助手WTRU可藉由使用MAC控制元素僅在UL-SCH上向eNB發送XDSR。如果用於UL-SCH的TRL UL授權不可用，藉由PUCCH或RACH，用於UL排程請求的現有LTE-A程序可被用來獲得在TRL UL上的初始UL授權。
如果XDSR在TRL UL-SCH上被發送，XDSR可使用XDSR MAC控制元素在UL-SCH上被發送給eNB，或使用最小XDBSR MAC控制元素在TRL UL-SCH上被發送給eNB。如果XDSR使用XDSR MAC控制元素在UL-SCH上被發送給eNB，新類型的MAC控制元素可被用於在TRL UL-SCH上的XDSR。在一個實施方式中，XDSR MAC控制元素可具有長度0（例如它沒有實際的MAC控制元素體）。在該實施方式中，在MAC標頭中僅放置具有用於XDSR的LCID的R/R/E/LCID欄位。XDSR MAC控制元素可藉由重新使用保留的LCID來識別。助手WTRU如何使用不同選項向eNB發送XDL排程請求的詳細程序在下文參考第28圖和第29圖來描述。
第28圖是助手WTRU 2810使用XDSR MAC控制元素在TRL UL-SCH上向eNB 2820發送XDSR的方法的流程圖2800。在第28圖顯示的示例中，可能需要對TRL PDCCH的擴展以用於將XDL排程資訊從eNB 2820攜帶給助手WTRU 2810。如果助手WTRU 2810沒有TRL UL授權，助手WTRU可執行LTE-A程序來獲得一個（2802）。助手WTRU 2804可使用在TRL UL-SCH上的MAC控制元素向eNB 2820發送XDSR（2810）。一接收到XDSR，在eNB 2820處的XDL排程器2806可指派初始XDL授權，並將它經由在TRL上的PDCCH發送給助手WTRU 2810（2808）。
第29圖是助手WTRU 2910在TRL PUCCH上向eNB 2920發送XDSR的方法的流程圖2900。在第29圖顯示的示例中，可能需要對TRL PUCCH的1位元擴展，以用於將XDSR從助手WTRU 2910攜帶到eNB 2920。同樣地，可能需要對TRL PDCCH的擴展，以用於將XDL排程資訊從eNB 2920攜帶給助手WTRU 2910。助手WTRU 2910可使用TRL PUCCH向eNB 2920發送XDSR（2902）。一接收到XDSR，在eNB 2920處的XDL排程器2904可指派初始XDL授權，並將它經由TRL PDCCH發送給助手WTRU 2910（2906）。
在一個實施方式中，終端WTRU可首先在XUL上向助手WTRU發送TBSR，然後助手WTRU可將TBSR在TRL UL上中繼給eNB。TBSR可使用任意數目的不同方法在XL上被發送，這些方法可包括例如藉由XPUCCH在XUL上發送TBSR，和藉由常規BSR或TBSR MAC控制元素在XUL共用資料頻道上發送TBSR。
如果終端WTRU在XUL共用資料頻道上使用常規BSR或TBSR MAC控制元素發送TBSR，它可能需要XUL授權來向助手WTRU發送TBSR。在一個實施方式中，XUL授權可從正在進行的XUL傳輸獲得。如果沒有XUL授權，終端WTRU可使用上述XUL排程請求程序來請求XUL授權。
在從終端WTRU接收到TBSR後，一旦助手WTRU有如果將有從助手WTRU到eNB的正在進行的UL資料傳輸它可能需要的TRL UL授權，它可藉由在TRL UL-SCH上的MAC控制元素將TBSR發送給eNB。如果TRL UL授權不可獲得，助手WTRU可藉由PUCCH或RACH使用用於UL排程請求的現有LTE-A程序來從eNB請求初始TRL UL授權。
第30圖是當TRL UL授權可獲得時用於向eNB 3070發送TBSR的方法的信號圖3000。在第30圖顯示的示例中，終端WTRU 3050使用在XUL資料頻道上的常規BSR MAC控制元素或TBSR MAC控制元素或使用XPUCCH向助手WTRU 3060發送TBSR（3002）。如果助手WTRU 3060沒有TRL UL授權，它可能需要發起LTE-A程序以獲得一個（3004）。助手WTRU 3060可將TBSR放置在TBSR MAC控制元素中（3006）或將BSR放置在BSR MAC控制元素中（3008），並將其發送給eNB 3070。一接收到TBSR/BSR，在eNB 3070處的XUL排程器3010可指派XUL授權，並將它經由TRL PDCCH發送給助手WTRU 3060（3012）。在eNB 3070處的TRL UL排程器（3010）可指派TRL UL授權，並將它也經由TRL PDCCH發送給助手WTRU 3060（3014）。助手WTRU 3060可經由XPDDCH向終端WTRU 3050發送XUL授權（3016）。然後終端WTRU 3050可在XUL共用頻道上發送具有較新TBSR的資料給助手WTRU 3060（3018），其可將該資料中繼給eNB 3070（3020）。
XDBSR可由助手WTRU來測量。用於XDBSR的報告程序可類似於被用於助手WTRU藉由使用在TRL UL-SCH上的MAC控制元素報告常規BSR的程序。新類型的MAC控制元素可被用於XDBSR。它可具有與BSR相同的格式，並且可藉由重新使用保留的LCID欄位來識別。
第31圖是報告XDBSR的方法的信號圖3100。在第31圖顯示的示例中，可能需要對TRL PDCCH的擴展，以用於將XDL排程頻道從eNB 3120攜帶到助手WTRU 3110。如果助手WTRU 3110沒有TRL UL授權，助手WTRU 3110可能需要發起LTE-A程序以獲得一個（3102）。助手WTRU 3110可使用TRL UL-SCH上的MAC控制元素向eNB 3120發送XDBSR（3104）。一接收到TBSR，在eNB 3120處的XDL排程器3106可指派XDL授權，並將它經由在TRL上的PDCCH發送至助手WTRU 3110（3108）。
可能需要用於XDPHR和XUPHR的新類型的MAC控制元素以在TRL-SCH上向eNB發送XDPHR和XUPHR。用於XUPHR的相同MAC控制元素可在XUL共用資料頻道上被用來攜帶XUPHR給助手WTRU。
第32圖是在TRL UL-SCH上向eNB 3240發送XDPHR和XUPHR的方法的信號圖3200。終端WTRU 3220可使用在XUL共用資料頻道上的MAC控制元素向助手WTRU 3230發送XUPHR（3202）。如果助手WTRU 3230沒有TRL UL授權，它可能需要使用LTE-A程序來獲得一個（3204）。助手WTRU 3230可在TRL UL-SCH上將XUPHR MAC控制元素（3206）和/或XDPHR MAC控制元素（3208）中繼給eNB 3240。助手WTRU 3230還可在UL-SCH上向eNB 3240發送PHR（3210）。
在TRL UL-SCH和XUL共用資料頻道上使用的LCID可共用相同定義，即使它們可能不是永遠在這兩個頻道上出現。表1包括了通常使用的LCID值和可被用於在此描述的不同實施方式的LCID值的列表。然而，其他LCID值和排序也可是可能的。

表1

關於XL資源授權和排程，XL可共用在TRDL/TRUL上應用的頻帶（帶內配置），或採用與TRDL/TRUL完全分開的不同頻帶（帶外配置）。帶外配置可較不受XL和TRL間的裝置內和空氣干擾，因為帶外配置通常在XL和TRL間應用足夠的頻譜隔離，因此裝置可操作兩個無線電鏈，每一個具有它自己的基帶處理和獨立的FFT。雖然裝置內干擾可利用裝置的實體無線電設計被主要地，但空氣干擾可能需要以XL資源授權和部分由網路執行並且部分由WTRU執行的排程方案進行協調。
第33A圖是在由eNB 3350操作的胞元內助手WTRU 360和終端WTRU 370的系統的圖3300。助手WTRU 360A、360B、360C、360D、360E和360F的每一個經由各自的TRL UL/DL對3310A、3310B、3310D、3310F、3310H或3310I與eNB 3350直接通訊。終端WTRU 370A、370B、370D和370E的每一個經由一個或多個XL UL/DL對3320A、3320B、3320C、3320D、3320E、3320F或3320G與一個或多個助手WTRU 360A、360B、360C、360D、360E和360F通訊。某些終端WTRU（例如終端WTRU 370B、370D和370E）還可經由各自的TRL UL/DL對3310C、3310E或3310G與eNB 3350直接通訊。
在第33A圖顯示的示例系統中，所有XL潛在地互相干擾。在一個實施方式中，不同的多存取方案可應用在XL上以嘗試減輕該干擾。然而，在相同胞元中的所有XL可共用時間、頻率、碼和功率資源的固定池（fixed pool），並且網路可能需要新的度量和演算法來有效地分配XL資源。
為了支援在LTE系統中的高行動性並處理產生的短頻道相干時間，網路可在TRL上的每TTI動態地執行排程。然而，在XL上應用類似的動態授權和排程方案可要求網路具有對動態XDL和XUL頻道狀態資訊的存取。產生的信令可能相當大，特別在其中助手WTRU可能需要將所有終端WTRU回饋資訊中繼給網路的AT-R覆蓋模式中。此外，集中的動態授權和排程可引起HARQ時間線增加，因為助手WTRU可能需要時間來解碼和轉發授權和排程資訊給終端WTRU。
另外，TRL授權和排程不指定將被用於經排程的DL或UL傳輸的功率等級。對於TRL授權和排程，eNB總是使用全功率（即下鏈功率被集中化）來傳送DL資料頻道，而UL傳輸可基於諸如指派的調變和編碼方案（MCS）和實體資源塊（PRB）這樣的授權資訊藉由UL功率控制來調整（即UL功率控制機制是分散式的）。然而，對於XL，作為一個類型的資源分配，顯式的功率分配可能是期望的，因為在地理區域中所有XL可受限於特定功率等級以減輕互相干擾的意義上，在AT應用中WTRU的XL傳輸功率設定可構成共用資源的分佈。
AT-R覆蓋模式可提出附加的挑戰，因為助手WTRU可使用新的程序來向終端WTRU轉發網路授權和向網路中繼作為對授權演算法的輸入的終端WTRU測量。
因此，如上簡要描述那樣，在此描述了用於XL中2層排程的實施方式，其中第一層是由網路發佈的集中和半靜態的XLG，並且第二層是可由WTRU自身執行的分散式和動態的XLS。這些實施方式可被應用於AT-R和AT-LO應用兩者，但是為了易於解釋一些實施方式參考AT-R被描述。
第33B圖是WTRU和另一個WTRU之間在無線XL上無線資源排程的示例方法的流程圖3355。在第33B圖顯示的示例中，WTRU接收用於由至少該WTRU用於在無線電XL上的傳輸的XLG指定資源（3360）。該WTRU可在XLG中指定的資源內每TTI地執行XL排程（3362）。該WTRU可基於每TTI的XL排程向另一個WTRU傳送至少一個封包（3364）。
在一個實施方式中，網路控制的XLG可以是使用正交多重存取的頻道依賴授權方案。這樣的頻道依賴授權方案可消除胞元內XL干擾，而允許每個XL根據它的頻道狀況獲得最優的性能。然而，在一些實施方式中，當每胞元支援的XL數目過多時，網路可能沒有合適的資源來支持正交多重存取，並且由於顯著增加的信令負擔和導致的等待時間增加，每TTI的動態的頻道依賴排程可能不可行。例如，每XL的動態每TTI排程可引起對PDCCH/PUCCH容量的高要求。
在一個實施方式中，動態每TTI排程可基於在XLG中指定的資源和XL ACK/NACK消息或頻道品質指示符（CQI）的至少一個來實施，不需要網路介入。因為在一些AT應用中用於TRL和XL的分開的HARQ設計可防止ACK/NACK傳輸被轉發至網路，這樣的實施方式可能是想要的。
二層排程的第一層可被稱為XLG，並且第二層可被稱為XLS。就XLG而言，網路可發佈集中且半靜態的排程決策以基於短期測量和長期測量兩者在最大允許功率和實體頻道時間/頻率/碼配置方面分配XL的資源。這樣的短期和長期測量可包括例如XL回饋測量、XL信號和干擾測量和XL功率餘量報告。XLG可不考慮即時頻道狀況。每個授權可與顯式信號發送的有效期間相關聯。對於XLS，網路中的WTRU可在由XLG分配的資源中執行分散式且動態的排程決策，並以每TTI為基礎確定傳輸配置。以每TTI為基礎而確定的傳輸配置可包括，例如根據短期XL頻道狀況回饋測量來確定MCS和傳輸帶寬，以作為鏈路適應和業務量變化處理的結果。排程決策可被考慮到XL功率控制以計算傳輸功率。
XLG中指派的子載波資源可在XLG有效期間不改變地應用。換句話說，在每個XLG有效期間沒有動態頻率排程。WTRU可使用相同的經授權的子載波（例如在每個TTI中的子載波組或子帶）但是可為鏈路適應應用不同的功率和MCS。可替換地，XL排程可藉由基於特定於每個可指派的子載波組或子帶的特定SINR回饋調整子載波資源指派來在授權的帶寬內探測（explore）頻率選擇性。
雖然，在一個實施方式中，XLG可不攜帶任何MCS資訊，但它可為AT應用中的WTRU指定最大允許XL傳輸功率。這可作為由網路指示的慢功率控制的一種形式，以管理XL間的干擾和啟動有效的功率利用。例如，當鄰近的兩個XL共用相同的碼、頻率和時間資源時，最大允許功率（XLG功率）可被設定以減少XL間干擾和最佳化兩個XL的性能。然而，當在XL間應用正交資源分配時，XLG功率可被設定以在XL上傳遞最大MCS，只要它不超出根據裝置能力WTRU可應用的最大傳輸功率。
當在網路中指派大XL BW時，在胞元中的每個XL可首先被指派到頻率重新使用組中，其中可給每個指派的XL授權XL BW的專用部分。
第34圖是其中在胞元中的XL被部署在頻率重新使用組中的胞元3440的圖3400。在第34圖顯示出的示例中，在由eNB 3450操作的胞元3440中的XL可被部署在4個頻率重新使用組3460、3470、3480和3490中。頻率重新使用組3460包括XL 3402、3404、3406、3408、3410、3412和3414。頻率重新使用組3470包括XL 3416、3418、3420、3422、3424、3426和3428。頻率重新使用組3480包括XL 3430、3432、3434、3436、3438、3440和3442。頻率重新使用組3490沒有任何特別指派給它的XL。然而，本領域具通常知識者將意識到，在胞元中的XL可被組織到任意數目的頻率重新使用組中，其每組可包括任意數目的XL。
在一個實施方式中，除了FDMA外，XLG還可為應用CDMA的實體頻道和參考信號指定碼分配。例如，兩個XL特定參考信號可共同存在使用兩個基於ZC的序列的相同頻率資源位置中。這些序列可衍生自具有不同的循環位移的相同的基本序列，以便提供正交性。
當XL採用TDD雙工方案時，網路還可應用TDMA。例如，使用相同的頻率和碼資源分配指派的兩個XL可被配置具有不同的TDD XDL/XUL配置，由此XDL1和XUL2的傳輸時間一致。因為助手WTRU和終端WTRU傳輸可具有不同的碼配置，XDL1和XUL2可以不互相干擾。
用於AT-R應用的助手和終端WTRU XLG可包括許多不同類型的資訊的一個或多個。例如，助手WTRU XLG可授權助手WTRU由有效期間限制的許可，以根據傳輸的伴隨配置在XDL中向終端WTRU傳送。終端WTRU XLG可為終端WTRU授權許可來以類似的方式在XDL中向助手WTRU傳送。
可包括在助手WTRU XLG中的資訊的特定示例可包括有效期間的持續時間（例如以TTI的數目為單位）、在XL上的最大允許助手WTRU傳輸功率、在XLPC中應用的在終端WTRU處的目標標稱功率（例如以dBm為單位）、XDL/XUL雙工配置（例如用於TDD）、XDL指派索引（例如用於TDD）、用於所有XDL專用頻道的子載波資源分配（例如以子帶為單位）（在指派的頻率資源中這些頻道間的多工可被預定義）和XDL特定參考信號碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移）。用於助手WTRU XLG的資訊的其他示例可包括XPDFBCH特定參考信號碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移）、XPDCCH特定參考信號碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移）、XPDCCH資源配置（例如擴展因數或頻道碼指派）、XPGCH資源配置（例如擴展因數或頻道碼指派）、XPDDCH解調變參考碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移）、XPDDCH頻躍程指示符和XUL CQI以及信號測量請求和配置。
可包括在終端WTRU XLG中的資訊的特定示例可包括例如有效期間的持續時間（例如以TTI的數目為單位）、在XL上的允許終端WTRU最大傳輸功率（例如以dBm為單位）、在XLPC中應用的助手WTRU處的目標標稱功率（例如以dBm為單位）、XDL/XUL雙工配置（例如用於TDD）、XUL指派索引（例如用於TDD）、用於所有XUL專用頻道的子載波資源分配（例如以子帶為單位）（在指派的頻率資源中這些頻道間的多工可被預定義）和XUL特定參考信號碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移）。用於終端WTRU XLG的資訊的其他示例可包括XPUFBCH特定參考信號碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移）、XPUCCH特定參考信號碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移元）、XPUDCH資源配置（例如擴展因數或頻道碼指派）、XPUDCH解調變參考碼配置（例如擴展因數/擴展碼指派或基礎序列/循環位移）、XPUDCH頻躍程指示符或XDL CQI以及信號測量請求和配置。
助手WTRU或終端WTRU可能需要接收助手WTRU XLG和終端WTRU XLG兩者以操作XLG。附加地，特定的XLG資訊可從其他XLG資訊分開地被攜帶。例如，有效期間可以與SPS-Config資訊元素類似的方式在專用RRC信令中被通知。
在一個實施方式中，若干資訊欄位在助手WTRU XLG和終端WTRU XLG間可重疊。可替換地，一個合併的XLG可被應用並被傳送給助手WTRU和終端WTRU兩者。
XLG可被認為是在LTE系統中使用、特別是用於諸如IP語音服務這樣的低速率服務的半永久排程（SPS）的一種適應類型。在LTE中，PDCCH控制信令負擔被激勵並被正當化，因為它與在PDSCH/PUSCH上攜帶的有效負載相比仍然相對小。然而，對於一些具有小有效負載的服務來說，例如IP語音服務，控制信令負擔可使用SPS來減小。
在AT應用（例如AT-R覆蓋模式）中，控制信令減少可以是SPS類型的排程的主要動機。雖然AT應用不限於低速率服務，但動態的並且依賴頻道的第二級別的排程可在每TTI地改變功率等級、MCS和/或子載波指派的幫助下對資料業務量的大變化提供相當合適的處理。在接收到XLG後，WTRU可在在授權中指定的資源內每TTI地執行XL排程。如果WTRU不能調整授權的傳輸帶寬，它可調整MCS並計算每TTI的功率等級以相應地執行鏈路適應。表2提供了SPS類型排程對XLG排程的特性列表。
表2

網路可基於任意數目的不同輸入來推導XLG。為了初始XLG推導，可給某些輸入更多的權重，而其他的可被用於更新XLG推導。這樣的輸入的示例可包括基於QoS的請求頻譜效率、估計的XL信噪比（SINR）、緩衝狀態、資源分配歷史、XL回饋測量、XL功率餘量和在指派的子載波組中接收的信號測量。
對於基於QoS的請求頻譜效率，網路可使用QoS來確定XL和所需SINR的近似目標速率。當WTRU請求和建立它的服務時，這可用於例如准入控制以評估在XLPC中應用的目標功率。
對於估計的XL SINR，網路可基於授權和在XL上報告的測量來估計XL SINR，並將它與基於QoS計算的請求的SINR相比較以確定初始XLG。基於授權和測量產生的SINR的估計的一個示例可基於：

其中N是指派的子載波組的數目，BW_sub是每個子載波組的帶寬，IoT是指派的子載波組的總接收的干擾功率，PL是XL的助手WTRU和終端WTRU間的路徑損耗，N_o是熱功率密度並且NF是WTRU雜訊係數（noise figure）。
對於緩衝狀態，DL緩衝狀態可在eNB處容易地獲得，並且UL緩衝狀態可由WTRU週期地或當由預定義事件觸發時報告。緩衝狀態可應用於授權演算法以處理業務變化。對於資源分配歷史，先前發佈的XLG可以是其中的因素。
對於XL回饋測量（XLFB），LTE網路排程器可在為動態排程執行速率預測時考慮頻道狀態資訊（CSI）。類似的方法可應用於AT-R容量模式和AT-LO應用，其中兩個WTRU可在TRUL中根據請求或根據授權配置來報告每TTI的CSI。然而，在AT-R覆蓋模式中，由於在終端WTRU和eNB間缺乏直接鏈路，終端WTRU CSI資訊可不在每TTI的基礎上直接應用。
每TTI的短期XL CSI回饋例如在可獲得UL授權時可以PUSCH多工處理，在為WTRU排程以攜帶TRDL CSI的PUCCH中被傳送，或在專用於XL的PUCCH排程中被傳送。對於以PUSCH多工每TTI的短期XL CSI回饋，可增加識別字（例如1位元欄位）以便eNB區分多工的CSI資訊是特定於TRDL還是XL。關於在為WTRU排程以攜帶TRDL CSI的PUCCH中傳送每TTI的短期XL CSI回饋，也可以考慮諸如標誌位元這樣的識別字以指出該PUCCH正攜帶XL CSI。諸如CQI或PMI這樣的XL CSI可重新使用現有的PUCCH格式。對於在專用於XL的PUCCH排程中傳送每TTI的短期XL CSI回饋，PUCCH的排程可在攜帶XLG的PDCCH DCI格式中隱式或顯式地用信號發送。
在另一個實施方式中，可使用基於每TTI CSI的長期獲得的速率和頻道統計。這樣的統計可包括例如平均吞吐量測量或在XLG有效期間使用它們的標準差的平均XL CQI等同測量。平均和統計分析可由實體層根據在專用RRC信令中傳遞的配置來執行。
由於長期XL CSI回饋可能沒有大有效負載，它可類似於每TTI的短期回饋那樣被傳輸。並且，因為長期回饋可能沒有高等待時間要求，它還可在UL授權可獲得時被攜帶在PUSCH上的MAC PDU中。長期XL CSI回饋報告可由eNB使用用於資料傳輸的UL授權來請求。
大體來說，短期或長期XL回饋可向網路提供頻道狀況資訊以幫助評估分配的XL資源被使用得怎麼樣。
對於XL功率餘量（XLPH），LTE網路可評估UL排程決策以便在PUSCH功率餘量報告的幫助下確定授權中MCS和帶寬的有效率的組合。功率餘量可以是最大WTRU傳輸功率和假設無WTRU傳輸功率限制時可使用的經功率控制的資料頻道傳輸功率之間的差的測量。傳輸功率可由WTRU使用授權的MCS、授權的帶寬、授權的路徑損耗和接收的TPC命令來每TTI地計算。類似於XLFB，可使用目前LTE網路方法，並且也可以考慮每TTI的短期和長期功率餘量報告兩者。例如，在每個XLG有效期間，平均功率餘量值及其標準差可被報告給網路以確定在給定的頻道狀況下藉由授權帶寬傳送目標速率要求的功率等級。每TTI的短期功率餘量可基於授權的最大傳輸功率等級如下地來計算（並非如在LTE UL功率餘量中使用的WTRU最大傳輸功率）：

其中P_XLG是授權的XL功率，BW_TX是傳輸帶寬（其可與BWXLG（即授權的帶寬）相同），P_Nominal是在助手WTRU或終端WTRU處期望的功率等級，PL是助手WTRU和終端WTRU間的路徑損耗，Δ_TF是XPDDCH的預定義傳輸格式的預定義函數，並且TPC是接收的TPC位元的預定義函數。
在以上示例中，在括號中項的和是在子訊框i中的傳輸功率。另外，除了XLPH外，還可有考慮TRL和XL傳輸的另一個PHR，這可能需要網路中的新程序。在此討論的功率餘量可受限於XL的功率餘量。
在XLG有效期間，網路例如可為每TTI的短期功率餘量計算配置若干子訊框，並且WTRU可執行平均或其他類型的統計分析來獲得長期功率餘量。每TTI的短期和長期PHR可在例如專用於XL PHRR的新MAC控制元素或具有修改來容納交叉鏈路PHR的用於PHR的現有MAC控制元素（例如擴展的功率餘量MAC控制元素）的其中之一中被傳送。
XL PHR可被請求或由預定義的事件集合來觸發。例如，XL短期和/或長期PHR可在例如XL路徑損耗有顯著改變、預定義數目的單向TPC命令被應用或在預定義數目的子訊框上的每TTI的短期功率餘量值生成超過預定義閾值的長期功率余量時被報告。
對於在指派的子載波組中接收的信號測量，信號等級可被用來評估達到的XL SINR，並且還可被用來推導在XL功率控制中使用的P_Nominal。干擾計算可基於對所有偵測到的XL特定參考信號的寬頻類比能量測量和碼功率測量。可假定XL特定參考信號使用授權功率無改變地被連續傳輸。因此，結合的這兩個測量可提供XL的SINR並識別主要干擾XL。在為兩個助手WTRU被指派相同的特定參考信號的罕見情況下，終端WTRU將不能區分這兩個參考信號，結果終端WTRU可發現參考信號的良好SINR，卻遭受惡化的XPDCCH/XPDDCH塊錯誤率（BLER）性能。XL信號測量還以位元圖的形式被報告給網路以減少信令負擔。信號測量可能要求在預配置的期間平均和過濾，並且傳輸可以MAC PDU的形式應用PUSCH。
當相關的XL回饋、功率餘量和測量報告被攜帶在PUSCH中時，可要求網路指派與測量請求和/或配置相關聯的PUSCH授權。
當在LTE UL中應用SPS時，WTRU可根據相同的UL授權來傳送，直到SPS被去啟動。由於頻率指派和MCS固定，傳輸功率可僅使用TPC命令來調節。作為一個選項，XLG還可固定帶寬和其他傳輸配置，但MCS除外。參與AT-R和AT-LO應用的WTRU可基於頻道狀況、業務變化和ACK/NACK接收來調整MCS。MCS可進一步被應用於計算XL傳輸功率。這可被認為是為了顯著減少信令負擔的益處指定給與鏈路適應相關的WTRU的受限程度的WTRU自主權。網路可以仍然按理斷言在XL傳輸上的近乎完全的控制，因此提議的XLG可被視為保留網路控制的功能。
以下描述的XLG程序可概述可應用於WTRU獲取初始XLG、接收更新的XLG和執行和報告用於網路XLG確定的測量的事件序列。這些程序可在不同的AT應用間改變並分開地來討論。
初始XLG可由在AT-R應用中列出的事件來觸發，例如終端WTRU傳輸XSR/BSR或網路為行動終止的連接傳呼處於RRC IDLE模式的終端WTRU。XSR/BSR事件的終端WTRU傳輸可在若干程序中存在，包括例如來自終端WTRU的行動發起連接、助手WTRU/終端WTRU關聯或從活動的助手WTRU到備用助手WTRU的終端WTRU切換。網路為行動終止連接事件傳呼處於RRC IDLE模式的終端WTRU可特定於AT-R覆蓋模式。當網路在覆蓋模式中傳呼處於RRC IDLE模式的終端WTRU時，助手WTRU可藉由在XPDACH中警示終端WTRU關於該到來的傳呼並促使終端WTRU讀取在XPDSACH或XPGCH中的XLG來將傳呼消息轉發給終端WTRU。換句話說，助手WTRU可將傳呼指示符與XLG一起發送，終端WTRU可將其用於讀取在XPDDCH中的傳呼消息。
在AT-LO應用中，初始XLG可結合本地卸載WTRU到WTRU呼叫建立程序來發佈。初始XLG獲取可在鄰居搜索WTRU可在若干鄰近的鄰居存在WTRU中找到鄰居候選者的鄰居發現程序之後。在AT-R應用的情況下，鄰居存在WTRU的其中之一被配置為助手WTRU。
在TRDL上，初始和更新XLG例如可從攜帶在PDCCH中的新裝置類別識別字（DCI）格式、攜帶在PDSCH中的新MAC控制元素、攜帶在PDSCH中的新MAC控制元素或在PDSCH中的專用RRC信令的其中之一的網路中被傳送。對於攜帶在PDCCH中的新DCI格式，為了減少對DPCCH盲解碼努力的衝擊，可重新使用現有的DCI格式。解碼選項可包括例如使用胞元無線電網路臨時識別字（C-RNTI）來解碼在WTRU特定搜索空間中的PDCCH，和當WTRU參與AT應用時使用指定給WTRU的新XL特定RNTI（例如AT-RNTI或XL-RNTI）。對於使用C-RNTI來解碼在WTRU特定搜索空間中的PDCCH，例如在AT-R應用中，助手WTRU和終端WTRU可使用它自己的C-RNTI來分別接收助手WTRU XLG和終端WTRU XLG。對於使用新的XL特定RNTI，AT-RNTI可以是每XL的。PDCCH傳輸可以是健壯的，因此XLG可高可靠性地被接收。然而，此選項可要求更多的網路PDCCH容量，並且可增加WTRU PDCCH解碼努力。對於在PDSCH中攜帶的新MAC控制元素，XLG的半靜態屬性可不強加對傳輸等待時間的高要求，並且PDSCH可被用於XLG傳輸。然而，PDSCH可遭受較高的BLER，並且目前的MAC控制元素不具有應答。對於在PDSCH中的專用RRC信令，可使用新的資訊元素（IE），並且RLC應答可向網路提供對於XLG是否已被正確接收的狀態。
在AT-R覆蓋模式中的XL上，初始和更新XLG可在例如XPDDCH、XPDSACH、XPGCH或攜帶在XPDDCH中的新MAC控制元素的其中之一中從助手WTRU傳送給終端WTRU。對於XPDCCH，XLG可以XL上的其他控制資訊多工處理。對於XPDSACH，由於實體頻道是未排程的，XLG傳輸可引起系統中更多的干擾。對於XPGCH，用於XLG傳輸的專用實體頻道以增加系統信令負擔為代價提供了較高的可靠性。
實體控制和資料XLG傳輸兩者可經歷差錯，因此XLG可能丟失。為了確保可靠的XLG傳輸，WTRU可供給XLG保全機制以通知網路關於XLG傳輸失敗並提示重新傳輸。例如，當WTRU在正在進行的XLG期滿前未接收到更新XLG時，WTRU可掛起XL通訊以便不引起不協調的干擾。然而，網路可能不知道WTRU丟失XLG，特別是對以MAC控制元素形式的XLG傳輸。在該情況下，WTRU可應用新的實體層類型的回饋以指示接收XLG的失敗。該回饋可以是在PUCCH中傳輸的1位元應答。當接收到更新XLG時，WTRU可發送肯定應答（ACK），並且還可以子訊框為單位將計時器設定為關於子訊框預配置的值（其可從接收的XLG有效期間推導）。如果當該計時器期滿時未接收到更新XLG，WTRU可發送否定應答（NACK）以觸發來自網路的XLG重新傳輸。
該XLG重新傳輸機制可不被應用於初始XLG傳輸。如果初始XLG傳輸失敗，WTRU可根據預定義的協定重新傳輸SR/BSR。eNB因此可以從該SR/BSR重新傳輸推斷以前的XLG未被WTRU適當地接收，從而重新傳輸XLG。
第35A圖和第35B圖包括在容量模式中示例初始授權獲取程序和更新XLG操作的信號圖3500A/3500B。在第35A圖和第35B圖顯示的示例中，鄰居搜索WTRU 3502、鄰居存在WTRU 3504和eNB 3506可參與鄰居發現程序。一旦鄰居發現程序完成，一個鄰居存在WTRU可被選定為終端WTRU 3508的候選助手WTRU 3510（3512）。終端WTRU 3508和助手WTRU 3510兩者均處於RRC 連接模式3514/3516。
當助手WTRU 3510和終端WTRU 3508兩者都從eNB 3506接收到關聯消息時（3517/3518），助手WTRU 3510和終端WTRU 3508可使用胞元特定XL配置執行XL測量（3519/3520）。這樣的XL測量可包括測量由網路廣播的指派給該胞元的XL BW（可指派XL資源的粒度可被預定義（例如子載波組或子帶配置））和測量由網路廣播的XL特定參考信號碼組或基礎序列組。XL測量可由助手WTRU 3510和終端WTRU 3508分別在XUL和XDL上做出。每對XDL/XUL的特徵可以例如是為XL特定參考信號指派的子載波組和/或唯一的碼序列。
當XL應用TDD方案時，相同的子載波組可被指派給一個XL的XDL和XUL兩者。使用FDD方案，指派給一個XL的XDL和XUL的子載波組可由雙工距離來分開。在兩種雙工情況下，相同的序列或碼可被用於XDL和XUL兩者。在一個指派的子載波組處偵測到的XL特定參考信號可指示現有的XL，並且網路可嘗試避免使用相同的子載波組和參考信號的組合來發佈XLG。
例如，如果XDL可被劃分為X個子帶和Y個可指派的序列或碼，則為了向網路提供資源使用的全面描述（thorough picture），終端WTRU可能需要詳細地陳述在每個子帶中偵測到多少序列碼。如果該序列實現是基於ZC的並且從通用根序列的循環位移產生，該根序列的功率延遲預設檔（PDP）的通用頻域計算可使用單一操作（single operation）提供從相同根序列導出的所有簽名的連續（concatenated）PDP。這可減少每子帶的測量的數目。XDL測量結果可被用來構建X乘Y位元大小的點陣圖，其中每個位元指示該序列或碼是否在子帶中被偵測到。換句話說，點陣圖可展示什麼碼和頻率資源在測量終端WTRU附近被其他XDL佔用。點陣圖格式可減少XLG所需的信令負擔。
因為在AT-R容量模式中的助手WTRU和終端WTRU均具有TRUL連接，XL測量報告可作為對XLG導出的輸入在PUSCH上被發送給eNB（3522、3524）。終端WTRU還可經由PUCCH傳送XL SR或經由PUSCH傳送XL BSR。網路可例如評估什麼碼和子帶對報告助手WTRU/終端WTRU來說是可用的，並據以做出指派。初始助手WTRU/終端WTRU XLG可在例如PDSCH上以MAC控制元素的形式被發送（3526/3528）。通常與控制頻道相比，XLG的資料頻道傳輸的潛在問題可能是相對高的差錯率。HARQ重新傳輸可同樣失敗，並且可能接收不到攜帶初始XLG的PDU。在該情況下，可依賴XSR重新傳輸計時器來觸發XSR/BSR的另一個傳輸以嘗試重獲初始XLG。XLG還可被攜帶在到WTRU特定搜索區域中的助手WTRU和終端WTRU的PDCCH中，以實現XLG傳輸的高可靠性。它可能需要新的DCI格式，其可增加WTRU盲解碼的數目。該DCI格式可具有小有效負載或具有與具有修改欄位的現有DCI格式的其中之一相同數目的位元。在PDCCH中攜帶XLG可能需要在網路中增加PDCCH容量。
當助手WTRU 3510和終端WTRU 3508接收到XLG時，它們可應用這些XLG，並在計時器、接收XLG時參考的預定義時間間隔或預指定的開始時間的幫助下開始同步資料通訊（3530）。助手WTRU 3510和終端WTRU 3508可開始跟蹤有效期間並應用XLG配置以在應用TDD的情況下遵循雙工配置、傳送XL特定參考信號、傳送XPDCCH/XPDDCH和XPUCCH/XPUDCH和/或傳送用於XPDDCH和XPUCCH的DMRS。對於傳送XL特定參考信號，助手WTRU 3510和終端WTRU 3508兩者可傳送XL特定參考信號，並且助手WTRU的信號可用於終端WTRU 3508而與助手WTRU 3510同步（助手WRTU的定時和頻率可以是主）。此外，助手WTRU參考信號可由終端WTRU 3508用來執行頻道估計（以解碼XPDCCH）、確定回饋測量（例如CQI）和/或推導傳輸功率控制（TPC）位元。終端WTRU參考信號也可被應用於那些目的，但不可被用於同步目的。
每個助手WTRU/終端WTRU可在XLG中指定的相同帶寬上傳送，並且基於接收的ACK/NACK和CQI來調整MCS。因此，CQI可在相同的帶寬上被測量，因為沒有頻率選取排程可被使用在XL上。CQI可提供對MCS的推薦。可替換地，可探測指派的XLG帶寬的頻率選擇性，並且助手WTRU/終端WTRU可報告在授權帶寬中不同子載波組更精確的CQI，並在不同的帶寬上動態地排程傳輸。XLS資訊可在專用控制頻道（例如XPDCCH）中在XL上被傳送。排程資訊可包括例如MCS、子載波資源（如果可調整傳輸帶寬）、新的資料指示符或者冗餘版本。這些位元使用用諸如AT-RNTI這樣的XL識別擾亂的循環冗餘校驗（CRC）位元來保護。
對於基於選取的MCS和授權的帶寬的每個TTI每個助手WTRU/終端WTRU（其在XLG有效期間可以是不變的）可例如基於下式計算XPDDCH/XPUDCH傳輸功率：

其中P_XLG是授權的XL功率，BW_TX是傳輸帶寬（其可與BWXLG或授權帶寬相同），P_Nominal是在助手WTRU或終端WTRU處期望的功率等級，PL是在助手WTRU和終端WTRU間的路徑損耗，Δ_TF是XPDDCH的預定義傳輸格式的預定義函數，並且TPC是接收的TPC位元的預定義函數。
助手WTRU和終端WTRU之間的路徑損耗可基於XL特定參考信號來計算，假設該信號總是應用在XLG中指定的最大允許功率P_XLG。同樣，P_Nominal可以是給定其干擾等級的助手WTRU和終端WTRU處的期望或目標功率。因此，+PL的值表示基本開放迴路開始點。在LTE UL控制中的等同參數可包括諸如例如可在-126到+24 dBm範圍內並可被用來導出不同BLER操作點以實現重新傳輸的低可能性的P_{O_NOMINAL_PUSCH}、或可在-8到+7 dB範圍內並可被用來補償由於在估計的路徑損耗中的差錯引起的WTRU傳輸功率中的系統偏移的P_{O_UE_PUSCH}這樣的分量。
P_{O_NOMINAL_PUSCH}可經由網路廣播被用信號發送給WTRU，並且P_{O_UE_PUSCH}可經由專用信令用信號發送給WTRU，因此它們在本質上也可以是半靜態的。對於XL，P_Nominal可包括在XLG中並可基於發送給網路的XL測量報告被更新。Δ_TF可以是選取的MCS的函數，並且TPC可以是接收的TPC位元的函數。
結合2層排程，分散式功率控制函數可由WTRU執行。換句話說，XLS中的TPC命令可由助手WTRU和終端WTRU基於接收的品質（例如參考符號的SINR和/或資料傳輸的BLER）使用預定義演算法導出。TPC命令可在專用XL控制頻道中被傳送，或者可在通用控制頻道中與其他控制資訊多工。TPC速率可比每TTI一次的慢，並且可以是設計參數。LTE FDD系統可在在接收到TPC位元的子訊框後4個子訊框應用TPC位元。
在一個實施方式中，專用控制和資料頻道可以是時間多工的。例如，在XDL中，XPDCCH在每個TTI中可在XPDDCH之前，並且終端WTRU可能需要讀取該XPDCCH以獲取解碼XPDDCH所需的所有資訊並繼續在相同的TTI中接收XPDDCH。例如，這可類似於LTE DL，其中WTRU可在解碼在相同TTI中的PDSCH之前讀取PDCCH。然而，當終端WTRU基於從網路接收的授權排程傳輸時，這可能是在XDL和XUL兩者上的情況。如果專用控制和資料頻道未在頻域中多工，則一個益處可能是減少無線電要求，在該情況下助手WTRU/終端WTRU傳輸功率在所有子載波上可能是相同的。這可能還暗示XL專用控制頻道可具有與可更適於針對控制頻道格式和有效負載的XL專用資料頻道不同的功率控制機制。例如，子訊框i的XPDCCH可基於下式被計算：

其中Δ_TF是XPDCCH的預定義傳輸格式的函數。另外，應用於XPDCCH傳輸的帶寬可被預定義並是該函數的因素。如上所述，TPC是由WTRU執行的分散式功率控制函數。
對於每個傳輸，助手WTRU/終端WTRU可使用計算出的傳輸功率來導出XLPH。另外，一有來自網路的請求，它們可使用與發佈的XLG直接相關的配置繼續XL測量（3532/3534）。例如，網路可請求在特定的子載波組上的特定信號強度測量以幫助將XLG更新最佳化，而不是在初始XLG前報告的點陣圖。在該情況下，測量結果可以是在請求的子載波組中請求的XL特定參考信號的信號強度。該結果可以類似於在LTE網路中接收的信號碼功率（RSCP）的方式來量化，並可被考慮在LTE UL中的實體頻道上傳輸。例如，該結果可與諸如CQI位元這樣的UL控制資訊位元一起在PUCCH中傳輸、除PUCCH外還可以在新的專用實體XL回饋頻道中傳輸，或在PUSCH中攜帶的XL RRC測量中傳輸。
參考第35A圖和第35B圖，助手WTRU 3510和終端WTRU 3508可執行請求的XL測量，並在PUSSCH上向eNB 3506發送一個或多個XL測量報告（3536/3538/3540/3542）。
實體頻道傳輸可得益於低等待時間，但可能需要額外的PUCCH資源。可替換地，測量結果可在TRUL授權是可獲得時以與PUSCH中CQI多工類似的方式與PUSCH進行多工。在AT-R容量模式中，XL RRC測量可以與常規鄰居胞元測量相同的方式被請求、配置和報告。在AT-R覆蓋模式中，終端WTRU可以沒有RRC實體，因此助手WTRU可能需要在PUSCH中向網路轉發該終端WTRU測量。
助手WTRU和終端WTRU的測量可在使用TDD方案的XL情況下在它們的接收子訊框中發生，並且在FDD方案的情況下在指定帶中發生。可能需要測量間隙配置來暫停TRL傳輸。一接收到所有XL測量，網路可更新XLG以最佳化資源分配和協調交叉鏈路間干擾（3548）。
在一個實施方式中，功率控制機制可在XLG被更新前被管理以在維持QoS的同時藉由調整P_XLG來促進功率資源的有效使用（3544）。例如，當指派的帶寬不改變地應用時，傳送WTRU可根據指派的P_XLG和功率控制公式計算最大MCS。後續的資料傳輸可造成在接收WTRU處測量的預定義期間的BLER比。接收WTRU然後可基於該BLER比來生成TPC命令以調整功率，並且單向TPC命令的連續數目可觸發功率餘量報告。例如，當功率多於遞送MCS所需時，接收WTRU可發送若干連續的DOWN TPC命令，其可以被預定義為PHR觸發，並且傳送WTRU可向eNB報告功率餘量。然後eNB可在下一個授權中減少P_XLG。一旦XLG已被更新，資料傳輸可被恢復（3550）。
第36A圖和第36B圖包括容量模式中另一個示例初始授權獲取程序和更新XLG操作的信號圖3600A/3600B。然而，在第36A圖和第36B圖顯示的示例中，終端WTRU 3602和助手WTRU 3604初始地處於RRC IDLE模式（3608/3610）。終端WTRU 3602和助手WTRU 3604的每一個參與與eNB 3606的傳呼程序（3612/3614），在其後終端WTRU 3602和助手WTRU 3604兩者都處於RRC CONNECTED模式（3616/3618）。在圖示的示例中，當助手WTRU 3604和終端WTRU 3602兩者轉換到RRC CONNECTED模式時，eNB 3606基於這對WTRU的歷史XLG向終端WTRU 3602和助手WTRU 3604的每一個發送測量請求和配置（3620/3622）。第36圖顯示的剩餘信令和程序與在第35A圖和第35B圖中顯示的實施方式相同，並且給相應的信號/程序在第35A圖、第35B圖、第36A圖和第36B圖中相同的元件符號。
第37A圖和第37B圖包括在覆蓋模式中示例初始授權獲取和繼續的XLG更新程序的信號圖3700A/3700B。在AT-R容量和覆蓋模式中XLG程序間的主要不同可能是由在終端WTRU處缺乏TRL引起的。例如，在AT-R覆蓋模式中，XLG可經由XL被傳送給終端WTRU，來自終端WTRU的所有XL測量可由它的助手WTRU中繼給網路，並且可實施新的安全機制來預防XL傳輸上XLG丟失。
在第37A圖和第37B圖顯示的示例中，鄰居搜索WTRU 3702、鄰居存在WTRU 3704和eNB 3706參與鄰居發現程序，在其之後鄰居WTRU 3704被選為候選助手WTRU（3708）。鄰居搜索WTRU 3702和選擇的候選助手WTRU 3704然後可在XPDSACH上交換關聯消息（3710）。鄰居搜索WTRU 3702和候選助手WTRU 3704然後可交換RRC消息。然而，候選助手WTRU 3704可在XPDSACH上傳送它的RRC消息（3710）。它的RRC消息可包括基本系統資訊，例如候選助手WTRU的胞元ID和臨時行動用戶識別（TMSI）或助手WTRU的C-RNTI（3712）。鄰居搜索WTRU 3702在XPUSACH上傳送它的RRC消息。它的RRC消息可包括候選助手WTRU 3704已被選取為助手WTRU的指示（3714）。如果必要的話，選取的助手WTRU 3704和eNB 3706然後可參與RACH和RRC連接建立程序（3715），在其之後選取的助手WTRU 3704處於RRC CONNECTED模式（3718）並且現在鄰居搜索WTRU 3702是終端WTRU 3716。
選取的助手WTRU 3704可在XPDACH上向終端WTRU 3716傳送選擇指示符（3720）。作為響應，終端WTRU 3716可在XPUACH上向選取的助手WTRU 3704發送XSR，並在XPUSACH上進行XL測量（3722）。選取的助手WTRU 3704然後可在PUCCH上向eNB 3706發送XSR，並在PUSCH上進行XL測量（3724）。
選取的助手WTRU 3704可從eNB 3706接收初始助手WTRU/終端WTRU XLG（3726）。為了向終端WTRU 3716轉發XLG，選取的助手WTRU 3704可在XPDSACH或XPGCH中向終端WTRU傳送初始XLG（3727）。對於XPDSACH，XPDACH可指示供終端WTRU 3716讀取的在XPDSACH中的XLG。XPDSACH是資料頻道，並且XLG可以是類似於在用於LTE系統的RACH存取響應（RAR）中使用的MAC控制元素或MAC PDU的形式。對於XPGCH，XPDACH可指示在XPGCH中的XLG。XPGCH可以僅是PHY頻道，並且XLG可以是控制位元的形式。選取的助手WTRU 3704現在可以是活動的助手WTRU 3728。
終端WTRU 3716、助手WTRU 3728和eNB 3706可在初始XLG後開始資料傳輸（3730）。eNB 3706可在PDSCH上向助手WTRU 3728發送XL測量請求和配置消息（3732），並且助手WTRU 3728可在XPDCH上將該XL測量請求和配置轉發給終端WTRU 3716（3734）。作為響應，終端WTRU 3716可在XPUDCH上向助手WTRU 3728發送XL測量報告（3736），並且助手WTRU 3728可在PUSCH上將該測量報告轉發給eNB 3706（3738）。該程序必要時可以重複（例如3740/3742）。eNB 3706然後可參與最佳化每個XL的授權功率等級的程序（3744）。
助手WTRU 3728可在PDSCH上從eNB 3706接收更新的助手WTRU/終端WTRU XLG（3746）。為了向終端WTRU 3716轉發該更新的XLG，助手WTRU 3728可在XPDSACH/XPGCH、XPGCH、XPDDCH或XPDDCH中向終端WTRU 3716傳送更新XLG（3748）。對於XPDSACH/XPGCH（未排程的PHY頻道），助手WTRU 3728可以它進行初始XLG相同的方式傳送更新XLG。在XLG被更新後，可恢復正常傳輸（3750）。
在一個實施方式中，如在AT-R容量模式中那樣，到終端WTRU的初始XLG傳輸可使用XSR重新傳輸來保證（例如，如果未收到初始XLG，終端WTRU可根據計時器來重新傳輸XSR）。然而，一旦更新XLG丟失，它們不可恢復，並且終端WTRU然後可暫停它的傳輸。在該情況下，助手WTRU可偵測到在XUL上的無線電鏈路故障（RLF）。因此可能需要新的處理來避免不必要的RLF。例如，當助手WTRU偵測到與更新XLG有效期間開始一起的突然XUL特定參考信號測量劣化，助手WTRU可嘗試重新傳輸更新XLG以瞭解參考信號等級是否恢復。可替換地，如果在正在進行的XLG的有效期間，沒有從助手WTRU接收到更新XLG，終端WTRU可在XPUCCH中傳送丟失更新XLG的指示。這可觸發助手WTRU向終端WTRU重新傳輸。這種類型的防止XLG丟失的保全機制在XLG攜帶在具有比實體層控制頻道高的錯誤率的資料頻道中時可能是有用的。
應用在AT-LO應用中的XLG程序可類似於結合AT-R容量模式討論的程序，因為參與AT-LO應用的所有WTRU可與網路相關聯。AT-LO應用可採用不同的實體頻道集合，包括例如可被用來將XLG攜帶給所有叢集成員的XL實體叢集頭廣播頻道（XPCHBCH）。並且，指派的XLG可以是每叢集的，並且叢集頭可在多個XL上執行更擴展的XL排程。例如，可需要叢集頭來根據每個XL的頻道狀況和業務量變化動態地將由XLG分配的資源排程給不同的XL。每個叢集成員可關於叢集頭提供如上所述那樣的類似測量以幫助排程決策。
實施例
1．一種在第一節點和第二節點間的無線電交叉鏈路上的無線電資源排程方法，該方法包括第一節點接收指定由至少第一節點用於在無線電交叉鏈路上的傳輸的資源的交叉鏈路授權。
2．根據實施例1所述的方法，進一步包括第一節點在在交叉鏈路授權中指定的資源內執行每傳輸時間間隔（TTI）的交叉鏈路排程。
3．根據實施例2所述的方法，進一步包括第一節點基於每TTI的交叉鏈路排程向第二節點傳送至少一個封包。
4．根據實施例1-3的任一個所述的方法，其中交叉鏈路授權是最大允許交叉鏈路傳輸功率、交叉鏈路帶寬的指派、交叉鏈路功率控制參數的提供或在交叉鏈路上所有實體頻道的指定碼配置的至少一個。
5．根據實施例2-4的任一個所述的方法，其中第一節點執行每TTI的交叉鏈路排程包括基於頻道狀況回饋動態地調整在在交叉鏈路授權中指定的帶寬上使用的調變和編碼方案。
6．根據實施例2-5的任一個所述的方法，其中第一節點執行每TTI的交叉鏈路排程包括基於在交叉鏈路授權中指定的調變和編碼方案、在交叉鏈路授權中指派的交叉鏈路帶寬、在交叉鏈路授權中指定的交叉鏈路路徑損耗和在交叉鏈路授權中提供的傳輸功率控制命令來計算相應的需要的傳輸功率。
7．根據實施例1-6的任一個所述的方法，其中交叉鏈路授權包括有效期間，在其之後該交叉鏈路授權不再有效。
8．根據實施例1-7的任一個所述的方法，其中交叉鏈路授權是基於交叉鏈路信號和干擾測量、交叉鏈路功率餘量報告或交叉鏈路回饋測量的至少一個。
9．根據實施例2-8的任一個所述的方法，其中每TTI的交叉鏈路排程是基於在交叉鏈路授權中指定的資源以及交叉鏈路應答/非應答（ACK/NACK）消息或頻道品質指示符（CQI）的至少一個。
10．根據實施例1-9的任一個所述的方法，其中第一和第二節點是無線傳輸/接收單元（WTRU）。
11．根據實施例1-9的任一個所述的方法，其中第一和第二節點是增強型節點B（eNB）。
12．一種無線傳輸/接收單元（WTRU）包括：接收器，被配置為接收無線電鏈路控制（RLC）協定資料單元（PDU）；本地緩衝器；和部分RLC層。
13．根據實施例12所述的WTRU，其中部分RLC層被配置為將接收的RLC PDU儲存在本地緩衝器中的基於邏輯頻道的頻道佇列中。
14．根據實施例13所述的WTRU，其中部分RLC層進一步被配置為為儲存在基於邏輯頻道的頻道佇列中的接收的RLC PDU設定丟棄計時器。
15．根據實施例14所述的WTRU，其中部分RLC層進一步被配置為在WTRU經由無線電交叉鏈路中繼RLC PDU之前丟棄計時器期滿的情況下，從本地緩衝器中丟棄接收的RLC PDU。
16．根據實施例12-15的任一個所述的WTRU，其中WTRU被配置為藉由經由傳統無線電鏈路與基地台通訊和經由無線電交叉鏈路與其他WTRU通訊來在基地台和另一個WTRU之間中繼資料。
17．根據實施例12-16的任一個所述的WTRU，其中其他WTRU不位於由基地台操作的胞元中。
18．根據實施例16或17所述的WTRU，進一步包括被配置為向其他WTRU傳送被WTRU丟棄的所有RLC PDU中最高的RLC PDU的序列號的傳輸器。
19．根據實施例16-18的任一個所述的WTRU，進一步包括被配置為在傳輸塊大小在傳統無線電鏈路和無線電交叉鏈路之間不同的情況下，為在傳統無線電鏈路和無線電交叉鏈路間中繼資料執行RLC重新分段的處理器。
20．根據實施例12-19的任一個所述的WTRU，其中WTRU被配置為藉由在包括WTRU和基地台之間的傳統無線電鏈路和在WTRU和其他WTRU之間的無線電交叉鏈路的中繼路徑上與基地台和其他WTRU通訊來在基地台和另一個WTRU之間中繼資料，基地台和其他WTRU被配置為藉由包括傳統無線電鏈路的直接路徑上互相通訊。
21．根據實施例20所述的WTRU，其中分開的資料無線電承載（DRB）被建立以分別經由直接路徑和中繼路徑來攜帶資料。
22．一種高級拓撲（AT）系統，包括被配置為操作無線胞元的基地台和包括第一無線傳輸/接收單元（WTRU）和被配置為在第一無線電交叉鏈路上與第一WTRU通訊的第二WTRU的多個WTRU。
23．根據實施例22所述的AT系統，其中多個WTRU進一步包括第三WTRU和被配置為在第二無線電交叉鏈路上與第三WTRU通訊的第四WTRU。
24．根據實施例23所述的AT系統，其中第一WTRU、第二WTRU、第三WTRU和第四WTRU被配置為接收指定由第一WTRU、第二WTRU、第三WTRU和第四WTRU用於在第一無線電交叉鏈路和第二無線電交叉鏈路上的傳輸的資源的交叉鏈路授權。
25．根據實施例24所述的AT系統，其中第一WTRU和第二WTRU被配置為在用於第一無線電交叉鏈路上的傳輸的交叉鏈路授權中指定的資源內協商每傳輸時間間隔（TTI）的第一交叉鏈路排程，並且基於每TTI的第一交叉鏈路排程在第一無線電交叉鏈路上傳送至少一個封包。
26．根據實施例24或25所述的AT系統，其中第三和第四WTRU被配置為在用於第二無線電交叉鏈路上的傳輸的交叉鏈路授權中指定的資源內協商每TTI的第二交叉鏈路排程，並基於每TTI的第二交叉鏈路排程在第二無線電交叉鏈路上傳送至少一個封包。
27．根據實施例22-26的任一個所述的AT系統，其中多個WTRU進一步包括多個其他WTRU對，多個其他WTRU對的每一對被配置為經由個別的無線電交叉鏈路在它們自身內通訊。
28．根據實施例27所述的AT系統，其中在胞元內的每個無線電交叉鏈路被指派給多個頻率重新使用組的一個。
29．根據實施例28所述的AT系統，其中被指派給多個頻率重新使用組的特定一個的每個無線電交叉鏈路被授權在交叉鏈路授權中提供的交叉鏈路帶寬的專用部分。
30．根據實施例22-29的任一個所述的AT系統，其中第一WTRU和第二WTRU的其中之一被配置為在基地台與第一WTRU和第二WTRU的另一個間中繼資料的第一助手WTRU。
31．根據實施例23-30的任一個所述的AT系統，其中第三WTRU和第四WTRU的其中之一被配置為在基地台與第三WTRU和第四WTRU的另一個間中繼資料的第二助手WTRU。
32．根據實施例22-31的任一個所述的AT系統，其中第一和第二助手WTRU的每一個包括部分無線電鏈路控制（RLC）層。
33．根據實施例32所述的AT系統，其中部分RLC層被配置為在本地緩衝器的基於邏輯頻道的頻道佇列中儲存接收的RLC協定資料單元（PDU）。
34．根據實施例33所述的AT系統，其中部分RLC層被進一步配置為為儲存在基於邏輯頻道的頻道佇列中的接收的RLC PDU設定丟棄計時器。
35．根據實施例34所述的AT系統，其中部分RLC層進一步被配置為在RLC PDU經由個別第一或第二無線電交叉鏈路被中繼前丟棄計時器期滿的情況下從本地緩衝器丟棄接收的RLC PDU。
36．根據實施例32-35的任一個所述的AT系統，其中第一和第二助手WTRU的每一個被配置為向第一和第二WTRU的另一個傳輸被該WTRU丟棄的所有RLC PDU中最高的RLC PDU序列號（HDSN）。
37．根據實施例36所述的AT系統，其中第一和第二WTRU的另一個的每一個被配置為響應於從第一和第二助手WTRU的其中之一接收到HDSN，將第一和第二WTRU的另一個的接收窗的下邊緣更新為HDSN+1。
38．根據實施例30-37的任一個所述的AT系統，其中第一和第二助手WTRU的每一個進一步被配置為向基地台傳送從由請求用於上鏈傳輸的初始交叉鏈路授權的交叉鏈路上鏈排程請求、請求用於下鏈傳輸的初始交叉鏈路授權的交叉鏈路下鏈排程請求、用於由基地台以及該WTRU和另一個WTRU的其中之一聯合地確定在交叉鏈路上鏈中的排程的終端WTRU緩衝狀態報告、用於由基地台和該WTRU聯合地確定在交叉鏈路下鏈中的排程的交叉鏈路下鏈漢城狀態報告以及用於由基地台、該WTRU和另一個WTRU聯合地確定交叉鏈路排程的交叉鏈路功率餘量報告機制組成的組中選取的至少一個媒體存取控制（MAC）狀態報告。
39．根據實施例22-38的任一個所述的AT系統，其中第一WTRU、第二WTRU、第三WTRU和第四WTRU的每一個位於無線胞元中。
儘管以上以特定的組合描述了特徵和元素，但是本領域具通常知識者將理解，每個特徵或元素可以單獨地或與其它的特徵和元素任意組合地使用。此外，在此描述的方法可在包括在由電腦或處理器執行的電腦可讀取媒介中的電腦程式、軟體或韌體中實現。電腦可讀取媒介的示例包括電子信號（藉由有線或無線連接傳送）和電腦可讀取儲存媒介。電腦可讀取儲存媒介的示例包括但不限制為唯讀記憶體（ROM）、隨機存取記憶體（RAM）、暫存器、緩衝記憶體、半導體記憶體裝置、諸如內部硬碟和可移除磁片這樣磁性介質、磁光介質和諸如CD-ROM光碟和數位通用光碟（DVD）這樣的光介質。與軟體相關聯的處理器可用來實現在WTRU、UE、終端、基地台、RNC或任何主電腦中使用的無線電頻率收發器。
A diagram of an example communication system 100 in which one or more of the disclosed embodiments can be implemented in FIG. 1A. Communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. Communication system 100 enables multiple wireless users to access such content by sharing system resources including wireless bandwidth. For example, communication system 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), etc.
As shown in FIG. 1A, communication system 100 can include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, radio access network (RAN) 104, core network 106, public switched telephone network (PSTN). 108, the Internet 110 and other networks 112, but it will be understood 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), mobile stations, fixed or mobile subscriber units, pagers, cellular Telephones, personal digital assistants (PDAs), smart phones, laptops, portable Internet devices, personal computers, wireless sensors, consumer electronics, and more.
Communication system 100 can also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b can be of any type configured to form a wireless interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more, such as the core network 106, the Internet 110. And a device of a communication network such as network 112. By way of example, base stations 114a, 114b may be base station transceiver stations (BTS), node B, eNodeB, home node B, home eNodeB, site controller, access point (AP), wireless Router, etc. While each of the base stations 114a, 114b is depicted as a single component, it should be understood that the base stations 114a, 114b can 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), a relay node. Wait. Base station 114a and/or base station 114b can be configured to transmit and/or receive wireless signals within a particular geographic area that can be referred to as a cell (not shown). The cell can be further divided into cell sectors. For example, a cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one for each sector of a cell. In another embodiment, base station 114a may employ multiple input multiple output (MIMO) technology, and thus multiple transceivers may be used for each sector of the cell.
The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via the air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 can be established using any suitable radio access technology (RAT).
More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base station 114a and WTRUs 102a, 102b, 102c in RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wide Frequency CDMA (WCDMA) to establish an air interface 116. 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).
In another embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-Advanced ( LTE-A) to establish air interface 116.
In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement, for example, IEEE 802.16 (ie, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000) Radio technology such as Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN).
The base station 114b in FIG. 1A may be, for example, a wireless router, a home Node B, a home eNodeB, or an access point, and any suitable RAT may be used to facilitate wireless connectivity in a local area, such as a business location, home, Vehicles, campuses, etc. In one embodiment, base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In still another embodiment, base station 114b and WTRUs 102c, 102d may use cell-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Yuan (femtocell). As shown in FIG. 1A, the base station 114b can be directly connected to the Internet 110. Therefore, the base station 114b does not need to access the Internet 110 via the core network 106.
The RAN 104 can communicate with a core network 106, which can be of any type configured to provide voice, data, applications, and/or via an internet protocol to one or more of the WTRUs 102a, 102b, 102c, 102d Voice over Internet (VoIP) service. For example, core network 106 may provide call control, billing services, location based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in FIG. 1A, it should be understood that the RAN 104 and/or the core network 106 can communicate directly or indirectly 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 employ an E-UTRA radio technology, the core network 106 may also be in communication with another RAN (not shown) employing a GSM radio technology.
The core network 106 can 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 a circuit switched telephone network that provides Plain Old Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices that use a universal communication protocol, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol in the TCP/IP Internet Protocol suite ( IP). Network 112 may include a wired or wireless communication network that is owned and/or operated by other service providers. For example, network 112 may include another core network that is connected to one or more RANs that may employ the same RAT as RAN 104 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, 102d may include communications for communicating with different wireless networks over different wireless links. Multiple transceivers. For example, the WTRU 102c shown in FIG. 1A can be configured to communicate with a base station 114a that can employ a cell-based radio technology and a base station 114b that can employ an IEEE 802 radio technology.
FIG. 1B is a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keyboard 126, a display/trackpad 128, a non-removable memory 130, and a removable Memory 132, power source 134, global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be understood that the WTRU 102 may include any sub-combination of the aforementioned elements, consistent with the embodiments.
The processor 118 can 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 associated with the DSP core, a controller, a micro control , dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), state device, etc. The processor 118 may perform signal encoding, 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 can be coupled to a transceiver 120 that can be coupled to the transmit/receive element 122. Although FIG. 1B illustrates processor 118 and transceiver 120 as separate components, it will be appreciated that processor 118 and transceiver 120 can be integrated together in an electronic package or wafer.
The transmit/receive element 122 can be configured to transmit to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, the transmit/receive element 122 can be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be a transmitter/detector configured to, for example, transmit and/or receive IR, UV or visible light signals. In yet other embodiments, the transmit/receive element 122 can be configured to transmit and receive both RF and optical signals. It will be appreciated that the transmit/receive element 122 can be configured to transmit and/or receive any combination of wireless signals.
Moreover, although the transmit/receive element 122 is depicted as a single element in FIG. 1B, 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 transmission/reception elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals through the air interface 116.
The transceiver 120 can be configured to modulate the signal to be transmitted by the transmission/reception element 122 and demodulate the signal that is received by the transmission/reception element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Accordingly, transceiver 120 may include, for example, a plurality of transceivers for enabling WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.
The processor 118 of the WTRU 102 can be coupled to a speaker/microphone 124, a keyboard 126, and/or a display/touchpad 128, such as a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit, and Receive user input data from them. The processor 118 can also output user profiles to the speaker/microphone 124, the keyboard 126, and/or the display/trackpad 128. In addition, processor 118 can access information from any type of suitable memory, such as non-removable memory 130 and/or removable memory 132, and store the data therein. Non-removable memory 130 may include random access memory (RAM), read only memory (ROM), hard disk, or any other type of memory device. The removable memory 132 can 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 (e.g., on a server or a home computer (not shown).
The processor 118 can receive power from the power source 134 and can be configured to allocate and/or control power to other elements in the WTRU 102. Power source 134 can be any suitable device for powering WTRU 102. For example, the power source 134 may include one or more dry cells (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 a GPS chipset 136 that may be configured to provide location information (e.g., longitude and latitude) with respect to the current location of the WTRU 102. In addition to or in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base station 114a, 114b) via air interface 116, and/or based on signals from two or more nearby base stations. The timing of the reception determines its position. It will be appreciated that the WTRU 102 may obtain location information by any suitable location determination method consistent with the implementation.
The processor 118 can be further coupled to other peripheral devices 138, which can include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, peripheral device 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photo or video), a universal serial bus (USB) port, a vibrating device, a television transceiver, hands-free headset, Bluetooth R module, FM radio unit, digital music player, media player, TV game module, internet browser, etc.
1C is a system diagram of RAN 104 and core network 106, in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c via the air interface 116. The RAN 104 also communicates with the core network 106.
The RAN 104 may include eNodeBs 140a, 140b, 140c, but it will be understood that the RAN 104 may include any number of eNodeBs consistent with the embodiments. Each of the eNodeBs 140a, 140b, 140c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c via the air interface 116. In one embodiment, the eNodeBs 140a, 140b, 140c may implement MIMO technology. Thus, eNodeB 140a, for example, may use multiple antennas to transmit wireless signals to and receive wireless signals from WTRU 102a.
Each of the eNodeBs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, users in the uplink and/or downlink Schedule and so on. As shown in FIG. 1C, the eNodeBs 140a, 140b, 140c can communicate with each other on the X2 interface.
The core network 106 shown in FIG. 1C may include an active management gateway (MME) 142, a service gateway 144, and a packet data network (PDN) gateway 146. While each of the above elements is illustrated as being part of core network 106, it will be understood that any of these elements may be owned and/or operated by entities other than the core network operator.
The MME 142 may be coupled to each of the eNodeBs 142a, 142b, 142c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 142 may be responsible for authenticating the users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular service gateway during initial attachment of the WTRUs 102a, 102b, 102c, and the like. The MME 142 may also provide control plane functionality for switching between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.
The service gateway 144 can be coupled to each of the eNodeBs 140a, 140b, 140c in the RAN 104 via an S1 interface. The service gateway 144 is generally routable and forwardable to user data packets from/to the WTRUs 102a, 102b, 102c. The service gateway 144 may also perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging, managing and storing the context of the WTRUs 102a, 102b, 102c when the downlink information is available to the WTRUs 102a, 102b, 102c Wait.
The service gateway 144 can also be coupled to a PDN gateway 146 that can provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the Internet 110, to facilitate the WTRUs 102a, 102b, Communication between 102c and the IP boot device.
The core network 106 facilitates communication with other networks. For example, core network 106 may provide WTRUs 102a, 102b, 102c with access to a circuit-switched network, such as PSTN 108, to facilitate communications between WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, core network 106 may include or be in communication with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that interfaces between core network 106 and PSTN 108. In addition, core network 106 can provide WTRUs 102a, 102b, 102c with access to network 112, which can include other wired or wireless networks that are owned and/or operated by other service providers.
FIG. 2 is a system diagram of the LTE-A relay system 200. The illustrated LTE-A relay system includes a supply cell 202, a relay node 204, and a terminal WTRU 206. The supply cell 202 and the relay node 204 communicate with each other via the backhaul link 208. Relay node 204 and terminal WTRU 206 communicate with one another via access link 210. Relay node 204 can be configured to relay PDCP Service Data Units (SDUs) between provisioning cell 202 and terminal WTRU 206. The backhaul link 208 and the access link 210 can operate completely independently of each other.
FIG. 3 is a block diagram of a layer 2 (L2) stack 300 for the LTE-A relay system 200 of FIG. As described above, the backhaul link 208 and each access link 210 have their own complete L2 stack, including the complete MAC, RLC, and PDCP layers, all of which are in the supply cell 202, the relay node 204, and the terminal WTRU. Termination at 206. Thus, in the embodiment illustrated in FIG. 3, the supply 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 supply cell 302 communicates with the PDCP layer 320 of the relay node 304, the RLC layer 312 of the supply cell 302 communicates with the RLC layer 322 of the relay node 304, and the MAC layer 314 and the relay node of the cell 302 are supplied. The MAC layer 324 of 304 communicates, the PDCP layer 340 of the terminal WTRU 306 communicates with the PDCP layer 326 of the relay node 304, the RLC layer 342 of the terminal WTRU 306 communicates with the RLC layer 328 of the relay node 304, and the MAC layer of the terminal WTRU 306 344 communicates with the MAC layer 330 of the relay node 304.
In order to operate a handover of a Type 1 relay node in an RLC Answer Mode (AM), the source relay node may forward any unsent PDCP SDUs to the target relay node via the source and target provisioning eNBs in order to achieve lossless handover. Assuming that most traffic is based on Transmission Control Protocol (TCP) and the TCP protocol should provide sufficient traffic control capabilities, flow control cannot be applied with current LTE Type 1 trunk configurations.
In LTE, if the PDCP SDU is too long in the transmit buffer, the PDCP SDU drop can be used to clear the PDCP SDU. This can reduce the delay of subsequent data when the PDCP SDU buffer is full of delay data caused by, for example, possible physical link errors. When the PDCP SDU enters the PDCP buffer, the drop timer associated with it can begin. When the timer expires, if no fragment of the SDU has been mapped to the RLC PDU, the PDCP SDU is discarded. The timeout value of the drop timer can be configured by a higher layer.
In addition, in LTE, the scheduling is done by the eNB on the network side. The UL scheduling decision requires the WTRU to send a MAC status report to the eNB. For example, the WTRU may send a UL Scheduling Request (ULSR) if the WTRU wants to initiate a UL data transmission. As another example, the WTRU may also send a buffer status report (BSR) for each logical channel group at the WTRU. As another example, a WTRU may send a power headroom report (PHR) measured at the WTRU. The ULSR is sent via a Physical Uplink Control Channel (PUCCH) or by a Random Access Channel (RACH) procedure. The BSR and PHR are transmitted on the UL Service Channel (UL-SCH) by the MAC Control Element.
Additionally, in LTE, scheduling is channel dependent and is performed by the eNB to dynamically allocate resources for UL and downlink (DL) data channels on a per transmission time interval (TTI) basis. The granularity of resource allocation is implemented in resource blocks (RBs), which are clusters of 12 consecutive subcarriers occupying one TTI. LTE scheduling applies orthogonal multiple access in both DL and UL to ensure that WTRUs associated with the same cell use orthogonal resources without intra-cell interference in any given TTI. Furthermore, the UL transmission power per TTI on the assigned resources is adjusted by UL power control.
In an attempt to optimize a set of performance metrics, the LTE scheduling algorithm typically considers the range of input parameters, which may include, for example, maximum/average/minimum throughput, maximum/average/minimum delay, total/per user spectral efficiency, and Outage probability. The user experience is directly affected by the above performance metrics. Typical input parameters include quality of service type identification (QCI), channel quality indicator (CQI), BSR, acknowledgment/non-acknowledgement (ACK/NACK), and resource allocation history.
As mentioned above, scheduling is applied to both traditional downlink (TRDL) and 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 band. The physical channels carried on the TRDL include a Physical Downlink Shared Channel (PDSCH), a Physical Broadcast Channel (PBCH), a Physical Multicast Channel (PMCH), an Entity Control Format Indicator Channel (PFICH), and an Entity Hybrid Automatic Repeat Request (HARQ). Indicator Channel (PHICH). The TRDL also carries a physical signal including reference and synchronization signals. 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 band. The physical channels carried on the TRUL include a Physical UL Shared Channel (PUSCH), a Physical UL Control Channel (PUCCH), and a Physical Random Access Channel (PRACH). TRUL also carries a reference signal.
The TRDL/TRUL scheduling information is transmitted to each WTRU with the help of a Device Type Identifier (DCI) format carried in the DL PDCCH for each TTI. The DL schedule takes effect in the same subframe where the DL DCI is received. However, the UL grant is valid in several subframes after receiving the subframe of the UL DCI (eg, 4 subframes in an LTE Frequency Division Duplex (FDD) system).
The LTE network has full control over the resource allocation for 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.
In contrast to the Type 1 relay nodes described above that use high power, stationary relay nodes, it is described herein to use direct WTRU-to-WTRU communications and/or direct base-to-base station communications over the network and such as terminal WTRUs or terminals. Relay data between the destination entities of the base station ("AT relay" or "AT-R" mode) or to transfer data directly between the WTRU or the base station ("AT Local Offload" or "AT-LO" mode The implementation of the advanced topology (AT) network. For example, in one embodiment, a smart phone or base station can be configured to act as your infrastructure node in addition to its primary role to operate in AT-R and/or AT-LO mode. In an AT-R implementation, the terminating WTRU or base station may exchange data with the network by another WTRU or base station, referred to as the assistant WTRU or the assistant base station, respectively. In the AT-R, any WTRU may act as a terminal WTRU or a facilitator WTRU at different times and may use 2 hop settings to relay data between the terminal WTRU and the eNB. In a 2-hop setting, the first hop may be between the terminal WTRU and the assistant WTRU or between the eNB and the assistant WTRU, and depending on whether the transmission is in the UL or DL, the second hop may be during the first hop The range used. In an AT-LO implementation, WTRUs that are adjacent to each other can participate in direct data communication with each other under the control of the central network. Although all embodiments are described herein with respect to relay entities and destination entities for a WTRU, all embodiments are equally applicable to relay entities that are any type of node, such as a base station (eg, an eNB), and/or A destination entity of any type of node, such as a base station (e.g., an eNB).
The AT-R implementation can be used to increase capacity (capacity mode or AT-RCap) and coverage (overlay mode or AT-RCov) in a cellular system. In AT-RCap, the helper WTRU may increase the radio link capacity between the existing WTRU and the base station to increase the capacity of the network and increase the capacity of data transmission. In AT-RCov, the facilitator WTRU may be used to provide coverage for WTRUs that are not in the coverage area and therefore do not have a link to the base station.
In AT-RCov for a baseline LTE cellular system, for example, if the WTRU registers with the network (eg, it is in the EMM-REGISTERED state), it can decode the broadcast channel (BCH) from the appropriate cell in the network and read Primary System Information (SI), which decodes the paging channel (PCH) and reads the paging message and secondary SI, which can reach the cell using the RACH procedure in IDLE mode or PUCCH/PUSCH in CONNECTED mode, and it can By transmitting and receiving a specific minimum data rate through the PUSCH and PDSCH, it can be considered to be in the coverage area. WTRUs that do not meet these criteria may be considered to be outside the coverage area and may continue to undergo cell reselection until they find the appropriate cell. At the same time, for emergency call purposes, they can camp on any available cell, but cannot be paged. In the AT-RCov implementations described herein, such a non-coverage WTRU (e.g., a potential terminal WTRU) may be provided with coverage by the facilitator WTRU. However, in order to utilize AT-RCov, the WTRU still has to have network synchronization and timing.
In an AT-LO implementation, two neighboring WTRUs may initiate a local offload transmission under the control of the central network. In one embodiment, a neighboring set of WTRUs may be assigned to a cluster having a cluster header specified by the network. In this embodiment, the cluster head can communicate directly with each cluster member and can be responsible for access control and radio resource management (RRM) for all cross-links (XL) between the various WTRU pairs in the cluster. Under the coordination and control of the cluster head, the cluster members can apply direct WTRU-to-WTRU communications.
The WTRU's communication to the WTRU can be applied to many real-world scenarios with significant potential benefits. For example, a user with very poor coverage within a building may obtain coverage and additional capacity by a well-aided assistant WTRU located around or outside the building. As another example, users who are close together and need to exchange data or have a voice session can do so directly without routing data/voice through the base station and the core network. For example, colleagues in the office can conduct conversations and exchange materials in this way. 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 also enables a true wireless gaming experience with extremely low latency by connecting directly to the user rather than by network routing. If multiple users are downloading similar information from the network, the network can transmit the data to a smaller subset of users who can then relay the data to other end users. For example, a user in the stadium who wishes to view an instant replay of an event on the venue may fall into that category. Users in different vehicles traveling along highways can form direct links and transmit information to each other. One potential application could be to have an accident/traffic instant messaging relayed to vehicles that are further behind the same road so that they can be redirected.
In AT-R and AT-LO implementations, inter-WTRU communications may occur in a dedicated manner known as a cross-link (XL), as opposed to traditional eNB-to-WTRU communications occurring, for example, over traditional radio links (TRLs). In the channel. For an AT-LO implementation, the XL can be used for communication between a pair of WTRUs, and for an AT-R implementation, the XL can be used for communication between the assistant WTRU and the terminal WTRU pair. In one embodiment, it may be assumed that the XL channel is sufficiently separate from the TRL such that no inter-carrier or adjacent channel interference occurs between the TRL and the XL. In this embodiment, the XL may require a separate radio frequency (RF) transceiver chain. However, in-band operation of the XL is also possible. In one embodiment, the XL resource can be set out of band with respect to the TRL. Similar to, for example, baseline LTE, the XL channel can use OFDM for its physical layer (PHY) multiplex processing. The assistant and terminal WTRUs can communicate with each other using FDD or Time Division Multiplexing (TDD), and the associated configuration can be defined by the network. In one embodiment, the network may provide coarse resource allocation for the XL, and the WTRU (eg, one or both of the facilitator WTRU and the terminal WTRU) may have the freedom to process each TTI resource allocation.
FIG. 4 is a diagram of an example XL PHY frame structure 400. In the example shown in FIG. 4, the XL PHY frame structure includes a number of frames (e.g., 440 and 450) and corresponding sub-frames (e.g., 402, 404, 406, 408, and 410). The sub-frames 402, 404, 406, 408, and 410 include a number of different areas, including a neighbor discovery area 412, an unscheduled control area 414, a normal control area 416, and a data area 418.
Neighbor discovery area 412 appears twice in each frame, appears once in each direction, or appears based on a network configuration. For example, frame 440 includes an occurrence 412b of neighbor discovery area 412 and an occurrence 412d of neighbor discovery area 412 in subframe 406 in subframe 402. Only one sub-frame 410 of frame 450 is shown in FIG. 4, and sub-frame 410 includes an occurrence 412f of neighbor discovery area 412. However, frame 450 includes additional sub-frames (not shown), and one of the additional sub-frames may include an additional occurrence of a neighbor discovery area. During the Neighbor Discovery Zone (e.g., 412a), the WTRU may transmit a Neighbor Discovery Initial Transport (NDIT) 422 and wait for Neighbor Discovery Response Transport (NDRT) 420.
In each subframe (eg, 402, 404, 406, 408, and 410), time-frequency resources may be divided into unscheduled control area (UCZ) 414, normal control area (NCZ) 416, and data area (DZ). 418. In an alternative embodiment (not shown), the neighbor discovery area may be considered part of the subframe structure, in which case the subframe may also be considered to be in the same direction as the neighbor discovery area (eg, transmit or receive).
UCZ 414 includes a set of predetermined resources that can appear in each frame (once in each direction) or in a specific frame that can be calculated based on a Cell System Frame Number (SFN) (eg, based on network configuration). . Therefore, all XLs in a cell can have a UCZ in the same frame. For example, frame 440 includes an occurrence 414b of UCZ 414 in subframe 402 and an occurrence 414d of UCZ 414 in subframe 406. Only one sub-frame 410 of frame 450 is shown in FIG. 4, and it does not include the presence of UCZ. However, frame 450 includes additional sub-frames (not shown), and some of the additional sub-frames may include the presence of UCZ.
In the example shown in FIG. 4, the neighbor looking WTRU may use UCZ 414a to transmit to the neighboring presence WTRU an indication that it has been selected by the neighbor as the prospective WTRU ("Assistant WTRU Pick Message") (426). The UCZ may also be used by the neighboring WTRU to look to the neighbor for the WTRU to transmit basic system information to cause the association to form (424). These transmissions may occur prior to association formation and may potentially be transmitted without scheduling resources from the eNB. Thus, multiple neighbor presence WTRUs can transmit basic system information in the same UCZ, which can provide diversity benefits. The helper WTRU picking messages from multiple neighbors looking for WRTUs may overlap at the same WTRU, but may be separated using, for example, an PHY scrambling mechanism.
NCZ 416 appears in each subframe. In the example shown in FIG. 4, each of the sub-frames 402, 404, 406, 408, and 410 includes individual NCZ occurrences 416b, 416c, 416d, 416e, and 416f. Only one sub-frame 410 of the frame 450 is shown in FIG. However, frame 450 includes additional sub-frames (not shown), each of which may include the presence of an NCZ. In addition, in the example shown in FIG. 4, the NCZ (eg, 416a) may be used for the XL entity DL Control Channel (XPDCCH) 428, the XL Entity UL Control Channel (XPUCCH) 430, the keep-alive message, and the association. The transmission of the message.
DZ 418 appears in each subframe of the frame. In the example shown in FIG. 4, each of the sub-frames 402, 404, 406, 408, and 410 includes individual DZs 418b, 418c, 418d, 418e, and 418f. Only one sub-frame 410 of the frame 450 is shown in FIG. However, frame 450 includes additional sub-frames (not shown), each of which may also include the presence of DZ. DZ (e.g., DZ 418a) may be used to transmit inter-WTRU data transport blocks (TBs), e.g., on cross-link DL (XDL) shared channel (XPDSCH) 432 and XUL shared channel (XPUSCH) 434. The DZ may also include a reference signal that enables the WTRU to make measurements of the XL.
For an AT-R implementation, the XL may include several physical channels in the XDL and XUL. The XDL is the radio access link from the facilitator WTRU to the terminal WTRU. It applies to the assistant WTRU and the terminal WTRU and operates in the XL band. The XUL is the radio access link from the terminal WTRU to the facilitator WTRU. It applies to the helper WTRU and the terminal WTRU and operates in the XL band. The XDL physical channel may include, for example, an XL entity neighbor discovery channel (XPNDCH), an XL entity DL associated channel (XPDACH), an XL entity DL shared access channel (XPDSACH), an XL entity authorized channel (XPGCH), an XL entity DL feedback channel (XPDFBCH). ), XL entity DL data channel (XPDDCH) and XL entity DL control channel (XPDCCH). The XUL physical channel may include, for example, an XL entity neighbor discovery channel (XPNDCH), an XL entity UL associated channel (XPUACH), an XL entity UL shared access channel (XPUSACH), an XL entity UL feedback channel (XPUFBCH), an XL entity UL data channel ( XPUDCH) and XL entity UL Control Channel (XPUCCH). The XUL may also carry a reference signal including, for example, an XL specific reference signal and a keep alive signal. In one embodiment, the XL physical channel is assumed to be OFDM based.
The XPNDCH may carry a sequence of neighbor discovery transmissions including Neighbor Discovery Initial Transmission (NDIT) and Neighbor Discovery Response Transmission (NDRT). In one embodiment, the XPNDCH may occupy preset and predefined symbol and subcarrier resource locations that are not subject to XL authorization or scheduling control. The XPNDCH may apply code division multiple access (CDMA), and the code configuration may be derived by the WTRU, for example, according to a predefined algorithm. When the XL bandwidth is greater than the preset frequency resource, the network may allocate additional resources (such as subcarriers) for the channel to increase the neighbor discovery capacity.
The XPDACH may carry PHY control information including, for example, a paging indicator, an associated transmission/reception (TX/RX) indicator, or an XL grant (XLG) indicator. In one embodiment, the XPDACH can occupy preset and predefined symbol locations that are not subject to XL authorization (XLG) or scheduling control. The XPDACH may apply Frequency Division Multiple Access (FDMA) and/or CDMA, and the configuration may be derived by the WTRU based on the code configuration of its previously associated XPNDCH.
The XPUACH may carry PHY control information including, for example, XL Scheduling Request (XSR) and XL Measurement Indicator. In one embodiment, the XPUACH can occupy preset and predefined symbol locations that are not subject to XLG and scheduling control. The XPUACH may apply FDMA and/or CDMA, and the configuration may be derived by the WTRU based on the code configuration of its previously 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 Assistant WTRU information. In one embodiment, the XPDSACH can occupy preset and predefined symbol locations that are not subject to XL authorization or scheduling control. The XPDSACH may apply FDMA and/or CDMA, and the configuration may be derived by the WTRU based on the configuration of its associated XPDACH. In one embodiment, the information necessary to decode the channel, such as the transmission format, can be predefined.
The XPUSACH can carry higher layer control information including, for example, XL measurements. In one embodiment, XPUSACH can occupy preset and predefined symbol locations that are not subject to XLG or scheduling control. The XPUSACH may apply FDMA and/or CDMA, and the configuration may be derived by the WTRU based on the configuration of its associated XPUACH. In one embodiment, the information necessary to decode the channel, such as the transmission format, can be predefined.
The XPGCH may carry XLG information including, for example, subcarrier allocation, TDD subframe duplexing scheme, maximum XL power, dedicated XL channel code configuration, and reference signal configuration. In one embodiment, the XPGCH can occupy preset and predefined symbol locations, which can be uncontrolled by XLG or scheduling. The XPGCH may apply FDMA and/or CDMA, and the configuration may be derived by the WTRU based on the configuration of its associated XPDACH. This unscheduled version of XPGCH can only exist in the AT-R overlay mode. In the AT-R capacity mode and the coverage mode, the XLG for the facilitator WTRU may also specify the full resource configuration of the channel for the XL dedicated to the XLG transmission from the facilitator WTRU to the terminal WTRU, and in this case, the XPGCH may Application space, time, frequency or code division multiple access. In one embodiment, the channel may only be applied on the XDL.
The XPDFBCH can carry XUL's Channel Status Information (CSI) and ACK/NACK for XUL data transmission. In one embodiment, the full resource allocation for the channel may be determined by the XLC of the facilitator WTRU. XDFBCH can apply space, time, frequency or code division multiple access.
The XPDDCH can carry XDL user data received from the MAC layer. In one embodiment, the full resource allocation for this channel may be determined by the XLC of the facilitator WTRU. XPDDCH can apply space, time, frequency or code division multiple access.
The XPDCCH may carry data related to control information of the XPDDCH decoded by the terminal WTRU in the same TTI. In one embodiment, the full resource allocation for this channel may be determined by the XLC of the facilitator WTRU. The XPDCCH can apply space, time, frequency or code division multiple access.
The XPUFBCH can carry the channel status information of XDL and the ACK/NACK of XDL data transmission. In one embodiment, the full resource allocation for this channel may be determined by the XLC of the terminal WTRU. XUFBCH can apply space, time, frequency or code division multiple access.
The XPUDCH can carry XUL user data received from the MAC layer. In one embodiment, the full resource allocation for this channel may be determined by the XLC of the facilitator WTRU. XPUDCH can apply space, time, frequency or code division multiple access.
The XPUCCH can carry the control information necessary for the assistant WTRU to correctly decode the XPUDCH. In one embodiment, the full resource allocation for this channel may be determined by the XLC of the terminal WTRU. XPUCCH can apply space, time, frequency or code division multiple access.
In one embodiment, the XL physical channels can be divided into two groups. The first group can be used without XLG (eg, any XL can be transmitted and received in these channels in relation to a collection of predefined programs). The second group may include all physical channels dedicated to a particular XL.
The first group may include XPNDCH, XPDACH, XPUACH, XPDSACH, XPDUSACH, and SPGCH. In one embodiment, the potential helper WTRU may use XPDSACH to transmit BSI to its potential terminal WTRU without the network grant in the ongoing neighbor association procedure. Although the XPDSACH transmission does not require network authorization, it can follow all necessary information including the detection and decoding of the channel (eg when to transmit XPDSACH related to the neighbor discovery procedure, how to encode and modulate, XPDSACH and include in the MAC PDU) What information) of the predefined agreement. The unscheduled attributes of the channel group can subject them to competition. CDMA based schemes (eg different XPDSACH using different orthogonal sequence spreading) can be used to minimize the probability of competition.
The second group may include XPDFBCH, XPUFBCH, XPDCCH, XPUCCH, XPDDCH, XPUDCH, and XPGCH. In one embodiment, these channels are only available after receiving an XLG from the network.
The reason for dividing the channel into groups may be to allow XL physical layer transmission without network intervention (eg, when the WTRU outside the coverage is establishing higher layer signaling in the neighbor association procedure). Thus, unscheduled channels may be specifically used for AT-R coverage implementations due to the lack of association of the terminal WTRU with the network. For the AT-LO implementation and the AT-R implementation, when the trunk is established and the network authorization is received, no unscheduled channels can be used except for XPNDCH, and all XLs are authorized according to the network. Specific communications can be carried on the scheduled channel.
Figure 5 is a diagram 500 of an example of different possibilities for multiplexing different XL physical channels into different types of XL subframes. For each of the example sub-frames 502, 520, and 540 shown in FIG. 5, the network-assigned XL bandwidth (BW) and minimum XL BW (eg, 72 sub-carriers) are displayed. In one illustrative example, XPNDCH 504A, guard period 506A, XL specific reference signal 508A, XPDCCH and XPDFBCH 510A and XPDDCH and demodulation variable reference signal (DMRS) 512A are multiplexed into XDL subframe 502 by XPNDCH. In another illustrative example, XL-specific reference signals 508B, XPDCCH and XPDFBCH 510B and XPDDCH and DMRS 512B are multiplexed in XDL data subframe 520. In another illustrative example, XPNDCH 504b, guard period 506B, XL unscheduled reference signal 514, XL physical access channel (XPACH) 516, and XL slow access channel (XSACH) 518 are multiplexed by XPNDCH. The shared accessible subframe 540 is shared.
The MAC layer can provide services to the RLC in the form of logical channels. The type of logical channel may be a control channel for controlling the transmission of information and configuration information or a traffic channel for carrying user data. The XL logical channel may include an XL Physical Control Channel (XPCCH), an XL Universal Control Channel (XCCCH), an XL Dedicated Control Channel (XDCCH), and an XL Dedicated Service Channel (XDTCH).
The PHY may provide services to the MAC in the form of a transmission channel, and the XL transmission channel may include an XL paging channel (XPCH), an XL universal channel (XCCH), an XDL scheduling channel (XDL-SCH), and a XUL scheduling channel (XUL-SCH). . The material on the transmission channel can be organized into transport blocks, and in one embodiment, one transport block of a particular size can be transmitted in each TTI. For implementations that employ special multiplexing (eg, MIMO), up to two transport blocks can be transmitted in one TTI.
6A, 6B, 6C, and 6D are diagrams of example channel mappings between logic, transmission, and physical channels on the XL.
Figure 6A is an example channel map 600A for XDL. In the example shown in FIG. 6A, the logical channels for XPCCH 602, XCCCH 604, XDCCH 606, and XDTCH 608, XPCH 610, XCCH 612, and XDL-SCH 614 DL transmission channels, and XPDSACH 616, XPDDCH 618, XPDACH are shown. Mapping of 620, XPDCCH 622, XPDFBCH 624, XPGCH 626, and XPNDCH 628 DL physical channels. Figure 6B is an example channel map 600B for XUL. In the example shown in FIG. 6B, the XCCCH 604, XDCCH 606, and XDTCH 608 UL logical channels, XCCH 612, and XUL-SCH 630 UL transmission channels, as well as XPUSACH 632, XPUDCH 634, XPUCCH 636, XPUACH 638, XPUFBCH are shown. Mapping of 640 and XPNDCH 628 UL physical channels. Figure 6C is an example channel map 600C for XDL. In the example shown in FIG. 6C, the channel for PCCH 642, XCCCH 604, DCCH 644 and DTCH 646 DL, XPCH 610, XCCH 612 and XDL-SCH 614 DL transmission channels and XPCDCCH 648, XPDSCH 650, XPACH 652 are shown. Mapping to the XPDCCH 622 DL physical channel. Figure 6D is an example channel map 600D for XUL. In the example shown in FIG. 6D, the XCCCH 604, DCCH 644 and DTCH 646 UL logical channels, XCCH 612 and XUL-SCH 630 UL transmission channels, and XPUCCH 654, XPUSCH 656, XPUCCH 636 and XPACH 652 UL physical channels are shown. Mapping.
The embodiments described below provide enhancements to the features of the AT system to enable the normal WTRU to effectively act as a facilitator WTRU that relays data between the terminal WTRU and the eNB, and in some embodiments provides data offload between the WTRUs. In one embodiment, the L2 architecture for the facilitator WTRU is described for relaying data between the terminal WTRU and the eNB. Such an embodiment may include using a partial RLC that may be transparent to the eNB and the terminal WTRU at the assistant WTRU. Such an architecture supports scheduling flexibility between TRL and XL. In another embodiment, a method is described for discarding data that is delayed in a buffer of a helper WTRU and notifying the terminal WTRU of the discarded material. In this embodiment or in an alternative embodiment when using different L2 architectures, a flow control mechanism may be implemented to prevent the assistant WTRU buffer from overflowing because the facilitator WTRU may have a relatively limited buffer space or be limited to the assistant WTRU. The amount of data buffered to reduce the delay caused by data buffering. In one embodiment, a data resegmentation mechanism is described to initiate independent scheduling on TRL and XL. In one embodiment, a new MAC status report for coverage extension mode that is sent from the facilitator WTRU to the terminal WTRU that can be reported to the eNB to support the XL schedule is described. In one embodiment, a two-level scheduling approach is described for XL, where the first level is centralized and the semi-static XLG is published by the network, the second level is decentralized and the dynamic XL scheduling (XLS) can be made by the WTRU itself. carried out.
Figure 7A is a block diagram 700 of an L2 stack 702 for an AT system including a MAC layer (718/720) and a partial RLC layer 722 at the assistant WTRU 704. In the example shown in FIG. 7A, an L2 stack for eNB 703, helper WTRU 704, and terminal WTRU 706 is shown. The displayed eNB 703 includes a PDCP layer 708, an RLC layer 710, and a MAC layer 712, the displayed helper WTRU 704 includes a partial RLC layer 722 and a MAC layer 718/720, and the displayed terminal WTRU 706 includes a PDCP layer 713, an RLC layer 714, and a MAC. Layer 716.
In an embodiment of the partial RLC layer 722, the automatic repeat request (ARQ) function in the RLC AM mode terminates only at the eNB 703 and the terminal WTRU 706, but not at the assistant WTRU 704. Thus, in this embodiment, the helper WTRU 704 does not retransmit the data according to the RLC ARQ function. This allows the RLC to avoid data loss for seamless assistant WTRU actions in the RLC AM mode. The RLC re-segmentation can be used to rebuild the transport block (TB) for the second hop, if desired. In one embodiment, two separate HARQ entities, one for the XL and the other for the TRL, may be included at the assistant WTRU. However, other configuration options for HARQ at the assistant WTRU are also possible.
In one embodiment, the RLC PDUs arriving at the Assist WTRU 704 may be stored in a logical channel based queue, which may allow data to be discarded on a per logical channel basis. Discard timer information for each logical channel can be exchanged as part of the configuration information. When the partial RLC layer 722 buffers the RLC PDU in a logical channel based queue, if the RLC PDU is considered to be delayed due to, for example, its associated discard timer expires, the partial RLC layer 722 may discard the RLC PDU, when necessary, The second hop re-segmentates the RLC PDU and transmits the highest dropped sequence number (HDSN) by the second hop in the RLC AM mode. The L2 stack 702 can be applied to both UL and DL.
In an RCap mode embodiment, all signaling between the terminal WTRU and the eNB may be accomplished by a direct path in the legacy radio link between the eNB and the terminal WTRU, while the data may flow through the direct path or relay Path (including the legacy radio link between the eNB and the facilitator WTRU and the XL between the facilitator WTRU and the terminal WTRU). In one embodiment, separate data radio bearers (DRBs) may be established to carry data by direct path and relay path, respectively. In another embodiment, a generic DRB can be used for both direct path and relay path. In this embodiment, the PDCP PDU can split between the two paths. For RCov mode, data can only flow through the relay path.
Figure 7B is a diagram 750 of an example system architecture for an embodiment in which separate DRBs are established to carry data by direct path and relay path, respectively. In the example shown in FIG. 7B, the eNB 772 communicates with the terminal WTRU 770 via the direct path 774 and the relay path. The relay path is a path between the legacy radio link 776 between the eNB 772 and the assistant WTRU 778 and the eNB 772 and the terminal WTRU 770 of the XL 777 between the facilitator WTRU 778 and the terminal WTRU 770. The Assistant WTRU protocol stack 700 shown in Figure 7B is identical to the Assistant WTRU protocol stack 700 in Figure 7A. The direct path protocol stack 752 for the eNB 772 and the terminal WTRU 770 includes the same entities that may typically be included in the LTE protocol stack, including the PDCP layers 754 and 762, the RLC layers 756 and 764, the MAC layers 758 and 766, and the PHY layer 760 and 768.
In an embodiment mode of RCov mode, the helper WTRU may be used for both signaling and data transfer. Therefore, access stratum (AS) security may need to be established by the helper WTRU. Since the LTE protocol supports mutual authentication and relay protection with the use of temporary identifiers, establishing security for the AS by the facilitator WTRU may not cause new security considerations. The PDCP layer is responsible for encryption and integrity protection. The facilitator WTRU may operate at the MAC/H-ARQ level and may not interpret the encrypted terminal WTRU data. The encrypted and/or integrity protected terminal WTRU data may be tunneled by the facilitator WTRU.
Figure 8 is a flow diagram 800 of a method of discarding delay data at the assistant WTRU on the DL. In one embodiment, the eNB 703 may send a TB per TTI to the helper WTRU 704. The MAC layer 718/720 of the facilitator WTRU 704 may parse the MAC headers in the received TBs to identify the MAC SDUs and RLC PDUs for each logical channel. The helper WTRU 704 may store the received RLC PDU in a logical channel based queue (802) and turn on the discard timer associated with each RLC PDU stored in the local buffer (804). The helper WTRU 704 can then determine if the drop timer has expired (806). The aide WTRU 704 may discard the RLC PDU from the local buffer (808) if the drop timer expires before the corresponding RLC PDU is sent to the terminal WTRU 706 via the XL. The facilitator WTRU 704 can then determine if the RLC PDU has been discarded (810). In RLC AM mode, if at least one RLC PDU has been dropped, the facilitator WTRU 704 may send the highest sequence number (SN) (HDSN) among the dropped RLC PDUs to the terminal WTRU 706 using the new type of STATUS PDU, Receive (Rx) window (812) at the WTRU at the mobile terminal. The facilitator WTRU 704 does not expect to receive an ACK/NACK for receiving/non-receiving STATUS PDUs from the terminal WTRU 706. Based on the XDL grant, the facilitator WTRU 704 may use the buffered RLC PDU, if necessary, applying RLC re-segmentation (see the detailed description of RLC re-segmenting below) to establish the XL MAC PDU. The helper WTRU 704 and eNB 703 can perform flow control on a per-logical basis on the TRL to prevent local buffer overflow. A similar embodiment can be applied on the UL.
Because the helper WTRU forwards data between different radio links (eg, TRL and XL), the facilitator WTRU may be configured to perform re-segmentation in the case of a transport block size (TBS) that is different between TRL and XL Forward information between roads. For the RLC AM mode, the helper WTRU may perform re-segmentation of the first hop RLC AM PDU using the normal RLC protocol.
Figure 9 is a diagram of a header 900 for RLC unacknowledged mode (UM) segmentation that the helper WTRU may use to perform re-segmentation on the first hop RLC UM PDU. The example header 900 for RLC UM PDU segmentation shown in FIG. 9 includes the same PDU Segmentation Indication (RF) 906, Last Segmentation Flag (LSF) 916 and minutes as included in the RLC AM PDU of the normal RLC protocol. Segment Offset (SO) fields 918 and 920. However, it also includes R1 fields 902 and 904, framed information (FI) field 908, extended bit field 910, and 10-bit serial number (SN) 914.
An example of the helper WTRU dropping the received RLC PDU is described below with reference to FIGS. 10 through 15.
For example, referring to the RLC AM mode in the DL, when the assistant WTRU drops the RLC PDU because the associated discard timer expires, if the terminal WTRU is not notified that the RLC PDU has been discarded, the Rx window at the terminal WTRU will not The dropped SN is bypassed until the retransmission of the discarded RLC PDU arrives at the terminal WTRU. Retransmission of RLC PDUs waiting to be dropped may be time consuming and unnecessary, as these RLC PDUs may contain delay profiles that should be ignored to reduce delay. For at least this reason, the facilitator 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. Therefore, all RLC PDUs with SN<HDSN are outside the Rx window. Therefore, in this scenario, the terminal WTRU does not require the corresponding RLC PDU to be retransmitted.
Figure 10 is a diagram of an RLC STATUS PDU 1000 that can be used to carry an HDSN on a second hop in the RLC AM mode. The example RLC STATUS PDU 1000 shown in FIG. 10 includes a data control indication (D/C) 1002 (eg, D/C = 0), a control PDU type (CPT) 1004 (eg, CPT = 001), and an H_SN column for indicating the HDSN. Bit 1008 and padding 1010.
In the RLC UM mode, the Rx window of the terminal WTRU may be updated using the highest received out-of-port SN from the received RLC PDU. This prevents the Rx window from being delayed after the helper WTRU drops the RLC PDU. Therefore, it is not necessary to transmit the HDSN on the second hop in the UM mode as compared with the AM mode.
The RLC SDU reassembly procedure at the second hop receiver can be modified in the AM mode to accommodate changes in the Rx window in the second hop receiver. In one embodiment, the RLC in the second hop receiver may assemble the RLC PDU with SN <variant VR(R) as an RLC SDU. The second hop receiver may analyze the SN of the RLC PDUs if the segmentation from the RLC SDU is determined to be lost (eg, the second hop receiver has not received the RLC SDU and the RLC SDU is outside the current Rx window), Then the second hop receiver can discard all other data segments for the same RLC SDU.
Discarding RLC PDUs on a per logical channel basis reduces the delivery delay caused by delay data in the helper WTRU queue. In one embodiment, regardless of whether the PDU is in the eNB buffer or in the WTRU queue, all RLC PDUs associated with the PDCP SDU may be discarded at the time the PDCP drop timer expires (eg, the helper WTRU is in use) The original PDCP SDU of the PDCP SDU to which the RLC PDU belongs belongs to the buffered RLC PDU when the timer expires at the same time. However, due to implementation limitations, the actual discard time can be different.
The helper WTRU may set the drop timer period according to any of a number of different methods. For example, in the DL, the helper WTRU may not drop the RLC PDU and may not set a drop timer. The delay caused by the helper WTRU buffer can be limited by minimizing the queue length. In this example, tighter flow control may be required to maintain the length of the queue. For another example, the timeout value for the drop timer for each logical channel associated with the terminal WTRU may be provided at the time of configuration or reconfiguration of the partial RLC layer. The drop timer value can be set to the same value as the value of the corresponding PDCP SDU drop timer. In this example, the total discard time for the PDCP SDU segment may be within the window from the 1* drop timer to the 2* drop timer (since two separate drop timers are potentially in both the eNB and the assistant WTRU) operating). For another example, the RLC PDU header may carry the remaining drop timer timeout value when the eNB sends it out. In this example, the discard time for all segments of the PDCP SDU can be exactly 1* discard timer. However, this may require an extension to the RLC header to carry the remaining drop timer timeout value. One or a combination of the examples listed above may be implemented in one embodiment.
In embodiments where the RLC PDU header carries the remaining drop timer timeout value when the eNB sends it out, an extension may be added to the RLC PDU header to carry the remaining drop timer timeout value from the eNB to the helper WTRU. For example, this can be done by adding an extended (E2) bit to the normal AMD and a UMD PDU indicating the presence of the remaining time (LT) field and the optional 8-bit LT field, the LT field indicates Discard the time remaining in the timer. An optional LT field can be placed after the SN field.
Figures 11 and 12 are diagrams of example RLC PDUs 1100 and 1200 with E2 bits and optional LT fields, respectively. In the embodiments shown in Figures 11 and 12, if no LT bit exists in the PDU after the SN field, the E2 bit may take a value of 0, and if there is an LT bit in the PDU after the SN field Yuan, E2 bit can take 1 value.
Figure 11 is a diagram of an example RLC PDU 1100 with a 10-bit SN 1102. For an example RLC PDU 1100 with a 10-bit SN 1102, the E2 bit 1104 occupies a third R-bit in the UMD PDU after R bits 1108 and 1110.
Figure 12 is a diagram of an example RLC PDU 1200 with a 5-bit SN 1202. For an example RLC PDU 1200 with a 5-bit SN 1202, the E2 bit occupies a new 4-bit including bits 1204, 1206, 1208, and 1210 after the first E-bit field for the AMD PDU and UMD PDU. The first bit of the field.
Figure 13 is a diagram 1300 of an example procedure for an RLC PDU dropped at the assistant WTRU. In the illustrated example, congestion occurs on the XL at certain points in time.
At 1302, the PDCP PDU/RLC SDU is divided into RLC PDUs having SNs of 10 (1310), 11 (1311), 12 (1312), 13 (1313), 14 (1314), and 15 (1315). RLC PDUs 1310, 1312, 1313, and 1314 arrive at the assistant WTRU 1320. The RLC PDU 1311 did not successfully reach the helper WTRU 1320. The PDU 1315 and subsequent PDUs 1316 and 1317 stay in the eNB 1322. At 1304, the RLC PDU 1311 arrives at the assistant WTRU later due to the HARQ retransmission. XL is not available and TRL is also stopped by flow control. At 1306, the WTRU 1320 drops the PDUs 1310, 1312, 1313, and 1314 as the discard timer expires. At 1308, PDUs 1315, 1316, and 1317 are sent to the facilitator WTRU to fill the space in the helper WTRU buffer. The XL then recovers and HDSN = 14 (corresponding to the dropped PDU 1314 with the highest SN) is sent to the terminal WTRU (not shown) to act on the Rx window. The facilitator WTRU may then send PDUs 1311, 1315, 1316, and 1317 to the terminal WTRU. The terminal WTRU may filter out the PDU 1311 because it is outside the Rx window. The PDU 1315 is filtered out in the reassembly procedure because it includes data segments from incompletely received SDUs with certain discard segments (e.g., data in PDUs 1310, 1311, 1312, 1313, and 1314).
Figures 14A and 14B include diagrams 1400A/1400B for an example procedure for acting on an Rx window at the assistant WTRU in RLC AM mode. In the illustrated example, the SN space is [0-7] and the SN window size = 4. The PDCP PDU/RLC SDU is segmented into RLC PDUs. The boundaries of the RLC SDU are displayed.
At time t1, XL is not available, RLC PDUs with SNs of 5 (1415), 6 (1416), 7 (1417), and 0 (1410) stay at eNB 1402 with SNs of 1 (1411) and 2 (1412) The RLC PDUs of 3, 1413, and 4 (1414) are stored in the buffer at the facilitator WTRU 1404. At time t2, the assistant WTRU discards the RLC PDUs 1411, 1412, and 1413 because the discard timer expires. Subsequently, XL is restored. The HDSN STATUS PDU with HDSN = 3 (corresponding to the discarded 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 eNB 1402 is also moved by ACK. At time t4, the RLC PDU 1414 is sent to the terminal WTRU 1406. Since it is in order, the Rx window moves again. The Tx window in eNB 1402 is also moved by ACK. The RLC PDU 1414 is outside the Rx window. The first data segment in the RLC PDU 1414 is the remaining segment of the RLC SDU with the acknowledged missing component, so it is discarded. Save the remaining segments for subsequent reorganization. At time t5, more data is sent to the helper WTRU 1404 after the Tx window is updated. At time t6, the facilitator WTRU 1404 sends more data to the terminal WTRU 1406 and combines the valid SDUs with the data segmented in the PDUs 1414, 1415, and 1416. Therefore, in this example, after the XL is recovered from the problem, the XL delay is well restored by using the HDSN to update the Rx window.
15A and 15B include diagrams 1500A/1500B of an example procedure for moving an Rx window at the assistant WTRU 1522 when the HDSN is lost. The parameters used for this example are the same as those described with reference to FIGS. 14A and 14B. However, in this example, the status PDU carrying the HDSN is lost in the XL. Here, the Rx window is only moved when the retransmission of the discarded PDU arrives.
At time t1, XL is not available, and RLC PDUs with SNs of 0 (1510), 5 (1505), 6 (1506), and 7 (1507) stay in eNB 1524 and have SNs of 1 (1501), 2 ( The RLC PDUs of 1502), 3 (1503), and 4 (1504) are stored in a buffer at the facilitator WTRU 1522. At time t2, the adjunct WTRU 1522 discards the RLC PDUs 1501, 1502, and 1503 as the discard timer expires. Subsequently, XL is restored. The facilitator WTRU 1522 sends the terminal WTRU 1520 an HDSN STATUS PDU with the highest dropped SN = 3 (corresponding to the dropped RLC PDU 1503 with the highest SN), but it is lost on the XL. Therefore, the Rx window at the terminal WTRU 1520 is not updated. At time t3, the facilitator WTRU 1522 sends an RLC PDU 1504 to the terminal WTRU 1520. It is not in order, so the reordering timer starts. At time t4, the reordering timer expires and the terminal WTRU 1520 sends a STATUS PDU with ACK_SN=1/NACK_SN=2 to the eNB 1524. Upon receipt of the STATUS PDU, the eNB 1524 retransmits the RLC PDUs 1501, 1502, and 1503 to the facilitator WTRU 1522. At time t5, the facilitator 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 order and the Rx window is updated. At time t6, the RLC SDU is delivered.
The example described with reference to FIGS. 15A and 15B is similar to the case where the HDSN is not transmitted to the RLC of the second hop receiver to actuate the Rx window. Thus, even when the HDSN is lost on the XL, if the retransmission of the lost RLC PDUs to the facilitator WTRU is allowed after they are discarded, the system can eventually recover. However, without receiving the HDSN STATUS PDU, the data stream can take longer to recover (eg, the reordering timer expires and the retransmission request).
In addition to the partial RLC layer described above, another embodiment may include an L2 layer in which none of the MAC, RLC, and PDCP layers terminate at the assistant WTRU. In this embodiment, the MAC TB can be relayed between XL and TRL without modification. In another L2 implementation, only the MAC layer (and not the RLC or PDCP layer) may terminate at the assistant WTRU. In this embodiment, scheduling flexibility between XL and TRL can be achieved by segmenting the MAC PDU on the second hop. MAC level flow control and MAC level delay data discarding can be applied to improve performance. In another L2 implementation, the MAC and RLC layers may terminate at the assistant WTRU. In this embodiment, the facilitator WTRU may relay the RLC SDU between the terminal WTRU and the eNB. In another L2 implementation, the MAC, RLC, and PDCP layers may all terminate at the assistant WTRU. In one embodiment, one or more of the L2 implementations described herein can be combined with the architecture described above.
With reference to flow control, flow control over the first hop in the coverage extended mode application can serve as a purpose of limiting the buffer depth of the local buffer at the assistant WTRU to reduce transmission delay and prevent data overflow by the helper WTRU buffer. . If flow control is not applied on the first hop, there may be a risk of overflow in the assistant WTRU buffer in the RLC UM mode since the immediate throughput on the first and second hops may be different.
In the RLC AM mode, the RLC Rx/Tx window at the terminal WTRU and eNB may perform flow control between the first hop and the second hop. However, in some embodiments, the maximum number of RLC PDUs stored in the assistant WTRU buffer may need to be smaller than the window size. One example of this may include embodiments in which the facilitator WTRU does not use a drop timer to discard data, so the delay caused by the facilitator WTRU buffer may be minimized by limiting the maximum number of RLC PDUs buffered at the facilitator WTRU.
Flow control can be applied at the MAC level that treats data from different logical channels as a whole or at the RLC level based on each active logical channel. The accuracy of flow control can vary from binary on/off commands to more precise commands using multi-level control.
In embodiments where the MAC layer and a portion of the RLC layer terminate at the assistant WTRU, RLC level flow control can be used to achieve precise control of each active logical channel. Flow control of the Xon/Xoff type can be used to reduce the flow control burden. In the Xon/Xoff implementation, when the buffer level is above the preset high water mark, the Xoff command can be sent to the transmitter to stop entering the data. Once the buffer level is below the low water mark, the Xon command can be sent to the transmitter to resume access. In one embodiment, the flow control command may be sent from the helper WTRU to the first hop transmitter to control the data entering the assistant WTRU. For the UL direction, if the helper WTRU is combined with the network under the control of the XUL schedule, flow control on the XUL may not be required.
Figure 16 is a diagram 1600 of an example MAC control element for carrying traffic information on a TRL UL. The example MAC control element shown in FIG. 16 includes an R field 1602, a logical channel identification (LCID) field 1604, and an on/off field 1606. The LCID field can be used to identify the logical channel instance of the corresponding MAC SDU or the corresponding MAC Control element or the type of padding for the DL-SCH, UL-SCH, and Multicast Channel (MCH), respectively. In the embodiment shown in Figure 16, the flow control MAC Control Element can be identified by reusing the reserved LCID. The on/off field 1606 may be "1" to indicate that more data may be sent (eg, resume entry) or "0" to indicate that more data may not be sent (eg, stop entering data).
The MAC status report from the terminal WTRU may need to be relayed to the network to assist in the XL scheduling. In addition, additional MAC status reports from the facilitator WTRU associated with data in the process of relaying between the network and the terminal WTRU may need to be sent to the network. Thus, in one embodiment, it is necessary to map logical channels on the XL to logical channels on the TRL.
Figure 17 is a diagram 1700 of an example mapping between logical channels on XL to logical channels on the TRL. In the example shown in FIG. 1700, TRL logical channels 1706 and 1708 belonging to logical channel group 1720 terminate at the facilitator WTRU 1714 and are not mapped to any XL logical channels. However, TRL logical channels 1702 and 1704 belonging to logical channel group 1718 are not terminated at assistant WTRU 1714 and are instead mapped to XL logical channels 1710 and 1712 and terminated at terminal WTRU 1716.
Other new MAC status reports can also be used in embodiments. Such MAC status reports may include XUL Scheduling Request (XUSR) from the terminal WTRU, XDL Scheduling Request (XDSR) from the facilitating WTRU, UL Buffer Status (TBSR) from the terminal WTRU, XDL buffer status from the facilitator WTRU ( XDBSR), Cross Link DL Power Headroom Report (XDPHR) from the WTRU, and XUL Power Headroom Report (XUPHR) from the terminal WTRU. In addition, regular MAC status reports from the facilitator WTRU, such as SR, BSR, or PHR, may be used for the embodiments described herein in accordance with baseline LTE.
When the terminal WTRU wants to send data on the XUL but does not have XUL authorization, it may need to send a XUSR to the network to request an initial XUL grant. The terminal WTRU may send the XUSR to the network in a number of different manners, including, for example, a terminal WTRU that is currently in RRC idle mode and wants to initiate a transition to RRC connected mode to send a XUSR on the UCZ to change the facilitator WTRU, or is currently in RRC connected mode. The terminal WTRU sends XUSR on the XUL Control Channel XPUCCH. When the facilitator WTRU wants to send data to the terminal WTRU on the XDL but no XDL grant is available, the facilitator WTRU may need to send an XDSR to the network to request the initial XDL grant.
The TBSR may indicate the UL buffer status at the terminal WTRU. This information can be used to determine the XUL schedule, which can be implemented by the network in conjunction with the assistant or terminal WTRU, as described in more detail below.
The transmission of the TBSR may be triggered by one or more events at the terminal WTRU, which may include, for example, an arrival of data having a higher priority than the data currently in the transmission buffer, a period controlled by a timer, or when populated at the MAC When used in the header. The TBSR may be first sent to the facilitator WTRU via the XUL and then relayed to the eNB on the TRL UL. In one embodiment, the TBSR can be 6 bits.
Depending on the XPUCCH design, the TBSR can be sent to the helper WTRU on the XUL either directly on the XPUCCH or via the MAC Control Element on the XUL Shared Data Channel. On the TRL, the TBSR MAC Control element can be used to carry the TBSR. The TBSR MAC Control Element may be in the same format as the BSR defined for the legacy LTE MAC, including a truncated BSR, a short BSR, or a long BSR. The TBSR MAC Control Element can be identified by reusing the reserved LCID.
If the MAC Control Element is used to carry the TBSR on the XUL Shared Data Channel, it may be in the form of a regular BSR MAC Control Element or a TBSR MAC Control Element. If a regular BSR MAC Control element is used, the facilitator WTRU may convert the regular BSR MAC Control Element it receives from the XUL Shared Data Channel to the TBSR MAC Control Element on the TRL UL-SCH.
Figure 18 is a diagram 1800 showing an example transition of BSR 1808 on XUL-SCH to TBSR 1812 on TRL UL-SCH. In the example shown in FIG. 18, XL TB 1802 includes a MAC header 1806 and a BSR 1808. The TRL TB 1804 includes a MAC header 1810 and also includes a converted TBSR 1812 with other conventional MAC Control elements 1814.
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 placing a TBSR MAC Control Element on the TRL UL-SCH.
The XDBSR is a DL buffer status report for the XL at the assistant WTRU. The network can use this information to jointly determine the XDL schedule with the helper WTRU. The XDBSR MAC Control Element may be in the same format as the BSR defined in the legacy LTE MAC. They may for example be in the form of a truncated BSR, a short BSR or a long BSR. The new XDBSR MAC Control Element can be identified by reusing the reserved LCID. The transmission of the XDBSR may be triggered by several different events at the assistant WTRU, which may include, for example, a period trigger controlled by a timer, otherwise the XDL queue depth exceeds a threshold when padding is used in the MAC header (this may be by XDL) Flow control is substituted instead, or if the helper WTRU sends an XDSR to the network using the XDBSR, when the helper WTRU wants to request the initial XDL grant for the data to be sent to the terminal WTRU.
Figure 19 is a diagram 1900 illustrating an example transmission of a UL TBSR in coverage extended mode for an AT application. In the example shown in FIG. 19, TRL logical channels 1902, 1904, 1906, and 1908 are configured to transmit data from respective UL buffers 1914, 1916, 1918, and 1920 at the assistant WTRU 1950 to a network eNB (not shown). In one embodiment, the assistant WTRU 1950 can be configured to transmit BSRs for these logical channels to a network eNB (not shown). XL logical channels 1910 and 1912 may be configured to transmit TBSRs to respective UL buffers 1922 and 1924 at terminal WTRU 1960 to helper WTRU 1950.
Figure 20 is a diagram illustrating an example transmission of a DL BSR in an overlay extension mode for an AT application. In the example shown in FIG. 20, TRL logical channels 2002, 2004, 2006, and 2008 are configured to transmit data from a network eNB (not shown) to the helper WTRU 2050. XL logical channels 2010 and 2012 may be configured to transmit BSRs to respective DL buffers 2014 and 2016 at the facilitator WTRU 2050 to the terminal WTRU 2060.
Both DL and UL power headroom (XDPHR and XUPHR) for XL are used to jointly determine the XL schedule by the network and the facilitator WTRU/terminal WTRU. The XUPHR can be sent from the terminal WTRU and relayed to the network by the facilitator WTRU. The XDPHR can be sent from the helper WTRU and reported directly to the network. The XDPHR may be triggered at the helper WTRU by a number of different events, which may include, for example, a periodic trigger controlled by a timer, a XL path loss change exceeding a threshold, or an XDL schedule changed by the helper WTRU or terminal WTRU. The XUPHR may be triggered at the terminal WTRU by a number of different events, which may include, for example, a periodic trigger controlled by a timer, a XL path loss change exceeding a threshold, or a XUL schedule changed by a terminal WTRU or a facilitator WTRU. The XDPHR and XUPHR MAC Control Elements may be in the same format as the PHR MAC Control Element defined in the legacy LTE MAC. The XDPHR MAC Control Element and the XUPHR MAC Control Element can be identified by reusing the reserved LCID.
The terminal WTRU may initiate a XUL scheduling request and send it to the helper WTRU. The helper WTRU can then relay it to the eNB. Depending on the RRC mode, the terminal WTRU may use a different procedure to send the XUSR to the helper WTRU. The terminal WTRU in the RRC idle mode may send a XUL scheduling request in the UCZ. Depending on how the control channel is designed on the XL, the terminal WTRU in RRC connected mode may send a XUL scheduling request to the helper WTRU in the form of TBSR or XUSR.
Figure 21 is a flow diagram 2100 of a method for a terminal WTRU to send a XUL scheduling request to an eNB using a TBSR in an RRC connected mode. In the example shown in FIG. 21, in the event that the terminal WTRU has UL data transmission (2102), the terminal WTRU may send a TBSR to the facilitator WTRU via the XUL control channel (2104). If the XPUCCH can carry the TBSR directly, the terminal WTRU can send the TBSR directly to the assistant WTRU on the XPUCCH, without XUSR.
If the XPUCCH does not carry the TBSR, the terminal WTRU may send the XUSR on the XPUCCH. Figure 22 is a flow diagram 2200 of a method for a terminal WTRU to send a XUL scheduling request to an eNB using XUSR in an RRC connected mode. In the example shown in FIG. 22, in the event that the terminal WTRU has UL data to transmit (2202), the terminal WTRU determines if it has an XUL grant (2204). In case the terminal WTRU has XUL grant, the terminal WTRU may determine that XUSR does not need to be sent, and thus may not send XUSR (2208). In the event that the terminal WTRU does not have XUL grant, the terminal WTRU may send XUSR to the helper WTRU via XPUCCH (2206).
Sending XUSR on XPUCCH saves bandwidth on XPUCCH because XUSR can only be 1-bit information. The information of this bit can be carried in the same or similar manner as the regular SR carried on the PUCCH. In this embodiment, there may be no need to have a RACH procedure on the XL because XPUCCH is always present when both the facilitator WTRU and the terminal WTRU are in RRC connected mode.
Figure 23 is a flow diagram 2300 of a method for a facilitating WTRU to relay XUSR to an eNB using both TRL PUCCH and TRL UL-SCH. In the example shown in Figure 23, the terminal WTRU sends XUSR (2302) to the facilitator WTRU via XUSR on XPUCCH. Upon receiving the XUL scheduling request, the facilitator WTRU may relay it to the eNB. In the illustrated embodiment, the helper WTRU may send the received XUSR to the eNB in a different manner depending on the TRL UL status. In the presence of a TRL PUCCH (2304), the facilitator WTRU may send XUSR (2308) to the eNB by a new bit dedicated to XUSR on the TRL PUCCH. If not present, if the TRL UL grant for the UL-SCH is available (2306), the facilitator WTRU may send the XUSR (2312) on the UL-SCH using the MAC Control Element. In case the TRL UL grant for UL-SCH is not available (2306), the existing LTE-A RACH procedure can be used to obtain the initial UL grant on the TRL (2310) and then via UL-SCH The eNB sends XUSR (2312).
Figure 24 is a flow diagram 2400 of a method for a facilitator WTRU to relay XUSR to an eNB using only UL-SCH. In the example shown in FIG. 24, the facilitator WTRU may send the XUSR to the eNB only on the UL-SCH by using the MAC Control element. The terminal WTRU may send XUSR (2402) to the facilitator WTRU via XPUCCH. In case the TRL UL grant for UL-SCH is not available (2404), the existing LTE-A procedure for UL scheduling request by PUCCH or RACH can be used to obtain the initial UL grant on the TRL UL (2406). The facilitator WTRU may then send XUSR to the eNB via the UL-SCH (2408). Where the TRL UL grant for the UL-SCH is available (2404), the facilitator WTRU may simply send the XUSR to the eNB via the UL-SCH (2408).
If the XUSR is sent on the TRL UL-SCH, the XUSR can be sent to the eNB using a new type of MAC Control element on the UL-SCH or using the smallest TBSR on the TRL UL-SCH. The minimum TBSR may represent the size of the short TBSR MAC Control Element.
For embodiments in which a new type of MAC control element on the UL-SCH is used to transmit XUSR to the eNB, the XUSR MAC Control Element may have a length of zero (eg, it may not have a true MAC Control Element body). In this embodiment, only the R/R/E/LCID field with the LCID for XUSR is placed in the MAC header. The XUSR MAC Control Element can be identified by reusing the reserved LCID. The facilitator WTRU may send a XUL scheduling request to the eNB in a number of different manners, an example of which is described below with reference to Figures 25, 26 and 27.
Figure 25 is a flow diagram 2500 of a method for a facilitating WTRU to relay XUSR to an eNB on a TRL UL-SCH using a XUSR MAC Control Element. In the example shown in FIG. 25, an extension to the TRL PDCCH may be required to carry the XUL grant from the eNB to the helper WTRU. The terminal WTRU 2520 may send XUSR (2502) to the facilitator WTRU 2530 on the XPUCCH. If the helper WTRU 2530 does not have a TRL UL grant, the LTE-A procedure can be performed to obtain such an authorization (2504). The helper WTRU 2530 can then send the XUSR (2506) to the eNB (2540) using the MAC Control element on the TRL UL-SCH. Upon receiving the XUSR, the XUL Scheduler 2508 at the eNB 2540 can assign an initial XUL grant and send it to the helper WTRU 2430 via the PDCCH on the TRL (2510). The facilitator WTRU 2530 can then send an XUL grant to the terminal WTRU 2520 via the XPDCCH (2512).
Figure 26 is a flow diagram 2600 of a method for the facilitator WTRU 2630 to relay XUSR to the eNB 2640 over the TRL UL-SCH using the minimum TBSR MAC Control Element. In the example shown in FIG. 26, an extension to the TRL PDCCH may be required to carry the XUL grant from the eNB 2640 to the helper WTRU 2630. The terminal WTRU 2620 may send XUSR (2602) to the facilitator WTRU 2630 on the XPUCCH. In one embodiment, if the TRL UL grant is not available, it may be necessary to perform an LTE-A procedure to obtain such an authorization (2604). The facilitator WTRU 2630 may then send the minimum TBSR to the eNB 2640 using the MAC Control element on the TRL UL-SCH (2606). Upon receiving the TBSR, the XUL Scheduler 2608 at the eNB 2640 can assign an initial XUL grant and send it to the helper WTRU via the PDCCH on the TRL (2610). The facilitator WTRU 2630 may then send an initial XUL grant to the terminal WTRU 2620 via the XPDCCH (2710). In this embodiment, the minimum TBSR may correspond to the size of the short BSR.
Figure 27 is a flow diagram of a method for the facilitator WTRU to relay XUSR to the eNB on the TRL PUCCH. In the example shown in FIG. 27, a 1-bit extension for carrying the XUSR from the facilitator WTRU 2730 to the eNB 2740 may be required on the TRL PUCCH. As such, an extension to the TRL PDCCH for carrying the XUL grant from the eNB 2740 to the helper WTRU 2730 may be required. The terminal WTRU 2720 can send XUSR (2702) to the facilitator WTRU 2730 on the XPUCCH. The facilitator WTRU 2730 can relay the XUSR to the eNB 2740 using the TRL PUCCH (2704). Upon receiving the XUSR, the XUL Scheduler 2706 at the eNB 2740 can assign an initial XUL grant and send it to the helper WTRU 2730 via the TRL PDCCH (2708). The facilitator WTRU 2730 can send an XUL grant (2710) to the terminal WTRU 2720 via the XPDCCH.
When the helper WTRU has data to send to the terminal WTRU on the XDL but does not have XDL authorization, it can send an XDSR requesting XDL authorization to the network. In one embodiment, the helper WTRU may send the XDSR to the eNB in a different manner depending on the TRL UL status at this time. For example, if there is a PUCCH for the TRL, the helper WTRU may send the XDSR to the eNB using the new bit dedicated to the XDSR on the TRL PUCCH. If there is no PUCCH for the TRL, the helper WTRU may send the XDSR on the UL-SCH using the MAC Control Element. If the TRL UL grant for UL-SCH is not available, the existing LTE-A RACH procedure can be used to obtain an initial UL grant on the TRL. For another example, the facilitator WTRU may send an XDSR to the eNB only on the UL-SCH by using the MAC Control Element. If the TRL UL grant for UL-SCH is not available, the existing LTE-A procedure for UL scheduling requests can be used to obtain an initial UL grant on the TRL UL by PUCCH or RACH.
If the XDSR is transmitted on the TRL UL-SCH, the XDSR may be sent to the eNB on the UL-SCH using the XDSR MAC Control Element or to the eNB on the TRL UL-SCH using the minimum XDBSR MAC Control Element. If the XDSR is sent to the eNB on the UL-SCH using the XDSR MAC Control Element, a new type of MAC Control Element can be used for the XDSR on the TRL UL-SCH. In one embodiment, the XDSR MAC Control Element may have a length of zero (eg, it does not have an actual MAC Control Element Body). In this embodiment, only the R/R/E/LCID field with the LCID for the XDSR is placed in the MAC header. The XDSR MAC Control Element can be identified by reusing the reserved LCID. The detailed procedure for how the facilitator WTRU sends an XDL scheduling request to the eNB using different options is described below with reference to Figures 28 and 29.
Figure 28 is a flow diagram 2800 of a method by which the facilitator WTRU 2810 transmits an XDSR to the eNB 2820 over the TRL UL-SCH using the XDSR MAC Control Element. In the example shown in FIG. 28, an extension to the TRL PDCCH may be required for carrying XDL scheduling information from the eNB 2820 to the facilitator WTRU 2810. If the facilitator WTRU 2810 does not have a TRL UL grant, the helper WTRU may perform an LTE-A procedure to obtain one (2802). The facilitator WTRU 2804 may send an XDSR (2810) to the eNB 2820 using the MAC Control element on the TRL UL-SCH. Upon receiving the XDSR, the XDL scheduler 2806 at the eNB 2820 can assign an initial XDL grant and send it to the helper WTRU 2810 via the PDCCH on the TRL (2808).
Figure 29 is a flow diagram 2900 of a method by which the facilitator WTRU 2910 transmits an XDSR to the eNB 2920 on the TRL PUCCH. In the example shown in FIG. 29, a 1-bit extension to the TRL PUCCH may be required for carrying the XDSR from the facilitator WTRU 2910 to the eNB 2920. As such, an extension to the TRL PDCCH may be required for carrying XDL scheduling information from the eNB 2920 to the facilitator WTRU 2910. The facilitator WTRU 2910 may send an XDSR (2902) to the eNB 2920 using the TRL PUCCH. Upon receiving the XDSR, the XDL scheduler 2904 at the eNB 2920 can assign an initial XDL grant and send it to the helper WTRU 2910 via the TRL PDCCH (2906).
In one embodiment, the terminal WTRU may first send a TBSR to the facilitator WTRU on the XUL, and then the facilitator WTRU may relay the TBSR 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, transmitting the TBSR on the XUL via the XPUCCH, and transmitting the TBSR on the XUL shared data channel by the conventional BSR or TBSR MAC Control Element.
If the terminal WTRU transmits a TBSR using the regular BSR or TBSR MAC Control element on the XUL shared data channel, it may require a XUL grant to send the TBSR to the facilitator WTRU. In one embodiment, the XUL grant can be obtained from ongoing XUL transmissions. If there is no XUL grant, the terminal WTRU may request the XUL grant using the XUL Schedule Request procedure described above.
After receiving the TBSR from the terminal WTRU, once the facilitating WTRU has a TRL UL grant that it may need if there is going to be ongoing UL data transmission from the facilitating WTRU to the eNB, it may be through the MAC Control element on the TRL UL-SCH The TBSR is sent to the eNB. If the TRL UL grant is not available, the helper WTRU may request an initial TRL UL grant from the eNB using the existing LTE-A procedure for UL scheduling request by PUCCH or RACH.
Figure 30 is a signal diagram 3000 of a method for transmitting a TBSR to an eNB 3070 when the TRL UL grant is available. In the example shown in FIG. 30, the terminal WTRU 3050 transmits the TBSR to the helper WTRU 3060 using the regular BSR MAC Control Element or 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 get one (3004). The facilitator WTRU 3060 may place the TBSR in the TBSR MAC Control Element (3006) or place the BSR in the BSR MAC Control Element (3008) and send it to the eNB 3070. Upon receiving the TBSR/BSR, the XUL Scheduler 3010 at the eNB 3070 can assign an XUL grant and send it to the helper WTRU 3060 via the TRL PDCCH (3012). The TRL UL Scheduler (3010) at the eNB 3070 can assign a TRL UL grant and send it to the helper WTRU 3060 (3014) via the TRL PDCCH as well. The facilitator WTRU 3060 may send an XUL grant (3016) to the terminal WTRU 3050 via the XPDDCH. The terminal WTRU 3050 can then send a profile with the newer TBSR to the facilitator WTRU 3060 (3018) on the XUL shared channel, which can relay the data to the eNB 3070 (3020).
The XDBSR can be measured by the helper WTRU. The reporting procedure for the XDBSR can be similar to the procedure used by the facilitating WTRU to report regular BSRs by using the MAC Control Element on the TRL UL-SCH. A new type of MAC Control element can be used for the XDBSR. It can have the same format as the BSR and can be identified by reusing the reserved LCID field.
Figure 31 is a signal diagram 3100 of the method of reporting the XDBSR. In the example shown in FIG. 31, an extension of the TRL PDCCH may be required for carrying the XDL scheduled channel from the eNB 3120 to the facilitator WTRU 3110. If the facilitator WTRU 3110 does not have a TRL UL grant, the facilitator WTRU 3110 may need to initiate an LTE-A procedure to obtain one (3102). The facilitator WTRU 3110 may send an XDBSR to the eNB 3120 using the MAC Control element on the TRL UL-SCH (3104). Upon receipt of the TBSR, the XDL scheduler 3106 at the eNB 3120 can assign an XDL grant and send it to the helper WTRU 3110 via the PDCCH on the TRL (3108).
A new type of MAC Control Element for XDPHR and XUPHR may be needed to send XDPHR and XUPHR to the eNB on the TRL-SCH. The same MAC Control Element for XUPHR can be used to carry the XUPHR to the Assistant WTRU on the XUL Shared Data Channel.
Figure 32 is a signal diagram 3200 of a method of transmitting XDPHR and XUPHR to an eNB 3240 on a TRL UL-SCH. The terminal WTRU 3220 may send the XUPHR to the helper WTRU 3230 using the MAC Control element on the XUL shared data channel (3202). If the facilitator WTRU 3230 does not have a TRL UL grant, it may need to use the LTE-A procedure to obtain one (3204). The facilitator 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 facilitator WTRU 3230 may also send a PHR (3210) to the eNB 3240 on the UL-SCH.
The LCIDs used on the TRL UL-SCH and XUL shared data channels can share the same definition, even though they may not always appear on both channels. Table 1 includes a list of commonly used LCID values and LCID values that can be used for the different embodiments described herein. However, other LCID values and rankings may also be possible.

Table 1

Regarding XL resource authorization and scheduling, XL can share the frequency band applied in TRDL/TRUL (in-band configuration) or use a different frequency band (out-of-band configuration) that is completely separate from TRDL/TRUL. The out-of-band configuration is less susceptible to in-device and air interference between the XL and TRL, as the out-of-band configuration typically applies sufficient spectral isolation between the XL and the TRL, so the device can operate two radio chains, each with its own baseband Processing and independent FFT. While the in-device interference can be primarily utilized by the device's physical radio design, air interference may need to be coordinated with XL resource authorization and partially scheduled by the network and partially scheduled by the WTRU.
Figure 33A is a diagram 3300 of a system of assistant WTRU 360 and terminal WTRU 370 within a cell operated by eNB 3350. Each of the helper WTRUs 360A, 360B, 360C, 360D, 360E, and 360F communicates directly 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 via one or more XL UL/DL pairs 3320A, 3320B, 3320C, 3320D, 3320E, 3320F, or 3320G and one or more assistant WTRUs 360A, 360B, 360C, 360D, 360E and 360F communication. Certain terminal WTRUs (e.g., terminal WTRUs 370B, 370D, and 370E) may also communicate directly with eNB 3350 via respective TRL UL/DL pairs 3310C, 3310E, or 3310G.
In the example system shown in Figure 33A, all XLs potentially interfere with each other. In one embodiment, different multiple access schemes may be applied on the XL in an attempt to mitigate this interference. However, all XLs in the same cell can share a fixed pool of time, frequency, code, and power resources, and the network may require new metrics and algorithms to efficiently allocate XL resources.
In order to support high mobility in the LTE system and handle the resulting short channel coherence time, the network can dynamically schedule every TTI on the TRL. However, applying a similar dynamic authorization and scheduling scheme on the XL may require the network to have access to dynamic XDL and XUL channel status information. The resulting signaling may be quite large, particularly in an AT-R coverage mode where the facilitator WTRU may need to relay all terminal WTRU feedback information to the network. In addition, centralized dynamic authorization and scheduling can cause an increase in the HARQ timeline because the facilitator WTRU may need time to decode and forward the grant and scheduling information to the terminal WTRU.
In addition, TRL grants and schedules do not specify the power level that will be used for scheduled DL or UL transmissions. For TRL grants and scheduling, the eNB always uses full power (ie, downlink power is centralized) to transmit DL data channels, while UL transmissions can be based on modulation and coding schemes (MCS) such as assignments and physical resource blocks (PRB) Such authorization information is adjusted by UL power control (ie, the UL power control mechanism is decentralized). However, for XL, as a type of resource allocation, explicit power allocation may be desirable because in the sense that all XLs in the geographic area may be limited to a particular power level to mitigate mutual interference, in the AT application, the WTRU The XL transmission power setting can constitute a distribution of shared resources.
The AT-R coverage mode may present an additional challenge because the facilitator WTRU may use a new procedure to forward network grants to the terminal WTRU and relay the terminal WTRU measurements as input to the grant algorithm to the network.
Thus, as briefly described above, embodiments for Layer 2 scheduling in XL are described herein, where the first layer is a centralized and semi-static XLG issued by the network, and the second layer is executable by the WTRU itself. Decentralized and dynamic XLS. These embodiments can be applied to both AT-R and AT-LO applications, but some embodiments are described with reference to AT-R for ease of explanation.
Figure 33B is a flow diagram 3355 of an example method of radio resource scheduling on a wireless XL between a WTRU and another WTRU. In the example shown in FIG. 33B, the WTRU receives an XLG designated resource (3360) for transmission by at least the WTRU for use on the radio XL. The WTRU may perform XL scheduling (3362) per TTI within the resources specified in the XLG. The WTRU may transmit at least one packet (3364) to another WTRU based on the XL schedule per TTI.
In one embodiment, the network controlled XLG may be a channel dependent authorization scheme that uses orthogonal multiple access. Such a channel-dependent authorization scheme eliminates XL interference within the cell, allowing each XL to achieve optimal performance based on its channel conditions. However, in some embodiments, when the number of XLs supported by each cell is excessive, the network may not have the appropriate resources to support orthogonal multiple access, and due to the significantly increased signaling burden and resulting increase in latency, each TTI's dynamic channel-dependent scheduling may not be feasible. For example, dynamic per TTI scheduling per XL can cause high demands on PDCCH/PUCCH capacity.
In one embodiment, the dynamic per TTI schedule may be implemented based on at least one of a resource specified in the XLG and an XL ACK/NACK message or a channel quality indicator (CQI), without network intervention. Since separate HARQ designs for TRL and XL in some AT applications can prevent ACK/NACK transmissions from being forwarded to the network, such an implementation may be desirable.
The first layer of the two-layer schedule may be referred to as XLG, and the second layer may be referred to as XLS. In the case of XLG, the network can issue centralized and semi-static scheduling decisions to allocate XL resources 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 reports. XLG does not consider the status of the instant channel. Each grant can be associated with a valid period of explicit signaling. For XLS, the WTRUs in the network can perform decentralized and dynamic scheduling decisions in the resources allocated by the XLG and determine the transmission configuration on a per TTI basis. The transmission configuration determined on a per TTI basis may include, for example, determining the MCS and transmission bandwidth based on short term XL channel condition feedback measurements as a result of link adaptation and traffic change processing. Scheduling decisions can be taken into account with XL power control to calculate transmission power.
The subcarrier resources assigned in the XLG can be applied unchanged during the XLG validity period. In other words, there is no dynamic frequency scheduling during each XLG lifetime. The WTRU may use the same authorized subcarriers (e.g., subcarrier groups or subbands in each TTI) but may apply different power and MCS for link adaptation. Alternatively, the XL schedule may exploit frequency selectivity within the authorized bandwidth by adjusting subcarrier resource assignments based on a particular SINR feedback specific to each assignable subcarrier group or subband.
Although, in one embodiment, the XLG may not carry any MCS information, it may specify a maximum allowed XL transmission power for the WTRU in the AT application. This can be a form of slow power control indicated by the network to manage interference between XLs and initiate efficient power utilization. For example, when two adjacent XLs share the same code, frequency, and time resources, the maximum allowed power (XLG power) can be set to reduce inter-XL interference and optimize the performance of both XLs. However, when orthogonal resource allocation is applied between XLs, the XLG power can be set to pass the maximum MCS on the XL as long as it does not exceed the maximum transmit power that the WTRU can apply according to the device capabilities.
When a large XL BW is assigned in the network, each XL in the cell can be first assigned to a frequency reuse group, where each assigned XL can authorize a dedicated portion of the XL BW.
Figure 34 is a diagram 3400 of cells 3440 in which XLs in cells are deployed in a frequency reuse group. In the example shown in FIG. 34, the XL in cell 3440 operated by eNB 3450 can be deployed in 4 frequency reuse groups 3460, 3470, 3480, and 3490. Frequency reuse group 3460 includes XLs 3402, 3404, 3406, 3408, 3410, 3412, and 3414. Frequency reuse group 3470 includes XL 3416, 3418, 3420, 3422, 3424, 3426, and 3428. Frequency reuse group 3480 includes XL 3430, 3432, 3434, 3436, 3438, 3440, and 3442. The frequency reuse group 3490 does not have any XLs assigned to it. However, those of ordinary skill in the art will recognize that XLs in cells can be organized into any number of frequency reuse groups, each of which can include any number of XLs.
In one embodiment, in addition to FDMA, the XLG may also assign code assignments to physical channels and reference signals to which CDMA is applied. For example, two XL-specific reference signals may co-exist in the same frequency resource location using two ZC-based sequences. These sequences can be derived from the same basic sequence with different cyclic shifts in order to provide orthogonality.
When the XL adopts the TDD duplex scheme, the network can also apply TDMA. For example, two XLs that use the same frequency and code resource allocation assignments can be configured with different TDD XDL/XUL configurations, whereby the transmission times of XDL1 and XUL2 are consistent. Because the facilitator WTRU and the terminal WTRU transmissions may have different code configurations, XDL1 and XUL2 may not interfere with each other.
The helper and terminal WTRU XLG for AT-R applications may include one or more of many different types of information. For example, the facilitator WTRU XLG may authorize the facilitator WTRU to be permitted by the validity period to transmit to the terminal WTRU in the XDL according to the companion configuration of the transmission. The terminal WTRU XLG may authorize the terminal WTRU to transmit to the facilitator WTRU in XDL in a similar manner.
Specific examples of information that may be included in the facilitator WTRU XLG may include the duration of the validity period (eg, in units of the number of TTIs), the maximum allowed interprompt WTRU transmission power on the XL, the application at the terminal WTRU in the XLPC Target nominal power (eg, in dBm), XDL/XUL duplex configuration (eg for TDD), XDL assignment index (eg for TDD), subcarrier resource allocation for all XDL dedicated channels (eg by sub The band is a unit (the multiplexing between these channels can be predefined in the assigned frequency resource) and the XDL specific reference signal code configuration (eg, spreading factor/spreading code assignment or base sequence/cyclic shift). Other examples of information for the facilitator WTRU XLG may include an XPDFBCH specific reference signal code configuration (eg, spreading factor/spreading code assignment or base sequence/cyclic shift), XPDCCH-specific reference signal code configuration (eg, spreading factor/spreading code assignment or basis) Sequence/cyclic shift), XPDCCH resource configuration (eg, spreading factor or channel code assignment), XPGCH resource configuration (eg, spreading factor or channel code assignment), XPDDCH demodulation variable reference code configuration (eg, spreading factor/spread code assignment or base sequence) /cyclic shift), XPDDCH frequency range indicator and XUL CQI as well as signal measurement request and configuration.
Specific examples of information that may be included in the terminal WTRU XLG may include, for example, the duration of the validity period (eg, in units of the number of TTIs), the maximum WTRU's maximum transmission power (eg, in dBm) on the XL, at XLPC Target nominal power at the WTRU's application WTRU (eg, in dBm), XDL/XUL duplex configuration (eg for TDD), XUL assignment index (eg for TDD), sub-channel for all XUL-specific channels Carrier resource allocation (eg in sub-bands) (multiple inter-channel multiplexing can be predefined in assigned frequency resources) and XUL-specific reference signal code configuration (eg spread factor/spread code assignment or base sequence/cyclic shift) ). Other examples of information for the terminal WTRU XLG may include an XPUFBCH specific reference signal code configuration (eg, spreading factor/spread code assignment or base sequence/cyclic shift), XPUCCH specific reference signal code configuration (eg, expansion factor/spread code assignment or basis) Sequence/cyclic shift element), XPUDCH resource configuration (eg spread factor or channel code assignment), XPUDCH demodulation variable reference configuration (eg spread factor/spread code assignment or base sequence/cyclic shift), XPUDCH frequency jump indicator or XDL CQI and signal measurement request and configuration.
The facilitator WTRU or the terminating WTRU may need to receive both the facilitator WTRU XLG and the terminating WTRU XLG to operate the XLG. Additionally, specific XLG information can be carried separately from other XLG information. For example, the validity period can be notified in dedicated RRC signaling in a similar manner to the SPS-Config information element.
In one embodiment, several information fields may overlap between the facilitator WTRU XLG and the terminal WTRU XLG. Alternatively, a combined XLG can be applied and transmitted to both the facilitator WTRU and the terminal WTRU.
The XLG can be considered an adaptation type of semi-permanent scheduling (SPS) used in LTE systems, particularly for low rate services such as IP voice services. In LTE, the PDCCH control signaling burden 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 IP voice services, the control signaling burden can be reduced using SPS.
In AT applications (eg, AT-R coverage mode), control signaling reduction may be the primary motivation for scheduling SPS types. While AT applications are not limited to low rate services, dynamic and channel dependent second level scheduling can provide significant changes to data traffic with the help of changing power levels, MCS and/or subcarrier assignments per TTI. Proper handling. Upon receiving the XLG, the WTRU may perform XL scheduling per TTI within the resources specified in the grant. If the WTRU is unable to adjust the authorized transmission bandwidth, it can adjust the MCS and calculate the power level per TTI to perform link adaptation accordingly. Table 2 provides a list of SPS type schedules for XLG schedules.
Table 2

The network can derive XLG based on any number of different inputs. For the initial XLG derivation, some inputs can be given more weight, while others can be used to update the XLG derivation. Examples of such inputs may include QoS based request spectral efficiency, estimated XL signal to noise ratio (SINR), buffer status, resource allocation history, XL feedback measurements, XL power headroom, and signals received in assigned subcarrier groups measuring.
For QoS-based request spectral efficiency, the network can use QoS to determine the approximate target rate of XL and the required SINR. This can be used, for example, for admission control to evaluate the target power applied in the XLPC when the WTRU requests and establishes its services.
For the estimated XL SINR, the network can estimate the XL SINR based on the grant and the measurements reported on the XL and compare it to the SINR based on the QoS calculated request to determine the initial XLG. An example of an estimate of SINR based on authorization and measurement may be based on:

Where N is the number of assigned subcarrier groups, BW_SubIs the bandwidth of each subcarrier group, IoT is the total received interference power of the assigned subcarrier group, and PL is the path loss between the assistant WTRU and the terminal WTRU of XL, N_oIt is the thermal power density and NF is the WTRU noise figure.
For buffer status, the DL buffer status can be readily obtained at the eNB, and the UL buffer status can be reported by the WTRU periodically or when triggered by a predefined event. The buffer status can be applied to the authorization algorithm to handle business changes. For resource allocation history, previously published XLG can be a factor in it.
For XL feedback measurements (XLFB), the LTE network scheduler can consider channel state information (CSI) when performing rate prediction for dynamic scheduling. A similar approach can be applied to AT-R capacity mode and AT-LO applications, where two WTRUs can report the CSI per TTI in the TRUL according to the request or according to the authorization configuration. However, in the AT-R coverage mode, the terminal WTRU CSI information may not be directly applied on a per TTI basis due to the lack of a direct link between the terminal WTRU and the eNB.
The short-term XL CSI feedback per TTI may be PUSCH multiplexed, for example, when a UL grant is available, transmitted in a PUCCH scheduled for the WTRU to carry TRDL CSI, or transmitted in a PUCCH schedule dedicated to XL. For short-term XL CSI feedback per PUTI multiplexed per TTI, an identification word (eg, a 1-bit field) may be added so that the eNB distinguishes whether the multiplexed CSI information is TRDL-specific or XL-specific. Regarding the transmission of short-term XL CSI feedback per TTI in a PUCCH scheduled for the WTRU to carry TRDL CSI, an identification word such as a flag bit may also be considered to indicate that the PUCCH is carrying XL CSI. An XL CSI such as CQI or PMI can reuse the existing PUCCH format. For short-term XL CSI feedback per TTI transmitted in a PUCCH schedule dedicated to XL, the scheduling of PUCCH may be implicitly or explicitly signaled in the PDCCH DCI format carrying the XLG.
In another embodiment, long-term 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 using their standard deviation during XLG validity. The averaging and statistical analysis can be performed by the entity layer according to the configuration passed in the dedicated RRC signaling.
Since long-term XL CSI feedback may not have a large payload, it can be transmitted similar to short-term feedback per TTI. Also, because long-term feedback may not have high latency requirements, it may also be carried in the MAC PDU on the PUSCH when the UL grant is available. The long-term XL CSI feedback report may be requested by the eNB using the UL grant for data transmission.
In general, short-term or long-term XL feedback can provide channel status information to the network to help assess how the allocated XL resources are being used.
For XL Power Headroom (XLPH), the LTE network can evaluate the UL scheduling decision to determine an efficient combination of MCS and bandwidth in the grant with the help of the PUSCH Power Headroom Report. The power headroom may be a measure of the difference between the maximum WTRU transmission power and the power controlled data channel transmission power that can be used assuming no WTRU transmission power limit. The transmission power may be calculated per TTI by the WTRU using the authorized MCS, authorized bandwidth, authorized path loss, and received TPC commands. Similar to XLFB, current LTE network methods can be used, and both short-term and long-term power headroom reports per TTI can also be considered. For example, during each XLG active period, the average power headroom value and its standard deviation can be reported to the network to determine the power level required to deliver the target rate by granting bandwidth under a given channel condition. The short-term power headroom per TTI can be calculated based on the authorized maximum transmission power level as follows (not the maximum transmit power of the WTRU as used in the LTE UL power headroom):

Where P_XLGIs authorized XL power, BW_TXIs the transmission bandwidth (which can be the same as BWXLG (ie authorized bandwidth)), P_NominalIs the desired power level at the assistant WTRU or the terminal WTRU, and PL is the path loss between the assistant WTRU and the terminal WTRU, Δ_TFIs a predefined function of the predefined transport format of XPDDCH, and TPC is a predefined function of the received TPC bit.
In the above example, the sum of the terms in parentheses is the transmission power in subframe i. In addition, in addition to XLPH, there may be another PHR that considers TRL and XL transmissions, which may require new procedures in the network. The power headroom discussed herein can be limited by the power headroom of the XL.
During the XLG active period, the network may, for example, configure several subframes for each short-term power headroom calculation of the TTI, and the WTRU may perform an average or other type of statistical analysis to obtain a long-term power headroom. The short-term and long-term PHR per TTI may be, for example, a new MAC Control Element dedicated to XL PHRR or an existing MAC Control Element (eg, Extended Power Headroom MAC Control Element) for PHR modified to accommodate the Cross-Link PHR. One of them is transmitted.
The XL PHR can be requested or triggered by a predefined set of events. For example, the XL short-term and/or long-term PHR may have a significant change in, for example, XL path loss, a predefined number of unidirectional TPC commands are applied, or a short-term power headroom value per TTI is generated over a predefined number of subframes. The long-term power headroom of the predefined threshold is reported.
For signal measurements received in the assigned subcarrier group, the signal level can be used to evaluate the XL SINR achieved and can also be used to derive the P used in the XL power control._Nominal. The interference calculation can be based on broadband analog energy measurement and code power measurement for all detected XL-specific reference signals. It can be assumed that the XL-specific reference signal is continuously transmitted without change using the authorized power. Therefore, the combined measurements can provide the SINR of the XL and identify the primary interference XL. In the rare case where two helper WTRUs are assigned the same specific reference signal, the terminal WTRU will not be able to distinguish between the two reference signals, and as a result the terminal WTRU may find a good SINR for the reference signal but suffer a degraded XPDCCH/XPDDCH block error rate. (BLER) performance. The XL signal measurements are also reported to the network in the form of a bit map to reduce the signaling burden. Signal measurements may require averaging and filtering during pre-configured periods, and transmissions may apply PUSCH in the form of MAC PDUs.
When the associated XL feedback, power headroom, and measurement report are carried in the PUSCH, the network may be required to assign a PUSCH grant associated with the measurement request and/or configuration.
When SPS is applied in LTE UL, the WTRU may transmit according to the same UL grant until the SPS is deactivated. Due to the frequency assignment and the MCS fixed, the transmit power can be adjusted using only the TPC commands. As an option, XLG also has fixed bandwidth and other transport configurations, with the exception of MCS. A WTRU participating in an AT-R and AT-LO application may adjust the MCS based on channel conditions, traffic changes, and ACK/NACK reception. The MCS can be further applied to calculate the XL transmission power. This can be thought of as a limited degree of WTRU autonomy assigned to the WTRU associated with the link adaptation in order to significantly reduce the benefit of the signaling burden. The network can still reasonably assert near-complete control over the XL transmission, so the proposed XLG can be considered a reserved network control function.
The XLG procedure described below can outline an event sequence that can be applied to a WTRU acquiring an initial XLG, receiving an updated XLG, and performing and reporting measurements for network XLG determination. These programs can be changed and discussed separately between different AT applications.
The initial XLG may be triggered by events listed in the AT-R application, such as the terminal WTRU transmitting the XSR/BSR or the network terminating the connection to the terminal WTRU in RRC IDLE mode. The terminal WTRU transmission of the XSR/BSR event may exist in several procedures including, for example, an action initiated connection from the terminal WTRU, a facilitator WTRU/terminal WTRU association, or a terminal WTRU handover from the active facilitator WTRU to the alternate facilitator WTRU. The network WTRUs in the RRC IDLE mode for the mobile terminated connection event paging may be specific to the AT-R coverage mode. When the network is paging the terminal WTRU in RRC IDLE mode in the overlay mode, the facilitating WTRU may place the paging message by alerting the terminal WTRU in the XPDACH about the incoming paging and causing the terminal WTRU to read the XLG in the XPDSACH or XPGCH. Forwarded to the terminal WTRU. In other words, the facilitator WTRU may send the paging indicator with the XLG, which the terminal WTRU may use to read the paging message in the XPDDCH.
In an AT-LO application, the initial XLG may be issued in conjunction with a local offload WTRU to WTRU call setup procedure. The initial XLG acquisition may be followed by a neighbor discovery procedure in which the neighbor search WTRU may find neighbor candidates in the presence of several neighbors. In the case of an AT-R application, one of the neighboring presence WTRUs is configured as a facilitator WTRU.
On the TRDL, the initial and updated XLG may be, for example, from 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 in the PDSCH. The network is transmitted in one of the dedicated RRC signaling. For the new DCI format carried in the PDCCH, in order to reduce the impact on DPCCH blind decoding efforts, the existing DCI format can be reused. The decoding options may include, for example, using a Cell Radio Network Temporary Identification Word (C-RNTI) to decode the PDCCH in the WTRU-specific search space, and when the WTRU participates in the AT application, using a new XL specific RNTI assigned to the WTRU (eg, AT- RNTI or XL-RNTI). For C-RNTI to be used to decode PDCCHs in a WTRU-specific search space, such as in an AT-R application, the facilitator WTRU and the terminal WTRU may use their own C-RNTI to receive the facilitator WTRU XLG and the terminating WTRU XLG, respectively. For a new XL specific RNTI, the AT-RNTI can be per XL. The PDCCH transmission can be robust, so the XLG can be received with high reliability. However, this option may require more network PDCCH capacity and may increase WTRU PDCCH decoding efforts. For the new MAC Control element carried in the PDSCH, the semi-static nature of the XLG may not impose high demands on the transmission latency and the PDSCH may be used for XLG transmission. However, the PDSCH can suffer from a higher BLER and the current MAC Control element does not have a response. For dedicated RRC signaling in the PDSCH, a new information element (IE) can be used, and the RLC response can provide the network with a status as to whether the XLG has been received correctly.
On the XL in the AT-R coverage mode, the initial and updated XLGs may be transmitted from the facilitator WTRU to the terminating WTRU in one of, for example, XPDDCH, XPDSACH, XPGCH, or a new MAC Control element carried in the XPDDCH. For XPDCCH, the XLG can be multiplexed with other control information on the XL. For XPDSACH, since physical channels are unscheduled, XLG transmissions can cause more interference in the system. For XPGCH, dedicated physical channels for XLG transmission provide higher reliability at the expense of increased system signaling burden.
Both entity control and data XLG transmissions can experience errors, so XLG may be lost. To ensure reliable XLG transmission, the WTRU may provide an XLG security mechanism to inform the network that the XLG transmission failed and prompt for retransmission. For example, when the WTRU does not receive an Update XLG before the ongoing XLG expires, the WTRU may suspend the XL communication so as not to cause uncoordinated interference. However, the network may not know that the WTRU lost the XLG, especially for XLG transmissions in the form of MAC Control Elements. In this case, the WTRU may apply a new entity layer type of feedback to indicate the failure to receive the XLG. This feedback can be a 1-bit response transmitted in the PUCCH. The WTRU may send an acknowledgement (ACK) when an Update XLG is received, and may also set the timer to a sub-frame pre-configured value (which may be derived from the received XLG valid period) in subframes. If the update XLG is not received when the timer expires, the WTRU may send a negative acknowledgement (NACK) to trigger an XLG retransmission from the network.
The XLG retransmission mechanism may not be applied to the initial XLG transmission. If the initial XLG transmission fails, the WTRU may retransmit the SR/BSR according to a predefined agreement. The eNB may therefore infer from the SR/BSR retransmission that the previous XLG was not properly received by the WTRU, thereby retransmitting the XLG.
Figures 35A and 35B include signal diagrams 3500A/3500B that illustrate an initial authorization acquisition procedure and an update XLG operation in capacity mode. In the examples shown in Figures 35A and 35B, the neighbor search WTRU 3502, the neighbor presence WTRU 3504, and the eNB 3506 may participate in a neighbor discovery procedure. Once the neighbor discovery procedure is complete, a neighbor presence WTRU may be selected as the candidate helper WTRU 3510 of the terminal WTRU 3508 (3512). Both the terminal WTRU 3508 and the assistant WTRU 3510 are in RRC connected mode 3514/3516.
When both the facilitator WTRU 3510 and the terminal WTRU 3508 receive an association message from the eNB 3506 (3517/3518), the facilitator WTRU 3510 and the terminal WTRU 3508 can perform XL measurements (3519/3520) using the cell-specific XL configuration. Such XL measurements may include measuring XL BWs assigned by the network to the cell (the granularity of assignable XL resources may be predefined (eg, subcarrier group or subband configuration)) and measuring XL broadcast by the network Specific reference signal code group or base sequence group. The XL measurements may be made on the XUL and XDL by the facilitator WTRU 3510 and the terminal WTRU 3508, respectively. The characteristics of each pair of XDL/XUL may, for example, be a subcarrier group and/or a unique code sequence assigned for the XL specific reference signal.
When the XL applies the TDD scheme, the same subcarrier group can be assigned to both the XDL and XUL of one XL. Using the FDD scheme, the subcarrier groups assigned to the XDL and XUL of one XL can be separated by the duplex distance. In both duplex cases, the same sequence or code can be used for both XDL and XUL. The XL-specific reference signals detected at one of the assigned subcarrier groups may indicate the existing XL, and the network may attempt to avoid using the same combination of subcarrier groups and reference signals to issue the XLG.
For example, if the XDL can be divided into X subbands and Y assignable sequences or codes, in order to provide the network with a thorough picture of the resource usage, the terminal WTRU may need to state in detail in each subband. How many serial codes are measured. If the sequence implementation is ZC-based and generated from a cyclic shift of the universal root sequence, the general frequency domain calculation of the Power Delay Preset (PDP) of the root sequence can be derived from the same root sequence using a single operation. All signed concatenated PDPs. This can reduce the number of measurements per sub-band. The XDL measurements can be used to construct a bitmap of X by Y bit size, where each bit indicates whether the sequence or code was detected in the subband. In other words, the bitmap can show what code and frequency resources are occupied by other XDLs near the measurement terminal WTRU. The bitmap format reduces the signaling burden required by XLG.
Because both the facilitator WTRU and the terminal WTRU in the AT-R capacity mode have a TRUL connection, the XL Measurement Report can be sent to the eNB (3522, 3524) on the PUSCH as an input to the XLG. The terminal WTRU may also transmit the XL SR via the PUCCH or the XL BSR via the PUSCH. The network may, for example, evaluate what codes and subbands are available to the reporting aid WTRU/terminal WTRU and make assignments accordingly. The initial facilitator WTRU/terminal WTRU XLG may be sent (3526/3528) in the form of a MAC Control element, for example on the PDSCH. The potential problem with XLG's data channel transmission is usually a relatively high error rate compared to the control channel. HARQ retransmissions may fail as well, and may not receive PDUs carrying the initial XLG. In this case, an XSR retransmission timer can be relied upon to trigger another transmission of the XSR/BSR to attempt to regain the initial XLG. The XLG may also be carried in the PDCCH to the facilitator WTRU and the terminal WTRU in the WTRU-specific search area to achieve high reliability of XLG transmission. It may require a new DCI format that can increase the number of WTRU blind decodings. The DCI format may have a small payload or have the same number of bits as one of the existing DCI formats with modified fields. Carrying the XLG in the PDCCH may require increasing the PDCCH capacity in the network.
When the facilitator WTRU 3510 and the terminal WTRU 3508 receive the XLG, they can apply these XLGs and begin synchronous data communication with the help of a timer, a predefined time interval referenced when receiving the XLG, or a pre-specified start time (3530). The facilitator WTRU 3510 and the terminal WTRU 3508 may begin tracking the active period and apply the XLG configuration to follow the duplex configuration, transmit the XL specific reference signal, transmit the XPDCCH/XPDDCH and XPUCCH/XPUDCH, and/or transmit for the XPDDCH and if the TDD is applied. XPUCCH DMRS. For transmitting XL-specific reference signals, both the facilitator WTRU 3510 and the terminal WTRU 3508 can transmit XL-specific reference signals, and the assistant WTRU's signals can be used by the terminal WTRU 3508 to synchronize with the facilitator WTRU 3510 (the timing and frequency of the assistant WRTU can be primary) . In addition, the facilitator WTRU reference signal can be used by the terminal WTRU 3508 to perform channel estimation (to decode the XPDCCH), to determine feedback measurements (eg, CQI), and/or to derive Transmission Power Control (TPC) bits. The terminal WTRU reference signal can also be applied for those purposes, but cannot be used for synchronization purposes.
Each helper WTRU/terminal WTRU may transmit on the same bandwidth specified in the XLG and adjust the MCS based on the received ACK/NACK and CQI. Therefore, the CQI can be measured over the same bandwidth because no frequency selection schedule can be used on the XL. CQI can provide recommendations for MCS. Alternatively, the frequency selectivity of the assigned XLG bandwidth can be detected, and the helper WTRU/terminal WTRU can report a more accurate CQI for different subcarrier groups in the licensed bandwidth and dynamically schedule transmissions over different bandwidths. The XLS information can be transmitted on the XL in a dedicated control channel (e.g., XPDCCH). The scheduling information may include, for example, MCS, subcarrier resources (if the transmission bandwidth is adjustable), a new data indicator, or a redundancy version. These bits are protected using a Cyclic Redundancy Check (CRC) bit that identifies the scrambling with an XL such as AT-RNTI.
For each TTI based on the selected MCS and the authorized bandwidth, each helper WTRU/terminal WTRU (which may be constant during the XLG validity period) may calculate XPDDCH/XPUDCH transmission power, for example based on:

Where P_XLGIs authorized XL power, BW_TXIs the transmission bandwidth (which can be the same as BWXLG or authorized bandwidth), P_NominalIs the desired power level at the assistant WTRU or the terminal WTRU, and PL is the path loss between the assistant WTRU and the terminal WTRU, Δ_TFIs a predefined function of the predefined transport format of XPDDCH, and TPC is a predefined function of the received TPC bit.
The path loss between the facilitator WTRU and the terminal WTRU may be calculated based on the XL specific reference signal, assuming that the signal is always applied to the maximum allowed power P specified in the XLG._XLG. Similarly, P_NominalIt may be the desired or target power at the assistant WTRU and the terminal WTRU for which the interference level is given. therefore,The value of +PL indicates the starting point of the basic open loop. Equivalent parameters in LTE UL controlMay include, for example, a low probability P that can range from -126 to +24 dBm and can be used to derive different BLER operating points for retransmission_{O_NOMINAL_PUSCH}Or may be in the range of -8 to +7 dB and may be used to compensate for system offsets in the WTRU transmission power due to errors in the estimated path loss._{O_UE_PUSCH}Such a component.
P_{O_NOMINAL_PUSCH}Can be signaled to the WTRU via a network broadcast, and P_{O_UE_PUSCH}It can be signaled to the WTRU via dedicated signaling, so they can also be semi-static in nature. For XL, P_NominalIt can be included in the XLG and can be updated based on the XL measurement report sent to the network. Δ_TFIt can be a function of the selected MCS, and the TPC can be a function of the received TPC bit.
In conjunction with the 2-layer scheduling, the decentralized power control functions 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 predefined algorithm based on the received quality (eg, the SINR of the reference symbol and/or the BLER of the data transmission). The TPC command can be transmitted in a dedicated XL control channel or can be multiplexed with other control information in a common control channel. The TPC rate can be slower than once per TTI and can be a design parameter. The LTE FDD system can apply TPC bits in 4 subframes after receiving the subframe of the TPC bit.
In one embodiment, the dedicated control and data channels can be time multiplexed. For example, in XDL, the XPDCCH may precede the XPDDCH in each TTI, and the terminal WTRU may need to read the XPDCCH to obtain all the information needed to decode the XPDDCH and continue to receive the XPDDCH in the same TTI. For example, this can be similar to LTE DL, where the WTRU can read the PDCCH before decoding the PDSCH in the same TTI. However, when the terminal WTRU transmits based on an authorized schedule received from the network, this may be the case on both XDL and XUL. If the dedicated control and data channels are not multiplexed in the frequency domain, one benefit may be to reduce radio requirements, in which case the WTRU/terminal WTRU transmission power may be the same on all subcarriers. This may also imply that the XL dedicated control channel may have a different power control mechanism than the XL dedicated data channel that may be more suitable for control channel format and payload. For example, the XPDCCH of subframe i can be calculated based on:

Where Δ_TFIs a function of the predefined transport format of the XPDCCH. Additionally, the bandwidth applied to the XPDCCH transmission can be predefined and is a factor of this function. As noted above, TPC is a decentralized power control function that is executed by the WTRU.
For each transmission, the facilitator WTRU/terminal WTRU may use the calculated transmission power to derive the XLPH. In addition, once there is a request from the network, they can continue the XL measurement (3532/3534) using the configuration directly related to the published XLG. For example, the network may request specific signal strength measurements on a particular subcarrier group to help optimize the XLG update, rather than a bitmap that was reported prior to the initial XLG. In this case, the measurement result may be the signal strength of the XL-specific reference signal requested in the requested subcarrier group. The result can be quantized in a manner similar to the received signal code power (RSCP) in an LTE network and can be considered for transmission on physical channels in LTE UL. For example, the result may be transmitted in the PUCCH together with UL control information bits such as CQI bits, in addition to the PUCCH, in the new dedicated entity XL feedback channel, or in the XL RRC measurement carried in the PUSCH. .
Referring to Figures 35A and 35B, the facilitator WTRU 3510 and the terminal WTRU 3508 can perform the requested XL measurements and send one or more XL measurement reports (3536/3538/3540/3542) to the eNB 3506 on the PUSSCH.
Physical channel transmissions may benefit from low latency, but may require additional PUCCH resources. Alternatively, the measurement may be multiplexed with the PUSCH in a manner similar to CQI multiplexing in the PUSCH when the TRUL grant is available. In the AT-R capacity mode, XL RRC measurements can be requested, configured, and reported in the same manner as regular neighbor cell measurements. In the AT-R coverage mode, the terminal WTRU may not have an RRC entity, so the facilitator WTRU may need to forward the terminal WTRU measurements to the network in the PUSCH.
The measurements of the facilitator WTRU and the terminal WTRU may occur in their receive subframes using the XL of the TDD scheme and in the designated band in the case of the FDD scheme. It may be necessary to measure the gap configuration to pause the TRL transmission. Upon receiving all XL measurements, the network can update the XLG to optimize resource allocation and coordinate cross-link interference (3548).
In one embodiment, the power control mechanism can be managed before the XLG is updated to adjust P while maintaining QoS._XLGTo promote the effective use of power resources (3544). For example, when the assigned bandwidth is applied unchanged, the transmitting WTRU may be based on the assigned P._XLGAnd the power control formula calculates the maximum MCS. Subsequent data transmissions may result in a BLER ratio for a predefined period of time measured at the receiving WTRU. The receiving WTRU may then generate a TPC command based on the BLER ratio to adjust the power, and a contiguous number of unidirectional TPC commands may trigger a power headroom report. For example, when more power is needed than to deliver the MCS, the receiving WTRU may send several consecutive DOWN TPC commands, which may be predefined as PHR triggers, and the transmitting WTRU may report the power headroom to the eNB. The eNB can then reduce P in the next grant._XLG. Once the XLG has been updated, the data transfer can be restored (3550).
Figures 36A and 36B include another example initial authorization acquisition procedure in capacity mode and a signal diagram 3600A/3600B to update the XLG operation. However, in the examples shown in Figures 36A and 36B, the terminal WTRU 3602 and the assistant WTRU 3604 are initially in RRC IDLE mode (3608/3610). Each of the terminal WTRU 3602 and the assistant WTRU 3604 participates in a paging procedure with the eNB 3606 (3612/3614), after which both the terminal WTRU 3602 and the assistant WTRU 3604 are in RRC CONNECTED mode (3616/3618). In the illustrated example, when both the facilitator WTRU 3604 and the terminal WTRU 3602 transition to RRC CONNECTED mode, the eNB 3606 sends measurement requests and configurations to each of the terminal WTRU 3602 and the facilitator WTRU 3604 based on the pair of WTRU's historical XLGs ( 3620/3622). The remaining signaling and procedures shown in Figure 36 are the same as those shown in Figures 35A and 35B, and the corresponding signals/programs are in Figures 35A, 35B, 36A and 36B. The same component symbol.
Figures 37A and 37B include signal diagrams 3700A/3700B of an exemplary XLG update procedure for initial authorization acquisition and continuation in overlay mode. The main difference between XLG procedures in AT-R capacity and coverage mode may be caused by the lack of TRL at the terminal WTRU. For example, in the AT-R coverage mode, the XLG can be transmitted to the terminating WTRU via the XL, all XL measurements from the terminal WTRU can be relayed to the network by its facilitator WTRU, and a new security mechanism can be implemented to prevent the XL transmission. XLG is missing.
In the examples shown in Figures 37A and 37B, neighbor search WTRU 3702, neighbor presence WTRU 3704, and eNB 3706 participate in a neighbor discovery procedure, after which neighbor WTRU 3704 is selected as a candidate helper WTRU (3708). The neighbor search WTRU 3702 and the selected candidate helper WTRU 3704 can then exchange the associated message on the XPDSACH (3710). The neighbor search WTRU 3702 and the candidate helper WTRU 3704 can then exchange RRC messages. However, the candidate helper WTRU 3704 can transmit its RRC message on the XPDSACH (3710). Its RRC message may include basic system information such as the cell ID of the candidate facilitator WTRU and the Temporary Action User Identity (TMSI) or the C-RNTI of the facilitator WTRU (3712). The neighbor search WTRU 3702 transmits its RRC message on XPUSACH. Its RRC message may include an indication that the candidate helper WTRU 3704 has been selected as the assistant WTRU (3714). If necessary, the selected assistant WTRU 3704 and eNB 3706 can then participate in the RACH and RRC connection setup procedure (3715), after which the selected assistant WTRU 3704 is in RRC CONNECTED mode (3718) and now the neighbor search WTRU 3702 is the terminal WTRU 3716 .
The selected helper WTRU 3704 may transmit a selection indicator (3720) to the terminal WTRU 3716 on the XPDACH. In response, the terminal WTRU 3716 can send an XSR to the selected assistant WTRU 3704 on the XPUACH and an XL measurement on the XPUSACH (3722). The selected helper WTRU 3704 can then send an XSR to the eNB 3706 on the PUCCH and perform an XL measurement on the PUSCH (3724).
The selected facilitator WTRU 3704 may receive the initial facilitator WTRU/terminal WTRU XLG from the eNB 3706 (3726). In order to forward the XLG to the terminal WTRU 3716, the selected facilitator WTRU 3704 may transmit the initial XLG (3727) to the terminal WTRU in XPDSACH or XPGCH. For XPDSACH, the XPDACH may indicate the XLG in the XPDSACH for the terminal WTRU 3716 to read. The XPDSACH is a data channel, and the XLG may be in the form of a MAC Control Element or MAC PDU similar to that used in RACH Access Response (RAR) for LTE systems. For XPGCH, XPDACH can indicate XLG in XPGCH. The XPGCH may be just a PHY channel, and the XLG may be in the form of a control bit. The selected assistant WTRU 3704 can now be the active assistant WTRU 3728.
The terminal WTRU 3716, assistant WTRU 3728, and eNB 3706 may begin data transmission after the initial XLG (3730). The eNB 3706 can send an XL Measurement Request and Configuration message (3732) on the PDSCH to the facilitator WTRU 3728, and the facilitator WTRU 3728 can forward the XL Measurement Request and Configuration to the terminal WTRU 3716 on the XPDCH (3734). In response, the terminal WTRU 3716 can send an XL measurement report (3736) on the XPUDCH to the facilitator WTRU 3728, and the facilitator WTRU 3728 can forward the measurement report to the eNB 3706 on the PUSCH (3738). This procedure can be repeated as necessary (eg 3740/3742). The eNB 3706 can then participate in a procedure to optimize the authorized power level for each XL (3744).
The facilitator WTRU 3728 can receive the updated helper WTRU/terminal WTRU XLG from the eNB 3706 on the PDSCH (3746). In order to forward the updated XLG to the terminal WTRU 3716, the facilitator WTRU 3728 may transmit an update XLG (3748) to the terminal WTRU 3716 in XPDSACH/XPGCH, XPGCH, XPDDCH or XPDDCH. For XPDSACH/XPGCH (unscheduled PHY channel), the assistant WTRU 3728 can transmit the update XLG in the same manner as the initial XLG. After the XLG is updated, normal transmission (3750) can be resumed.
In one embodiment, as in the AT-R capacity mode, the initial XLG transmission to the terminal WTRU may be guaranteed using XSR retransmission (eg, if the initial XLG is not received, the terminal WTRU may retransmit the XSR according to the timer) ). However, once the updated XLG is lost, they are unrecoverable and the terminal WTRU can then suspend its transmission. In this case, the assistant WTRU may detect a radio link failure (RLF) on the XUL. Therefore new processing may be needed to avoid unnecessary RLF. For example, when the assistant WTRU detects a sudden XUL-specific reference signal measurement degradation along with the start of the update XLG validity period, the facilitator WTRU may attempt to retransmit the update XLG to see if the reference signal level is recovered. Alternatively, if the update XLG is not received from the facilitator WTRU during the ongoing XLG validity period, the terminal WTRU may transmit an indication of the missing update XLG in the XPUCCH. This may trigger the helper WTRU to retransmit to the terminal WTRU. This type of security mechanism to prevent XLG loss may be useful when the XLG is carried in a data channel having a higher error rate than the physical layer control channel.
The XLG program applied in the AT-LO application can be similar to the procedure discussed in connection with the AT-R capacity mode, as all WTRUs participating in the AT-LO application can be associated with the network. The AT-LO application may employ a different set of physical channels, including, for example, an XL Entity Cluster Head Broadcast Channel (XPCHBCH) that can be used to carry XLG to all cluster members. Also, the assigned XLG can be per cluster, and the cluster header can perform a more extended XL schedule on multiple XLs. For example, a cluster header may be required to dynamically schedule resource allocations allocated by XLG to different XLs based on channel conditions and traffic changes for each XL. Each cluster member can provide similar measurements as described above with respect to the cluster head to aid in scheduling decisions.
Example
1. A radio resource scheduling method on a radio cross link between a first node and a second node, the method comprising the first node receiving a cross link specifying resources for transmission by the at least first node for use on the radio cross link Authorization.
2. The method of embodiment 1, further comprising the first node performing a cross-link schedule per transmission time interval (TTI) within the resource specified in the cross-link grant.
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 schedule per TTI.
4. The method of any of embodiments 1-3, wherein the cross-link grant is a maximum allowed cross-link transmission power, an assignment of cross-link bandwidth, a provision of cross-link power control parameters, or all entities on the cross-link At least one of the channel's assigned code configurations.
5. The method of any of embodiments 2-4, wherein the performing, by the first node, the cross-link scheduling per TTI comprises dynamically adjusting the modulation used on the bandwidth specified in the cross-link grant based on channel condition feedback And coding scheme.
6. The method of any of embodiments 2-5, wherein the first node performing cross-link scheduling per TTI comprises assigning in a cross-link grant based on a modulation and coding scheme specified in the cross-link grant The cross-link bandwidth, the cross-link path loss specified in the cross-link grant, and the transmit power control commands provided in the cross-link grant are used to calculate the corresponding required transmit power.
7. The method of any of embodiments 1-6, wherein the cross-link authorization comprises a valid period after which the cross-link authorization is no longer valid.
8. The method of any of embodiments 1-7, wherein the cross-link authorization is based on at least one of a cross-link signal and an interference measurement, a cross-link power headroom report, or a cross-link feedback measurement.
9. The method of any of embodiments 2-8, wherein the cross-link schedule per TTI is based on resources specified in the cross-link grant and cross-link acknowledgement/non-acknowledgement (ACK/NACK) messages or channels At least one of quality indicators (CQI).
10. The method of any of embodiments 1-9, wherein the first and second nodes are wireless transmit/receive units (WTRUs).
11. The method of any of embodiments 1-9, wherein the first and second nodes are enhanced Node Bs (eNBs).
12. A wireless transmit/receive unit (WTRU) includes a receiver configured to receive a Radio Link Control (RLC) Protocol Data Unit (PDU); a local buffer; and a partial RLC layer.
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.
14. The WTRU of embodiment 13 wherein the partial RLC layer is further configured to set a drop timer for the received RLC PDUs stored in the logical channel based channel queue.
15. The WTRU of embodiment 14 wherein the partial RLC layer is further configured to drop the received RLC PDU from the local buffer if the WTRU expires before the WTRU relays the RLC PDU via the radio cross-link.
16. The WTRU of any of embodiments 12-15, wherein the WTRU is configured to communicate between the base station and another WTRU by communicating with the base station via the legacy radio link and communicating with other WTRUs via the radio cross-link Relay data.
17. The WTRU of any of embodiments 12-16 wherein the other WTRUs are not located in a cell operated by the base station.
18. The WTRU of embodiment 16 or 17 further comprising a transmitter configured to transmit to other WTRUs a sequence number of the highest of the RLC PDUs of all RLC PDUs discarded by the WTRU.
19. The WTRU of any of embodiments 16-18, further comprising being configured to be in a conventional radio link and radio cross-link if the transport block size is different between a legacy radio link and a radio cross-link The inter-route relay data performs a RLC re-segmentation processor.
20. The WTRU of any of embodiments 12-19, wherein the WTRU is configured to relay by a conventional radio link between the WTRU and the base station and a radio cross link between the WTRU and other WTRUs The path communicates with the base station and other WTRUs to relay data between the base station and another WTRU, the base station and other WTRUs being configured to communicate with one another via a direct path including conventional radio links.
twenty one. The WTRU of embodiment 20 wherein separate data radio bearers (DRBs) are established to carry data via direct paths and relay paths, respectively.
twenty two. An advanced topology (AT) system comprising a base station configured to operate a wireless cell and a second comprising a first WTRU and configured to communicate with the first WTRU on a first radio cross-link Multiple WTRUs of the WTRU.
twenty three. The AT system of embodiment 22 wherein the plurality of WTRUs further comprises a third WTRU and a fourth WTRU configured to communicate with the third WTRU on the second radio cross-link.
twenty four. The AT system of embodiment 23, wherein the first WTRU, the second WTRU, the third WTRU, and the fourth WTRU are configured to receive for use by the first WTRU, the second WTRU, the third WTRU, and the fourth WTRU for Cross-link authorization for transmitted resources on the first radio cross-link and the second radio cross-link.
25. The AT system of embodiment 24, wherein the first WTRU and the second WTRU are configured to negotiate a per transmission time interval (TTI) within a resource specified in a cross-link grant for transmission on the first radio cross-link The first cross-link schedule is scheduled and the at least one packet is transmitted on the first radio cross-link based on the first cross-link schedule per TTI.
26. The AT system of embodiment 24 or 25, wherein the third and fourth WTRUs are configured to negotiate a second cross per TTI within a resource specified in a cross-link grant for transmission on the second radio cross-link The link schedules and transmits at least one packet on the second radio cross link based on the second cross-link schedule per TTI.
27. The AT system of any of embodiments 22-26, wherein the plurality of WTRUs further comprises a plurality of other WTRU pairs, each pair of the plurality of other WTRU pairs being configured to be within themselves via an individual radio cross-link communication.
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.
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 authorized to be a dedicated portion of the cross-link bandwidth provided in the cross-link grant.
30. The AT system of any one of embodiments 22-29, wherein one of the first WTRU and the second WTRU is configured to relay data between the base station and another of the first WTRU and the second WTRU An assistant WTRU.
31. The AT system of any one of embodiments 23-30, wherein one of the third WTRU and the fourth WTRU is configured to relay data between the base station and another of the third WTRU and the fourth WTRU Second assistant WTRU.
32. The AT system of any of embodiments 22-31, wherein each of the first and second helper WTRUs comprises a partial radio link control (RLC) layer.
33. The AT system of embodiment 32, wherein the portion of the RLC layer is configured to store the received RLC Protocol Data Unit (PDU) in a logical channel based channel queue of the local buffer.
34. The AT system of embodiment 33, wherein the partial RLC layer is further configured to set a drop timer for the received RLC PDUs stored in the logical channel based channel queue.
35. The AT system of embodiment 34, wherein the partial RLC layer is further configured to discard the reception from the local buffer if the RLC PDU expires before being relayed via the individual first or second radio cross-links RLC PDU.
36. The AT system of any one of embodiments 32-35, wherein each of the first and second helper WTRUs is configured to transmit to the other of the first and second WTRUs the highest of all RLC PDUs discarded by the WTRU RLC PDU Sequence Number (HDSN).
37. The AT system of embodiment 36, wherein each of the other of the first and second WTRUs is configured to respond to the first and second in response to receiving the HDSN from one of the first and second facilitator WTRUs The lower edge of the receive window of the other of the WTRU is updated to HDSN+1.
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 an intersection from an initial cross-link authorization requested for uplink transmission a link uplink scheduling request, a cross-link downlink scheduling request requesting an initial cross-link grant for downlink transmission, for jointly determining by the base station and one of the WTRU and another WTRU at the cross a scheduled terminal WTRU buffer status report in the uplink of the link, a cross-link downlink Seoul status report for the base station and the WTRU to jointly determine the schedule in the cross-link downlink, and for use by the base station The WTRU and the other WTRU jointly determine at least one selected medium access control (MAC) status report selected from the group consisting of cross-link power headroom reporting mechanisms for cross-link scheduling.
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 are located in a wireless cell.
Although the features and elements are described above in a particular combination, those of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Moreover, the methods described herein can be implemented in a computer program, software or firmware included in a computer readable medium executed 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, read only memory (ROM), random access memory (RAM), scratchpad, buffer memory, semiconductor memory devices, such as internal hard disks and removable A magnetic medium such as a magnetic sheet, a magneto-optical medium, and an optical medium such as a CD-ROM disc and a digital versatile disc (DVD). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

3355．．．流程圖3355. . . flow chart

TTI．．．傳輸時間間隔TTI. . . Transmission time interval

XL．．．交叉鏈路XL. . . Cross link

XLG．．．XL授權XLG. . . XL authorization

Claims

一種在一第一節點和一第二節點之間的一無線電交叉鏈路上的無線電資源排程的方法，該方法包括：
該第一節點接收一交叉鏈路授權，該交叉鏈路授權指定由至少該第一節點針對在該無線電交叉鏈路上的傳輸使用的一資源；
該第一節點在該交叉鏈路授權中指定的該資源內執行每傳輸時間間隔（TTI）的交叉鏈路排程；以及
該第一節點基於每TTI的該交叉鏈路排程向該第二節點傳送至少一個封包。A method of scheduling radio resources on a radio cross link between a first node and a second node, the method comprising:
The first node receives a cross-link grant specifying a resource used by at least the first node for transmission on the radio cross-link;
The first node performs a cross-link schedule per transmission time interval (TTI) within the resource specified in the cross-link grant; and the first node is based on the cross-link schedule per TTI to the second The node transmits at least one packet.

如申請專利範圍第1項所述的方法，其中該交叉鏈路授權是以下至少其中之一：
一最大允許交叉鏈路傳輸功率、一交叉鏈路帶寬的一指派、交叉鏈路功率控制參數的提供或用於該交叉鏈路上所有實體頻道的指定碼配置。The method of claim 1, wherein the cross-link authorization is at least one of the following:
A maximum allowed cross-link transmission power, an assignment of a cross-link bandwidth, provision of cross-link power control parameters, or a designated code configuration for all physical channels on the cross-link.

如申請專利範圍第1項所述的方法，其中該第一節點執行每TTI的交叉鏈路排程包括以下至少其中之一：
基於頻道狀況回饋，動態地調整在該交叉鏈路授權中指定的一帶寬上使用的一調變和編碼方案，或
基於在該交叉鏈路授權中指定的調變和編碼方案、在該交叉鏈路授權中指派的一交叉鏈路帶寬、在該交叉鏈路授權中指定的一交叉鏈路路徑損耗及在該交叉鏈路授權中提供的傳輸功率控制命令來計算一相應的需要的傳輸功率。The method of claim 1, wherein the cross-link scheduling of the first node to perform per TTI comprises at least one of the following:
Dynamically adjusting a modulation and coding scheme used on a bandwidth specified in the cross-link grant based on channel status feedback, or based on a modulation and coding scheme specified in the cross-link grant, in the cross-chain A cross-link bandwidth assigned in the way grant, a cross-link path loss specified in the cross-link grant, and a transmit power control command provided in the cross-link grant to calculate a corresponding required transmit power.

如申請專利範圍第1項所述的方法，其中該交叉鏈路授權包括一有效期間，在該有效期間之後該交叉鏈路授權不再有效。The method of claim 1, wherein the cross-link authorization comprises a valid period after which the cross-link authorization is no longer valid.

如申請專利範圍第1項所述的方法，其中該交叉鏈路授權是基於交叉鏈路信號和干擾測量、交叉鏈路功率餘量報告、及交叉鏈路回饋測量的至少其中之一。The method of claim 1, wherein the cross-link authorization is based on at least one of a cross-link signal and interference measurement, a cross-link power headroom report, and a cross-link feedback measurement.

如申請專利範圍第1項所述的方法，其中每TTI的該交叉鏈路排程是基於在該交叉鏈路授權中指定的該資源以及以下的至少其中之一：
交叉鏈路應答/非應答（ACK/NACK）消息及一或頻道品質指示符（CQI）。The method of claim 1, wherein the cross-link schedule per TTI is based on the resource specified in the cross-link grant and at least one of:
Cross-link acknowledgement/non-acknowledgement (ACK/NACK) message and one or channel quality indicator (CQI).

如申請專利範圍第1項所述的方法，其中該第一節點和第二節點是無線傳輸/接收單元（WTRU）。The method of claim 1, wherein the first node and the second node are wireless transmit/receive units (WTRUs).

如申請專利範圍第1項所述的方法，其中該第一節點和第二節點是增強型節點B（eNB）。The method of claim 1, wherein the first node and the second node are enhanced Node Bs (eNBs).

一種無線傳輸/接收單元（WTRU），該WTRU包括：
一接收器，被配置成接收一無線電鏈路控制（RLC）協定資料單元（PDU）；
一本地緩衝器；以及
一部分RLC層，被配置成：
將該接收的RLC PDU儲存在該本地緩衝器中的一基於邏輯頻道的頻道佇列中，
為儲存在該基於邏輯頻道的頻道佇列中的該接收的RLC PDU設定一丟棄計時器，以及
在該WTRU經由該無線電交叉鏈路中繼該RLC PDU之前該丟棄計時器期滿的情況下，從該本地緩衝器中丟棄該接收的RLC PDU。A wireless transmit/receive unit (WTRU) that includes:
a receiver configured to receive a Radio Link Control (RLC) Protocol Data Unit (PDU);
a local buffer; and a portion of the RLC layer configured to:
Storing the received RLC PDU in a logical channel based channel queue in the local buffer,
Setting a discard timer for the received RLC PDU stored in the logical channel based channel queue, and in the event that the discard timer expires before the WTRU relays the RLC PDU via the radio cross link, The received RLC PDU is discarded from the local buffer.

如申請專利範圍第9項所述的WTRU，其中：
該WTRU被配置成藉由經由一傳統無線電鏈路與一基地台通訊和經由該無線電交叉鏈路與其他WTRU通訊、在該基地台和另一個WTRU之間中繼資料，以及
該其他WTRU不位於由該基地台操作的胞元內。The WTRU as described in claim 9 wherein:
The WTRU is configured to relay data between the base station and another WTRU by communicating with a base station via a legacy radio link and communicating with other WTRUs via the radio cross link, and the other WTRU is not located Within the cell operated by the base station.

如申請專利範圍第10項所述的WTRU，該WTRU進一步包括一傳輸傳輸器，該傳輸器被配置成向該其他WTRU傳送被該WTRU丟棄的所有RLC PDU中最高的RLC PDU的一序列號。A WTRU as claimed in claim 10, the WTRU further comprising a transport transmitter configured to transmit to the other WTRU a sequence number of the highest RLC PDU of all RLC PDUs discarded by the WTRU.

如申請專利範圍第10項所述的WTRU，該WTRU進一步包括一處理器，該處理器被配置成在一傳輸塊大小在該傳統無線電鏈路和該無線電交叉鏈路之間不同的情況下，為在該傳統無線電鏈路和該無線電交叉鏈路之間中繼資料執行RLC重新分段。The WTRU of claim 10, the WTRU further comprising a processor configured to be different if a transport block size is different between the legacy radio link and the radio cross link, RLC re-segmentation is performed to relay data between the legacy radio link and the radio cross-link.

如申請專利範圍第9項所述的WTRU，其中：
該WTRU被配置成藉由在一中繼路徑上與基地台和其他WTRU通訊來在該基地台和該另一個WTRU之間中繼資料，該中繼路徑包括在該WTRU和該基地台之間的一傳統無線電鏈路以及在該WTRU和該其他WTRU之間的該無線電交叉鏈路，該基地台和該其他WTRU被配置成在包括該傳統無線電鏈路的一直接路徑上互相通訊，以及
分開的資料無線電承載（DRB）被建立以分別藉由該直接路徑和該中繼路徑來攜帶資料。The WTRU as described in claim 9 wherein:
The WTRU is configured to relay data between the base station and the other WTRU by communicating with the base station and other WTRUs on a relay path, the relay path being included between the WTRU and the base station a conventional radio link and the radio cross link between the WTRU and the other WTRU, the base station and the other WTRU being configured to communicate with each other on a direct path including the legacy radio link, and to separate A data radio bearer (DRB) is established to carry data by the direct path and the relay path, respectively.

一種高級拓撲（AT）系統，該系統包括：
一基地台，被配置成操作一無線胞元；以及
複數個無線傳輸/接收單元（WTRU），該複數個WTRU包括：
一第一WTRU和被配置成在一第一無線電交叉鏈路上與該第一WTRU通訊的一第二WTRU，和
一第三WTRU和被配置成在一第二無線電交叉鏈路上與該第三WTRU通訊的一第四WTRU，其中：
該第一WTRU、該第二WTRU、該第三WTRU和該第四WTRU被配置成接收一交叉鏈路授權，該交叉鏈路授權指定針對該第一無線電交叉鏈路和該第二無線電交叉鏈路上的傳輸由該第一WTRU、該第二WTRU、該第三WTRU和該第四WTRU使用的一資源，
該第一WTRU和該第二WTRU被配置成在在用於該第一無線電交叉鏈路上的傳輸的該交叉鏈路授權中指定的該資源內協商每傳輸時間間隔（TTI）的一第一交叉鏈路排程，並基於每TTI的該第一交叉鏈路排程在該第一無線電交叉鏈路上傳送至少一個封包，以及
該第三WTRU和該第四WTRU被配置成在在用於該第二無線電交叉鏈路上的傳輸的該交叉鏈路授權中指定的該資源內協商每TTI的一第二交叉鏈路排程，並基於每TTI的該第二交叉鏈路排程在該第二無線電交叉鏈路上傳送至少一個封包。An advanced topology (AT) system that includes:
a base station configured to operate a wireless cell; and a plurality of wireless transmit/receive units (WTRUs), the plurality of WTRUs comprising:
a first WTRU and a second WTRU configured to communicate with the first WTRU on a first radio cross-link, and a third WTRU and configured to communicate with the third WTRU on a second radio cross-link A fourth WTRU of communications, wherein:
The first WTRU, the second WTRU, the third WTRU, and the fourth WTRU are configured to receive a cross-link grant specifying for the first radio cross-link and the second radio cross-link The transmission on the road is a resource used by the first WTRU, the second WTRU, the third WTRU, and the fourth WTRU.
The first WTRU and the second WTRU are configured to negotiate a first cross per transmission time interval (TTI) within the resource specified in the cross-link grant for transmission on the first radio cross-link Link scheduling, and transmitting at least one packet on the first radio cross-link based on the first cross-link schedule per TTI, and the third WTRU and the fourth WTRU are configured to be in the Negotiating a second cross-link schedule per TTI within the resource specified in the cross-link grant for transmission on the two radio cross-links, and based on the second cross-link schedule per TTI on the second radio At least one packet is transmitted on the cross link.

如申請專利範圍第14項所述的AT系統，其中該複數個WTRU進一步包括複數個其他WTRU對，該多個其他WTRU對中的每一對被配置成經由一個別的無線電交叉鏈路彼此通訊，其中：
在該胞元內的每個無線電交叉鏈路被指派給多個頻率重新使用組中的一組，以及
指派給該複數個頻率重新使用組中的特定一組的每個無線電交叉鏈路被授權在該交叉鏈路授權中提供的一交叉鏈路帶寬的一專用部分。The AT system of claim 14, wherein the plurality of WTRUs further comprises a plurality of other WTRU pairs, each of the plurality of other WTRU pairs being configured to communicate with each other via a further radio cross link ,among them:
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 authorized A dedicated portion of a cross-link bandwidth provided in the cross-link grant.

如申請專利範圍第14項所述的AT系統，其中：
該第一WTRU和該第二WTRU中的一個被配置為一第一助手WTRU，用於在該基地台與該第一WTRU和該第二WTRU中的另一者之間中繼資料，以及
該第三WTRU和該第四WTRU中的一個被配置為一第二助手WTRU，用於在該基地台與該第三WTRU和該第四WTRU中的另一者之間中繼資料。For example, the AT system described in claim 14 of the patent scope, wherein:
One of the first WTRU and the second WTRU is configured as a first facilitator WTRU for relaying data between the base station and the other of the first WTRU and the second WTRU, and One of the third WTRU and the fourth WTRU is configured as a second facilitator WTRU for relaying data between the base station and the other of the third WTRU and the fourth WTRU.

如申請專利範圍第16項所述的AT系統，其中該第一助手WTRU和第二助手WTRU的每一個包括一部分無線電鏈路控制（RLC）層，該部分RLC層被配置成：
將一接收的RLC協定資料單元（PDU）儲存在一本地緩衝器中一基於邏輯頻道的頻道佇列中，
為儲存在該基於邏輯頻道的頻道佇列中的該接收的RLC PDU設定一丟棄計時器，和
在該RLC PDU經由個別的第一或第二無線電交叉鏈路中繼之前該丟棄計時器期滿的情況下，從該本地緩衝器中丟棄該接收的RLC PDU。The AT system of claim 16, wherein each of the first and second helper WTRUs comprises a portion of a Radio Link Control (RLC) layer, the portion of the RLC layer being configured to:
Storing a received RLC Protocol Data Unit (PDU) in a local buffer based on a logical channel-based channel queue,
Setting a discard timer for the received RLC PDU stored in the logical channel based channel queue, and expiring the discard timer before the RLC PDU is relayed via the individual first or second radio cross link In the case of the received RLC PDU, the received RLC PDU is discarded.

如申請專利範圍第16項所述的AT系統，其中：
該第一助手WTRU和第二助手WTRU的每一個被配置成向該第一和第二WTRU的另一者傳送被該WTRU丟棄的所有RLC PDU中最高的RLC PDU的一序列號（HDSN），以及
該第一和第二WTRU的該另一者的每一個被配置成響應於從該第一助手WTRU和第二助手WTRU中的一者接收到該HDSN，將該第一和第二WTRU中的另一者的一接收視窗的一下邊緣更新為HDSN+1。For example, the AT system described in claim 16 of the patent scope, wherein:
Each of the first helper WTRU and the second helper WTRU is configured to transmit to the other of the first and second WTRUs a sequence number (HDSN) of the highest RLC PDU of all RLC PDUs discarded by the WTRU, And each of the other of the first and second WTRUs is configured to respond to receiving the HDSN from one of the first facilitator WTRU and the second helper WTRU, the first and second WTRUs The other side of the receiving window is updated to HDSN+1.

如申請專利範圍第16項所述的AT系統，其中該第一助手WTRU和第二助手WTRU的每一個進一步被配置成向該基地台傳送從以下組選擇的至少一個媒體存取控制（MAC）狀態報告，該組由請求用於上鏈傳輸的一初始交叉鏈路授權的一交叉鏈路上鏈排程請求、請求用於下鏈傳輸的一初始交叉鏈路授權的一交叉鏈路下鏈排程請求、用於由該基地台以及該WTRU和該另一個WTRU中的一者聯合地確定在該交叉鏈路上鏈中的排程的一終端-WTRU緩衝狀態報告、用於由該基地台和該WTRU聯合地確定在該交叉鏈路下鏈中的排程的一交叉鏈路下鏈緩衝狀態報告、以及用於由該基地台、該WTRU和該另一個WTRU聯合地確定交叉鏈路排程的一交叉鏈路功率餘量報告機制組成。The AT system of claim 16, wherein each of the first facilitator WTRU and the second helper WTRU is further configured to transmit to the base station at least one media access control (MAC) selected from the group consisting of: Status report, a set of cross-link uplink scheduling requests for an initial cross-link grant requesting for uplink transmission, and a cross-link downlink with an initial cross-link grant for downlink transmission Requesting, for use by the base station and one of the WTRU and the other WTRU, jointly determine a terminal-WTRU buffer status report for scheduling in the cross-link uplink, for use by the base station and The WTRU jointly determines a cross-link downlink buffer status report for scheduling in the downlink of the cross-link, and for jointly determining cross-link scheduling by the base station, the WTRU, and the other WTRU A cross-link power headroom reporting mechanism.

如申請專利範圍第14項所述的AT系統，其中該第一WTRU、該第二WTRU、該第三WTRU和該第四WTRU的每一個位於該無線胞元內。

The AT system of claim 14, wherein each of the first WTRU, the second WTRU, the third WTRU, and the fourth WTRU are located within the wireless cell.