常见异常事件信令分析

合集下载

大唐后台信令跟踪LDT异常事件解读

⼤唐后台信令跟踪LDT异常事件解读3、CDL⽂件掉话失败原因分析3.1、cdl分析关注要点⽬前的CDL⽂件使⽤LDT分析后，UE掉话对应的有“掉话事件”和“掉话原因”，掉话原因为关注的重点，具体掉话原因对应的有：1)RL failure or RLC error timer expiry。

RB建⽴后，掉话；2)Receive Ue TimerOut Response Message In DTD Proc。

RB建⽴失败，影响接通；3)切换过程中发⽣RL失败引起的掉话。

切换失败导致掉话；4)未知原因引起的掉话。

切换失败导致掉话；5)failed because cell update occurs。

⼩区更新失败导致掉话；6)Receive Ue Timeout Msg during HO。

切换失败导致掉话；7)⼩区更新超时。

实为切换失败掉话；8)RL Failure引起的掉话。

⽆线链路失败触发⼩区更新，导致掉话；9)user or link forece release。

UE在cs域和ps域中建⽴RAB，kpi中会统计为掉话或接⼊失败；10)RA THO, as waiting lu timer expire message, received a cell change order from utran failuremessage。

系统间切换失败导致掉线；11)rolled Fail during HO。

⼩区更新导致切换失败掉话；12)The reason for the action is expiry of timer TRELOCoverall.。

系统间切换失败导致掉话；13)RRC release when INTEGRITY CHECK fail。

RAB建⽴失败14)Cell Update Confirm 超时。

⼩区更新，掉线；15)Receive Ue Failure Response Message In DTD Proc。

短消息系统信令错误分析及故障处理

短消息系统信令错误分析及故障处理摘要：本文通过对短消息的系统原理进行简单阐述，描述短信信令出错原因并结合相关案例，描述短消息故障处理的思路。

关键词：短消息信令；MO；MT；取路由；出错信息一、短信系统概述短消息中心是独立于GSM网络的一个业务处理系统，主要功能是提交、存储、转发短消息，并完成与PSTN、ISDN、PSPDN等网络的互通，以传递来自其它短消息实体SME（Short Message Entity，如：人工台/自动台等）的短消息。

鉴于GSM网络信令的复杂性、业务的多样性，从业务表现出来的故障现象比较简单（下发消息失败），但原因很复杂。

如果维护人员熟悉短消息系统结构，掌握信令规范和SMPP协议，从消息流程上可以逐段分析排除定位。

下图简单描述了短消息的业务流程。

二、短信信令错误原因因种种原因，在短消息发送过程中，HLR和MSC都可能给网关返回出错信息。

这些出错信息由GSM09.02协议规定。

网关将这些出错信息以及自身处理过程产生的错误传递给调度中心，调度中心将根据出错信息和错误类型的设置决定短消息的重发或删除。

短信接通率是短消息系统的重要性能指标之一，优化系统性能是我们努力的方向。

深入分析这些出错信息，有助于问题的准确定位。

如果短消息中心无法接收短消息，G/IW网关将给Servicing MSC返回错误。

这些错误可能包括：a）G/IW网关接收MAP_MO_FORWARD_SHORT_MESSAGE后，如果发现原语数据有无，将返回意外数据和数据丢失给MSC；b）如果没有标注SC，网关返回SM转发失败给MSC；c）SC返回的错误，网关用SM转发失败带诊断信息转发给MSC；d）如果网关无法将短消息传递到SC或传递过程因某种原因失败，网关将给MSC返回系统错误。

MT失败产生错误的原因可能来自于1.网关发送路由请求后HLR可能返回的部分错误原因。

表1 取路由回应过程中出错信息2.网关取到路由后，向Servicing MSC发送短消息，MSC 可能返回的部分错误原因表2 MT回应过程中出错信息3.MapServer提供的错误值及与协议错误值的映射从上面可知，MO过程的出错处理是网关向Servicing MSC发送出错消息，从短消息中心角度出发，这是一个输出过程。

信令流程及异常事件解决方案

MS主叫信令1．信道请求Channel Request（Rach）MS→BTSMS通过动态地在RACH信道（随机接入信道）上发送一个随机接入脉冲向一个（BTS）BTS申请一条信道。

2．申请信道Channel Required( BTS→BSC)BTS向BSC发一条申请信道消息。

3．信道激活Channel Activation (BSC→BTS)收到从BTS发来的申请信道消息后，BSC开始按照一定的条件为此次呼叫寻找和分配SDCCH信道，同时BSC向BTS发送一条信道激活消息。

4．信道激活证实Channel Activation ACK(BTS→BSC)这是对信道激活消息的应答。

当BTS收到这条消息后，它开始在SACCH信道发送和接受消息。

5．立即指配命令immediate assignment (BSC→BTS)BSC告诉BTS关于被使用的SDCCH信道。

