牢牢掌握一个完整呼叫的信令流程

1.概述
作为一名网优工程师, 需要牢牢掌握一个完整呼叫的信令流程. 我们做GSM优化, 主要是对Um口要把握的更深些. 尤其是Layer3信令－也就是我们平常做路测的工程师说的层3信令。关于层3信令，可以参考GSM规范04.08. 对层3信令的准确理解,可以帮助我们快速分析和定位网络问题.

2. 理论部分
2.1一次完整的主叫流程（含切换）
IDLE：
DL: SYSTEM INFORMATION TYPE 1：包括小区信道描述和RACH控制参数
DL: SYSTEM INFORMATION TYPE 2（2bis，2ter）：邻小区BCCH频点描述，RACH控制信道，允许的PLMN（扩展邻小区BCCH频点描述+RACH控制信道；扩展邻小区BCCH频点描述2）
DL: SYSTEM INFORMATION TYPE 3：CI，LAI，控制信道描述，小区选择，小区选择参数，RACH控制参数
DL: SYSTEM INFORMATION TYPE 4：LAI，小区选择参数，RACH控制参数，CBCH信道描述，CBCH移动配置
DL: SYSTEM INFORMATION TYPE 7：小区重选参数
DL: SYSTEM INFORMATION TYPE 8：小区重选参数
UL: Channel request
DL: Immediate assignment（SDCCH）
试呼：
UL:CM service request（如果后面直接收到System Information Type1，则视为起呼失败）
DL: CM service Request
DL: CM service accept
DL: AUTHENTICATION REQUEST
UL: AUTHENTICATION RESPONSE
DL: CIPHER MODE COMMAND
UL: CIPHER MODE COMPLETE
DL: TMSI REALLOCATION COMMAND
UL: TMSI REALLOCATION COMPLETE
UL: SETUP

DL: CALL PROCEEDING
DL: ASSIGNMENT COMMAND
UL: ASSIGNMENT COMPLETE （TCH）
DL: ALERTING
成功起呼：
DL: CONNECT（呼叫成功的标志,）
UL: CONNECT ACKNOWLEDGE
DL: SYSTEM INFORMATION TYPE 5（5bis，5ter）：邻近小区BCCH频点描述（扩展邻近小区BCCH频点描述）
DL: SYSTEM INFORMATION TYPE 6：CI，LAI，小区参数设置
UL: MEASUREMENT REPORT
DL:Handover Command
DL:Physical Information
UL:Handover Complete(切换成功的标志)
DL:Physical Information
DL: SYSTEM INFORMATION TYPE 6
UL: MEASUREMENT REPORT
DL:Disconnect（收到该条消息或Release中的任何一条，则视为正常释放，如果两条消息均未收到，而是直接收到System Information Type1，则视为一次掉话）
UL:Release
DL:Release Complete
DL:Channel Release
UL:Release Complete
2.2一次正常的LAR&RAU信令流程：
Direction
Type
Layer 3 Message
UL
RR
Channel Request
DL
RR
Immediate Assignment
UL
MM
Location Updating Request
UL
RR
Classmark Change
UL
RR
GPRS Suspension Request
DL
MM
Authentication Request
UL
MM
Authentication Response
DL
MM
Identity Request
UL
MM
Identity Respone
DL
MM
Location Updating accept
UL
MM
TMSI Realocation Complete
DL
RR
Channel Release
UL
GPRS MM
Routing Area Update Request

UL
RR
Channel Request
DL
RR
Immediate Assignment
DL
GPRS MM
Routing Area Update Accept
UL
GPRS MM
Routing Area Update Complete
2.3 各种情况对应的信令
² 掉话（既没有Disconnect，也没有Release，则视为掉话）： Paging Request→Channel Request→Immediate Assignment→CM Service Request→CM Service Accept→Setup→Assignment Command→Assignment Complete→Connect/Alerting→System Information Type1
² 通话正常结束(Disconnect和Release都有或只有其中一个都视为通话正常结束)：Paging Request→ChannelRequest→Immediate Assignment→CMService Request→CM Service Accept→Setup→Assignment Command→Assignment Complete→Alerting→Disconnect→Release→ReleaseComplete→Channel Release
² 呼叫失败： Paging Request→ChannelRequest→Immediate Assignment→CMService Request→System Information Type1（在一次呼叫过程中，若连续出现多个CM Service Request，则视为一次呼叫失败）
² 呼叫成功：Paging Request→ChannelRequest→Immediate Assignment→CMService Request→CM Service Accept→Setup→Assignment Command→Assignment Complete→Connect/Alerting
² 切换成功：Handover Command→HandoverComplete
² 切换失败：Handover Command→HandoverFailure
2.4常见Disconnect / Release Cause Value:
Cause Value
Reason
31
BSS or MSC problem
34(beforeAssignmentCommand)
TCH Blocking
34(after Assignment Complete)
MSC Blocking
41(after Assignment Command)
BSS problem, especially DRI problem
41(after Assignment Complete)
MSC problem
42
MSC Congestion
44
BSS problem, especially the CIC blocking

