中兴IOT经验交流

赵鹏目标：Attach成功过程：在中兴LTE_TD试验室,使用海信25号单板,真实USIM卡,开机搜网竟然一下子就回OK了，不过立刻ARMASSERT了.要求网侧不要发SIB6~SIB12后，找网成功。出乎意料.NT-25_fail.lst记录了激动人心的一刻搜网成功后，Attach遇到了问题。ConnectionComplete貌似发不上去，SS不断重发ConnectionSetup。DSP确认已经发送了该消息，换了几块单板也不行，只能和SS对码流了。中兴的LOG打印也是分级别的，L2的LOG默认是关闭的，而且有时会出现丢LOG的问题。另外TTI貌似也和UE对不上，对码流希望渺茫。在armlog中察看码流时，发现ConnectionComplete这条消息ARMLOG竟然解不出来，比较蹊跷。以前上海成功的LOG中，这条消息都能够解出来。顺着这条路一直往下追，发现NAS在attach消息中配置的GUTI为全FF？？？！！！！汗流浃背。同样是NT-25_fail.lst记录了出错的过程。目标：同频重选成功过程：重选过程要注意两个3个要点：1、RRC要求PHY进行同频临区测量2、PHY上报同频临区测量结果3、邻区要符合S准则，且Rank排序高于服务小区测试过程中遇到了邻区信号高于服务小区，但邻区不符合S准则的情况。这时需要网侧调整SIB3中重选最小接入电平。目标：切换成功过程：为了测切换，SS需要构造两个小区，A和B，并在B小区上增加衰减器，需要切换时，将B小区信号调高。促使从A-〉B的切换。为此，做了如下准备工作：1、衰掉B小区信号，在空闲态下核对UE测量出来的RSRP值。2、衰掉A小区信号，在空闲态下核对UE测量出来的RSRP值。此时网侧调整了一下接入参数，UE顺利收到了paging完成了IDLE下的系统消息更新流程。（参见内网”IDLE下系统消息更改_paging.lst”）3、A,B小区里在connected下分别核对UE测量出来的RSRP值准备好后，开始做切换流程测试。此时，不幸的事发生了，connected下，即使UE收到了网侧的MeasConfig，RRC也没有要求PHY发起同频测量。经过检查，发现UE和SS对S_measure这个参数为0时，理解不一致。修改代码后，可以下发测量请求，然后上报A3测量报告给网侧。同频测量报告也顺便测试通过了。MeasureReport上报成功后，网侧下发MobilityControl，又出问题了。UE没有发起HO，而是发起了在目标小区的重建，重建被网侧Reject（参见内网”第二次MEASConfig失败.lst”）。ZTE在切换时要求更改SRB2的配置，而UE代码不允许这样做。修改代码后可以发起handover,不幸运的是，切换后总收不到RAR；幸运的是，HO失败后在目标小区重建总能成功(参见”handover失败后重建成功.lst”）。与家里测试相比，ZTE在重建后还会进行一次重配，此时PS内存释放报错。临时修改后通过。教训：家中测试配置太简单，且没有把相关流程彻底走完。目标：切换成功过程：继续切换测试。出现有时PS不配置发送preamble的情况。与xujin沟通后，确认在maskIndex=0时，MAC层代码有一个BUG，家中没有遍历过。修改后仍然RAR解不出来。下班前抓了一把数，希望能在PC上分析出点线索。目标：切换成功过程：Raber使用PC软件分析抓到的数，竟然解出了RAR。对参数之后，发现是PS根本没有配置handover参数。修改代码后，HO通过。参见“handover成功.lst”教训：以前我们更多的关注的是这些消息中携带的L2以及L2以上的参数配置，往往因为某些IE我们不理解或觉得应该是PHY关注而忽视这些L1的配置，被动等待L1给我们解释，被动等待在联调时发现错误时再清理再修改。如果某个流程侥幸PASS了就认为代码是正确的（窃喜Sysd代码挺给力的），如果没过，首先就怀疑脚本，恳求betty将参数修改成一个舒服的值，能适应我们代码的值。这样一来，导致在IOT中载跟头。目标：休息好过程：自由活动目标：剩余RRC用例过程：上午分析Log，发现以下问题:1、Preamble发送不顺利。经常要发送好几次。2、上行MAC重传严重。3、下行MAC重传严重。4、有些参数PS配置有误。下午比较顺利，通过了以下用例：1、ContentionHo（竞争切换成功.lst）网侧修改切换参数，从非竞争改为竞争2、Paging发起MT业务（PAGING成功.lst）IDLE下，网侧向UE发起ping包。3、周期性测量上报（周期性测量报告成功.lst）网侧将测量类型设置为周期类型。目标：NAS相关用例通过过程：专用承载相关用例带问题通过起初，使用家里的AT命令发起专用承载建立，NAS竟然直接向网侧发起Reject命令。LOG发给wenjing定位后，居然是LOG打错了。晕。其次，QOS=1时，SS认为是GRB配置，而NAS认为是None_GBR配置。修改AT命令后通过。接着，尝试专用承载修改，更改Qos通过。最后，MO释放专用承载时，信令已经跑完，但UE没有回OK。算勉强通过了。整个流程参见“建立装用承载无OK.lst”目标：UL上行用户数据待发出发ServiceReq过程：该用例需要打桩测试。如果使用PPP连接，PC会不断发UL上行包，则UE无法回到IDLE态。只有在不连接PPP的情况下，通过桩发起上行数据业务。参见”UL数据出发ServiceRequest.lst”目标：网侧主动的PS用例过程：1、周期性TAU（“过了很多（周期TAU，网侧detach）.lst”）网侧将周期性TAU时间从1个小时缩短到1分钟2、网侧Detach（“过了很多（周期TAU，网侧detach）.lst”）网侧主动Detach3、Connected下Paging（“connectedPaging.lst”）Connected状态下网侧修改sib1中的参数4、加解密（“加解密成功.lst”）配置PDCP加密/完整性算法不为空，跑完attach流程目标：PHR、手动搜网和TA超时过程：ZTE网络不支持同一个eNodeb配置两个频点，只能一个小区配两个PLMN，开机进行手动找网，然后指定PLMN驻留。环境搭建好后，开机直接手动搜网，立即指定驻留，NAS直接返回ERROR，参见”手动搜网失败.lst”。修改后OK。SS最好能配置成两个异频小区，进行测试。