TPCWin和OMSTAR使用说明.doc

安庆移动大楼TD单通问题分析报告 安庆移动大楼TD单通问题分析报告问题描述2010年6月1日，安庆移动反馈，在黄土炕安庆移动公司大楼偶尔会出现TD单通问题：主叫可以听到被叫，但是被叫听不到主叫。主叫终端型号是：三星，3930C，软件版本是S3930CZMIK5。问题分析问题复现测试：1. 现场复测准备6月4日6日，在安庆移动公司大楼6楼复测， 主叫手机：IMSI 460020858844204 三星3930C，软件版本是S3930CZMIK5；被叫手机：IMSI 460005133653617 联芯8130E，软件版本是8130.2.00.09_v3；测试方法：主叫呼被叫，持续180s，间隔30S，接通后主被叫听语音；2. 记录RNC侧、NodeB的数据RNC侧使用CDT记录数据；NodeB侧使用TPCWin记录用户面数据。2.1 CDT记录数据要求：需要记录好主被叫CDT信令，记录方法如下：Lmt客户端软件设置：1) 将CDTMSGTYPE部分的内容其“value”设置为1。2) 将LMT客户端重新启动后，填入IMSI号3) 按照如下要求，将“L2数传上报时长”设置为100小时，“周期性数传统计上报”、“AI采集周期”和“带内信令跟踪”都需要选中。按照如上要求将主被叫的CDT都记录好。2.2 TPCWin记录数据要求如下：记录之前的要求：需要知道主被叫UE所在小区及载波，如果不好确认用户UE占用哪个载波，则需要记录该小区的所有载波。一般在远端记录TPCWin数据。在远端记录TPCWin数据时需要注意：1) 从产品侧获取UE所在小区的基站远程维护IP地址，或者通过OMC查询获取；然后在lmt客户端上ping 基站远程维护IP地址，如果ping不通，咨询产品侧加路由。2) 通过LMTB，使用命令“LST OMCH”查询维护通道的ST“承载业务类型”，一般要求是“UBRPLUS”；否则，容易导致丢失抓取的数据。一定要将其修改为“UBRPLUS”。如果不会修改，请咨询产品侧维护工程师。3) 由于一般不好确定UE占用小区哪个载波，所以需要记录该小区所有载波的TPCWin数据。通过LMTB，使用命令“LST CARRIERRES”查询，注意：“本地小区设备ID”，一般每个基站第一小区的“本地小区设备ID”是0；第二小区的“本地小区设备ID”是6；第三小区的“本地小区设备ID”是12。每个小区的“载波资源ID”分配规则是：第一个载波的“载波资源ID”是0；第二个载波的“载波资源ID”是1；第三个载波的“载波资源ID”是2；第四个载波的“载波资源ID”是3；依此类推。TPCWin数据跟踪：1) 安装好与NodeB版本配套的TPCWin软件。2) 从配套的NodeB版本中找到配套的“HeaderFiles”文件，其中有进行Load Opcode时需要的头文件。3) 设置Opcode头文件必须是“xssopo_n_x_bic”，否则导致抓不到数据。4) 登陆TPCWin5) 跟踪用户面信息：需要注意：1) DspGroupID不能错；2) Slot不能错；3) Circuit不能错。否则，抓取的数据会漏掉。4) 控制字必须是0x7FF,0Xffffffff,0x0,0x0,0x0,0x0,0x0,0x0 逗号必须是英文的逗号，否则消息会出现问题。5) SubSystem选择“PUC”；两次Test Level设置完毕后，可以启动该载波的用户面数据跟踪。说明：每次启动一个载波的用户面数据跟踪，必须按照上面的要求，设置两次Test Level，然后通过“Start Trace”启动该载波的用户面数据跟踪。由于跟踪一次TPCWin数据很不容易，跟踪时必须查看log中是否有相应的数据，如下：3. RNC侧环回测试：环回测试方法如下，3.1如何进行上下行环回测试：3.2 Iu上行环回测试3.3 UE上行环回判断3.4 Iu口下行环回测试3.5 UE下行环回判断3.6 安庆单通环回测试结果6月6日，9：56，主叫切入650小区后，发现主叫可以听到被叫，但是被叫听不到主叫。然后在RNC侧Iu口进行环回测试，测试结果如下：a) 主叫上行环回，主叫听不到自己；b) 主叫下行环回，被叫可以听到自己；c) 被叫上行换回，被叫可以听到自己；d) 被叫下行换回，主叫听不到自己；环回测试结果表明：主叫无线侧有问题，可能的问题段是RNCBBURRU天线空口主叫UE。4. RNC侧数据分析主要是利用OMSTAR对RNC侧的数据进行分析：MACD层数据统计和WAV文件转换。4.1 MACD层数据统计4.1.1安装好OMSTAR按照OMSTAR安装指导说明书，安装好OMSTAR软件。4.1.2 将CDT导入OMSTAR4.1.3 层2数据分析注意：报表统计显示的时间与CDT跟踪时间刚好相差8个小时。4.1.4 WAVE文件转换和分析4.2 安庆CDT数据分析使用OMSTAR，通过分析主叫的CDT log，发现单通之后，主叫的下行收发数据块和吞吐量等指标正常，而主叫上行的收发数据块异常和吞吐量为0。如下：从CDT文件：AQRNC2_CDT_2010-06-06-09-37-54_IMSI-460020858844204_53（从不单通到单通）CDT log统计数据图CDT 信令中统计数据图通过上图分析，单通后，RNC没有收到主叫上行数据包；CDT跟踪的时间与OMSTAR统计的时间刚好相差8个小时。通过OMC查看RNC和NodeB的告警信息，发现该基站不存在任何告警，则排除由于Iub口传输问题导致丢包。RNC侧分析结论：通过对主叫CDT分析，单通后主叫上行吞吐量是0，RNC没有收到主叫的上行数据包。问题可能发生在BBURRU天线空口主叫UE。5. BBU侧数据分析说明：由于使用TPCWIN跟踪多个用户UE、多个小区和多个载波的log，都保存在同一个文件中。需要通过小区号、载波频点、RNC Communication Context ID和NodeB Communication Context ID来确定一个用户UE接入或切入该小区的TPCWIN 的log记录。5.1 首先确认用户UE占用小区和载波其方法是在接入过程中和切入过程中，通过不同信令中的信元来确认UE占用的小区和载波。1）、接入过程中，通过“RB setup”消息来判断小区号和业务频点，如下：上图中的第4个字节到第7个字节表示小区号，例如图中的十六进制数据“028A”，其转换为十进制后是“650”，650是用户UE所在的小区号；上图中的第1个字节到第3个字节表示LAC号，例如图中的十六进制数据“5CD”，其转换为十进制后是“1485”，1485是用户UE所在LAC号；上图中的频点是用户UE所在小区的主载波频点。上图中的频点是用户UE所在的业务载波的频点。2）、切入过程中，通过“Physical channel reconfiguration”消息来判断小区号和业务频点，如下：上图中的第4个字节到第7个字节表示小区号，例如图中的十六进制数据“028A”，其转换为十进制后是“650”，650是用户UE所在的小区号；上图中的第1个字节到第3个字节表示LAC号，例如图中的十六进制数据“5CD”，其转换为十进制后是“1485”，1485是用户UE所在LAC号。上图中的频点是用户UE所在小区的主载波频点。上图中的频点是用户UE所在的业务载波的频点。到此，已经确认好用户UE在单通时所在的小区和频点。5.2 确认用户UE的RNC Communication Context ID和NodeB Communication Context ID一般CS用户UE接入或切入一个小区后，如果不再切换到其它小区，一直处于连接状态时，其RNC Communication Context ID和NodeB Communication Context ID不会改变。在同一个小区同一个载波中多个UE通过RNC Communication Context ID和NodeB Communication Context ID可以区分不用的用户。其方法是在接入过程中和切入过程中，通过不同信令中的信元来确认UE占用的RNC Communication Context ID和NodeB Communication Context ID。1) 如果UE接入小区，则从信令“RL_RECFG_READY”中获取“RNC Communication Context ID”，一般为8个字节，不够8位，则前面补零。图中其“RNC Communication Context ID”是“00 02 a2 9a”。从信令“RL_RECFG_PREP”中获取“NodeB Communication Context ID”，一般为4个字节，不够4位，则前面补零。图中其“NodeB Communication Context ID”是“02 21”。由此可以确定该用户的用户面标识是“00 02 a2 9a 02 21”。2) 如果UE切入该小区，则从切换信令中的“RL_SETUP_RSP”中找到RNC Communication Context ID和NodeB Communication Context ID。如下：从图中显示其“RNC Communication Context ID”是“00 02 af 52”。图中其“NodeB Communication Context ID”是“00 83”。由此，可以确定该用户的用户面标识是“00 02 af 52 00 83”，也就是用户UE所在的RNC Communication Context ID和NodeB Communication Context ID。5.3 在TPCWIN的log中查找用户UE对应的记录其方法是：在TPCWIN的log中的记录，每一条数据中第1个字节到第4字节表示小区ID，第5个字节到第8字节表示小区的业务载波频点，第9个字节到第16字节表示UE的RNC Communication Context ID，第19个字节到第20字节表示UE的NodeB Communication Context ID。在本例中，主叫UE从其它小区切入650小区后，被叫听不到主叫，开始单通。包含“02 8A 27 57 00 02 AF 52 00 83”这次单通的最后一个上行“UL_DCH_FP”如下：例如：log文件中的一条记录“O_FPTS_UL_DCH_FP(087C) 00000605|000001BE|1 00000600|0000011F|1 00025097 92 2010-06-06 09:56:30(840) 02 8A 27 57 00 02 AF 52 00 83 00 01 5D 8A 00 27 0E B1 10 41 DA 5C 02 01 01 8A 74 6D 54 0F 10 41 81 A5 3B AB 56 25 70 65 50 E8 AE 01 FF 56 45 D8 A6 D6 FA 88 F8 DC C3 E8 80 B0 71 78 05 01 B2 41 81 A5 3B AB 00 5B 4E DF D5 4D A6 2E 10 80 62 00 04 90 03 0F 88 F8 DC C3 E8 80 B0 71”其中的“02 8A”表示小区ID，其小区ID是650；“27 57”表示该小区的业务载波频点是10071；“00 02 AF 52”表示用户UE的RNC Communication Context ID；“00 83”表示用户UE的NodeB Communication Context ID。而从这一时刻，以及其后的TPCWin log中包含“02 8A 27 57 00 02 AF 52 00 83”这次单通记录，都只有O_FPTS_DL_DCH_FP（下行数据包），而没有O_FPTS_DL_DCH_FP（上行数据包）。而同一个TPCWin log中可以看到其它用户既有上行包，又有下行包。NodeB分析结论：该用户没有上行包，而同一时段其它用户上下行数据包正常，可能的问题段是：RRU天线空口主叫UE。6. RRU和天线分析RRU是DNB6200的射频远端处理单元。在接收方向上，负责接收和处理来自天线的信号，发送到基带处理单元。通过天馈接收射频信号，将接收信号下变频至中频信号，并进行放大处理、模数转换、匹配滤波后发送给DBBP530处理。天线基本功能是发射和接收无线电波。发射时，将高频电流转换为电磁波；接收时，将电磁波转换为高频电流。从工作原理上来说，RRU和天线对接收或发射出去的信号进行处理是不去分用户的；另外，同一时段用其它测试终端测试也是正常的，从NODEB抓包可以发现同一时刻其他用户的上下行数据包正常，没有出现单通。同时，RRU收发功率正常，天线也无相关告警。RRU和天线分析结论：对于语音通话，RRU和天线只是对终端侧的上下行数据包进行透传，并不区分用户，同一时刻其它用户正常，可能问题段是空口主叫UE。7. 空口质量分析问题时间段的空口质量统计如下，上行空口质量良好，上行Bler基本为零（使用lmt跟踪），上行时隙的ISCP都小于104dBm，不存在上行干扰和弱场。如下：起始时间周期对象名称CARR.TddMaxIscp.TS1CARR.TddMaxIscp.TS2CARR.TddMeanIscp.TS1CARR.TddMeanIscp.TS2CARR.TddMinIscp.TS1CARR.TddMinIscp.TS206/06/2010 09:45:0015AnQingRNC2/载波:载频索引=PRIMARY, 小区标识=650-105.813-106.99-107.943-108.031-1