5GNR漫谈13:Zadoff –Chu(ZC)序列性质

在LTE系统中,PSS、SSS、cellRS、DMRS、SRS、PRACH、PUCCH信号基本上都涉及到了Zadoff –Chu信号,NR除了PSS和SSS信号采用M序列来生成抵抗大频偏场景,其它信号也同样涉及到了Zadoff –Chu序列,不搞物理层没做过信号处理的小伙伴可能心理就犯嘀咕,这种序列这么有市场,到底有什么优点?
Zadoff –Chu序列,顾名思义,就是Zadoff 和Chu共同发现的。我们来看它的表达式。式中的u,就是它的根。
在这里插入图片描述

ZC序列具有以下特点:
**1 恒包络:**任意长度的ZC序列幅值恒定,这也意味着功率恒定,这个好处就是射频器件不用忽大忽小的改变放大能量。为什么能够恒包络?看ZC序列的生成表达可以看到,本质就是一个底数为e的指数序列,每一个序列值代表单位圆上的一个点。每一个点值,仅是改变相位而已。复指数是一个二维I、Q的平面图。
令u=10,L_RA = 839,则有:
1.00000000000000 + 0.00000000000000i 0.997197130765289 - 0.0748189975439091i 0.974868361720748 - 0.222781680835533i 0.900736645368189 - 0.434365624435061i 0.732445182467781 - 0.680826009109331i 0.432678482961282 - 0.901548296200666i -0.00187222337202524 - 0.999998247388287i -0.502160298476613 - 0.864774557115252i -0.902356786904935 - 0.430989824852748i 。。。。。。。。。。。
在这里插入图片描述

**2 理想周期自相关:**ZC序列循环移位N,如果N不等于ZC序列的长度(N等于序列长度,循环移位后回到起始点了),则移位后的序列和原序列不相关。啥意思?就是说虽然本是同根生,但是只要屁股挪了一下,哪怕是挪一位,那长得一点都不像没有挪前的样子。这个性质有什么好处?假如没挪前的序列表示一个UE,挪位后的序列表示另一个UE,那么基站用根序列与接收到的序列一相关运算,就知道有几个UE在向他打报告申请资源了。至于“相关”运算,可以理解为查看两条序列长得“像不像”的工具,长得“像”,相关峰值就又直又高耸入云,长得不“像”,相关峰值就软绵绵趴在地上。

在这里插入图片描述

**3 良好的互相关:**ZC序列循环移位N后,原序列只与移位后的序列得良好的相关峰值,其它位置的序列相关峰值为0。除此之外,两个根如果是互质的,生成的序列相关峰值几乎为零。前面的特点,上图已经体现,后面的特点,有啥好处?我们知道一个根序列的长度是有限度的(139或者839),每移位NCS位就许配给一个UE,那由一个根生成的ZC序列很快用完,需要用到其它根来生成preamble,这个时候两个根生成的序列之间的互相关性就显得重要,它们要长得不“像”,即互相关几乎为0,否则基站区别不出它们。
在这里插入图片描述

**4 傅立叶变换后仍是ZC序列:**这个性质,简直就是为OFDM系统量身打造,也省去多少运算量。既可以在时域相关,也可以在频域相关,灵活决定姿势,怎么方便怎么来。
了解了ZC序列的以上性质后,也就明白了为什么在移动通信标准中,它有那么大的用处。
好了,我们来看看怎么用ZC序列测量时间偏移。
OFDM符号采用IFFT变换而来,OFDM符号要想保持正交性,就要求首尾要保持相位的连续性。OFDM本质是多个并行的子载波采用正交IQ调制,然后相加在一起,以单个子载波对应的时间周期T,离散化后,刚好是一个离散逆傅立叶变换IFFT,这是OFDM调制采用IFFT变换的本质。
在这里插入图片描述

我们知道无线电波在空中传输,会存在时延,而且还会存在多径衰落,因此每两次传输之间都会存在保护间隔,避免上一次传输影响到下一次,两者间出现尾头重叠现象。OFDM符号,巧妙的把每一个符号尾巴复制一部分,放到前面保护间隔位置,形成循环前缀CP。

在这里插入图片描述

这样即使接收端收到的OFDM符号有一定的时延,但只要时延不超过CP长度,OFDM符号仍然保持正交性, IFFT变换后仍然可以恢复数据。前述我们知道,ZC序列循环移位后,原序列和移位后的相关峰值出现在移位大小的位置。PRACH序列就是利用这个性质求时间偏移的大小。基站采用原序列与接收到的序列做相关,由于OFDM符号是首尾相连的,如果有时延,则相关峰值就会出现移位,不出现在起始位置。接收的数据存放是按照采样时间顺序存放在buffer里面的,只要统计移位的样点数,就可以知道时间延时大小了。因为终端的时间是以基站侧为基准的,终端发送的上行信号当然的也会以上行子帧或者slot或者符号为基准,当基站发现接收到终端上行数据有时延,当然就会通知终端:下次早点来。

喜欢 文章可添加公众号,回复SSB,LDPC,ZC可获得代码:
在这里插入图片描述

### 构建任务失败解决方案 当遇到 `Execution failed for task ':app:shrinkReleaseRes'` 错误时,这通常意味着资源压缩过程中出现了问题。此错误可能由多种原因引起,包括但不限于配置不正确、依赖冲突或特定于项目的其他因素。 #### 可能的原因分析 1. **ProGuard 或 R8 配置不当** ProGuard 和 R8 是用于优化和混淆代码以及减少 APK 大小的工具。如果这些工具的配置存在问题,可能会导致资源无法正常处理[^1]。 2. **重复资源** 如果项目中有多个模块定义了相同的资源名称,可能导致冲突并引发该错误。检查是否存在重名的 drawable、string 等资源文件[^2]。 3. **第三方库兼容性** 某些第三方库可能与当前使用的 Gradle 插件版本或其他库存在兼容性问题,从而影响到资源打包过程中的行为[^3]。 4. **Gradle 缓存问题** 有时旧缓存数据会干扰新编译的结果,尝试清理本地仓库和重新同步项目可以帮助排除此类潜在障碍[^4]。 #### 推荐的操作方法 为了有效解决问题,建议按照以下步骤逐一排查: ```bash # 清理项目构建目录 ./gradlew clean # 删除 .gradle 文件夹下的所有内容以清除缓存 rm -rf ~/.gradle/caches/ ``` 调整 `build.gradle` 中的相关设置也是一个重要环节: ```groovy android { ... buildTypes { release { minifyEnabled true // 是否启用代码缩减 shrinkResources true // 是否开启资源压缩 proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' // 尝试禁用 shrinkResources 来测试是否为资源压缩引起的错误 // shrinkResources false } } } ``` 此外,在 `proguard-rules.pro` 文件内添加必要的保留规则,防止关键类被意外移除: ```text -keep class com.example.yourpackage.** { *; } # 替换为你自己的包路径 -dontwarn androidx.**,com.google.** # 忽略警告信息 ``` 最后,确保所使用的 Android Studio 版本是最新的稳定版,并且已经应用了所有的补丁更新。
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值