常见异常事件信令分析
大唐后台信令跟踪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 ，有可能会发生二次寻呼后被叫无响应，造成一次未接通。
切换异常的几种原因分析及排查
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的数字传输链路实现。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
常见异常事件信令分析目录：一、日常指标中常见异常事件 (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消息。
对于SDCCH拥塞，我们首先要区分是由于LU引起的信令拥塞，还是由于主叫发起引起的信令拥塞，这可以通过分析MC02a、MC02h和MC04来区分：1）如果小区话务量适中，且MC02a和MC02h在一个数量级上，则我们认为是主叫发起引起的信令拥塞。
解决信令拥塞最根本的办法是，在逻辑参数上增加适量的SDCCH。
2）如果小区话务量偏小，且MC02a远大于MC02h，对此我们认为是LU引起的SDCCH拥塞，我们可以通过增加CRH的值来降低频繁往复的位置更新次数，从而减小SDCCH的占用次数，达到降低拥塞的目的，一般在LAC边界设为10~12dB。
3）除了上述正常情况外，还有一种特殊的SDCCH 拥塞情况，那就是GSM特有的ghost 现象。
这种情况发生在BCCH和TCH 混合分频条件下，表现为小区话务量小，SDCCH试呼次数异常大。
对此，我们可开启RACH TA FILTERING，一般设为15，以解决此类问题。
现网中SDCCH拥塞的信令：暂时截取不到信令流程图2、SDCCH分配失败：引起SDCCH分配失败的原因有：无线原因、BSS问题2.1无线原因引起SDCCH分配失败：信令流程如下：无线问题会导致T3101超时，MS无法及时占用SDCCH信道，BSC发RF Channel Release 到BTSMC149：统计无线问题造成的SDCCH分配失败现象具体的无线问题一般可分为：功率预算不平衡、覆盖不好、干扰2.2 BSS问题引起的SDCCH分配失败：信令流程如下：无专门计数器2.3 SDCCH分配失败信令分析：以下取出了Abis口的SDCCH分配失败信令截图（数据来源于5月22日17点10291小区）从中可以看出当网络发出立即分配指令IMASS（Immediately Assignment）后，由于SDCCH分配未成功，导致下一步网络直接发起无线信道释放RCHRL（RF Channel Release）。
正常的SDCCH分配应该如下（主叫）：当网络发出立即分配指令IMASS（Immediately Assignment）后，SDCCH分配成功后，手机发起了CM 业务请求CMSREQ（CM Service Request），而后经过AUTREQ——AUTREP——SETUP——CPROC等一系列流程建立通话。
其中：CHNAV（Channel Activation）BSC向BTS发送一条信道激活消息。
此消息中包含的参数有：DTX控制、信道的ID（识别）、信道描述、移动台和基站的最大功率电平、基站控制器计算的有关此次接入的初始时间提前量等信息。
IMASS(Immediate Assignment)通过AGCH信道告知移动台有关使用SDCCH信道的情况。
在这条消息中，包括的参数有：寻呼模式、SDCCH信道描述、随路SACCH、跳频，如果应用了跳频，则还应包括请求参考（与建立原因相同）、初始时间提前量和频率分配。
移动台向网络发送CM业务请求，目的是为连接管理子层实体申请一项服务，比如：主叫连接建立、补充业务激活或短消息传送。
CLASSMARK包括了以下信息：MS Revision Level ——手机的修正版本MS Ciphering Capability ——手机支持的加密算法MS Frequency Capability ——手机支持的频段MS RF Power Capability in Each Band ——手机在各频段支持的发射功率3、SDCCH掉话引起SDCCH掉话的原因有：无线问题、BSS问题、SDCCH切换失败（在现网中SDCCH 切换都关闭，在此不讨论）3.1无线问题引起SDCCH掉话：信令流程如下：MC138：统计无线原因引起的每个小区SDCCH掉话Clear Request：非正常的信道释放3.2 BSS问题引起SDCCH掉话：信令流程如下：MC137：BSS原因引起的每个小区SDCCH掉话BSS问题：包括BTS/BSC hardware、software失败现象，Abis传输问题等3.3 SDCCH掉话信令分析以下取出了Abis口SDCCH掉话信令截图（被叫）：（数据来源于5月18日10点30011小区）当信道激活CHNA V(Channel Activation)，以及信道激活被确认CHNAK(Channel Activation Acknowledge)后，网络发出了立即分配指令IMASS（Immediately Assignment），在立即分配过程中分配了SDCCH信道给手机，随后网络发起Paging请求，当Paging 请求得到响应时PAGRES(Paging response)，此时由于YY_TXPWR_M原因引起了连接失败CONFL(Connection Failure)，即发生了SDCCH掉话，随后网络发起信道释放指示RELRQ(Release Indication)来释放无线信道。
正常的信令如下(被叫)：正常的流程应该是：网络发起Paging请求PAGRES(Paging response)后，建立SETUP，随后是呼叫被证实CCONF（Call Confirmed)，网络发出系统信息5 SYSINF5（System Information Type 5），TCH分配请求ASSCMD(Assignment Command)、完成等一系列过程。
其中：PAGRES(Paging Response)基站收发信台通过返回建立指示消息确认立即指配命令。
建立指示消息有两种用途。
首先，建立指示消息从基站收发信台的角度出发，指出移动台目前正在SDCCH信道上。
这样，基站收发信台向基站控制器发一消息，指示现在移动台的CM业务请求正在所描述的这种SDCCH信道上传送。
另外，基站收发信台将识别这一连接并把接收到的第3层的消息加入到这条消息中SETUP（Setup）BSC通过BTS把建立命令发送到MS，是为了通知MS将要进行通话。
4、TCH拥塞信令流程如下：MC812统计了5种TCH拥塞原因MC821=MC612A+MC612B+MC612C+MC612D+MC612EMC612A不许排队；MC612B队列已满；MC612CT11超时；MC612D被高优先级MS 挤出队列；MC612E Abis资源被用完1）、不允许排队或队列已满：在A接口BSC发Assignment Failure "No Radio Resource Available"2）、呼叫进入队列，但T11时间内没有TCH空出：在A接口BSC发Clear Request "No Radio Resource Available"3）、呼叫被优先级更高的呼叫挤出队列：在A接口BSC发Assignment Failure "No Radio Resource Available‖在现网中的TCH拥塞信令如下（数据取至2007年7月9日11时31901小区）：从上图看出，网络已完成SDCCH的分配以及鉴权过程后，发起建立SETUP，随后是呼叫进行CPROC（Call Proceeding），当进行到分配TCH的阶段时，由于网络无空闲的TCH分配给手机，导致网络直接断开当前连接DISC（Disconnect），释放无线信道，造成一次TCH拥塞现象。
5、TCH分配失败引起TCH分配失败的原因有：无线原因、BSS原因、Abis口拥塞（此情况已在TCH拥塞中说明，在这不讨论）5.1无线原因引起的TCH分配失败：信令流程如下：MC746B：统计无线原因造成的TCH分配失败5.2 BSS原因引起的TCH分配失败：信令流程如下：MC14B：统计BSS原因造成的TCH分配失败以下列出了TCH分配过程中的异常情况：1）、T9108超时: BTS对physical context request没有响应，之后的Channel Activation 消息中将不带TA和手机及BTS的发射功率信息2）、T9103超时: Channel Activation没有回应A接口上BSC发Assignment Failure "Radio Interface Failure"；BSC向BTS发RF Channel Release消息3）、在原来的信道上（如SDCCH信道）收到Assignment Failure消息：手机收到Assignment Command后，在新信道上发SABM消息，BTS收到后向手机发UA消息。