111
BSS or MSC problem
2.5 两个MS通话的流程
MS1 Uplink Channel Request
MS1 Downlink Immediate Assignment
MS1 Uplink CM Service Request
MS1 Downlink CM Service Accept SDCCH分配成功
MS1 Uplink Setup
MS1 Downlink Call Proceeding
MS1 Downlink Assignment Command
MS1 Uplink Assignment Complete TCH分配成功
MS2 Uplink Channel Request
MS2 Downlink Immediate Assignment
MS2 Uplink Paging Response SDCCH分配成功
MS2 Downlink Setup
MS2 Uplink Call Confirmed
MS2 Downlink Assignment Command
MS2 Uplink Assignment Complete TCH分配成功
MS2 Uplink Alerting
MS1 Downlink Alerting
MS2 Uplink Connect
MS2 Downlink Connect Acknowledge
MS1 Downlink Connect
MS1 Uplink Connect Acknowledge
MS1 Uplink Disconnect
MS1 Downlink Release
MS1 Uplink Release Complete
MS2 Downlink Disconnect
MS2 Uplink Release
MS1 Downlink Channel Release
MS2 Downlink Release Complete
MS2 Downlink Channel Release

3. 案例介绍
3.1 MS呼叫未接通：
问题描述: 在做DT测试过程中发生了一次未接通，地点是LAC区交接处.在DT测试的行程中，可能发生数次跨LAC区的切换，极易发生掉话或未接通情况。主要有以下三条信令消息：
UL：CHANNEL REQUEST
DL：IMMEDIATE ASSIGNMENT
UL：CM SERVICE REQUEST
问题分析: (1)在上行的CM SERVICE REQUEST信令发出后，没有下行的响应，通话状态由起呼直接转为空闲模式（IDLE），由此可以断定发生了一次未接通。由于上行UL：CM SERVICE REQUEST是MS发起的对SDCCH的申请，发出申请后没有应答，没有出现标志呼叫接通的信令消息，可以断定发生了一次未接通情况。其原因可能为该服务小区的SDCCH信道拥塞，也可能是由于无线环境的恶化造成SDCCH信令丢失。因为此次DT测试发生在跨数个LAC的路段，而且是上一个通话刚刚结束，起初判断可能是发生了一次位置更新。
(2) 位置更新信令消息如下：
DL：CHANNEL RELEASE
UL：CHANNEL REQUEST（开始位置更新）
DL：IMMEDIATE ASSIGNMENT
UL：LOCATION UPDATING REQUEST
DL：AUTHENTICATION REQUEST
UL：AUTHENTICATION RESPONSE
DL：LOCATION UPDATING ACCEPT
UL：TMSI REALLOCATION COMPLETE
DL：CHANNEL RELEASE
结合此例的第三层信令消息来看，例子中MS发出了UL：CM SERVICE REQUEST，并不是UL：LOCATION UPDATING REQUEST，由此可以判断出此例并非是位置更新。
3.2 位置更新导致数据吞吐量为0
问题描述: 在某路段,进行数据业务测试时,发现MS数据吞吐量变为0,没有了与GPRS网络的连接.
问题分析: (1) 在该路段进行语音业务测试, 确认已经完全覆盖.
(2) 分析当时数据业务测试的层3信令. 当时的信令为:
DL：SYSTEM INFORMATION TYPE 1 UL：LOCATION UPDATING REQUEST UL：CHANNEL REQUEST