6．立即指配immediate assignment (BTS→MS) AGCH基站分系统通过AGCH信道告知移动台有关使用的SDCCH信道的情况，在这条消息中，包括的参数有：寻呼方式、SDCCH信道描述、随路SACCH、跳频、申请参数（与建立原因相同）、初始时间提前量和频率分配（跳频应用）。

7．CM业务请求CM service request (MS→BTS→BSC→MSC)移动台向网络发送CM业务请求，目的是为连接管理子层实体申请服务8．无编号确认UA(SDCCH)9．鉴权Authentication Request MSC→BSC→BTS→MS10．TMSI再分配命令TMSI Reallocation11．建立SetupMS处在SDCCH信道中，准备开始真正呼叫建立信令。

MS发送一建立消息给BSC，再被送到MSC。

BSC向MSC发送建立消息来告知MSC将要执行的呼叫。

12．呼叫接续Call Proceeding（MSC→BSC→MS (SDCCH)）MSC对建立消息的响应。

e8踪信令分析异常事件方法和案例

通过IMSI跟踪信令分析异常事件方法和案例2010年9月16日--------------------------可以编辑的精品文档，你值得拥有，下载后想怎么改就怎么改--------------------------- ==========================================================================目录一：简要说明 (3)二：正常信令流程 (3)三：信令筛选方法简介： (3)四：异常事件分析和案例 (4)4.1 未接通分析 (4)4.2 切换失败 (8)4.3 掉话分析 (9)--------------------------可以编辑的精品文档，你值得拥有，下载后想怎么改就怎么改--------------------------- ==========================================================================--------------------------可以编辑的精品文档，你值得拥有，下载后想怎么改就怎么改---------------------------==========================================================================一：简要说明为了保障和及时了解联通第三方测试采用情况，现场对测试号码实施IMSI 跟踪，通过IMSI 跟踪的异常事件来分析，第一时间掌握测试路线和沿路异常隐患，下面重点描述通过IMSI 判断几类主要异常事件的方法主要异常事件主要有：未接通事件；掉话事件；切换失败事件目的：通过IMSI 跟踪信令来发现和定位异常事件，结合几类常见异常事件进行辅助说明。

二：正常信令流程下面链接包含主、被叫接入流程和释放流程；BSC 内切换和跨BSC 切换流程，用来对异常事件实施对比分析:IMSI正常信令流程916.xls三：信令筛选方法简介：1：使用sigtrcw.exe 分别打开主被叫IMSI 信令 2：点击【查询】--〉【过滤】 3：主要选择如下信令：4：对筛选出来的异常事件相关信令进行逐个时间点对应分析四：异常事件分析和案例4.1 未接通分析仅仅通过IMSI跟踪，容易遗漏寻呼无响应和被叫位置更新造成的未接通事件，因此在跟踪路测结果时，依据现场实际条件，可以借助提取话单或CDT辅助分析，对异常话单或CDT 异常事件进行IMSI信令进一步分析原因，下表为几类主要未接通类型和信息来源：【案例1】：指配TCH失败：下图为指配TCH信道后由于质量差造成指配失败，可以看出如下信息：-----从信道激活信令中可以查看具体指配载频和频点信息----异常事件主要包含：指配故障、错误指示、错误报告、CS失败事件其中：指配故障描述原因为无线接口故障错误报告描述原因为T200超时CS失败事件描述为指配过程手机未接入--------------------------可以编辑的精品文档，你值得拥有，下载后想怎么改就怎么改--------------------------- ==========================================================================--------------------------可以编辑的精品文档，你值得拥有，下载后想怎么改就怎么改---------------------------==========================================================================通过上图可以判断为一次被叫指配失败造成未接通事件【案例二】：寻呼无响应：如果仅仅从IMSI 来判断，这需要对被叫IMSI 进行筛选，提取出【寻呼（582）】信息，对比间隔，如果连续多个寻呼消息间隔小于2s ，有可能会发生二次寻呼后被叫无响应，造成一次未接通。

切换异常的几种原因分析及排查

RadioLinkSetupRequest
RNC发起无线链路建立，NodeB返回失败；
RadioLinkSetupFailure
RelocationFailure
RNC向CN发送重定位失败消息，根据失败的类型填写消息中的错误码；
IuReleaseRequest
D侧发起Iu连接释放过程；
IuReleaseCommand
原因分析及排查手段：
可能原因为：
UE未收到CONFIRM消息（下行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；
排查方法：
网络侧向终端发起物理信道重配过程，定时时间内终端未发送物理信道重配完成消息，且在等待时间内未上报小区更新；
measurementReport
UciuHelloForward
UciuHelloForwardAck
SUciuMacMeasReport
RadioLinkDeletionRequest
网络侧删除目标小区无线链路及承载；
RadioLinkDeletionResponse
FpSRelReq
IuReleaseRequest
原因分析及排查手段：
UE收到了RECONFIGURATION消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；
UE收到了RECONFIGURATION消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；
1.1.2.5
1.信令截图：
2.原因分析及排查手段：

