5.0版本RNC跟踪CDT信令方法

第一篇：5.0版本RNC跟踪CDT信令方法

1)、首先到OMU上修改RncTestConfig.xml文件。登陆到文件管理器上：

然后进入weblmt->version_x（主区，可通过LST OMUAREA查询）->client->trace->resource下面。

找到RncTestConfig.xml文件，下载下来。

用文本格式打开，修改其中的L2和用户面相关开关。

找到CDTMSGTYPE下的PARA参数，正常如下，我们需要将Value＝“0”的修改成1。

修改后如下，然后保存此文件。

返回到WebLMT文件管理器，将原有的RncTestConfig.xml文件删除。

将修改后的RncTestConfig.xml文件上传上去。

2、进入LMT跟踪页面，填写IMSI，选择DEBUG模式

Other选项里面勾选相关用户面选项。

第二篇：跟踪孔令学影评

有关孔令学

这是去年四月就上映的一部电影，以前听说过，但是一直没有去看。平时关注的多是国外的一些影片，对于本国的电影关注确实太少。相比国内的大制作手笔，我更倾向于新生代导演用心制作的低成本电影，像是以前的《疯狂的石头》、《人在囧途》、《夜店》等等，虽称不上是大家风范的旷世奇作，但绝对可以称得上是一道精美的小品。

看这部电影不是趋于偶然，而是最近看了第十放映室的新春特别节目，其中有一期就专门介绍也范伟这个演员。说实话，我看范伟的电影并不多《天下无贼》、《非诚勿扰》和《建党伟业》。在以上电影里面，范伟都是以配角的身份出演的，戏份并不是很多，但其塑造的草根人物个性鲜明，总会给观众留下比较深刻的印象。在那期节目中，就提到了这部范伟主演的电影---《跟踪孔令学》。

孔令学同样的一个草根形象，在一所文武学校教授语文课的老师，虽然是地道的东北人，但是读课文时，句句都是字正腔圆的普通话，从这边可以体现出，孔老师的人物性格---做事认真到位。他年近40，有老婆有孩子，家庭不能说很富裕，但是很和睦。他每天都是努力的工作，这又是一个典型的中年男人的形象。故事缘起于孔老师没收了上课玩手机的一名同学的手机，这名同学是学校舞蹈班的一名女生刘萌，并且在这个过程中发生了一点肢体冲突。事后，刘萌名义上的男朋友阿祥，社会上开发廊的一个小混混，便找上了孔老师。他希望孔老师不要找刘萌的麻烦，但却被孔老师拒之千里、闭口不谈，甚至害怕阿祥会对自己的家人不利。但是阿祥依然是不依不饶的缠着孔老师，就这样，一场跟踪与反跟踪的好戏上演了。刚开始的时候，感觉这部电影像是剧情片，虽然它以喜剧片标签，但是前30分钟的剧情确实笑点不多；而中间30分钟的时候，感觉它又像是一部悬疑惊悚电影，似乎有些时候连自己也不知道，这个阿祥到底是为了什么才这么一直跟着孔老师的；等看完最后30多分钟的时候，终于发现，这部电影确实是一部喜剧电影，只不过是一部真正意义上的黑色喜剧，尤其是最后医生为孔老师给出了诊断---焦虑症。看完整部电影之后再看孔令学这个人物，当然，范伟的塑造真的是无懈可击，或许他真的对草根这样的角色做到了信手拈来的程度，总之，这个人物已经实体化了。他，孔令学就存在于我们的身边。我给孔令学下的定义是百分之五十的孔子加百分之五十的孔乙己，最终就成为了孔令学。他对于自己的工作，对于自己的家庭都是尽职尽责，十分认真，拥有一套自己的严格的道德规范，用医生的话就是太认真了；但是，他为人又显得过分自我，过于偏激，对凡是有悖于自己道德的事情，又过于否定。总之，他是一个有着自己追求，但是却容易受到外界影响的人。这种人有时候会活得很快乐，但是有时候会活得很累。在被跟踪的期间，孔老师始终没有给妻子说出事情的真相，而是变着花样的编瞎话，希望能够骗过妻子，但是孔老师的想法是好的，他这样做也是为了不想让妻子担心。还有就是他始终没能和阿祥做过一次真正的谈话，或许在他的道德里面，这种人就是垃圾，根本不值得一谈，即便是谈，也不会得出什么结论，因为孔老师早把阿祥在心里面完全否定了。但是他又和刘萌讲了手掌和拳头的道理，希望能通过沟通得到刘萌的认可，或许刘萌在他的眼中还是有药可救的一个人吧。因此，我感觉，孔令学这个人物性格中存在的多面的矛盾体。其实我们每个人都是矛盾体的组成，只是在外界的刺激下，我们凸显了其中的某一或者某些方面罢了。孔令学，是草根，他就生活在我们这些普普通通的人的身边。而我们自己就或多或少的有着他的影子在身上。但我们真的应该做些改变了，对什么事情，都要拥有一个平和的心态，做事情不要过于认真，这不也是片中的医嘱吗？

看到影片的结尾我的心里是暖和的，在孔令学上课的时候，有个男同学睡着了，这次他并没有想影片开头那样处理问题，而是边微笑着读课文，边把外套脱下来给那个同学盖上。我想，他的所有心结至此已经全部解开了吧。放平心态，正常面对，我们生存的社会就会多些和睦，温暖，欢笑...^ ^

第三篇：运动目标跟踪方法

方法大致可以分为四类：基于区域匹配的跟踪方法、基于模型的跟踪方法、基 于动态轮廓的跟踪方法和基于特征的跟踪方法。

