网站首页 > 博客文章 正文
在Rel-15中引入EN-DC单UL部署的动机有两个方面。一是提高不支持动态功率共享的EN-DC UE的功率利用效率。另一个是避免由互调失真(IMD:inter-modulation distortion)或谐波问题引起的UE接收机灵敏度降低。
考虑到Rel-15 EN-DC UE以半静态方式复用LTE 上行和NR 上行,并且仅针对LTE FDD指定基于TDM模式的单上行部署(SUO case 1),可以考虑以下方面在Rel-16中进一步增强。
- 支持带内EN-DC的单UL部署
- 使用LTE FDD PCell提高EN-DC的NR侧频谱效率
对于具有LTE FDD PCell的Rel-15 EN-DC,UE仅被允许在单Tx模式下,在由DL-reference TDD配置指定为UL的子帧中发送LTE SRS。并且被指定为特殊子帧的子帧被视为非UL子帧。而对于具有LTE TDD PCell的EN-DC,如果应用相同的行为,则LTE SRS传输的可用资源受到相当大的限制,如图1所示,其中LTE PCell具有小区特定TDD configuration 2并配置有DL-reference configuration 5。可以观察到,只有一个子帧可用于LTE SRS传输,而3个子帧可被用于NR SRS传输。更密集的SRS可以支持更高维度的下行链路MIMO,否则LTE侧的下行MIMO性能将显著降低,如这种情况。
考虑到LTE是MCG,优选为LTE SRS传输分配更多的资源,或者至少用于SRS传输的可用资源应均匀地分配给LTE和NR。为此,LTE SRS传输的子帧不应被DL-reference TDD配置限制在指定的UL子帧内。被指定为特殊子帧的子帧也可以被允许用于type1和type2 UE的SRS传输。
对于type1 UE,即具有动态功率共享能力,以下协议使得UE能够在所有上行场合中发送NR和LTE PUSCH。
对于type1 UE(即具有动态功率共享能力的UE):
- UE不应假设LTE PUSCH仅在由DL-reference配置的相关联的UL子帧中调度
- UE不应假设NR PUSCH仅在除由DL-reference配置的UL子帧之外的其余UL子帧中调度
如果存在冲突,在DL-reference配置中指定为上行的UL子帧中,预期UE将丢弃NR PUSCH。
重要的是要提到的是,协议为不能双PA的UE指定了非零切换时间,参考TS 38.101-3,其中上行切换时间定义为120us。因此,对于不能使用双PA的type1 UE,上述协议将对LTE和NR侧的PUSCH传输造成负面影响。下图中给出了一个示例,其中LTE PCell具有小区特定TDDconfiguration 1,并配置有DL-reference configuration 4。考虑UE在子帧#2中不调度LTE PUSCH的情况下在子帧中传输NR个PUSCH。UE无法在连续子帧#3中传输LTE PUCCH的所有14个符号,并且为了120us切换时间,LTE PUSCH的前两个符号将被丢弃。结果,LTE PUSCH不能以高概率被eNB成功解码。NR PUSCH也会出现类似的问题。
因此,上述协议中type1 UE的项目符号也应限制为能够双PA的UE。而对于不能双PA的type1的UE,其行为应与type2的UE相同。
对于能够双PA的type1 UE,应当指定用于在UL子帧中处理LTE PUSCH和NR PUSCH/PUCCH/SRS/PRACH之间的冲突的UE行为,而不是通过DL-reference TDD configuration指定的UL子帧,因为不能假设gNB和eNB彼此紧密协调。一般来说,PUCCH/PRACH比PUSCH更重要,因此当与NR PUCCH/PRACH发生冲突时,UE预计会丢弃LTE PUSCH。对于NR PUSCH,一般认为当UE与NR PUCCH冲突时,UE更有可能丢弃LTE PUSCH。否则,当UE在LTE UL中具有大量业务时,NR PUSCH将以高概率被阻塞。然后,对于NR SRS,因为NR SRS传输对于TDD部署是必不可少的,以促进具有高级预编码和波束赋形的DL MIMO传输,所以它应该优先于LTE PUSCH,超出由DL-reference TDD configuration指定为UL的子帧。
对于SRS,还可以允许能够双PA的type1 UE在由DL-reference TDD configuration指定为DL的原始TDD配置中的UL或特殊子帧中发送LTE SRS,并在其他UL或特殊子帧中发送NR SRS。允许type1 UE在更多子帧中发送SRS可以更好地利用传输资源。同时还应指定用于处理冲突的相应UE行为。例如,在指定为UL或专用的子帧中,UE在与LTE PUCCH冲突时应丢弃NR SRS/PRACH。当它与LTE PUSCH冲突时,UE可以丢弃LTE PUCCH。
对于PRACH,优选允许type1和type2 UE在由小区特定TDD配置的所有上行子帧中发送LTE PRACH。在Rel-15中,仅允许PRACH在DL-reference TDD configuration专用的上行子帧内进行传输。由于RACH资源是以小区特定的方式配置的,而DL-reference TDD configuration是UE特定的,因此这种限制降低了eNB确定适当RACH资源配置以匹配小区中具有不同DL-reference TDD configuration的UE的灵活性,并且如果为了上行业务扩展的目的为这些UE配置不同的HARQ偏移,则将引入更多限制。为了解决上述问题,一种有效的方法是允许UE在所有上行子帧中发送LTE PRACH。类似地,这种方法甚至有益于配置有FDD PCell和DL-reference TDD configuration的EN-DC UE。对于未被DL-reference configuration指定为UL并且使用LTE PRACH传输的UL子帧,可能存在同时NR传输。对于能够动态功率共享的type1 UE,NR调制解调器可以及时确认所有LTE PRACH传输时机,并且NR传输的发射功率可以相应地缩小。但是对于type2 UE,NR调制解调器可能不会立即意识到LTE PRACH传输。UE不存在违反SAR规则的风险,因为SAR规则需要至少6分钟的长平均时间,这为UE提供了足够的反应持续时间以降低NR功率。PRACH传输场合比其他UL业务PUSCH/PUCCH/SRS稀疏得多,并且其对SAR控制的负担可以忽略不计。因此,两种类型的UE都可以在不违反SAR规则的情况下安排适当的发射功率。
在Rel-15中,可以从高层发信号通知的HARQ偏移的候选值为0到9。而在LTE TDD PCell的情况下,应通过移除无效值来减少候选值。下图中说明了一个示例,其中LTE PCell具有小区特定TDD configuration 1,并配置了 DL-reference configuration2。有效HARQ偏移值可以是{0、1、5、6}之一。
下表列出了小区特定TDD配置和 DL-reference configuration之间的每个组合的HARQ偏移的有效值。注意,在R16中不支持在SIB1中配置的LTE PCell的TDD pattern 0和6的情况。通过将所有组合的有效值组合在一起,可以总结出HARQ偏移的有效值只能是{0,1,2,5,6}中的一个。
对于TDD LTE,当UE接收到具有DAI>1的DCI消息时,来自配置的PUCCH格式3/4/5资源之一的PUCCH资源将由相关DCI中的TPC字段的两个比特明确确定。当向UE通知DAI=1时,TPC字段将用于功率控制,并且由CCE索引隐式指示的PUCCH格式1a/1b资源将是回退资源。为了避免传统UE和EN-DC UE之间的潜在资源冲突,一致认为,对于DAI=1,EN-DC用户不应遵循上述传统方式。
在Rel-15 EN-DC的单UL部署中,UE将根据更高层信令tdm-PatternConfig-r15确定帧内的有效LTE UL子帧。Type2 UE仅限于在这些有效UL子帧中发送LTE UL信号,并且不允许在与有效LTE UL子帧在时间上重叠的任何NR个时隙中发送NR UL信号。如下图所示,对于第一部分为DL而后一部分为UL的NR 特殊时隙,如果其在时间上与有效LTE UL子帧重叠,则该特殊时隙的UL部分不能用于NR UL传输。
注意,特殊时隙中的UL部分可用于SRS传输,这有利于通过TDD频带中的UL/DL信道互易性来改善DL MIMO性能。但是,在单UL部署的当前机制下,用于NR SRS传输的可用UL资源显著减少,这将对DL MIMO的性能造成负面影响。NR TDD载波的UL资源通常远小于DL资源,因为大部分持续时间将被配置为DL,以满足DL主导业务。其中,用于NR SRS传输的UL资源在单个UL部署中可能不足,特别是对于高移动性的UE。由于这个原因,优选的是在NR侧允许更多的UL资源,至少用于在单个UL部署中用于EN-DC UE的SRS传输。例如,与LTE上行子帧的最后符号在时间上重叠的NR符号可以被维持用于NR SRS传输。在这种情况下,UE可以仅在子帧的前13个符号中发送LTE PUSCH/PUCCH,并且当在子帧中配置小区特定SRS时,LTE中已经支持这种短格式的PUSCH/PUCCH。对LTE规范的影响较小。
猜你喜欢
- 2024-10-08 5G通信标准学习笔记——众里寻他千百度(随机接入信道)
- 2024-10-08 5G NR 下行同步SSB(4)—频域配置多个SSB
- 2024-10-08 5G NR 随机接入(7)—RACH分类和重要流程总结
- 2024-10-08 5G 系统消息(5g消息是怎么回事)
- 2024-10-08 5G(NR) 网络中终端小区搜索过程(简述5g小区搜索流程)
- 2024-10-08 5G通信标准学习笔记——众里寻他千百度(同步广播块集合下)
- 2024-10-08 5G NR 随机接入(3)—PRACH时频资源
- 2024-10-08 R16 2-step RACH信道结构(2.4信道)
- 2024-10-08 点点滴滴学5G—深入了解NSA注册流程
- 2024-10-08 点点滴滴学5G—NR type0 PDCCH调度详解
你 发表评论:
欢迎- 07-08Google Cloud Platform 加入支持 Docker 的容器引擎
- 07-08日本KDDI与Google Cloud 签署合作备忘录,共探AI未来
- 07-08美国Infoblox与Google Cloud合作推出云原生网络和安全解决方案
- 07-08GoogleCloud为Spanner数据库引入HDD层,将冷存储成本降低80%
- 07-08谷歌推出Cloud Dataproc,缩短集群启动时间
- 07-08Infovista与Google Cloud携手推进射频网络规划革新
- 07-08比利时Odoo与Google Cloud建立增强合作,扩大全球影响力
- 07-08BT 和 Google Cloud 通过 Global Fabric 加速 AI 网络
- 最近发表
-
- Google Cloud Platform 加入支持 Docker 的容器引擎
- 日本KDDI与Google Cloud 签署合作备忘录,共探AI未来
- 美国Infoblox与Google Cloud合作推出云原生网络和安全解决方案
- GoogleCloud为Spanner数据库引入HDD层,将冷存储成本降低80%
- 谷歌推出Cloud Dataproc,缩短集群启动时间
- Infovista与Google Cloud携手推进射频网络规划革新
- 比利时Odoo与Google Cloud建立增强合作,扩大全球影响力
- BT 和 Google Cloud 通过 Global Fabric 加速 AI 网络
- NCSA和Google Cloud合作开发AI驱动的网络防御系统,加强泰国网络空间的安全性
- SAP将在沙特阿拉伯 Google Cloud 上推出BTP服务
- 标签列表
-
- ifneq (61)
- 字符串长度在线 (61)
- googlecloud (64)
- messagesource (56)
- promise.race (63)
- 2019cad序列号和密钥激活码 (62)
- window.performance (66)
- qt删除文件夹 (72)
- mysqlcaching_sha2_password (64)
- ubuntu升级gcc (58)
- nacos启动失败 (64)
- ssh-add (70)
- jwt漏洞 (58)
- macos14下载 (58)
- yarnnode (62)
- abstractqueuedsynchronizer (64)
- source~/.bashrc没有那个文件或目录 (65)
- springboot整合activiti工作流 (70)
- jmeter插件下载 (61)
- 抓包分析 (60)
- idea创建mavenweb项目 (65)
- vue回到顶部 (57)
- qcombobox样式表 (68)
- tomcatundertow (58)
- pastemac (61)
本文暂时没有评论,来添加一个吧(●'◡'●)