(3) 对比在当时显示图的信令部分可以明显的看出该MS正在做位置更新.
3.3 FTP下载中断
问题描述: 在DT FTP下载测试中，MS已成功登陆FTP Server，并已经开始下载数据，FTP下载进度为9％，在经过一次小区重选后, FTP下载不能继续进行，在一系列的Ping fail后，FTP掉线.
问题分析: (1) 查看层三信令,具体显示如下：
Direction Type Layer 3 Message
UL GPRS SM Deactivate PDP Context Request
DL RR System Information Type 13
UL RR Channel Request
DL RR Immediate Assignment
DL GPRS SM Deactivate PDP Context Accept
发现在事件列表中有PDP Deactivated的消息，在层三消息中可以看到是手机发起的上行消息.
(2)发生这种情况可能有3种原因：
一是手机在测试过程中电缆的某个接口发生了松动，这样手机可能会发出PDP去激活申请。
二是手机本身存在一些问题也可能导致这个问题。
三是测试用的笔记本电脑可能存在一些问题
3.4 没有物理消息导致切换失败
问题描述: 某地主要由4173、4081小区覆盖，上述两个小区及相邻小区同属于LAC：13588。DT测试过程中，MS当前服务小区为4173，当检测到有Level 更强的邻区时，BSC指示MS切换（发起DL：HANDOVER COMMAND），此时发生了连续的三次切换失败（UL：HANDOVER FAILURE）。虽然本例中经历了连续三次切换失败，MS仍然没有掉话（MS还在发送测量报告），但是对连续的切换失败应该给予很大的重视。
问题分析: (1) 查看当时的层三信令, 具体如下:
DL：HANDOVER COMMAND UL：HANDOVERACCESS UL：HANDOVER COMPLETE UL：MEASUREMENTREPORT UL：HANDOVER FAILURE DL：SYSTEMINFORMATION TYPE 5
(2) 从切换的两个小区来看，4173向4081切换，是不同步切换，所以BSC应该在MS发出UL：HANDOVER ACCESS消息后，接着发出DL：PHYSICAL INFORMATION，指示MS切换至目标小区的Timing Advance，即MS与切换目标小区的距离。同时，在MS发出UL：HANDOVERCOMPLETE之后，再发一条DL：PHYSICALINFORMATION。
(3)但是在本例中BSC没有发出这两条消息，导致发生切换失败。

3.5 MS呼叫失败.
经检查信令发现有立即指派拒绝(immediate assignment reject)消息 系统发现无可用信道.很可能是因为系统拥塞引起的
3.6 参数设置错误导致切换问题
问题描述: 某次路测中发现手机每当起呼占用（BCCH：554，BSIC：52，LAC：9488，CI：29403），其只能一直切换到DCS1800网，通话过程中无法测量到GSM900的频点，一直不能向GSM900网切换，在测试时不单该小区自己本身不能测量到GSM900的频点，在本次通话过程中的所涉及的所有小区都不能测量到GSM900的频点，导致在该路段出现弱信号和质差最后导致掉话（虽然在CDD中该小区的MBCCHNO中有GSM900的频点）；
问题分析: (1) 在其他小区进行起呼测试,发现MS 切换到该小区后,则在该小区仍然能测量到GSM900的频点。切换正常；说明问题出在该小区。
(2) 经仔细检查路测试数据的第三层信息，发现在该小区起呼时，第三层信息没有出现 UL-CLASSMARKCHANGE这条信令且在该小区的SYSTEM INFORMATION TYPE3中发现 EARLY SENDING ：EXPLICITY FORBIDDEN，导致系统认为手机为1800单频手机；
(3)经检查BSC数据，发现该小区的ECSC 参数设为 NO，其它小区该参数设为 YES。通过调整该参数，问题得到解决。
3.7定时器超时， 网络进行呼叫释放
问题描述: 在天津进行静态测试， 发现MO呼叫30秒后自动中断，网络发送disc消息給MS，后面进行正常的拆除过程。MT呼叫时，MS可以看到incomingcall，连接后显示进入连接状态，但主叫端仍然只能听到提示音，不能进行正常通话。
问题分析: (1)MO过程如下
MS net
－－CM req--------------->
<---ciph cmd-----------
---ciph completed------->
---setup---------------->
<-----call proceding---
<------assignmend cmd----
-----assignmend complete-->
<---alerting-----------
<----connect-----------
--------connect ack---->

after 30s
<--------disc-------------
(2)因为connect ack是在FACCH上发送的，怀疑网络未能收到ack消息， 因为发送connect消息后，网络端将启动一个为期30秒的定时器等待MS的确认，出于某种原因，ack消息未能到达网络， 此定时器超时， 网络进行呼叫释放