TD-SCDMA系统CDL工具问题分析流程指导书V1.011.doc

大唐移动通信工程有限公司产品名称密级TD-SCDMA NPO内部公开产品版本共34页TD-SCDMA系统CDL工具问题分析流程指导书项目名称文档编号版 本 号作 者修订记录日期修订版本描述作者2008-6-10V1.0初稿完成刘进目录1.引言41.1.编写目的41.2.预期读者和阅读建议41.3.文档约定41.4.参考资料41.5.缩写术语42.概述52.1.CDL分析模块52.2.信令跟踪53.CDL分析模块63.1.界面介绍63.2.功能及操作说明63.2.1.CDL文件加载73.2.2.事件显示及解码显示73.2.3.事件检索及过滤83.2.4.用户信息显示93.2.5.用户信息过滤103.2.6.用户呼叫过程分析113.2.7.掉话分析113.2.8.切换统计123.2.9.特定用户管理133.3.应用场景分析143.3.1.单IMSI用户呼叫次数统计143.3.2.对某小区内呼叫情况统计143.3.3.关注呼叫保持时间特别短的用户153.3.4.整系统掉话分析163.3.5.单个用户掉话分析173.3.6.某特定用户的统计183.3.7.特定用户群的呼叫统计193.3.8.系统内切换统计203.3.9.单个用户的切换统计203.3.10.一对小区的切换分析情况214.信令跟踪224.1.信令跟踪开关设置224.2.信令跟踪实时监视及回放244.3.信令跟踪应用及案例介绍254.3.1.信令跟踪应用254.3.2.案例介绍261. 引言1.1. 编写目的在项目现场优化工作中,网络优化工程师通过路测软件只能看到Uu口消息,其他Iu口、Iub等端口无法监控,收集问题信息太少,无法准确定位问题;在RNC端通过LDT对网络进行实时或离线跟踪,可以对问题进行准确的定位分析.本文档主要介绍LDT的离线CDL跟踪和实时的UE信令跟踪功能,为大家在优化工作中提供相应的参考.1.2. 预期读者和阅读建议本文档预期读者为网络规划优化相关人员以及机房操作人员1.3. 文档约定文档格式遵守公司技术类文档模板要求。1.4. 参考资料LDT用户手册RRM学员手册异常信令流程分析IUSV1.0.01.5. 缩写术语2. 概述该文档主要分为两个部分：第一部分介绍CDL分析模块和信令跟踪模块；第二部分使用信令跟踪以及CDL协助处理网络问题；2.1. CDL分析模块CDL分析模块包括3个方面的内容l 界面介绍从界面构成来讲解LDT的参数查询模块，重点讲述参数查询界面各元素的相互关系。l 功能及操作说明讲述配置管理模块的命令操作过程，包括配置对象数据的查询及单板状态查询命令。l 应用场景分析给出CDL典型的应用。2.2. 信令跟踪LDT的信令跟踪模块为研发人员提供了RNC子系统间UE呼叫消息监视功能，具体内容包括：l 信令跟踪开关设置l 信令跟踪实时监视及回放l 信令跟踪应用及案例介绍3. CDL分析模块3.1. 界面介绍CDL分析模块完成对CDL文件的加载、CDL事件解码显示、事件的过滤查询、对UE信息的解码，显示，分析等功能。在主菜单上选“维护”-“CDL分析”按钮，进入CDL分析界面，如下图所示：与别的界面不同的是CDL分析界面分上下两部分，上面包括两个Tab页，一个用于显示CDL事件列表，另一个用于显示UE消息流程图；下面包含四个Tab页，分别是CDL事件二进制码流、CDL文件列表、IE树列表、及UE列表。3.2. 功能及操作说明CDL分析工具是对工作站保存的CDL数据文件进行分析，从而达到问题定位的目的。LDT的CDL模块包括以下功能：l CDL文件加载l CDL事件显示l CDL事件解析l 事件检索与过滤l 用户信息显示l 用户检索l 用户呼叫过程分析l 掉话分析l 切换统计l 分析结果导出l 特定用户掉话分析及结果导出3.2.1. CDL文件加载将鼠标移至CDL界面文件加载快捷按钮，点击确定后，弹出接口选择窗口，选择要加载的接口，点击确定按钮，开始加载。注：提供单个CDL文件加载和多个CDL文件一起加载。3.2.2. 事件显示及解码显示CDL文件加载过程中，会对CDL事件进行分析，分析完的结果会以列表的方式显示在界面上，下图上半部分，鼠标选中要查看的事件记录行，解码结果会显示在界面的下方，如果需要查看码流，点击CDL事件码流Tab标签页。 3.2.3. 事件检索及过滤在事件列表上右键点击会弹出操作界面，事件列表上鼠标右键弹出如下菜单： 菜单项的功能如下： 设置行颜色 弹出行颜色设置界面； 设置过滤条件 弹出设置窗口，提供对事件列表的各种条件查询； 取消过滤 取消上次的过滤条件，事件列表恢复显示所有； 清除记录 清除当前的加载，包括事件列表、UE列表、切换、调话等列表，恢复各种操作状态； 事件列表信息导出Excel 提供导出功能； 鼠标单选记录，触发IE解码，提供IE树列表和二进制码流显示。分别显示在相应的界面上。 例如可根据不同的条件对事件进行过滤显示。提供按事件类型、事件名称、接口类型、UEID、CELLID、按时间、及复合查询。3.2.4. 用户信息显示cdl文件加载过程中会对UE信息进行自动分析，显示在UE列表中，如下图所示：3.2.5. 用户信息过滤在UE列表上右键点击弹出操作菜单，菜单操作功能如下： 设置过滤条件 弹出设置窗口，提供对UE列表的各种条件查询； 取消过滤 取消上次的过滤条件，UE列表恢复显示所有； UE统计 弹出统计图； UE分析保存为Excel 提供导出功能； 鼠标双击会进行流程显示。 设置过滤条件，显示如下界面：提供按照呼叫结果、失败原因、CELL ID、UEID、初始接入标识、IMSI及呼叫最短时长进行不同的检索。3.2.6. 用户呼叫过程分析CDL分析工具可对特定的用户进行呼叫流程显示，具体操作：在UE列表上选中要分析的UE记录行，鼠标双击显示流程图如下：如果要查看某条消息的信息，可把鼠标移动到流程图中的消息线条上，鼠标变为手形状后，右键确定后解码信息会现在下面的IE树列表中。3.2.7. 掉话分析 点击掉话分析快捷按钮，进行掉话分析，分析结果显示在CDL界面下方掉话分析标签页上，显示信息如下：3.2.8. 切换统计CDL文件导入过程中同时会从Common ID中取出接入的IMSI，同时把IMSI用户添加到用户切换统计树状列表中，真正的分析结果需要手动点击分析所有下拉菜单子项触发，该功能同时提供查询单个用户的切换情况，通过选中左树IMSI节点触发条件查询，该IMSI所有的切换都将显示在右边列表中。 在右区列表提供鼠标右击弹出一个操作菜单，菜单项可支持按照源、目标小区查询切换统计结果，并支持把结果保存到Excel表中。3.2.9. 特定用户管理 点击CDL主界面的加号图标（特定用户管理按钮），弹出特定用户管理界面如下：输入信息后，点击增加用户，添加特定用户信息，选中要删除的用户记录，点击删除用户可删除信息。特定用户的呼叫统计结果来源UE通话分析结果，仅提供把分析结果与特定用户信息的部分信息，（用户名）关联显示，如下： 同时提供过滤，保存功能。过滤由用户列表中选择用户记录，双击鼠标触发；3.3. 应用场景分析3.3.1. 单IMSI用户呼叫次数统计通过UE列表中过滤功能，将该IMSI进行过滤，界面即可打印出该IMSI用户发生呼叫总次数，以及呼叫各种情况，包括接入小区，终结小区，呼叫保持时间等3.3.2. 对某小区内呼叫情况统计通过UE列表中过滤功能，进行CELL_ID进行过滤，界面即可打印出该小区内用户发生呼叫总次数，以及呼叫各种情况，包括接入小区，终结小区，呼叫保持时间等；通过UE分析保存为EXCEL表格，即可按照EXCEL表格筛选功能实现，对接入小区，终结小区，某小区内接入用户数、某小区内终结用户数进行统计。3.3.3. 关注呼叫保持时间特别短的用户CDL提供呼叫保持时间的过滤功能，可以对呼叫保持时间进行筛选，进而关注某些特殊过程，比如电话一接通就断掉的情况；通过设置较短时间来进行察看。3.3.4. 整系统掉话分析通过点击RNC掉话分析按钮，实现系统掉话分析统计，并按照序列号进行罗列（即实现了统计功能），对掉话时间、掉话域、掉话原因进行了罗列。掉话分析是大概意义上的分析，保证了绝大部分掉话分析的正确性，如果要对某过程心存疑惑，则需要核对码流仔细分析掉话原因3.3.5. 单个用户掉话分析整系统掉话分析基础上，通过IMSI进行过滤，实现单用户掉话分析功能；考虑到IMSI过长不好输入，提供双击用户列表后，单击用户列表，即可以实现列表栏中内容的复制。3.3.6. 某特定用户的统计双击特定用户列表即可转生成该用户详细的呼叫统计，察看图一 到 图二：生成：此表中包括该用户在CDL加载时间段内在某个小区进行呼叫的详细情况，包括呼叫保持时长、掉话时间、以及何种类型呼叫、呼叫结果。3.3.7. 特定用户群的呼叫统计通过特殊用户呼叫分析提供的显示所有呼叫，则切换为特定用户群的呼叫统计；察看特定用户呼叫过程，则双击呼叫分析列表中该特定用户，则直接调出该用户呼叫过程码流；3.3.8. 系统内切换统计提供系统内所有用户切换的统计功能，即统计尝试切换次数和失败次数；对统计结果可以导出为EXCEL表格。3.3.9. 单个用户的切换统计点击该用户IMSI，就可以统计出该用户切换的尝试次数，失败次数；包括源小区、目标小区、切换时间、结果、失败原因。3.3.10. 一对小区的切换分析情况提供一对小区的切换统计，如下图示：4. 信令跟踪LDT的信令跟踪模块为研发人员提供了RNC子系统间UE呼叫消息监视功能，具体内容包括：l 信令跟踪开关设置l 信令跟踪实时监视及回放l 信令跟踪应用及案例介绍4.1. 信令跟踪开关设置在LDT主界面维护主菜单上点击子菜单项Ue跟踪，弹出Ue跟踪界面如下：激活任务跟踪任务查询去激活任务跟踪激活分为Ue跟踪激活、Next_N跟踪激活、Cell跟踪激活、No.7跟踪激活，界面分别如下：l UE跟踪激活UE ID为每次呼叫过程中RNC给UE分配的临时标识，针对每一次呼叫，当UE在呼叫过程中发生了重定位过程，在目标RNC中会重新给该次呼叫分配新的标识；该标识可以从RRC Connection Setup 或者Radio Bearer Reconfiguration 中读取。l Next_N跟踪激活l Cell跟踪激活l No.7跟踪激活4.2. 信令跟踪实时监视及回放在消息监视开关打开以后，LDT将会实时接收来自后台各子系统上报的各类消息，并将消息按照固定的格式解码，打印到如下的界面中：选中任何一条消息，该消息的解码结果会以两种方式分别显示在跟踪界面显示区的IE树列表和消息二进制码流标签页上。其中UE列表中会显示所有跟踪到的UEID； 在消息显示列表中可点击鼠标右键选择“保存码流”完成码流的保存。在进行后台分析的时候，同样在消息显示列表中可点击鼠标右键选择“导入文件”导入相应的码流进行分析，界面与实时监控的界面完全一致。4.3. 信令跟踪应用及案例介绍4.3.1. 信令跟踪应用UMTS（Universal Mobile Telecommunication System）通用移动通信系统与第二代移动通信系统在逻辑结构方面基本相同。如果从功能上看，可以分成一些不同功能的子网(subnetwork),主要包括核心网(Core Network，CN)和无线接入网(Radio Access Network，RAN)两部分。核心网主要处理UMTS系统内部所有的话音呼叫、数据连接和交换，以及与外部其它网络的连接和路由选择。无线接入网完成所有与无线有关的功能。这两个子网与用户终端设备(User Equipment，UE)一起构成了完整的UMTS系统，其结构如下图所示。图中UTRAN(UMTS Terrestrial Radio Access Network)执行RAN的功能，它与核心网CN之间的接口为Iu（电路域的Iu-CS接口，分组域的Iu-PS接口、以及广播域的Iu-BC），与用户终端设备UE之间的接口为Uu。在UTRAN内部，Node B与RNC之间的接口为Iub接口，RNC与RNC之间的接口为Iur接口。在工程师日常工作过程中，通过前后台软件的测试分析往往只能跟踪到Uu口的情况，这对处理网络问题提供的支持是远远不够的，我们必须要能够更进一步的了解各个接口的信令过程才能具体的定位问题。LDT的信令跟踪为我们提供了Uu口、Iub口、Iu口等等接口以及一些内部接口的消息码流，通过对某一个终端的详细跟踪就可以发现出现网络问题的具体环节以及原因值，从而制定相应的解决措施。4.3.2. 案例介绍1. UE上发测量报告不发生切换案例 故障现象在广州试验网测试过程中发现RNC9中广州湛塘路站点附近，周围站点都不能切入该站，在达到切换门限时UE不停上发测量报告，但一直收不到切换命令。 案例分析在该站底下发起业务，发现各业务都正常，且能够切出到周围小区去，说明该站基本功能正常，怀疑该站GPS不准，但测试过程发现在该站下小区间也不能正常切换，且该站没有告警，ISCP值也正常，让机房对该站进行复位，问题依旧。数据配置的问题可能行比较大。检查该站邻区与周围的邻区配置，邻区关系也都互相配置。无法发生切换测试过程如图：UE1空闲态驻留在湛塘路1小区，信号电平70dbm查看信令，发现UE上发测量报告后，没有受到下行任何消息，让机房进行单用户跟踪，通过机房跟踪UE信令，发现UE在上报测量报告后，RNC向CN发起了重定位过程，重定位指向目标RNC ID：1007周围已经并没有RNC ID为1007的基站，且目标小区CI：66025764 该CI现网中并不存在，所以CN返回RELOCATION Preparation Failure.导致切换过程无法继续CN返回RELOCATION Preparation Failure.现网中查询并没有该CI所标识的小区，由于该站是从RNC7割接至RNC9的站点，检查割接前的数据发现该CI是湛塘路1小区割接前的CI。说明当UE上报测量报告后，RNC根据上报频点码子仍然检索到的是目标小区割接前数据并发起了RNC间切换流程，但实际上该数据已经失效，导致CN指示目标小区在目标RNC中找不到。检查周围站点邻区列表，发现与湛塘路割接前的小区邻区关系都没有删除，让机房清除该站割接前的所以旧数据，该处切换关系恢复正常。 案例总结：对于割接站点，割接完成后要清除割接前的旧数据。割接后需要第一时间对该站进行验证。2. RAB建立失败案例 故障现象保定RNC2496做CS12.2K短呼验证其接入成功率时候发现在RAB建立时候建立成功率非常差，问题点发生在保津高速沿线，其呼叫建立成功率非常低，沿线呼叫成功率大概就50。 案例分析以南张3小区为例说明问题点:现象：在此小区连续的呼叫中，总是一次成功，一次失败，比如第一次失败，第二次必然成功，第三次必然失败，第四次必然成功.，失败和成功交替出现。问题是失败没有出现过拨打2次2次都失败，总是失败成功间隔的。路测中信令流程如下：图0 路程中测试的信令流程从图0的测试中可以看到RB建立完成后，被直接RELEASE掉了。且呼叫事件中显示为OUTGOING_CALL_BLOCK。释放原因也为正常释放。呼叫序列标中也显示为：图00 呼叫序列表显示从图00看到呼叫失败的原因为呼叫拥塞。但在下一次呼叫又成功了，在图00中时间为15:27:14。然后在第3次呼叫又失败，时间为15:28:22(图0中)，每次失败时候事件中显示为OUTGONG_CALL_BLOCK(呼叫拥塞)。现用户都没有，怎么会拥塞呢？机房TRACE跟踪分析：RAB失败时候UE TRACE 跟踪信令：图1 RAB建立失败信令从图1看到，RB建立完成后，CN直接给RNC发送一条释放的信令,而RAB成功时候UE TRACE跟踪信令：图2 RAB建立成功时候信令结合图1和图2从UU,IUB,IU口看到，失败和成功区别是失败时候没有 RAB ASSIGNMENT RESPONSE，而是CN直接给RNC发生一条释放的直传信令，DIRECT TRANSFER解码如下：图3 DIRECT TRANSFER 释放信令解码图3可以看到，CN发给RNC为正常释放。取消UU,IUB,IU过滤条件后发现有如下规律：RAB失败时候信令：图4 失败时候内部A2接口解码从图4看到，有A2接口上的IUSP_ALCAP_EST_REQ，但没有TNSS的回应。在描述中使用IU CS链路中ALCAP业务通路业务板标识为1287。RAB成功时候信令：图5 成功时候内部A2接口解码结合图4和图5可以看到，成功时候IUSP_ALCAP_EST_REQ和ALCAP_IUS