异常事件分析流程

异常事件分析流程掉话分析流程掉话流程图掉话总体分为以下几种：弱覆盖掉话、质差掉话、突然掉话；根据实际的测试现象逐步分析：分析说明弱信号掉话：处理流程图：质差掉话：质差掉话按照方向来分：A、上行质差掉话；B、下行质差掉话A、上行质差掉话：造成上行链路高误码一般都是由于上行信号受到干扰导致，主要由以下原因：1、网内干扰：自身网络的有源设备（如：直放站、拉远设备等）上行叠加噪声过大，基站对手机上行信号进行识别，影响通话，2、网外干扰：由于其他运营商的频段的互调干扰导致，或由于非法私装放大器导致硬件问题。

B、下行质差掉话：下行质量掉话的情况可以通过QUALSUB项直观地看到。

下行质量差的原因基本包括同邻频干扰、基站覆盖差、切换失败、基站硬件问题等。

处理流程图：突然掉话突然掉话是在信号质量好，信号强度较高和TA值不超现的情况下产生的。

我们大致知道一下原因可能导致突然掉话：无线环境突然变化，信号强度的突然衰落（如进入没有覆盖的建筑物或电梯、停车场等）；突然收到严重的干扰切换丢失基站硬件问题手机终端问题（如掉电）处理流程图：DT连续质差处理流程通话质差一般由于弱信号、干扰、设备故障导致。

日常处理流程如下：判断覆盖源是否为直放站或拉远设备，并通过临时关闭站点观察定位，并判断是否存在故障服务小区是否存在同邻频干扰覆盖小区不明显导致切换质差基站设备是否存在故障是否存在外部干扰，如高考考场的信号干扰器流程图如下:DT 切换频繁处理流程切换频繁一般是由于覆盖小区不明显，经常触发切换条件产生频繁的小区切换，影响通话质量，且容易造成掉话。

日常处理流程如下：确认覆盖路段主导小区是否明显，如没有主导小区，需要通过参数调整、天线调整、站点站址评估等优化手段，明确覆盖小区无线环境是否变化较大，导致信号波动严重，邻区小区波动严重导致；可以通过参数调整使切换带提前或推迟，减少切换次数。

切换参数设置时候合理，检查切换参数，如迟滞值，层值、服务小区和目标小区切换参数的一致性等检查是否存在紧急切换的情况（超TA、质差紧急切换等）流程图如下:DT 切换失败处理流程切换失败主要由于干扰引起，最主要来自同BCCH同BSIC的干扰，以及同BCCH的干扰，且针对服务小区和切换目标邻区受到干扰也会导致切换失败。

信令分析案例

1、MS呼叫未接通：问题描述: 在做DT测试过程中发生了一次未接通，地点是LAC区交接处.在DT测试的行程中，可能发生数次跨LAC区的切换，极易发生掉话或未接通情况。

主要有以下三条信令消息：UL：CHANNEL REQUESTDL：IMMEDIATE ASSIGNMENTUL：CM SERVICE REQUEST问题分析: (1)在上行的CM SERVICE REQUEST信令发出后，没有下行的响应，通话状态由起呼直接转为空闲模式（IDLE），由此可以断定发生了一次未接通。

由于上行UL：CM SERVICE REQUEST是MS发起的对SDCCH的申请，发出申请后没有应答，没有出现标志呼叫接通的信令消息，可以断定发生了一次未接通情况。

其原因可能为该服务小区的SDCCH 信道拥塞，也可能是由于无线环境的恶化造成SDCCH信令丢失。

因为此次DT测试发生在跨数个LAC的路段，而且是上一个通话刚刚结束，起初判断可能是发生了一次位置更新。

(2) 位置更新信令消息如下：DL：CHANNEL RELEASEUL：CHANNEL REQUEST（开始位置更新）DL：IMMEDIATE ASSIGNMENTUL：LOCATION UPDATING REQUESTDL：AUTHENTICATION REQUESTUL：AUTHENTICATION RESPONSEDL：LOCATION UPDATING ACCEPTUL：TMSI REALLOCATION COMPLETEDL：CHANNEL RELEASE结合此例的第三层信令消息来看，例子中MS发出了UL：CM SERVICE REQUEST，并不是UL：LOCATION UPDATING REQUEST，由此可以判断出此例并非是位置更新。