(1)基于区域匹配跟踪方法的主要思想：该方法主要是将包含运动目标的运动区域作为参考模板12引，在下一帧图像中按照一定的搜索方法搜索模板，找 到的最优搜索区域判定为匹配区域。该方法在理论上是十分有效，其可以获得 丰富的目标信息，对小目标跟踪效果好；但是当搜索范围较大时，目标匹配会 花费大量的时间，而且如果目标发生变化或者被遮挡时，跟踪效果会大大下降。

(2)基于模型跟踪方法的主要思想：该方法通常会使用三种模型进行目标

跟踪：线图模型、2D模型、3D模型【231。在实际的应用中，由于3D模型更接近现实生活中的物体，使用最多的是基于3D模型的跟踪方法，特别是针对刚体(如 汽车、飞机等)的跟踪。概括来说，跟踪的方法如下：利用获得的目标3D模型，然后针对实际的视频序列进行目标的搜索与匹配。在实际的跟踪环境中，3D模 型的运算量很大，而且获得所有目标的3D模型并全部存储是一项几乎不可能的 任务，因此该方法的实际应用比较少。

(3)基于动态轮廓跟踪方法的主要思想：该方法主要是指对目标的轮廓进

行提取，即用一组封闭的轮廓曲线来描述目标，将其作为匹配的模板。此轮廓 曲线能进行自我更新以适应非刚体目标的形状变化12引。例如Paragan等人利用短 程线的轮廓，加入水平集理论检测并跟踪目标【2 5J；最经典的算法是Michael Kass 等人在1 988年提出的主动轮廓模型(即Snake模型)的方法【2 6|，其本质是能量 的最小化。通过不断求解轮廓曲线能量函数的最小值，不断调整其形状，从而 实现对目标的跟踪。该方法在简单背景下，能够准确的进行目标跟踪。但其对 于背景复杂情况以及速度较快或形变较大的目标，运算速度很慢，而且对于遮 挡问题的解决不是很好，因此很少应用于实际的监控系统中。

(4)基于特征的跟踪方法的主要思想：该方法主要是通过提取目标特定的特征集合，如角点或边界线条等【2¨，将其作为跟踪模板，在下一帧中搜索并进 行帧间的匹配，从而实现目标的跟踪1281。改算法的优点在于其是以目标特征为 基础，因此，在目标的整体特征不完整，即目标被部分遮挡的情况下仍然可以 实现跟踪。该方法是目前应用最多的一种方法。

1．4．课题的研究内容与论文结构安排

运动目标检测与跟踪是智能视频监控领域的基础与前提。本文主要是针对 静态场景下的运动目标检测与跟踪，通过不断的研究和学习，找到更好的运动 目标检测与跟踪方法。

本文对目前常用的目标检测与跟踪方法进行了原理介绍与性能分析，并在 前人的基础上提出了自己的解决方案，且与原有的基于混合高斯模型的目标检 测方法以及基于基于码本模型的目标检测进行了比较。在运动目标跟踪方面采 用基于Kalman预测的Mean Shift方法，同时加入了信息量度量的方法，使得

第四篇：七号信令总结

其号信令

通信网主要可以分为两大部分：信令网和话路网，而信令网又是通信网络中的基础。在信令网中所运行的信令协议主要可分为：中国一号信令（随路信令）和NO7信令（共路信令）。而在我国的通信网中主要使用NO7信令。NO7信令是整个通信网络的基础，我可以用这样一个比喻来表达NO7信令的作用，如果将整个通信网络的硬件设施比喻成一个人的骨架，那么NO7信令就是流淌在这个人身体中的血液。由此可知，NO7信令是贯穿于整个通信网络的，它是为了完成呼叫接续的一种通信语言。NO7信令我们也可以说成是为了完成某种业务的操作交互而发出的一些指令或命令。

NO7信令有四种分类方式：按照传送方向分可以分为前向信令和后向信令；按照功能分可以分为管理信令、线路信令？；按照工作区域分可以分为局间信令和用户线信令；按照传送信道分可以分为共路信令和随路信令。下面我们重点介绍一下共路信令和随路信令：随路信令是指传送信令的链路和话路是同一条链路；共路信令是指传送信令的链路和话路不在同一条链路上。中国一号信令就是随路信令，而NO7信令是共路信令。共路信令依据其自身的构架而引发出了一些优点：信令传输速度快；信令容量大；信道利用率高；信令易于管理和维护；易于开发一些基于信令的上层应用。但有优点的同时也给共路信令提出了一些特殊的要求：信道传输的安全性要高；信道传输的误码率要低；话路通道要添加自身的监听功能，因为在共路信令系统中信令链路相通并不能代表着话路也是相通的。

上面主要讲述了NO7信令的分类以及各自的特点。下面我们来具体描述一下NO7信令的基本概念：

1.信令链路（Link）：即指用来传送信令的物理通道，一般为E1线的一个时隙；

2.信令链路集（LinkSet）：具有相同属性链路的集合，也可以说成是到一个局向的所有链路组成的集合。同一个信令链路集中的所有链路是负荷分担的。两个信令点之间直连的链路集只能有一个；

3.信令链路编码（SLC）、信令链路编码发送（SLCS）和链路编号（Link NO）：信令链路编码是用来区分同一个链路集中不同链路的；SLCS是在测试消息中所使用的，让对方来识别同一链路集中的链路；而链路编号则是用来区分同一模块中的不同链路的。同一条链路两端的SLC必须一致，如果不一致链路则不会相通；链路一端的SLC和SLCS一般必须配成一致，如果不一致链路很可能不会相同的；

4.信令路由（RT）：即到达某一信令点的路径；信令路由其有目的信令点和链路集组成的一个对应关系。到达某一信令点可能有多条路由；

5.信令点编码（SPC）：即指每个信令实体的编码，该编码相当于该信令实体的地址，在具体的寻址过程中会被使用到。而信令点编码依据其长度不同可以分为14位信令点和24位信令点。国际上一般采用14位信令点编码，而国内一般采用24位信令点编码；具体的编码结构可以参看下图：

