2017年，开发prach preamble的小结

忘是亡心i 2022-06-08 23:06 222阅读 0赞

的物理层的，上行三个序列。DMRS、SRS、PRACH.

DMRS相当于信道的山脊，位中频域中央，中心频点位置，标识：我就是我。SRS，位于信道两边，象卫兵一样保护 这个信道。

其中，我主要参与的是物理随机接入信道。

================================

PRACH，只出现在接入过程的第一步。

1）随机接入，有一些需求的要求，比如，要求快，目的是尽可能少占用这种公用资源的时间。

2）尽最大可能，同时发起接入的UE之间，使用的接入码，不相同。

3）如何处理没有上行同步的情况下，猜测的时间提前量，使得NodeB能接收到数据。还不能过长，有足够的保护时间，以免覆盖其它UE的数据。

\-------------------------------------

其中，我最关注的是第2条，ZC序列的设计与生成。可以简单来说，ZC序列，尽最大可能性，保证了最小自相关性。

然后，利用不同的角速度，使得所有的序列，不能发生共振，在这，在基站侧，两个接入的preamble序列，只有有一个参数有偏差，或者距离基站位置远近不同，基站就能够找到二者的交叉点，从而全部读取，或是抛弃其中一个。

这里的关键之一，是角速度的不同。使两个信号，不能平行。

\--------------------------------------  
导言：  
1）接入过程是分水岭，在接入前，没有上行同步，接入后，实现上行同步。  
2）接入过程，发生在需要进行上行数据传输前，而且，还没有实现上行同步的时候。  
3）上行同步的开发，困难在联调的时候。一般的过程，可以从基站侧得到消息交互的日志。但RACH接入过程，基站可能不会有任何显示。特别是基站的程序有bug时。  
4）PRACH,的其它部分，一般来说，设计成尽可能简单的模式。参用了参数尽可能少的ZC序列。与DMRS不同，DMRS的参数，则时尽最大可能的多。这是因为DMRS象山脊，是始终存在的。  
5）PRACH，可以完全用浮点数来做。这是因为PRACH的总空间，只有838\*339. 也就是根序列数u(0,838) , shift数，Cv(0,839).  
这里要注意，v，最多只能到64，因为一个小区，最多只能被分配64个接入的根序列（u）  
6)逻辑序列号，与根序列，的设计，是为了进一步打乱。所以，要时注意的是，一个小区分配的逻辑序列号，即使看起来是连续的，根序列号，一定是不连续的。  
\---------------------------------------  
综述：  
RACH preamble设计的综旨：  
1. 总空间有限。  
2. 最远始的数据点，尽可能固定。好处是，基站侧，可能只需要一个数，就能够确定出u,v值。  
3. 尽最大可能的打乱u,v值。比如，逻辑序号和根序列的映射，为的就是如此。还有v到Cv的换算。  
\---------------------------------------  
可以钻的空子：  
1. 大部分运算，在初始化时，全部做完。有的网上的实现，我们看到，在初始化时，一直做完DFT和IFFT。  
2. 用浮点数运算即可。因为，总空间有限。一个小区最多只有64个。不需要后期的计算。可以用空间换时间。比如，我们现在用的X86体系，我全部都用double来实现。  
3. 可以用C99的complex来运算。 一开始，是用codeblock作为IDE，GCC作为编译器来开发的，后来，做了一系宏，得以在不支持复数的编译器，如visual studio下（vs2015起，  
  
  
才开始支持C99的复数运算），也可以采用复数的语法来编写代码。  
\---------------------------------------  
卡住的地方  
1. 查表还是不查表，来计算sin ,cossin 。原来因为要与FPGA的同步，核对，所以用了定点数的标，并且查了表，才能对上。  
后来，申请了浮点数的标，这一套是没有查表的。所以，中间出了微小的错位的情况。  
2. 定标，前期有定点数，出了些问题。后来改用浮点之后，自然也就不存在了。  
3. 四舍五入(round)的方式。直到很晚才发现，标准数据（测试向量）中的数据，采用了FPGA的数据截断方式，也就是正数不变，负数减一的方式。而我们一直采用正数+0.5，负  
  
  
数减0.5的方式来计算，出了了较大的偏差。  
修正这里后，完全一致。  
=======================================  
总结：  
1. PRACH,有其特殊性。完全可以采用浮点数来运算。以达到最高精度。从运算的结果来看，与matlab，要以做到完全一致（最终结果以16bit \* 2）.  
2. 采用浮点数运算，更符合我的习惯。我一直坚持，只要效率能够满足，代码的可读性，是最最重要的。如果效率不能满足，代码需要分为debug版和release版，debug版，必须  
  
  
， 有可读性。因为代码是产品的生命，产品如果要想做得好，它的生命，必须能够有延续性。  
在文档丢失，员工离职后，代码不可读，也就意味着产品机体的一部分坏死了，失去了进化的可能性，代码只能重写了，这样，不论对原来的员工还是公司来说，都是浪费。新员工，也会不满。  
  
  
3. 采用浮点数，代码，可以与matlab的代码，一一对应。这样，可以大大减少工作量，以及提升研发体系，工序间的信息转换比。