2 、位置更新导致数据吞吐量为0问题描述: 在某路段,进行数据业务测试时,发现MS数据吞吐量变为0,没有了与GPRS网络的连接.问题分析: (1) 在该路段进行语音业务测试, 确认已经完全覆盖.(2) 分析当时数据业务测试的层3信令. 当时的信令为:DL：SYSTEM INFORMATION TYPE 1UL：LOCATION UPDATING REQUESTUL：CHANNEL REQUEST初步定位数据吞吐量变为0的原因是MS执行了一次跨路由区的小区重选(3) 对比在当时显示图的信令部分可以明显的看出该MS正在做位置更新.3 、FTP下载中断问题描述: 在DT FTP下载测试中，MS已成功登陆FTP Server，并已经开始下载数据，FTP下载进度为9％，在经过一次小区重选后, FTP下载不能继续进行，在一系列的Ping fail后，FTP掉线.问题分析: (1) 查看层三信令,具体显示如下：Direction Type Layer 3 MessageUL GPRS SM Deactivate PDP Context RequestDL RR System Information Type 13UL RR Channel RequestDL RR Immediate AssignmentDL GPRS SM Deactivate PDP Context Accept发现在事件列表中有PDP Deactivated的消息，在层三消息中可以看到是手机发起的上行消息.(2)发生这种情况可能有3种原因：一是手机在测试过程中电缆的某个接口发生了松动，这样手机可能会发出PDP去激活申请。

异常信令导致未接通

异常未接通专项分析报告1 概述上海移动测试组在2010年1月至2010年5月的无线测试中发现大量MS 异常信令未接通事件从而导致了无线网络接通率较低。

由于该现象出现比较频繁而且出现的原因也比较的复杂，要弄清具体的原因需要通过UM,ABIS,A 口的联合信令分析，由于我们资源有限无法进行端到端的分析，因此我们只能对UM 和A 口进行联合分析。

2 信令异常问题分析计划针对本次上海移动出现的多次异常未接通情况，设计院优化小组在优化期内重点收集了无线测试中发现异常未接通的事件，截止到11月设计院共发现异常未接通数量为12个，占了所有未接通比例的22.7%。

我们将结合A 口数据分析原因所在。

3 GSM 接口简介3.1 接口概述BSS 对外的接口都是标准接口，包括MS 与BSS 之间的Um 接口、BSS 与MSC 之间的A 接口，这些接口协议和规程都在ETSI 协议中有严格和完备的规定。

BSS 的各个网元（BTS 、BSC ）之间的接口以及BSS 与OMC 的接口都是内部接口，与设备供应商的实现有关。

其中ETSI 对BTS 与BSC 之间的Abis 接口也做了许多规定，但不够完备。

下图是GSM 系统信令模型，每个接口总体介绍如下：C M M MR RL A P D m S i g n . L a y e r 1 L 3L 2L 1B T S MM S U mS C C PM T P B T S M R R B S S M A PA b i sB T S B S CM S C AB S CS i g n . L a y e r 1S i g n . L a y e r 1S i g n . L a y e r 1R R L A P DL A P D m L A P D C M M MB S S M A PS C C P M T PMS：移动台BTS：基站收发信BSC：基站控制器台CM：接续管理MM：移动性管理MSC：移动交换中心SCCP：信令连接控制部分RR：无线资源管理MTP：消息传递部分LAPD：D信道上链路接入规程LAPDm：Dm信道上链路接入规程BSSMAP：基站子系统应用管理部分BTSM：BTS管理3.1.1 A接口A接口定义为网路子系统(NSS)与基站子系统(BSS)间的通信接口，就是移动业务交换中心(MSC)与基站控制器(BSC)之间的接口，物理链路采用标准的2.048Mb/s的数字传输链路实现。

异常信令

RRC连接建立异常信令原因分析：1.信令连接建立在DCH上，NODEB无线链路建立失败。

NODEB不能按照要求为用户建立RL时，向RNC返回RL Setup Failure消息，并包含失败原因。

RNC收回内部为该用户分配的无线资源，并通过UU口，向该用户发送RRC Connection Reject消息，拒绝用户接入。

信令连接建立失败，该过程结束。

2.信令连接建立在DCH上，Iub接口AAL2建立失败。

RNC在建立Iub接口上的ATM承载时，发生失败，从而导致空中接口的RRC连接无法建立，最终导致信令连接建立失败。

当RNC与NODEB之间RL建立成功后，RNC想NodeB发送ALCAP的Establish Request消息，发起AAL2连接建立过程，用于在Lub接口承载RRC信令。

RNC实体的ALCAP与NODEB实体的ALCAP进行协商，Nodeb实体拒绝建立该接口上的AAL2连接。

RNC收到AAL2建立失败消息后，RNC收回内部为该用户分配的无线资源。

RNC与nodeb交互，释放该用户的无线链路。

RNC通过UU口，向该用户发送RRC Connection Reject消息，拒绝用户接入。

信令连接建立失败，该过程结束。

3.信令连接建立在DCH或FACH上，网络拒绝RRC连接建立。

在RNC成功的为UE建立了无线链路和Iub接口上承载该信令连接的A TM承载后，在申请本地业务资源时，由于没有足够的本地资源或其他原因导致本地分配失败或逻辑连接建立失败，从而导致空口RRC连接无法建立，最终导致信令连接建立失败。

4.信令连接建立在DCH上，在RNC给UE发送RRC Connection Setup消息后，直至定时器超时RNC仍没有收到用户的响应信息（由于移动和无线环境的恶化等原因），则释放为该用户分配的无线资源，此次信令连接建立失败。