接下来我们再介绍一下NO7网的基本概念。NO7信令网是我国通信网的基础，它负责信令的交互以完成用户的某项业务需求。而NO7信令网是由信令点、信令转接点和信令链路组成的。下面就着重介绍一下这三要素：

1.信令点（SP）：即为信令网中发送或接收信令消息的实体。如果是发送信令消息，那

么就可以称该信令点为源信令点；如果是接收信令消息，那么就可以称该信令点为目的信令点；一般情况下，信令网中的每个信令点既为源信令点又为目的信令点；

2.信令转接点（STP）：也是信令网中的一个实体，但它既不是信令源点也不是信令目的点，它只是将收到的消息转发给另一个信令实体。

3.信令链路：该概念在前面已介绍过了，它在信令网中主要是负责连接不同信令点或信令转接点，使其相互之间能够贯通。至于信令网中的连接方式又可以分为两种：直连方式和准直连方式。直连方式即指两个信令点直接相连，中间不经过任何转接；而准直连方式是指两个信令点间的连接是经过一个或多个信令转接点转接的。因为信令转接点对用户传输来说是透明的，就如同直连，所以我们称之为准直连。现网中的连接方式以准直连方式居多；

再下来我们介绍一下我国NO7信令网的组成结构，其结构是比较清晰的，可以用两句话来描述全网结构：我国NO7信令网是三层架构，采用双平面结构。其三层结构分别为：高级信令转接点HSTP（分布在各主要省分）、低级信令转接点LSTP（分布在地级市）、信令点SP（又称为端局，一般分布在地级县）；而双平面结构主要是为了提高信令网的可靠性，我们一般采用A、B双平面结构，即HSTP一般都成对出现，并两两相连，这样即使一个HSTP故障了，另外一个还可以接替。具体的结构描述如下图：

NO7信令的承载方式有三种，分别为：TDM、ATM和IP；其各自在承载层上有很大的不同，但这些不同对上层用户来说是透明的。TDM和ATM我们称为窄带传输，而IP我们称为宽带传输；TDM和ATM需要时钟，而IP不需要时钟；TDM有两种速度，一种为64K（E1线中的某一个时隙），另一种为2M（利用E1线中31个时隙）；ATM的速度为2M，使用E1线中30个时隙（0号时隙用于传时钟，16号时隙用于传管理消息）；IP总带宽为100M，依照其建立的链路数不同，其带宽也相应的不同。三种承载方式的层次结构图如下：

下面将详细讲解NO7信令的层次结构，以及每层的作用。NO7信令的层次结构图如下：

我们HLR系统主要运用NO7信令的MAP协议层，其具体包含：MAP、TCAP、SCCP、MTP3、MTP2、MTP1。下面将详细介绍这六层的作用以及在CPCI平台的哪个模块处理：

1.MTP1－信令数据链路层：对应于OSI模型中的物理层。信令数据链路功能是MTP的第一功能级，定义信令数据链路的物理、电气和功能特性。而信令数据链路又可分为数字信令数据链路和模拟信令数据链路。在数字信令数据链路中规定采用64Kb/s的速率（PCM群的一个时隙的传输速率）；在模拟信令数据链路中，如采用频分复用传输系统的信令数据链路，规定采用

4.8Kb/s的速率。在我们移动通信网络中，都采用数字信令数据链路。

MTP1层简单的说它仅向MTP2提供了一个物理的通道，不对信令消息做任何处理。MTP1层在CPCI平台的EPI板上处理，在32模平台上是DTM板处理。

MTP1层就好像我们建立起的一条初始的公路，没有安装任何交通指示灯，也没有标明该条公路的去向。

在MTP1层上所具有的概念有：时隙、EPICFG、传输方式（例如DoubleFrame）。

2.MTP2－信令链路层：对应于OSI模型中的数据链路层。信令链路功能主要是规定了为在两个直接连接的信令点之间传送信令消息提供可靠的信令链路所需要的功能。MTP2层的主要功能有：信令单元的收发控制和信令链路状态监视。信令单元的收发控制主要包括：信令单元的分界、信令单元的定位、信令单元的差错检测和信令单元的差错校正。而信令链路状态监视主要包括：信令单元差错率的监视、处理机故障处理及信令链路故障处理和拥塞时的流量控制。MTP2层简单的说它为上层用户提供了一个可靠的逻辑通道，它对信令消息的内容不作任何处理，只是在消息码流中插入定位定界符和差错校验位。而这些插入的定位定界符和差错校验位对上层用户来说是透明的，所以我们也可以说MTP2层对信令消息不做任何处理。MTP2层在CPCI平台的CPC扣板处理，在32模平台上是LAP板处理。

MTP2层就好像一条安装了交通指示灯的公路，该公路上的车流有断连和畅通的状态。但该条公路还没有标明去向。

在MTP2层上所具有的概念有：链路、链路状态（激活、去活）、SLC、SLCS、链路编号、链路的类别（TDM64K、TDM2M、MTP3BLNK、M3UALNK）、链路级别的流控。

3.MTP3－网络层：该层和SCCP层一同对应于OSI的网络层。MTP2层保证了两个直接连接的信令点之间传送信令消息的可靠性，但它对信令消息不作任何处理（从用户层面上看，其实MTP2层会向消息码流中插入定位定界符和差错校验位），MTP3则是处理信令消息的最低一层。MTP3层在MTP2层的基础上实现了信令网络级别的功能，即具有路由寻址的功能。

MTP3层为整个信令网络提供了路由寻址的功能，其在信令消息发送和接收过程中都起着重要的作用。MTP3层主要有两大功能：信令消息处理和信令网络管理。信令消息处理内部又可以分为三大块：消息识别、消息分配和消息编路。信令网络管理主要可以分为：信令业务管理、信令路由管理、信令链路管理。根据上述的描述我们可以清楚的知晓MTP3的基本功能。

