CN108093479A - 一种提升lte***上行速率的方法 - Google Patents
一种提升lte***上行速率的方法 Download PDFInfo
- Publication number
- CN108093479A CN108093479A CN201611042257.9A CN201611042257A CN108093479A CN 108093479 A CN108093479 A CN 108093479A CN 201611042257 A CN201611042257 A CN 201611042257A CN 108093479 A CN108093479 A CN 108093479A
- Authority
- CN
- China
- Prior art keywords
- terminal
- uplink
- pusch
- frame
- base station
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L5/00—Arrangements affording multiple use of the transmission path
- H04L5/0001—Arrangements for dividing the transmission path
- H04L5/0003—Two-dimensional division
- H04L5/0005—Time-frequency
- H04L5/0007—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT
- H04L5/001—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT the frequencies being arranged in component carriers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/20—Control channels or signalling for resource management
- H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本申请公开了一种提升LTE***上行速率的方法,包括:判断终端在当前子帧是否已被分配用于发送上行共享信道UL‑SCH数据的上行资源;如果终端在当前子帧没有被分配用于发送UL‑SCH数据的上行资源,则基站构造上行预调度授权预UL Grant发送给所述终端,并且,不为所述终端配置物理上行控制信道PUCCH资源,将对应的资源块RB资源给物理上行共享信道PUSCH使用。应用本申请公开的技术方案,能够提升LTE***的上行速率。
Description
技术领域
本申请涉及移动通信技术领域,特别涉及一种提升LTE***上行速率的方法。
背景技术
在LTE(Long Term Evolution,长期演进)***中,PUCCH(Physical UplinkControl Channel,物理上行控制信道)的作用简述如下:
终端需要发送必要的上行L1/L2控制信息以支持上下行数据传输。上行L1/L2控制信息(Uplink Control Information,UCI)包括:
·SR(Scheduling Req,调度请求):用于终端向基站请求上行共享信道(UL-SCH)资源。
·HARQ ACK/NACK(混合自动重传请求确认/非确认):对在PDSCH(PhysicalDownlink Share Channel,物理下行共享信道)上发送的下行数据进行HARQ确认。
·CSI:Channel State Information(信道状态信息),包括CQI(信道质量指示)、PMI(预编码矩阵指示)、RI(秩指示)等信息,用于通知基站下行信道质量等,以帮助基站进行下行调度。CSI上报可以配置成周期性的(periodic),也可以是非周期性的(aperiodic)。
由于调度是在基站侧实现的,与上行资源分配相关的信息(Resource blockassignment(资源块分配)、MCS(调制与编码策略)等)是由基站通过UL grant(上行调度授权)通知终端的,且对应该UL grant,终端在哪个上行子帧发送数据是固定的(对应关系见3GPP36.213协议的Table 8-2),因此,基站知道终端将在哪个上行子帧的哪些RB(资源块)上使用哪种MCS发送数据,而不需要终端通知基站。
PUCCH在频域上通常被配置成位于上行***带宽的边缘。一个PUCCH在一个上行子帧内占2个时隙(slot),1个slot是1ms,每个slot在频域上占12个子载波(subcarrier),即1个RB。为了提供频域分集,PUCCH在slot的边界“跳频”:即在同一子帧内,PUCCH前后两个slot的PRB资源分别位于可用的频谱资源的两端(这2个PRB组成了一个RB对(RB pair)),而中间的整块频谱资源用于传输PUSCH。这样的设计能够提供PUCCH的频率分集增益。
即使终端没有被分配任何UL-SCH资源,终端也可能需要发送上行控制信息。根据终端是否已经被分配了上行UL-SCH资源,LTE定义了2种不同的方式用于发送上行L1/L2控制信息。
1、如果终端在当前子帧没有被分配用于发送UL-SCH数据的上行资源,则终端使用PUCCH来发送上行L1/L2控制信息。
2、如果终端在当前子帧被分配了用于发送UL-SCH数据的上行资源,则终端使用PUSCH来发送上行L1/L2控制信息。如果终端已经被分配了UL-SCH资源,就没必要再发送SR了。非周期性CSI只能在PUSCH上传输。
随着LTE***的广泛使用,使用小带宽的场景需求也越来越多。3M***带宽有15RB,1.4M***带宽只有6RB。
在RB资源如此紧张的小带宽情况下(例如带宽只有6RB),终端在一个子帧中独占一个RB pair来发送PUCCH太浪费资源了,一个RB pair就是2个RB。
由3GPP 36.213协议Table 7.1.7.2.1-1可知,在MCS确定的情况下,调度可发送数据量(bit)可查询。当前上行子帧PUSCH调度的RB数=总RB数-PUCCH占用RB数–PRACH占用RB数。将RB数扩展到10ms和1s,就能得到上行速率。其中,PRACH是物理随机接入信道。
以TDD-LTE 1.4M带宽(6个RB)为例,子帧配比1,特殊子帧配比7,上行子帧传输有2、3、7、8。假设物理随机接入信道(PRACH)(固定占用6个RB)10ms内有一次且用子帧8。MCS28阶对应的传输块大小(TBS)是26。
表1
因为PUCCH至少占用一个RB pair,即2个RB,所以上行速率使用的最大PUSCH调度的RB数是4。根据表1,PUCCH资源数配置最小2个RB时,上行速率为895.2K。
分析可知,如果配置更多的PUCCH资源,上行速率就会不升反而降。所以在***信噪比和编码稳定情况下,采用当前的方式提升速率比较困难。
发明内容
本申请提供了一种提升LTE***上行速率的方法,以提升LTE***的上行速率。
本申请提供了一种提升LTE***上行速率的方法,包括:
判断终端在当前子帧是否已被分配用于发送上行共享信道UL-SCH数据的上行资源;
如果终端在当前子帧没有被分配用于发送UL-SCH数据的上行资源,又有要求发送L1/L2控制信息的需求时,则基站构造上行预调度授权(UL Grant)去实现,只不过终端用PUSCH发送的上行数据是padding(MAC PDU空包),基站收到的数据也是padding(MAC PDU空包)。不配置、不使用PUCCH资源,其传输的上行L1/L2控制信息也能传输到基站。
较佳的,终端在所述PUSCH上发送数据和上行L1/L2控制信息。
较佳的,终端根据所述预UL Grant用PUSCH发送的上行数据是无效的,基站收到的对应的数据是无效的。
由上述技术方案可见,本申请提供的提升LTE***上行速率的方法,首先判断终端在当前子帧是否已被分配用于发送UL-SCH数据的上行资源;如果终端在当前子帧没有被分配用于发送UL-SCH数据的上行资源,则基站构造预UL Grant发送给所述终端,并且,不为该终端配置PUCCH资源,将对应的RB资源给PUSCH使用,从而能够显著提升LTE***的上行速率。
附图说明
图1为本发明一示例性资源位置示意图;
图2为本发明一较佳基站决策调度授权的流程示意图;
图3为本发明一示例性时序关系示意图。
具体实施方式
为使本申请的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本申请作进一步详细说明。
由香农公式C=Blog2(1+S/N)可知,在***信噪比以及编码技术稳定情况下,只有提高B才能提高信道容量。其中,C是信道容量,B是信道带宽(赫兹),S是信号功率(瓦),N是噪声功率(瓦)。
小带宽的场景对上行速率有更高的需求,为了有效地利用带宽资源,本发明采用不配置、不使用PUCCH资源的方式,省去PUCCH资源开销,将腾出的RB资源给PUSCH使用,从而可使上行速率有较大提升。如表2所示,当不配置PUCCH资源时,上行速率可达到1.3176M。
表2
因此,PUCCH资源腾出的RB资源也就越大,供PUSCH使用RB的也越多,上行速率提升效果越明显。
既然不配置、不使用PUCCH资源,其传输的上行L1/L2控制信息却还要传输到基站,如何实现呢?即如何做到不使用PUCCH,***的功能特性还基本不受影响或影响很小呢?
如协议所述,终端在接入网络之后,终端在当前子帧被分配了用于发送UL-SCH数据的上行资源,则终端使用PUSCH来发送上行L1/L2控制信息,即L1/L2控制信令与数据复用PUSCH。
可知,LTE支持一种不使用PUCCH而使用PUSCH传输L1/L2控制信息,但前提条件是终端在当前子帧被分配了用于发送UL-SCH数据的上行资源。
基于以上分析,本申请提出一种提升LTE***上行速率的方法,其主要思想是:
如果终端在当前子帧没有被分配用于发送UL-SCH数据的上行资源,则基站构造上行预调度授权(以下简称:预UL Grant)去实现,但是终端用PUSCH发送的上行数据是无效的,基站收到的数据也是无用的。
通过上述操作,使得终端在当前子帧获得了上行预调度授权,从而,终端就能使用PUSCH来发送数据,同时也发送上行L1/L2控制信息,而控制信息较少,不多占RB资源。
同时,上行预调度授权只是会增加物理下行控制信道(PDCCH)下行控制信息(DCI)的频度而已。
至此,就能把PUCCH空出的RB资源给PUSCH使用,因此,一定会提高上行速率,尤其对小带宽的LTE***的提升效果尤为突出。
既然不使用PUCCH资源,而使用PUSCH来发送上行L1/L2控制信息,如何保证控制信息的可靠传输呢?
相关描述参见3gpp 36.211协议和3gpp 36.212协议,已做了保证。因为这种方式LTE设计时是考虑到的。
CQI/PMI使用与PUSCH相同的调制方式,占用频谱高资源位置。
HARQ ACK/NACK反馈和RI要求高可靠性,所以使用BPSK/QPSK调制。
如图1所示,按照上述设计在每个子帧的前后两个时隙内都存在HARQ ACK/NACK反馈和RI,这样的配置使得当时隙之间存在跳频的时候,控制信令能够获得频率增益。ACK/NACK围绕在DMRS的两侧,可以使得ACK/NACK获得最精确的信道估计。RI的位置在ACK/NACK的两侧,即使ACK/NACK没有反馈,RI也不能占据相应的位置。CQI、PMI放置在PUSCH频率开始的位置,分布在PUSCH子帧内除去DMRS外的所有符号上。
从***的角度来看,只有当小区有下行数据需要发送(此时才会关心下行信道的相关信息)时,才会要求UE发送非周期性CSI上报。
综上所述,把PUCCH空出的RB资源给PUSCH使用,***功能和性能受影响小,如果对上行速率有较高的追求,则该方法不啻为一个可行的方法。
由于调度是在基站侧实现的,因此,本发明从基站角度描述如何决策调度授权,该决策流程如图2所示,包括以下步骤:
步骤1:判断当前下行(DL)子帧是否允许发送UL Grant,如果允许发送UL Grant,进入步骤2,如果不允许发送UL Grant,跳到步骤7。
步骤2:判断在对应的上行子帧是否有上行数据需要发送,如果有上行数据需要发送,跳到步骤5,如果没有上行数据需要发送,进入步骤3。
步骤3:判断对应的上行子帧是否有针对下行数据的HARQ ACK/NACK需要反馈给基站,如果有,继续步骤4。
步骤4,PDCCH构造预UL Grant,跳到步骤6。
步骤5:PDCCH只携带上行数据对应的授权,因为HARQ ACK/NACK反馈和上行数据一起通过PUSCH进行传输。
步骤6:判断PDCCH是否还有多余的CCE位置可用,如果有多余的CCE位置可用,继续执行步骤7,如果没有多余的CCE位置可用,结束本流程。
步骤7:判断eNB是否有下行数据需要发送,如果有下行数据需要发送,继续步骤8。
步骤8:eNB在当前下行子帧发送下行数据,然后,结束本流程。
由3Gpp 36.213协议中的Table 8-2可知,如果给出了终端在下行子帧n收到PDCCHwith DCI format 0,则在子帧n+k发送PUSCH。基于此,图3给出了本发明方法中基站和终端的UL Grant与PSUCH间时序关系。图3所示时序关系以配置1为例进行说明。
由上述技术方案可见,本申请的关键点在于:
1、***不配置PUCCH资源,从而不使用PUCCH,将腾出的RB资源给PUSCH使用。腾出的RB资源越大,上行速率提升效果越明显。
2、终端在当前子帧需要发送上行L1/L2的控制信息,完全通过PUSCH来传输。
3、如果终端在当前子帧没有被分配用于发送UL-SCH数据的上行资源,则基站构造预上行调度授权(UL Grant)来满足。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。
Claims (3)
1.一种提升长期演进LTE***上行速率的方法,其特征在于,包括:
判断终端在当前子帧是否已被分配用于发送上行共享信道UL-SCH数据的上行资源;
如果终端在当前子帧没有被分配用于发送UL-SCH数据的上行资源,则基站构造上行预调度授权预UL Grant发送给所述终端,并且,不为所述终端配置物理上行控制信道PUCCH资源,将对应的资源块RB资源给物理上行共享信道PUSCH使用。
2.根据权利要求1所述的方法,其特征在于:
终端在所述PUSCH上发送数据和上行L1/L2控制信息。
3.根据权利要求1所述的方法,其特征在于:
终端根据所述预UL Grant用PUSCH发送的上行数据是无效的padding,基站收到的对应的数据是无效的padding。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611042257.9A CN108093479A (zh) | 2016-11-23 | 2016-11-23 | 一种提升lte***上行速率的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611042257.9A CN108093479A (zh) | 2016-11-23 | 2016-11-23 | 一种提升lte***上行速率的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN108093479A true CN108093479A (zh) | 2018-05-29 |
Family
ID=62171030
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201611042257.9A Pending CN108093479A (zh) | 2016-11-23 | 2016-11-23 | 一种提升lte***上行速率的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108093479A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113826342A (zh) * | 2019-08-13 | 2021-12-21 | 华为技术有限公司 | 一种通信方法及相关设备 |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101772970A (zh) * | 2007-08-06 | 2010-07-07 | 高通股份有限公司 | 无线通信***中话务数据和控制信息的多路复用和传输 |
CN101959284A (zh) * | 2010-09-30 | 2011-01-26 | 中兴通讯股份有限公司 | 控制信息传输方法及装置 |
CN101978721A (zh) * | 2008-04-24 | 2011-02-16 | 夏普株式会社 | 移动站装置、移动通信***以及通信方法 |
CN102884742A (zh) * | 2010-05-04 | 2013-01-16 | 三星电子株式会社 | 用于指示上行链路控制信息的传输模式的方法和*** |
CN103119877A (zh) * | 2010-06-21 | 2013-05-22 | 华为技术有限公司 | 用于上行链路多入多出的控制信息多路复用的***和方法 |
CN103283168A (zh) * | 2010-11-08 | 2013-09-04 | 高通股份有限公司 | Pusch上的仅cqi传输 |
EP2996420A1 (en) * | 2013-05-09 | 2016-03-16 | NTT DoCoMo, Inc. | User terminal, wireless base station, and wireless communication method |
WO2016182047A1 (ja) * | 2015-05-14 | 2016-11-17 | 株式会社Nttドコモ | ユーザ端末、無線基地局及び無線通信方法 |
-
2016
- 2016-11-23 CN CN201611042257.9A patent/CN108093479A/zh active Pending
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101772970A (zh) * | 2007-08-06 | 2010-07-07 | 高通股份有限公司 | 无线通信***中话务数据和控制信息的多路复用和传输 |
CN101978721A (zh) * | 2008-04-24 | 2011-02-16 | 夏普株式会社 | 移动站装置、移动通信***以及通信方法 |
CN102884742A (zh) * | 2010-05-04 | 2013-01-16 | 三星电子株式会社 | 用于指示上行链路控制信息的传输模式的方法和*** |
CN103119877A (zh) * | 2010-06-21 | 2013-05-22 | 华为技术有限公司 | 用于上行链路多入多出的控制信息多路复用的***和方法 |
CN101959284A (zh) * | 2010-09-30 | 2011-01-26 | 中兴通讯股份有限公司 | 控制信息传输方法及装置 |
CN103283168A (zh) * | 2010-11-08 | 2013-09-04 | 高通股份有限公司 | Pusch上的仅cqi传输 |
EP2996420A1 (en) * | 2013-05-09 | 2016-03-16 | NTT DoCoMo, Inc. | User terminal, wireless base station, and wireless communication method |
WO2016182047A1 (ja) * | 2015-05-14 | 2016-11-17 | 株式会社Nttドコモ | ユーザ端末、無線基地局及び無線通信方法 |
Non-Patent Citations (2)
Title |
---|
ZTE: "Discussion on UCI transmission on an LAA SCell", 《3GPP TSG RAN WG1 MEETING #85 R1-164598》 * |
ZTE: "Issues on UCI transmission on PUSCH in LTE-Advanced", 《3GPP TSG RAN WG1 MEETING #62 R1-104673》 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113826342A (zh) * | 2019-08-13 | 2021-12-21 | 华为技术有限公司 | 一种通信方法及相关设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6972161B2 (ja) | 伝送データブロックサイズを判定するための方法およびノード | |
US20190037514A1 (en) | Method for determining uplink transmission timing of terminal having plurality of cells configured therein in wireless communication system, and apparatus using the method | |
US20190150187A1 (en) | Method for receiving data in wireless communication system, and apparatus therefor | |
CN105227266B (zh) | 传输上行控制信息的方法、用户设备和基站 | |
CN107534529A (zh) | 增强型授权辅助接入技术的控制信道设计 | |
JP2019126069A (ja) | セルラー移動通信システムでsrs送信方法及び装置 | |
WO2015108068A1 (ja) | ユーザ端末、無線基地局及び無線通信方法 | |
CN107277923A (zh) | 无线通信***中改善使用配置资源的传输的方法及装置 | |
CN104243108B (zh) | 上行混合自动重传请求反馈方法、装置和*** | |
CN108243630A (zh) | 指示以及实现新ue能力的方法以及装置 | |
WO2015008804A1 (ja) | 端末装置、方法、および集積回路 | |
RU2742350C1 (ru) | Выбор ресурсов для управляющей сигнализации в сети радиодоступа | |
WO2015002237A1 (ja) | 端末装置、基地局装置、集積回路、および通信方法 | |
CN104125039B (zh) | 一种确定传输链路的类型的方法、***及设备 | |
CN106575994A (zh) | 无线设备至设备通信调度 | |
WO2016138646A1 (zh) | 混合自动重传请求确认传输方法和装置 | |
CN101764642A (zh) | 一种下行控制信息的传输方法及传输*** | |
US20160227538A1 (en) | Method and apparatus for communication for terminal in wireless communication system | |
US20150098424A1 (en) | Method and apparatus for power headroom reporting in a wireless communication system | |
EP3054614B1 (en) | Transmission method for uplink control information, base station and user equipment | |
CN102316526A (zh) | 传输方法及装置 | |
JP6886399B2 (ja) | 無線端末、基地局、及びプロセッサ | |
WO2015008830A1 (ja) | 端末装置、基地局装置、集積回路、および無線通信方法 | |
JP7058640B2 (ja) | 電力ヘッドルームレポート方法及び装置 | |
KR20240011687A (ko) | 사이드링크 구성 그랜트들의 증가된 수량에 대한 지원 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180529 |
|
RJ01 | Rejection of invention patent application after publication |