LTE-中的timing-TA-时偏调整

固有timing（Ul-DLgap）首先上行到下行帧的切换点需要有gap（UE射频切换的时间），而协议在帧结构中没有提及(只讲了DL-UL的gap，没讲UL-DL的gap)其实协议中也是有的，不过没有放到一起讲，见211的8.1，固定为624offsetTANTs，20微秒多一点。由于UE离基站有远近，需要针对每个UE的Timing。调整后，得到一个值TAN，该值加上固有的值TAoffsetN，得到总共的提前值soffsetTATA)(TNN。Ts=1/(15000*2048)=32.55ns实际调整单位为16个Ts，即实际调整量，为“在信令中通知值”的16倍，即每个161632.550.52TAsNTnss。那么每调整一个单位，则对于的距离为163000.52156srcTmm。注意：LTE中timing调整值为正表示时间往前调，和wimax相反。RAR中的timing随机接入响应RAR中，timing字段为11bits，但大小取值为1到1282。随机接入时调整的是绝对值NTA=TA16。考虑最大取值，随机接入时容许的最大距离为1282*156m=199992m，即200公里。MAC信息元素中的timingMac控制元素调整的timing值，取值范围是0到63（6个bits）。而且用的是相对值，NTA,new=NTA,old+(TA31)16。则入网后，2次动态调整容许UE跑的距离是64*156=9984m，即10公里。由于该值可以为负，即每两次调整最多相差正负5公里。考虑到系统调整的最小时间为500毫秒，则系统最大支持的速度为3600公里/小时。物理层其他注意点1、生效时间点：在第n帧收到timing调整命令，则在第n+6帧开始真正调整timing。2、两帧时间冲突：如果第n帧发送未调整的上行数据，在n+1帧开始调整timing且时间往前调，那么两个上行子帧会碰撞。此时协议规定保证前一个子帧（n帧）完整的发送，而timing调整子帧前面部分丢掉。此时可能出现上行丢包的情况，但只要调整量不太大也不一定丢包，因为前面有CP长度为160Ts。因此只要向前调整不超过160Ts（即信令中timing值不大于10）还是能解出来的。如果用timing碰撞不丢包来衡量系统最大支持的距离，则为1560m，支持的最大速度为562公里/小时。Wimax不会出现这种情况，因为上行帧是连续的，且资源分配是先时域再频域，一个给到的频域上所有时间都是一个终端发送，而下次发送上行数据中间隔着下行帧（ul-dl有gap），也就是说wimax没有2个连续发送的上行帧。MAC层对timing的控制1、在随机接入时，基站通过rar消息让UE调整。2、平时，基站每隔一定时间就会给终端调整timing，什么时候调整基站自己决定，但两次调整间隔不能大于RRC消息中配置的最大时间间隔timeAlignmentTimer。取值为500ms到无限。取值：sf500,sf750,sf1280,sf1920,sf2560,sf5120,sf10240,infinity3、UEMAC层维护定时器timeAlignmentTimerA、每次收到调整，都重启定时器B、如果定时器超时，则清空所有HARQbuff，且停止所有发送接收，开始随机接入流程，不必要重新入网，因为随机接入可能还能恢复定时。4、由于RAR消息和一般的MAC信令中，消息中的timing值是不一样的，一个是相对值一个是绝对值，因此MAC还有个工作，把这两个值统一成一个值给PHY。但问题来了，一旦入网后用相对值调整后，如果又做了一个竞争的随机接入，此时要用绝对值了，但基站在随机接入的RAR并不知道是哪个终端，因此不能同步更新相对值，后面再用相对值调整，老值应该是上一次相对值调整的老值。这个协议没说，但自己推应该是这样，MAC需要十分注意。