5.信令连接建立在DCH上，UE收到无效的配置信息。

该过程描述是，在RNC内完成了RRC连接所需的配置,但是由于UE得原因（协议参数错误，UE的性能不支持等原因），导致信令连接建立失败。

异常事件详细分析

1.1 未接通事件1：被叫手机位置更新被叫手机RNC侧信令：（rnc侧信令时间等于空口信令时间+44秒）事件分析：UE沿图中方向行驶跨位置区，被叫位置更新导致本次呼叫未接通。

从主叫信令上看被叫已经上发了alerting，但从被叫信令看，被叫在位置更新结束后，有30秒中无信令（应是软件记录信令丢失，实际未丢失），实际上被叫已经上发了alerting和connect消息，但主叫已经超时。

主叫收到alerting的时间是10:42:09.8秒，一般connect至alerting的时间间隔是5秒左右，所以正常流程下主叫收到connect时间应该是10:42:14.8秒，但主叫上行disconnect时间是10：42：12.5，也就是主叫等不及connect就disconnect了（软件默认设置主叫connect时间是15秒）1.2 未接通事件2：未知原因导致未接通事件分析：UE沿望江路自西向东行驶，主叫手机占用社科院3小区，主叫上发rrcConnectSetupComplete,但没有上发CM SERVICE REQUEST,导致本次未接通。

由于rrc没有建立完成，所以RNC跟踪的信令不记录本次呼叫记录，因此看不出来是RNC没有收到rrcconnectsetupcomplete，还是RNC收到了，但UE异常没有发送CM service request消息。

查看该小区该时段上行干扰情况，从统计结果来看，无上行干扰。

所以应该是UE异常没有发送CM service request消息导致本次未接通。

1.3 未接通事件3：被叫频繁重选未及时收到寻呼导致未接通事件分析：UE沿图中方向行驶，主被叫均完成位置更新以后，主叫起呼，主叫call proceeding（10:47:29）后，被叫应该收到寻呼，查看被叫信令，被叫在10:47:30至10：47：40秒之间收到了4次寻呼，但都不是本次呼叫的寻呼，而是ps域寻呼，直到10：47：41秒才收到本次呼叫的寻呼，被叫手机响应本次寻呼完成。

手机信令数据的用户行为分析与异常检测研究

手机信令数据的用户行为分析与异常检测研究手机信令数据是指由手机与通信基站之间进行通信时所产生的非隐私信息。

这些数据包含了手机用户的通话记录、短信记录、位置信息等，是研究用户行为和进行异常检测的重要数据源。

本文将主要聚焦于手机信令数据的用户行为分析与异常检测的相关研究。

第一部分：手机信令数据的用户行为分析手机信令数据的用户行为分析可以帮助运营商和相关部门了解用户的行为特征，为用户提供个性化的服务，并监测潜在的风险。

以下是一些常见的手机信令数据用户行为分析方法：1. 基于位置的行为分析：通过分析手机用户的位置信息，可以了解用户的出行模式、活动范围以及日常行为习惯。

这对于城市规划、交通管理和广告投放等方面具有重要意义。

2. 基于通话模式的行为分析：通过分析手机用户的通话模式，可以了解用户的社交网络、通话习惯和消费行为。

这可以帮助运营商提供更精准的套餐推荐和增值服务。

3. 基于网站浏览行为的分析：通过分析手机用户的网站浏览行为，可以了解用户的兴趣偏好、消费意向和网络行为习惯。

这对于广告定向投放和营销策略制定具有重要意义。

4. 基于短信记录的分析：通过分析手机用户的短信记录，可以了解用户的沟通方式、社交关系和信息交流模式。

这对于社交网络分析、短信营销和欺诈检测等方面具有重要意义。

第二部分：手机信令数据的异常检测研究手机信令数据的异常检测可以帮助发现潜在的欺诈、窃密和恶意行为，保障网络安全和用户权益。

以下是一些常见的手机信令数据异常检测方法：1. 异常话单检测：通过分析通话记录、短信记录和上网记录等数据，在用户的通信行为中发现异常模式。

例如，突然出现大量通话或短信记录的异常行为可能是被恶意软件或欺诈行为所导致，运营商可以及时采取措施保护用户利益。

2. 异常位置检测：通过分析用户的位置信息，在用户的移动轨迹中发现异常模式。

例如，用户频繁在不同城市进行通信活动可能是被盗用或非法设备所导致的异常行为，可以通过异常检测算法进行识别和处理。

常见异常事件信令分析

