948-5G波束恢复机制.docx

上传人:太** 文档编号:36154791 上传时间:2022-08-25 格式:DOCX 页数:3 大小:140.12KB
返回 下载 相关 举报
948-5G波束恢复机制.docx_第1页
第1页 / 共3页
948-5G波束恢复机制.docx_第2页
第2页 / 共3页
点击查看更多>>
资源描述

《948-5G波束恢复机制.docx》由会员分享,可在线阅读,更多相关《948-5G波束恢复机制.docx(3页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。

1、方案1:重用PRACH设计方案2:重用PRACH设计方案3:上行同步信道(PUCCH、 PUSCH)BeamRecoveryBeamRecoveryBeamBeamRecovery5G波束恢复机制的三种方案5G系统中,上报波束故障的上行传输可与PRACH位于同一时域中,也就是时域资源可以正 交。针对波束恢复机制,本文给出了3种方案(来自MTK)。 方案1:用于波束故障报告的资源与PRACH位于同一时域中,并与PRACH资源正交。信号 可以是PRACH前导。 方案2:波束故障报告的资源可位于与PRACH不同的时域中。同样,信号可以是PRACH前 导。 方案3:使用其他信道/信号的其他机制,例如S

2、R、UL grant free PUSCHo可以以LTE中 的调度请求(SR: scheduling request )为例。这三个方案的时间实例例如如图1所示。在LTE中,PRACH周期从1ms到20nls不等,这比100ms控制面延迟要求要短得多。在NR中,控制 面延迟要求减少到10ms。为了满足这一延迟要求,可以合理地假设NR中PRACH的周期不应大 于10ms。这意味着方案1中的周期性最多为10ms。虽然方案2和方案3可以提供比方案1更多的 调度灵活性。PRACH periodicityPRACHIBeamIRecdvery图1 : 3中波束恢复机制方案现在,将方案1区分为两种不同的方

3、案:方案1-A和方案1-B。这两种方案之间的区别在于循 环移位:方案A的循环移位较长,而方案的循环移位较短。这里比拟了方案1-A、方案 1-B和方案3之间的容量。 方案1:用于波束故障报告的资源与PRACH位于同一时间实例中,并与PRACH资源正交。 信号是PRACH前导。方案A:具有更长循环移位的PRACH前导码方案1-B:具有较短循环移位的PRACH前导码 方案3:在LTE中,PUCCH formatl可以在一个PRB中执行多达36个调度请求(SR),如图 2所示。因此,选择PUCCH format 1上的LTE SR作为容量基准的候选。为了增强其容量, 假设(1)所有RE都用于SR, (

4、2) slotl和slot2之间没有跳频,以及(3) slotl和 slot2应用额外的正交覆盖码(OCC: orthogonal cover code)。 SIqL_Usr hi 132RESubframe图2:在 PUCCH formatl的LTE SRLTE中的PRACH前导码,例如表1中的方案l-A,设计用于上行异步和同步传输。因此,当场景 是上行同步时,有优化的空间。例如,可以减少循环移位样本(Ncs)的数量,因为已经为上 行链路同步UE补偿了往返传播延迟。这种优化导致方案1-B可以到达方案3中SR容量的74%。 表1总结了详细的分析和假设。表1:方案1-A,方案1-B,和方案.3的

5、容量比拟模式容量(per 6PRB)备注方案ALTE PRACH(Ncs=93)72 preamblesLTE PRACH formatO,用于非同步PRACH : Nzc=839, ZC根序歹J数= 8, Ncs=93玲capacity=72方案 BLTEPRACH(Ncs=9)744 preamblesLTE PRACH formatO与减少的Ncs为同步的PRACH: Nzc=893, ZC根序列数= 8 Ncs=9 T Capacity=744方案3PUCCH formatl 是的SR1008 sequences假设所有RE用于SR, (2) slotl和slot2之间无跳频, (3)

6、 slotl 和 slot2 有附力口的 orthogonal cover code (OCC)提出了波束恢复机制来应对波束失效。因此,gNB需要扫描不同的波束,以便从遇到波束故 障的UE接收新的波束指示。在NR中,PRACH是一种通过扫描波束传输到gNB的信道。因此, PRACH是波束恢复请求的一个很好的候选者。相反,如果使用方案3进行波束恢复请求,那么必 须引入和设计一个全新的信道。三种方案的比照方下:表2 :方案1/2/3之间的比拟总结规范影响周期性资源效率方案1低=10ms低(方案1-A)到中(方案1-B)方案2中比方案1更灵活(但应明确提高灵活性的必要性)低到中(类似方案1)方案3高

7、比方案1更灵活(但应明确提高灵活性的必要性)高根据之前的分析,方案1-B提供了与方案3相当的容量。然而,为了为连接的ue提供足够的专 用前导码,期望在相同的时频资源中使用多个根序列。这相应地增加了多址干扰。同步 PRACH不需要定时提前估计。因此,在非同步PRACH中,带宽可以减少并且比定时估计精度所 需的带宽窄。使用窄带PRACH,可以分配多个时频资源,以获得与方案1B相同甚至更多的容 量。这还可以减少来自其他根序列的干扰。图3显示了窄带PRACH的一个例如,其中假设两种 设计中的子载波间隔相同。通过减少带宽,前导序列长度相应地减少。由于根序列的数量和 序列长度都减少了,因此接收机的检测复杂

8、度也降低了。Root: (1, 2), Nzc=139,必=2 Root: (1, 2), “c=139,必=2 Root: (1, 2), “尸39,心立 Root: (1, 2), Nzc=139,%二2 Root: (lz 2), Nzc=139z Ncs=2Root: (1, 2), Nzc=139, Ncs=2RACH BW 124 preambles)interferencefrom other图3:上行同步UE的窄带PRACH设计例如为波束恢复请求分配的时频资源用于UE报告波束故障,并在发生波束故障时向gNB指示新的 波束信息。然而,当链路状况良好且没有波束故障时,这些时频资源正在被浪费。为了充分 利用这些分配的资源,建议在UE没有遇到波束故障时将其应用于其他请求或指示。例如, gNB可以向连接的UE分配专用PRACH前导码以发送波束恢复请求和SR。如果UE在服务波束上传 输其专用PRACH前导码,那么表示调度请求。另一方面,如果UE在非服务波束上传输其专用 PRACH前导码,那么意味着波束恢复请求。波束恢复请求和SR的联合设计例如如图4所示。PRACH to send SR andbeam recovery requestServinbeamNon-serving beamgNBUE d图4:波束恢复请求与调度请求的联合设计

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 应用文书 > 解决方案

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知得利文库网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号-8 |  经营许可证:黑B2-20190332号 |   黑公网安备:91230400333293403D

© 2020-2023 www.deliwenku.com 得利文库. All Rights Reserved 黑龙江转换宝科技有限公司 

黑龙江省互联网违法和不良信息举报
举报电话:0468-3380021 邮箱:hgswwxb@163.com