MTP3层就好像一条安装了交通指示灯，同时也标明了去向的公路。该公路上的车流不但有断连和畅通的状态，而且还有路由寻址的功能。

MTP3层所具有的概念有：目的信令点DSP、路由RT、链路集LKS、路由负荷分担、链路负荷分担、链路测试消息。

4.SCCP－信令连接控制层：和MTP3层一起对应于OSI模型中的网络层。信令连接控制部分的目的是加强消息传递部分（MTP）的功能，它和MTP3一起构成NO7信令的网络层，为信令在网络中的传输提供网络寻址转发的能力。由于MTP的寻址功能仅限于向节点传递消息，只能提供无连接的消息传递功能，而SCCP则利用目的信令点编码（DPC）和子系统（SSN）来提供一种寻址能力，用来识别节点中的每一个SCCP用户；另外，由SCCP提供的另外一种寻址方式是全局码（GT），从而弥补了MTP信令点编码不具备全局性、网内编码容量有限、用户过少的不足。SCCP的业务可以分为4类：0类为基本无连接类；1类为有序的无连接类；2类为基本面向连接类；3类为流量控制面向连接类。而我们在NO7信令系统中基本上使用0类SCCP消息。MTP层我们经常说为承载层，如果将MTP层比喻成卡车，那么SCCP层就等同于电子地图，它能帮助司机准确定位去向。

SCCP层所具有的概念有：GT地址，GT翻译，GT校验，SSN寻址，UDT和XUDT消息，N_notice消息。

5.TCAP－事务处理能力子层：TC是由事务处理能力应用部分（TCAP）及中间服务部分（ISP）两部分组成。其中，TCAP的功能对应于OSI的第7层，ISP对应于OSI的第4-6层。目前NO7信令中的应用都是基于无连接的TCAP层上的，没有使用到ISP层。所以下面将详细介绍一下TCAP层。

TCAP层将不同节点间的消息交互抽象为一个操作，TCAP的核心就是执行远程操作。TCAP消息的基本单元是成份（Component）。一个成份对应于一个操作请求或响应，一个消息中可以

包含多个成份。一个成份中包含的信息含义由TC用户定义，相关的成份构成一个对话，一个对话的过程可以实现某项应用业务过程。

TCAP为了实现操作和对话的控制，分为两个子层――成份子层（CSL）和事务处理子层（TSL），CSL主要进行操作管理，TSL主要进行事务（即对话）管理。TC用户与CSL通过TCAP原语接口，CSL与TSL通过TR原语接口，TSL与SCCP层通过N原语接口联系。其层次结构如下图：

事务处理子层（TSL）完成对本端成份子层用户和远端事务处理子层用户之间通信过程的管理，事务处理用户（TC用户）目前唯一的就是成份子层（CSL），因此对于对等CSL用户之间通信的对话与事务是一一对应的。事务处理子层对对话的启动、保持和终结进行管理，包括对话过程异常情况的检测和处理。在TCAP协议中，对话分为两大类――非结构化对话和结构化对话。具体描述如下：

非结构化对话是指TC用户发送不期待回答的成份（第四类操作），没有对话的开始、继续和结束过程，在TCAP中利用单向消息发送；

而结构化对话必须指明对话的开始、继续和结束。在两个TC用户间允许存在多个结构对话，每个对话必须由一个特定的事务标识号（TransactionID）标识。同一个对话中可全双工地交换成份，用户在发送成份前指明对话的类型。对话的类型具体有四类：对话开始（Begin）、对话的继续（Continue）、对话的结束（End）和对话中止（U_Abort和P_Abort）。

事务处理子层通过TR请求原语接受TC用户经成份子层发送的对话控制指示，生成指定类型的TCAP消息发往远端；同时通过TR指示原语将接收到的TCAP消息中的数据（成份）传送给成份子层。TCAP协议中定义了如下六种TR原语：TR_UNI（单向）、TR_BEGIN、TR_CONTINUE、TR_END、TR_U_ABORT和TR_P_ABORT。

成份处理子层（CSL）完成对话中成份的处理及对话的控制处理。事务处理子层负责传送对话消息的基本单元就是成份。一个对话消息可以包含一个或多个成份（少数无成份，只起到对话控制作用），一个成份对应于一个操作的执行请求或操作的执行结果。每个成份由不同的成份调用标识号（Invoke ID）标识，通过调用标识号，控制多个相同或不同操作成份的并发执行。操作的定义由具体的操作码及参数标识，由TC用户定义，成份子层通过TC成份原语进行成份处理，以对话的形式请求相关于某一对话标识的成份，将成份嵌入到对话与对话控制部分，通过TR原语发向对端的TCAP，因此成份子层分为成份处理和对话处理。

实际上，成份子层并部管理对话过程，它仅仅将TC用户的对话控制信息传送到事务处理子层，由事务处理子层完成对对话的控制。成份处理子层的TC原语包括成份处理原语和对话处理原语两种。成。份对处话理处原理语原包语括包括以以下下96种种：：TC-INVOKE, TC-RESULT-L, TC-U-ERROR, TC-U-REJECT, TC-L-REJECT, TC-R-REJECT, TC-U-CANCLE, TC-L=CANCEL

TC-UNI, TC-BEGIN, TC-CONTINUE, TC-END, TC-U-ABORT, TC-P-ABORT。

TCAP消息由一个单构成式信息单元组成，其包括事务处理子层的事务处理部分，与成份相关成份子层的成份部分及作为任选包含应用上下文及用户信息的对话控制部分。具体的TCAP消息结构如下图：

TCAP层所涉及的概念有：事务ID、OTID、DTID、InvokeID、OperationCode、对话或事务、DialogueID、TCAP协议状态机。