常见异常事件信令分析目录：一、日常指标中常见异常事件 (2)1、SDCCH拥塞： (2)2、SDCCH分配失败： (3)2.1无线原因引起SDCCH分配失败： (3)2.2 BSS问题引起的SDCCH分配失败： (3)2.3 SDCCH分配失败信令分析： (3)3、SDCCH掉话 (7)3.1无线问题引起SDCCH掉话： (7)3.2 BSS问题引起SDCCH掉话： (7)3.3 SDCCH掉话信令分析 (8)4、TCH拥塞 (10)5、TCH分配失败 (11)5.1无线原因引起的TCH分配失败： (11)5.2 BSS原因引起的TCH分配失败： (12)5.3 TCH分配失败信令分析： (13)6、TCH掉话 (16)6.1无线问题引起TCH掉话： (16)6.2切换失败引起TCH掉话： (17)6.3 BSS内部原因引起TCH掉话： (17)6.4传输问题引起TCH掉话： (17)6.5 TCH掉话信令分析： (18)6.5.1 MC736掉话 (18)6.5.2 MC621掉话 (19)6.5.3 MC14C掉话 (21)6.5.4 MC739掉话 (21)6.5.5 正常的挂机 (22)7、切换异常事件 (26)7.1、无线原因引起的切换失败返回信令流程（小区间异步切换）： (26)7.2、系统原因（BSS问题）引起的切换失败 (26)7.3、切换失败信令分析： (26)二、DT测试中的异常事件 (30)1、未接通 (30)1.1由于TCH拥塞 (30)1.2位置更新引起 (33)2、paging失败 (35)3、TCH掉话 (35)三、附录 (38)Abis口信令名词缩写解释： (38)一、日常指标中常见异常事件日常指标中常见异常事件主要表现为：SDCCH拥塞、SDCCH分配失败、SDCCH 掉话、TCH拥塞、TCH分配失败、TCH掉话、TCH切换失败1、SDCCH拥塞：信令流程如下：MC02a 位置更新次数MC02h 所有主叫电话占用SDCCH次数MC04 SDCCH拥塞次数当用户发起CHANNEL REQUEST时，网络发现无空闲的SDCCH信道时，BSC将会：如果小区参数En_Imm_Ass_Rej=“True”，则发Immediately Assignment Reject；否则Channel Required消息。

通信网络互联中信令故障的分析与处理

，
簌
。
。。‘ 一
摘
要：信令系统故障属于软故障，整个通信网络都会受其
起来，网络的不同部件之间传递和交换必要的信息使网在
严重影响．且难以处理。基于单候矿通信网络互联的故障处理及调度联网故障处理两个实际案例，结合通信网络的应用现状及信令流程特点．出逐步分段，速发现与定位提快的信令故障处理方法。关键词：令故障：令流程逐步分段；障定位；通信网信信故
ＬｉＸｉａｏｌａｎｇｉ
（ｎｆｒａｉｎａｄＣｏｔｏｎｅｆｉａｏｐＨｅｅ，ａｇｈｎ０３１）ＩｏｍｔｏｎｎｒｌＣｅｔｒｏｌｎＧｒｕ，ｂｉＴｎｓａ，６０８Ｋａｕ
Ａｂｓｒｔｔａｃ：Ｓｉｇｎａｉａｔｉｎｄｆｓｔｆｕｌ，ｂｗｈｉｈｈｅｗｈｏｌｏｍｍｕｎｉｔｏｎｎｅｗｏｒｌｎｇｆｕｌｓａｋｉｏｏｆａｔｙｃｔｅｃｃａｉｔｋ，ａｎｄｈｉｏｂｌｓｄｉｆｃｔｔｔｓｐｒｅｍｉｆｕｌｏｉｂｅｒｏｖｅｅｓｌｄ．ＢａｓｅｄｎｈｅｆｕｌｏｃｓｎｇｎｄｃｏｔａｔｐｒｅｓｉａｓｈｅｄｅｆｈｅｆｕｌｏｃｅｓｎｇｏｆｔｏｍｍｕｎｉａｉｕｌｏｒｔａｔｐｒｓｉｈｅｃｃｔｏｎｎｅｔｏｋｓｉＤａｎｈｏｕｗｒｎｍｉｎｅ，ｃｏｎｓｄｅｒｎｇｉｉｂｏｔｈｅａｐｐｌｃａｉｎｔｅｏｆｔｏｍｍｕｎｉａｉｔｏｒｎｄｈｅｃｈａａｔｉｔｃｏｆｔｉｈｔｉｔｏｓａｔｈｅｃｃｔｏｎｎｅｗｋｓａｔｒｃｅｒｓｉｈｅｓｇｎａｌｎｇｌ，ａｉｆｏｗｓｇｎａｌｎｇｆｕｌｏｃｓｎｇｅｈｏｄｆｓｇｍｅａｉｉｉａｔｐｒｅｓｉｍｔｏｅｎｔｔｏｎｔｓｅｐｂｙｔｐ，ｒｐｉａｕｌｎｄｉｓｅａｄｆｔｆｉｎｇａｎｄｌｃａｉｓｐｒｅｅｏｔｏｎｉｅｓｎｔｄ．Ｋｅｙｗｏｒ：Ｓｉｄｓｇｎａｌｎｇａｔｉｉｆｕｌ；ｓｇｎａｉａｕｌ；ｓｌｎｇｆｔｅｇｍｅｎｔｔｏｎｓｅｂｓｅｐ；ｆｕｌｏｃａｉａｉｔｐｙｔａｔｌｔｏｎ；ｃｏｍｍｕｎｉｔｏｎｅｗｏｒｃａｉｎｔｋｓ

信令跟踪数据异常检测算法

信令跟踪数据异常检测算法信令跟踪数据是指在通信网络中传输的控制信息，用于建立、维护和释放通信连接。

信令跟踪数据异常检测算法是指通过对信令跟踪数据进行分析和处理，检测出其中的异常情况，以提高通信网络的安全性和可靠性。

本文将介绍信令跟踪数据异常检测算法的原理和应用。

一、信令跟踪数据异常检测算法的原理信令跟踪数据异常检测算法主要基于以下原理进行操作：1.统计分析：通过对信令跟踪数据进行统计分析，包括数据的频率、分布、趋势等，以发现异常情况。

例如，对于通信连接建立过程中的信令数据，可以统计建立成功率、建立时间等指标，如果出现异常的统计结果，则可能存在异常情况。

2.模型建立：根据信令跟踪数据的特点，建立相应的数学模型，以描述正常的数据分布和行为。

通过与实际数据进行比较，可以检测出异常情况。

例如，可以使用高斯分布模型来建立信令数据的正常行为模式，当实际数据偏离模型过多时，则可能存在异常情况。

3.机器学习：利用机器学习算法对信令跟踪数据进行训练和分类，以区分正常数据和异常数据。

通过构建合适的特征向量和选择适当的分类算法，可以实现对异常数据的检测。

例如，可以使用支持向量机(SVM)、决策树等算法进行分类学习。

信令跟踪数据异常检测算法在通信网络中有广泛的应用。

主要包括以下方面：1.网络安全：通过对信令跟踪数据进行异常检测，可以及时发现网络攻击、入侵行为等安全威胁。

例如，当信令数据中出现大量的未知IP地址或异常的通信行为时，可以判断为可能存在攻击行为。

2.故障诊断：通过对信令跟踪数据进行分析，可以及时识别出通信网络中的故障点，并进行相应的处理和修复。

例如，在通信连接建立过程中，如果出现频繁的建立失败或超时，可以判断为可能存在网络故障。

3.性能优化：通过对信令跟踪数据进行异常检测，可以发现通信网络中的性能问题，并进行调优和优化。

例如，可以通过分析信令数据的延迟、丢包率等指标，优化网络资源的分配和调度，提高网络的传输效率和质量。

深圳联通前台信令分析异常事件汇总

.深圳联通前台信令分析异常事件汇总目录1 概述 (1)2 案例分析 (2)2.1 邻区漏配 (2)2.2 RB Reconfiguration消息 (3)2.3 软切换去后发射功率攀顶 (3)2.4 软切换加OFF值 (4)2.5 Cell Update截图 (5)图目录图2-1邻区漏配前台信令截图 (3)图2-2Radio Bearer Reconfiguration消息截图 (3)图2-3软切换去后终端发射功率攀升截图 (4)图2-4前台测试数据中OFF值截图 (5)图2-5CELL UPDATE消息截图 (6)1 概述近期在进行深圳联通业务区WCDMA网络摸底测试期间发现较多掉话事件，现结合前台信令进行总结。

首先，前台层3信令中如看到Uplink Direct Transfer、Downlink Direct Transfer消息则认为是终端主叫或被叫释放，如仅出现RRC Connection Release消息则是异常掉话（这里需明确是CS 业务，PS不能直接这么判断）。

其次，从深圳近期测试数据汇总来看，目前影响网络业务性能的因素主要有以下几点：1、站点邻区列表优化问题；2、 RNC版本处理问题；3、软切换去终端发射功率攀顶问题；4、软切换加失败问题；以上问题在前台CNA软件上主要有以下几点明显的流程出现：1、邻区列表优化问题导频柱状图上出现蓝色扰码显示，在测量报告中上报1A事件，为检测集上报。

目前系统支持两种检测集上报：Measurement identity为1：Detected set cells and monitored set cells；Measurement identity 为11：Detected set cells；现阶段前台重点关注ID为11的，该类问题需通过增加邻区配置解决。

当UE上报ID11测量报告而没有同扰码的ID1测量报告时，应都是漏配邻区；当同一扰码的小区既上报ID11又上报ID1报告时，需要查看配置确认是否漏配邻区。

软交换IP信令分析(二)-现网异常信令分析