6.MAP－移动应用子层：对应于OSI模型中的应用层。MAP的功能主要是为通信网络中各网络实体之间完成移动台的自动漫游功能而提供的一种信息交换方式。具体的MAP业务消息在TCAP消息中以成份形式存在，一般来讲，MAP业务的消息类型和TCAP成份中的操作码一一对应，而在消息传递过程中，一个消息对应一个调用识别（InvokeID），一个调用识别在其MAP对话过程中是对某个消息的唯一识别，通过区分调用识别，可以将一个成份“翻译”成对应的MAP业务消息，MAP与TCAP之间的消息转换是由MAP协议状态机（MAPPM）来完成的，此外协议状态机还负责对话流程及操作流程的控制等功能。

MAP消息所涉及的TCAP对话处理原语有：TC-BEGIN、TC-END、TC-CONTINUE、TC-U-ABORT；所涉及的成份处理原语有：TC-Invoke（调用成份）、TC-Result（结果成份）、TC-Error（返回错误成份）、TC-Reject（拒绝成份）等。

MAP层所涉及的概念有：各类MAP消息（如位置更新、取路由、取鉴权集等）、DialogueID、MAP协议状态机、MAP话统、MAP消息跟踪。

我们列举一个消息发送实例，来观察消息是如何经过各层次处理的以及了解各层次所做的操作。具体参看下图：

上面所讲述的正是我们信令数据配置的原理，下面我们将结合上述所介绍的信令数据配置原理来讲解一下信令数据配置中的一些注意细节。

SLC、SLCS、链路编号和时隙这四者的区别：

SLC（信令链路编码）是用来区分同一链路集中的不同的链路；SLCS（信令链路编码发送）主要用来填充在测试消息中，让对端来区分同一链路集中的链路的；链路编号一方面是用来区分同一模块下的链路，另一方面还与WCSU上的上下CPC扣板相关联，链路编号从0到15是在下CPC扣板处理，而链路编号从16到31则是在上CPC扣板处理；时隙这是物理层上的概念，我们的TDM和ATM承载方式都是使用的时分复用的原理，将一条E1线划分为32个时隙，每个时隙的速度为64Kb/s。另外时隙和链路编号还有一定的对应关系，即时隙号从0到127的链路编号范围为0~15,而时隙号从128到255的链路编号范围为16~31。

路由的负荷分担和链路的负荷分担原理：

路由的负荷分担和链路的负荷分担的原理是一样的，都是利用SLS和掩码经过负荷分担算法进行计算得到的选择的路由或链路。路由选择的掩码是在MTP目的信令点表中（N7DSP或MTP3BDSP或M3DE），而链路选择的掩码是在链路集表中（N7LKS或MTP3BLKS或M3LKS）。具体的负荷分担算法的原理如下：

SSN：

SSN子系统也是寻址中的一部分，它是在一个信令实体内部以SSN来进一步寻址，主要是用来确定是该信令实体中的哪个子系统（例如MSC和VLR就是同一个信令实体，但它们却有着不同的子系统）。至于SSN的作用，就要分上行消息和下行消息来描述：上行消息时，当经过DPC校验和GT校验后，会进行SSN寻址，即观察消息中所携带被叫地址中的SSN是否可用（这里的检测SSN是否可用的方法，即以消息中的DPC来作为DPC和OPC查询SCCPSSN表，看是否存在相应的SSN，然后再检测其状态）；下行消息时，当经过GT翻译后，我们会校验DPC是否配置、状态是否可及，然后就会校验SSN是否配置、状态是否可及，如果都可及，那么就会将消息下发到MTP层进行进一步寻址。注意一点，下行消息中的SSN虽然是在MAP层已被指定，但在SCCP层中也有可能更改，即如果GT翻译结果中含有SSN，那么就会将消息中的SSN替换成GT翻译所得的SSN。

GT地址翻译表的配置方法：

配置GT地址翻译表有两个原则：一，两个相邻的实体，其GT翻译结果类型一般为DPC或DPC＋SSN。两个不相邻的实体，其GT翻译结果类型一般为DPC+old GT或DPC+new GT；二，自身的GT翻译类型一般为DPC或DPC+SSN，以免在GT校验时发生循环，导致消息落不了地； STP转接的配置方法：

STP转接的配置方法有两种：一，MTP层转接，即使接收到的消息在MTP层校验DPC失败，失败后系统会尝试以该DPC重新寻址，将该消息转发出去（前提是该信令点有STP功能）；二，SCCP层转接，即使收到的消息在SCCP层校验GT失败，被叫地址中的GT翻译后所得的DPC和系统的SPC不同，此时系统会尝试以该GT翻译后的DPC来重新寻址，将该消息转发出去（前提是该信令点有STP功能）；

第五篇：深圳联通第三方测试保障后台信令跟踪分析过程总结V1.0

第三方测试保障后台信令跟踪分析过程V1.0

目录1软件工具使用................................................................................................................................3

1.1 后台信令抓取...........................................................................................................3

1.1.1 后台信令抓取任务设置和过程.......................................................................3 1.1.2 后台信令保存...................................................................................................4 1.2 信令文件处理工具...................................................................................................4

1.2.1 信令文件处理工具包.......................................................................................4 1.2.2 生成文件内容简介...........................................................................................5 1.3 PS业务速率统计................................................................................................................5 2 数据统计分析...........................................................................................................................7

2.1 测试号码业务定位...................................................................................................7

2.1.1 判断业务速率...................................................................................................7 2.1.2 判断业务主被叫...............................................................................................8 2.2 呼叫次数统计...........................................................................................................8

2.2.1 CS业务呼叫次数统计方式..............................................................................8