CAUSE解释： Temporary failure
BSC_O SEVER_O
HLR SEVER_T
BSC_T
CM SERVICE REQUEST
……………….省略 SETUP
CALL PROCEEDING SRI
SRI_ack
PRN PRN_ack
该IAM消息带有 “期望COT”，启
动T8计时器
SEVER_O
CM SERVICE REQUEST
HLR
SEVER_T
……………….省略 SETUP
CALL PROCEEDING
SRI
CANCLE LU_ACK PRN
DISCONNECT CAUSE41
SRI_ACK ERROR CODE 34
PRN_ACK ERROR CODE 39
HLR收到PRN_ACK 带有ERROR CODE 39（No roaming nr available）接着HLR再向主叫MSC回复SRI_ACK带有ERROR CODE 34（System failure）主叫MSC收到SRI_ACK后，向BSC下发DISCONNECT带CAUSE41 （Temporary failure）在PRN前有一条CANCEL LU消息，在出POOL至新SERVER的LU尚未完成，HLR中VLR 地址仍指向老的SERVER时，收到一个PRN消息，此时老的SERVER已经不存在该用户数据，导致回PRN_ACK，cause=39 No roaming number available00)
解释
数量占比数量占比数量占比
Unknown subscriber
0
0.00% 1 0.02% 1 0.03%

业务异常过程分析

根据该类问题典型的信令流程，NO REPLY失败原因值是由于基站下发rrcConnectionSetup消息以后，没有收到UE侧发回的rrcConnectionSetupComplete消息，这有可能是UE不能正常收到rrcConnectionSetup消息，或者UE侧发回的rrcConnectionSetupComplete消息没有被网络侧正常接收或解码，1 业务异常过程1.1 网络侧收不到RRC连接请求1.1.1 总体描述终端发起呼叫，从路侧终端上可以看到RRC连接请求已经发出，但网络侧看不到任何信令。

1.1.2 原因分析可能是由于UpPch所在位置存在干扰，导致网络侧解错终端上行包，使得RNC看不到任何消息。

⏹如果是特定终端出现该现象，而其他终端没有问题，则可以利用扫频仪在特定终端天线口处检测终端上行信号强度是否正常；⏹如果是普遍现象，则需要检查UpPch所在位置的干扰，如存在干扰则需要考虑对UpPch位置进行漂移。

1.2 RRC连接拒绝1.2.1 总体描述RNC收到UE发送的RRC CONNECTION REQUEST消息后，可能因一些原因导致无法为UE建立RRC资源，此时RNC会向UE发送RRC CONNECTION REJECT消息。

此类异常影响发起业务的无线接通率KPI指标。

1.2.2 典型信令过程1. 信令截图2. 重要信令解释1.2.3 原因分析可能造成RRC连接拒绝的常见原因有：⏹小区码道资源不足，没有足够的码道为UE分配（特殊地：UE只支持单载频，而主载频上已没有剩余的码道资源）；⏹干扰或功率受限，软资源接纳失败；⏹传输资源申请或带宽接纳失败；排查方法：⏹查看小区剩余的码道资源数看是否有足够的剩余资源；⏹查看公共测量值和配置的接纳门限，是否为功率干扰等软资源受限；⏹查看Iub口带宽大小是否受限；1.3 RRC连接建立超时1.3.1 总体描述RNC向UE发送RRC CONNECTION SETUP消息，在一定的时间之内未收到UE上报的RRC CONNECTION SETUP COMPLETE消息，则表示RRC连接建立超时，将删除建立的无线链路，该UE接入失败，此类异常影响业务的无线接通率KPI指标。

7号信令故障分析

7号信令常见故障分析一、MSC/VLR中的C7GTT表格数据配置错误导致某一HLR所属用户无法在此MSC漫游。

故障现象：属于外地同一HLR的一些用户漫游到本地MSC无法进行位置更新。

故障原因分析：首先检查本地HSTP和HLR的数据是否正确，检查无错误；对链路进行跟踪，找到这些用户位置更新的信令消息：1.MSC可以根据用户送上来的IMSI经过GT译码正确找到用户所属的HLR，去取鉴权三元组，HLR正确回送鉴权三元组；2.VLR对用户进行鉴权通过后，根据IMSI向HLR发出LocationUpdate消息；3.HLR向VLR发送ISD消息，VLR回送ISD ACK消息；4.但Location Update ACK消息却成为Abort消息，原因为unrecognizedTransactionID；同时链路上还有一条HLR回的END 消息，内容为system failure；5.这是来自两个不同HLR的消息。

经过检查，发现MSC给HLR发的Location Update消息的目的地地址为**FF60，而ISD ACK消息的目的地地址为**FFC0。

原因已查明，是MSC中的C7GTT表格里对HLR ID的GT翻译错了，本来该送到地址为**FF60的HLR的ISD ACK消息却送到了地址为**FFC0的HLR，地址为**FFC0的HLR回了条未识别的对话ID消息，地址为**FF60的HLR却因等ISD ACK消息超时回了条系统失败消息。

下面是两个HLR回的消息：ABORTDestination Transaction ID（HEX）：39 08 05 BAReasonAbort Cause：1＝unrecognizedTransactionIDENDDestination Transaction ID（HEX）：39 08 05 BAComponentReturn ErrorInvoke ID：26Error Code：Local Value：34＝System Failure二、外地漫游用户无法上网故障现象：外地漫游用户无法上网。