2.2.1.1 主叫相关次数统计...................................................................................8 2.2.1.2 被叫相关次数统计.................................................................................10 2.2.2 PS业务拨号相关次数统计方式....................................................................11 2.3 呼损分析.................................................................................................................12 2.3.1 主叫呼损分析.................................................................................................12 2.3.2 被叫引起呼损分析.........................................................................................12 2.3.3 呼损案例分析.................................................................................................13 2.4 掉话分析.................................................................................................................14 2.4.1 CS业务掉话分析............................................................................................14 2.4.2 PS业务掉话分析............................................................................................14 2.5 注意事项.................................................................................................................14 2.5.1 IMSIDetachIndication异常.............................................................................14 2.5.2 跨Iur口切换造成信令流程不完整..............................................................14 2.5.3 2-3G互操作....................................................................................................14

1软件工具使用

1.1 后台信令抓取

1.1.1 后台信令抓取任务设置和过程

本次深圳联通第三方测试主要在关内的8个RNC下测试，在信令跟踪Debug模式下，跟踪第三方测试的不同用户的RNLC_UE SIGNAL BY UEID任务信令。首先在信令跟踪工具启动需要跟踪的RNC传输网络层的连接: 选择文件->连接，在弹出的对话框中选择或添加RNC的服务器名称，ip地址以及端口号：

然后跟踪用户IMSI，过程如下：选择任务管理->创建RNL任务，填写任务名称，选择任务类型为：RNLC_UE SIGNAL BY UEID信令：

再在任务详细设置中填写IMSI号，勾选所有选项。

1.1.2 后台信令保存

深圳联通信令数据保存时间分上下午保存，分别保存.std格式和.txt格式。

注：因为后续批处理工具需要使用.txt文档的格式的码流，.Std格式的码流也需要抓取，用于后期详细分析使用。

1.2 信令文件处理工具 1.2.1 信令文件处理工具包

该工具包包括UESigStat.exe和UESig.bat，同时需要站点信息列表索引文件。

其中站点信息索引文件需要放在C盘根目录下，即C：，使用文本编辑软件（UEdit、Notepad等）打开来编辑。里面的数据以“cellid = 23 cellname = 金华新联通-3”的格式来添加。

通过后台信令抓取工具SignalTraceTool抓取信令后，需要保存1个或若干个*.txt的信令码流文件，然后把start.bat、UESigStat.exe放到和该信令码流同目录下，右键单击start.bat点编辑，再在文本中UESigStat命令的后面添加上需要处理的若干个码流文件名即可（如果添加了不存在的文件名，运行时也会跳过，不影响其他文本的生成）。举例如下： A：抓取信令后，需要保存1个或若干个*.txt的信令码流文件，然后把start.bat、UESigStat.exe放到和该信令码流同目录下；

B：可以对Uesig.bat进行编辑，目的是在文本中UESigStat命令的后面添加上需要处理的若干个码流文件名：

C：运行Uesig.bat，就可以在当前目录生成名称为之对应的多个*.txt，Report.txt的文本文件：

1.2.2 生成文件内容简介

附生成的*.txt，Report.txt文本：

生成的文本大致分为4部分：

1部分：为信令计数器列表，列举了流程中所有可能出现的信令并计数。对分析失败所处的流程有很大的参考意义。

2部分：

为业务计数器列表，主要统计了该信令中各类业务主被叫成功和失败次数，其中Unkown为部分特殊信令流程，如注册、位置区更新等，需要在实际信令中确认。

3部分：为每一次完整呼叫流程的关键信令，同时包括了信令的时间、方向、小区信息、时延等信息，对发现异常后的定位有很大帮助。

4部分：为跑车路线。

1.3 PS业务速率统计

PS业务后，需要在RNC端对前台速率进行评估，这里需要使用后台信令保存后的std格式文件。显示如下：

导入std格式码流文件：

显示速率相关信息：

生成名称为RateRecord.csv的文件是按照一分钟粒度进行采用，表中给出了每次采用的时间和速率：

在本次第三方测试中统计PS业务的速率的平均值，以及采样次数。数据统计分析

2.1 测试号码业务定位 2.1.1 判断业务速率

有2种方式可以看业务速率： 第一种：通过RAB_AssignmentRequestMsg信令中rAB_Parameters.maxBitrate.elem[0] = 64000

可以取得该业务上下行指派速率。

第二种：通过IuupSetupReq信令中的消息如下行的dwUlAssignedBitRate = 5760000可以取得该USIM的签约速率。

2.1.2 判断业务主被叫

业务建立起来后，通过rrcConnectionRequest信令中establishmentCause = terminatingConversationalCall可以判断该业务是主叫还是被叫。

对于CS主叫业务，可以通过安全模式结束后第一个DirectTransfer（Setup）中的Numbering plan identification=***获取被叫的号码，从而方便将主被叫配对。

2.2 呼叫次数统计

2.2.1 CS业务呼叫次数统计方式

CS业务包括CS12.2K业务和CS64K业务，这两种业务在业务建立的时候所进过的信令流程相同，因此呼叫次数统计方式也相同。

2.2.1.1 主叫相关次数统计

CS业务主叫呼叫包含如下信令，在第三方测试中，通常以RRC Connection Request到Alerting的信令流程为正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一个流程信令不完整而导致整个起呼信令不完整都可能认为是一次起呼失败。

UENodeBRNCCN(1)UL-CCCH:RRC Connection Request(originatingConversationalCall)(2)C_NBAP:Rdaio Link Setup Request(3)C_NBAP:Radio Link Setup Response(4)ALCAP:ERQ(5)ALCAP:ECF(6)DL_CCCH:RRC Connection Setup(7)UL_DCCH:RRC Connection Setup Complete(8)D_NBAP:Radio Link Restore Indication(9)UL_DCCH:Initial Direct Transfer(CM Service Request)(10)Initial UE Message(CM Service Request)(11)Direct Transfer(12)DL_DCCH:Downlink Direct Transfer(CM Service Accept)(13)UL_DCCH:Uplink Direct Transfer(Call Setup)(15)D_NBAP:Radio Link Reconfiguration Prepare(16)D:NBAP Radio Link Reconfiguration Ready(17)ALCAP:ERQ(18)ALCAP:ECF(19)D_NBAP:Radio Link Reconfiguration Commit(20)DL_DCCH:Radio Bearer Setup(21)UL_DCCH:Radio Bearer Setup Complete(22)RAB Assignment Response(23)DL_DCCH:Downlink Direct Transfer(Call Proceeding)(24)DL_DCCH:Downlink Direct Transfer(Alerting)(25)DL_DCCH:Downlink Direct Transfer(Connect)(26)UL_DCCH:Uplink Direct Transfer(Connect Acknowledge)(27)Direct Transfer(Connect Acknowledge)(14)RAB Assginment Request(Establishment)(CM Service Accept)步骤1：获取主叫起呼次数

首先可以由信令处理软件生成的Report.txt中以下内容确认主叫次数（MOSucc+MOFail=158+1），可以得到初步的起呼次数

# MO Succ = 158 MO Fail =1 MT Succ = 158 MT Fail = 1 PS Succ = 0 PS Fail = 0

Unkown = 1

#

步骤2：获取主叫业务建立成功次数

由文本中MOSucc的计数可以得出主叫建立成功的次数。

步骤3：获取主叫建立失败次数

由文本中MOFail可以进一步判断主叫建立失败次数。（由于软件将Connect DL被叫接听的信令作为呼叫成功的依据，但如Alerting DL后被叫未及时接听或挂断，也判断为一次建立失败，但此时应该根据实际情况来处理。）

通过上述2个步骤可以初步得出主叫建立失败次数，但仍然需要对出现异常的信令进行分析，以进一步判断是否是符合测试规范中定义的呼损。

2.2.1.2 被叫相关次数统计

CS业务被叫包含如下信令，在第三方测试中，通常以RRC Connection Request到Alerting的信令流程为正常起呼，信令中包含了RRC建立流程、RAB建立流程、RB建立流程等，任何一个流程信令不完整而导致整个起呼信令不完整都可能认为是一次起呼失败。

UENodeBRNC（1）PagingCN（2)DL_CCCH：Paging Type 1(3)UL-CCCH:RRC Connection Request(4)C_NBAP:Rdaio Link Setup Request(5)C_NBAP:Radio Link Setup Response(6)ALCAP:ERQ(7)ALCAP:ECF(8)DCCH_FP:Downlink SYNC(9)DCCH_FP:Uplink SYNC(10)DL_CCCH:RRC Connection Setup(11)UL_DCCH:RRC Connection Setup Complete(12)D_NBAP:Radio Link Restore Indication(13)UL_DCCH:Initial Direct Transfer（Paging Response）（16）DL_DCCH:Downlink Direct Transfer（Call Setup）（17））DL_DCCH:Uplink Direct Transfer（Call Confirmed)(14)Initial UE Message(PagingResponse)(15)Direct Transfer（Call Setup）(18)RAB Assignment Request(Establish)(18)D_NBAP:Radio Link Reconfiguration Prepare(19)D:NBAP Radio Link Reconfiguration Ready(20)ALCAP:ERQ(21)ALCAP:ECF(22)DTCH_FP:Downlink SYNC(23)DTCH_FP:Uplink SYNC(24)D_NBAP:Radio Link Reconfiguration Commit(25)DL_DCCH:Radio Bearer Setup(26)UL_DCCH:Radio Bearer Setup Complete(27)RAB AssignmentResponse(29)Direct Transfer(Alerting)(31)Direct Transfer(Connect)(32)Direct Transfer(Connect Acknowledge)(28)UL_DCCH:Downlink Direct Transfer(Alerting)(30)UL_DCCH:Downlink Direct Transfer(Connect)(33)DL_DCCH:Uplink Direct Transfer(Connect Acknowledge)

步骤1：获取被叫寻呼到次数

首先可以由信令处理软件生成的Report.txt文本中以下内容确认被叫次数（MTSucc+MTFail），可以得到初步的被叫次数：

# MO Succ = 158 MO Fail =1 MT Succ = 158 MT Fail = 1 PS Succ = 0 PS Fail = 0

Unkown = 1

#

步骤2：获取被叫业务建立成功次数

由文本中MTSucc的计数可以得出被叫建立成功的次数。

步骤3：获取被叫建立失败次数

由生成的文本中MTFail可以进一步判断被叫建立失败次数。（由于软件将Connect UL被叫接听的信令作为成功的依据，但如Alerting UL后被叫未及时接听或挂断，也判断为一次建立失败，但此时应该根据实际情况来处理。）

通过上述2个步骤可以初步得出被叫建立失败次数，但仍然需要对出现异常的信令进行分析，以进一步判断是否是符合测试规范中定义的呼损。

2.2.2 PS业务拨号相关次数统计方式

测试中PS业务没有主被叫之分，因此只需要判断PS业务起呼次数。由于测试中可能下载完成导致转Idle，再回来时候是不需要重新拨号，因此只需要统计PDP激活的次数。PS业务拨号相关流程如下图：

UENodeB(1)UL_DCCH:Uplink Direct Transfer(ACT.PDP Context Req)RNCCN(2)Direct Transfer(ACT.PDP Context Req)(3)RAB Assginment Request(Establishment)(4)D_NBAP:Radio Link Reconfiguration Prepare(5)D:NBAP Radio Link Reconfiguration Ready(6)ALCAP-ERQ(7)ALCAP-ECF(8)DTCH_FP:Downlink SYNC(9)DCCH_FP:Uplink SYNC(10)D_NBAP:Radio Link Reconfiguration Commit(11)DL_DCCH:Radio Bearer Setup(12)UL_DCCH:Radio Bearer Setup Complete(13)RAB Assignment Response(14)Direct Transfer(15)DL_DCCH:Downlink Direct Transfer(ACT.PDP Context Accept)(ACT.PDP Context Accept)

步骤1：获取拨叫次数

首先可以由信令处理软件生成的Report.txt文本中以下内容确认拨叫次数（PSSucc+PSFail），可以得到初步的拨号次数：

# MO Succ = 158 MO Fail =1 MT Succ = 158 MT Fail = 1 PS Succ = 5 PS Fail = 0

Unkown = 1

#

步骤2：获取拨叫成功次数

由生成的文本中PSSucc的计数可以得出拨号建立成功的次数。

步骤3：获取拨叫失败次数

由生成文本中PSFail的技术可以得出拨号建立失败的次数。

2.3 呼损分析 2.3.1 主叫呼损分析

确认主叫起呼的次数，可以通过rrcConnectionRequest、LocationUpdateReques和CMServiceRequest三条信令个数的关系来判断，如果rrcConnectionRequest = LocationUpdateRequest + CMServiceRequest，则可以判断RRC建立阶段没有失败，起呼次数为CMServiceRequest的个数。如果上式不满足，则可以认为RRC建立阶段出现呼损，需要到具体信令中定位（这一步需要根据实际规范看是否算在业务呼损里）。

其次可以进一步判断，通过CMServiceRequest、CallProceeding、Connect DL三条信令个数的关系可以判断呼损位置，如果CMServiceRequest=CallProceeding=Connect DL，则可以判断业务建立阶段没有失败，建立成功次数为Alerting DL。如果CMServiceRequest＞CallProceeding，则可能在RAB指派阶段产生了异常；如果CallProceeding＞Connect DL，有可能是被叫切换到了其他RNC或发生了2-3G互操作。具体异常需要到具体信令中定位。

2.3.2 被叫引起呼损分析

其次可以进一步判断被叫寻呼到的次数，可以分别通过rrcConnectionRequest、LocationUpdateReques和PagingResponse三条信令个数的关系来判断，如果rrcConnectionRequest = LocationUpdateRequest + PagingResponse，则可以判断RRC建立阶段没有失败，被叫寻呼到次数为PagingResponse的个数。如果上式不满足，则可以认为RRC建立阶段出现呼损，需要到具体信令中定位（这一步需要根据实际规范看是否算在业务呼损里）。

其次可以进一步通过PagingResponse、CallConfirm、Connect UL三条信令个数的关系可以判断是否有呼损，如果PagingResponse=CallConfirm= Connect UL，则可以判断业务建立阶

段没有失败，建立成功次数为Connect UL。如果PagingResponse＞CallConfirm，则可能在其中阶段产生了异常；如果CallConfirm大于Connect UL，则可能在业务建立产生了异常。具体异常需要到具体信令中定位。

2.3.3 呼损案例分析

以这次测试中的某一次呼损为例（这是一个2G呼3G的IMSI），下面给出初步的定位呼损原因的分析方法：

在生成的report.txt中的统计MO fail的次数可以认为是在这个RNC下此次导出的数据中可能出现呼损的次数

# MO Succ = 3 MO Fail = 0 MT Succ = 1 MT Fail = 1 PS Succ = 0 PS Fail = 0

Unkown = 6

# 再在这个文本文件中找到相关的呼损记录中的起呼流程如下，从该流程可以看出本次fail是被叫，在被叫振铃8s后发起了一个disconnect，为什么会disconnect呢？

根据时间点再到信令中去分析是哪里出了问题，从这条消息中我们可以看到disconnect的原因为user busy，从而可以认为此次呼损是因为被叫用户因为繁忙而释放此次连接。

2.4 掉话分析 2.4.1 CS业务掉话分析

对CS业务来说，查找是否有Iu_ReleaseRequestMsg，如果有，一般为掉话，此时可以查看原信令文件查看相关信令流程，定位问题。

2.4.2 PS业务掉话分析

对PS业务来说，查找是否有Iu_ReleaseRequestMsg，如果存在，则在原信令中查找到该Iu_ReleaseRequestMsg信令，看其cause.u.radioNetwork，判断过程如下：

 如果Cause值为TRANAP_user_inactivity，则PS业务为转空闲过程，不算掉话。

 如果Cause为其余值，则查看下一次rrcConnectionRequest后的第一次呼叫中是否存在PDPActiveRequest，如果有，说明下次业务建立为新的拨号，则上次Iu释放为掉话。 根据Cause值和其余相关信息定位此次PS业务掉话原因。

2.5 注意事项

2.5.1 IMSIDetachIndication异常

在测试过程中，PS业务可能会出现IMSIDetach的情况，该情况是由于数据卡或终端硬件异常导致，不能算为一种掉话。但在前面用生成的.t统计过程中会认为这是掉话。需要将这类失败去掉。

2.5.2 跨Iur口切换造成信令流程不完整

在测试过程中，跨Iur口切换业务可能会导致本RNC内信令流程不完整，从而影响掉话原因的分析，同时还可能造成在本RNC下主被叫呼叫次数的不一致。此时需要将跨Iur口前后的2个数据综合分析，排除异常。

2.5.3 2-3G互操作

在测试过程中，有可能会出现23G互操作的情况，如果被叫到了2G从而被主叫寻呼到，则在RNC的统计中会少了这次被叫的建立成功，因此需要通过cellChangeOrderFromUTRAN或handoverFromUTRANCommand_GSM信令查看是否发生了23G互操作，从而定位呼叫是否成功，寻呼是否成功。23G互操作也可能造成其他方面的统计问题(这种情况暂时还未遇到)