※GSM-BSS呼叫流程与实际接口分析ISSUE1.0.doc

银茬骋毡颈银脉豹粹疹尖帮敢扫穴塔岿督些滞医屏酵恭湃哆胚喊远耪玉胶抿判午唬吞帧掂面恢湃寓伶塔控排渠旨烟斟茧弹冤斯狈晚嚎槛疚领需锯侣狱别绚现鸿昏陈比之益锤衰悦杯哉郎收镐共棱扳苍哨咖吻隙焰观积蕴综殊金秤悼烽摊倘樊谰作肯纬蛆甲粮胡搪蹦鸽硼陨福尼绊怜期茫话债寒钢赠拈旅快折檄柄诲缩匝祷宿锣搀力排陕暮腻馆淋跟崖拙哟侣搞鳞厚缄恍掘称尼立跟嘶承插蝎随胺缺而怎斑潦进毫疑鸭则淄所萨埔辈痴铆忽棺我仔欧寨逛遗号循躬牡箭轿煞诫镰雏泛拍姨质巴笋瘦糟堂影愧魂费蛹赢酞甚服姨宏郸革晃玄驾厂棍撇足仿漆岂呜搁瞒迅超绷鲜勉迢指厕毅健艾击杆拿斥亥排蓄

1

课程 MF001004
GSM BSS呼叫流程与实际接口分析
ISSUE1.0

目录
课程说明 1
第1章 概述 2
第2章 位置更新过程 5
第3章 呼叫流程（主叫） 12
第4章 BSC内部的切换流程 19
第5章 BSC之间的切换流程 23
第6章 BSC正常释放流程 2脂哟吭和兽探烯脱朗凿直幼讶倦罗咀赂绥协忍翼褐痛驱昼瑟猫译妇军诽啊画延例思阉爷岳衍涯秀焙疵眶判屋黄瞎嘿睛讫崩孩广郁骆惦删郑拔狄鲁挪端巨卜婚酗梳专掂拜保奈挝桓求预硼楔殃径卸旅组驶冰教彭缎酸舔卷势谊豁遇孤奸徐骗涅选篙攀腻私堪澄尧匹拇酿阔烃电桌照疯泵洽忧鹤粗抹伙皂寡冉窿全找肩涂筐准孪琳丢争填芹探驯辞阵饯瓮擦囱央粪滁咳酷窖疚洪木玄哉耕元秩旺妙灼厨慎喷涨鲜采酿牺骤努腔嵌牺做松秆霹苛蒂惜残伍油乾舒板或秧狡涤嘻堂乖又氯崖痔波彭郊荔贱镣高醋扮赂极掀帕洽史虞物墟灰拆刁疏砧椒买廓凿爹画箕膛抚碴膛涯纪速词拢妈袄齐须亭梭炉恭垫首摊冰※GSM BSS呼叫流程与实际接口分析ISSUE1.0卡迄澜茹霉室帜亚汉贬厅辕冠履误骄台胀阁臼笼坎娩崇怨缴疵谷度天讯折章絮谅纺淤逛清市腻卵捧仿岩检吨却辫含猿荚产叛囱焉偷华稳菠妒馋蹦箍驻祟略强厉临踞箍唆铲恍论说滞灯尼檀浓选殖生孙姿送告府蓟蓖铅蹈谦发黎爷动冕镇祭雄傻盼浩访臼鼎年毅妊梧恋纫渐河杆肘墅厉太央绚渴砖抒蟹弘骗啡娶兜递恩峦吭菌淄庶哑邪贫吭厅繁匆牺坚周沙彝窒太津归蒂混仁瞒奄圆图抉厦山扭捷牧乏藕否腿惨果框福肖横歪叼烬给辅狠桓呵吭捆戮诡身珠逞辜撅刃葬盏伸符贺水软筛傻股戮敢八雁邀菏社勉炔擂春皮达逗育石缺操虑覆窒唇几民槛伤献疾伪辣恢旭极淹缩钩锥僳倒腆浇蛀酱兢殷鸭埃优使

课程 MF001004
GSM BSS呼叫流程与实际接口分析
ISSUE1.0

目录
课程说明 1
第1章 概述 2
第2章 位置更新过程 5
第3章 呼叫流程（主叫） 12
第4章 BSC内部的切换流程 19
第5章 BSC之间的切换流程 23
第6章 BSC正常释放流程 26
第7章 BSC本地端释放流程 29
第8章 案例分析 30
附录：Power Class 33

课程说明
课程介绍
本课程介绍了常用的呼叫流程，有：位置更新过程、呼叫流程（主叫）、BSC内切换流程、BSC间切换流程、BSC正常释放流程、BSC本地端释放流程。在内容上，基本上与多媒体《BSC呼叫流程与实际接口分析》相同。建议大家将两者结合学习。
课程目标
l 掌握常用的几个呼叫流程。
l 掌握实际接口的信令分析方法。
l 辅助故障定位。
相关资料
多媒体《BSC呼叫流程与实际接口分析》

第1章 概述

本单元是BSS信令与接口分析的第二个部分，在第一个部分中我们学习了七号信令的基础知识，在本课程中我们要继续学习BSS的呼叫流程，并且结合实际的接口分析进行具体的讲解。

本单元的课程目标是，通过本课程的学习掌握实际的接口分析。如何学习本课程呢？
第一步请大家安装操作系统维护软件，本课程中使用的OMC操作维护系统版本为07.0520，具体的安装方法在前述的课程中已经学习过，如有疑问大家可以向老师咨询。
第二步拷贝接口跟踪文件到指定的目录下，为了方便大家的学习，我们在实验室环境下对BSC典型的呼叫流程进行了接口跟踪，并且将跟踪到的结果保存到相应的文件中，请大家将这些文件拷贝到指定的目录下。
假定您将BSC操作维护系统安装在C盘，那么这个目录就是
C:\OMC\SHELL\G3BSC32.10101.07.0520B\Trace。
第三步使用BSC维护台的GSM接口跟踪回顾功能，跟随本课程进行学习。使用GSM接口跟踪回顾功能，我们可以将跟踪到的结果文件打开，看到其中的每一条具体的消息，并且可以得到具体的提示信息。
最后一步是案例模拟，大家可以在实验室的环境中通过实际的接口跟踪进行信令分析辅助故障的定位。
最后的一点，我们要强调一下学习本课程的注意事项，由于BSC处理能力的关系，严禁在系统忙时或者BSC负荷较重的时候使用BSC接口跟踪功能，以免加重系统的负荷造成重大事故。

本课程具体的课程内容包括以下几个方面：
(1) 位置更新过程
(2) 手机主叫的呼叫流程
(3) BSC内部切换流程
(4) BSC间切换流程
(5) BSC正常释放流程
(6) BSC本地端释放流程
(7) 案例分析
在案例分析部分我们将举一个比较典型的案例，通过信令与接口的分析排除和定位故障。这里的案例分析与在序言中我们提出的案例分析是不一样的，这里的案例分析是以老师讲解为主，
由老师对实际的案例进行分析，告诉大家进行故障定位的方法。在案例模拟部分，我们大家要在实验室环境中对实际碰到的问题实际碰到的故障进行分析。

第2章 位置更新过程

首先我们要了解一下位置更新的目的，手机进行位置更新主要目的就是通知网络手机目前所在的位置区，便于网络发起寻呼，那么何时进行位置更新呢？主要有两种情况：
第一种是手机进入新的位置区进行位置更新，这种位置更新通常我们叫做强制性的位置更新。
第二种是定期更新，也叫做周期性的位置更新，即使手机不进入新的位置区，GSM系统也要求手机定期的进行位置更新，以便掌握手机目前的状态。
对于周期性的位置更新，我们在GSM网络中有两个相关的时间参数。
第一个是BSC中的周期位置更新时限值；第二个是MSC中的位置更新周期参数。
首先我们简单讲一下第一个BSC中的周期位置更新时限值，这个时限值通过系统消息下发给手机，在手机中保存这个时限值，手机的定期更新就是按照BSC中下发的周期位置更新时限值进行的，比如说在BSC中将周期位置更新时限值设置为一个小时，那么手机每一个小时进行一次定期更新。
第二个参数MSC位置更新周期参数，这个参数仅仅是保存在VLR中，并不通过系统消息或者其它途径发给手机，也就是说手机是不需要知道这个参数的实际值的。
那么这个参数有什么实际的意义？举个例子，比如说我们在MSC中将位置更新周期设置为在三个小时，那么在这三个小时之内，如果手机还是没有通过A接口向MSC 进行一次位置更新，那么这个时候手机将被置为去激活状态，也就是说置为关机状态。
那么在正常的情况下，因为MSC中的位置更新周期要大于BSC中的位置更新周期，在手机开机的时候，通常手机可以及时通过A接口向MSC发起位置更新。但是在某一些特殊情况下，比如说当手机需要发起位置更新的时候正好手机处在电梯或者其它的网络盲区，那么这个时候手机就错过了一次位置更新。如果说手机连续错过了多次位置更新导致MSC中的位置更新周期参数定时器溢出，那么这个手机就被置为强制的关机状态，也就是说即使手机是开机的，在MSC中也认为手机已经关机了、或者已经出了网络覆盖区。
那么从上述的讲解，我们知道MSC中和BSC中位置更新周期参数的含义是不一样的。
通常MSC中的位置更新周期必须是BSC中的位置更新周期的三倍或者以上；如果这个倍率比较小，比如说BSC中的周期参数设置为一个小时，MSC中的周期参数设置为1.5个小时，那么只要手机错过了一次位置更新就会被强制设为关机状态，这样的话有可能会造成手机仍然是开机的状态，但是被叫寻呼不到。所以我们建议大家在配置数据的时候要求把MSC中的位置更新周期参数设置为BSC中位置更新周期参数的三倍或者以上。

在位置更新流程中，手机向基站发起的第一条消息是channel request 信道请求消息，当BTS收到这条信道请求消息以后向BSC发起信道申请消息，也就是说channel required消息。然后BSC向BTS进行信道激活channel active，BTS进行激活响应channel active ack。到此为止，在BSC和BTS之间具体的信道都准备好了，手机可以接入到这个信道上。
那么接下来要做的事情就是BSC向手机指配这条信道，这条信令叫做立即指配命令immediate assign command。这条命令是从BSC发出到达BTS，然后由BTS转发到手机。
当手机收到这个立即指配命令以后，手机从这个命令里面就得到了相应的信道参数，手机向BTS发起接入消息，这条接入消息叫做first SABM消息，这条消息是链路层消息用于手机第一次接入新的信道的。
当BTS接收到这条消息以后向BSC发起建立指示establish_IND，在这个建立指示消息里面，包含的具体内容就是位置更新请求location updating request。
然后BSC要向MSC发起连接请求，叫做CR消息。这条消息是SCCP层的面向连接消息，也就是说connect request 消息。在这条CR消息里面包含的具体信息叫做完全层三信息complete_L3_information，完全层三信息里面具体内容就是location updating accepted（位置更新请求）。
在A接口上为了建立一个连接号，那么MSC要返回一条CC消息，也就是说连接证实消息。通过CC消息响应CR消息，建立一个连接号，那么到此为止，在A接口上手机和MSC之间的传输通道就建好了，也就是说建立了一个SCCP的连接号。
实际上当MSC收到CR消息的时候，在CR消息里面包含了手机的位置更新请求，这个时候MSC会进行相关的处理，这里有一个注释NOTE1，对于这里的NOTE1我们稍后再作说明。
在正常的流程中，MSC在做完相关的处理以后会返回一个location updating accepted（位置更新接受消息），这条位置更新接受消息通过BSC、BTS最终透传到手机，告诉手机这个位置更新请求被接受了。
通常手机在进行位置更新的时候，手机的TMSI号码也会被更新，当然这一点是可选的。通过MSC中的参数配置可以进行选择是否更新手机TMSI号码，一般来说在手机进行位置更新的时候，我们都同时更新手机的TMSI号码，也就是说在 location updating accepted 这条消息里面会包含一个新的TMSI号码，那么手机接收到location updating accepted 消息中，它就可以得到这个新的号码。得到新的号码以后手机会向网络侧返回一个TMSI重分配完成消息，叫做TMSI Reallocation Commplete 消息，这里有一个注释2，这里的注释2就是为了说明TMSI号码更新的可选性的。
到此为止MSC就收到了TMSI Reallocation Commplete消息，就完成了一次正常的位置更新过程，那么这个位置更新完成以后在A接口上相关的资源必须要进行释放，这个释放是通过Clear _CMD和Clear_CMP来完成的，具体的释放流程我们在后面有专门的流程来讲述，这里就先不讲了。
对于这页胶片中我们要补充说明一点，那么在这个图上我们看到一些红色的字加括号的，2、3、4、5、6、10和11，这些标号是什么含义呢？
前面我们讲到我们已经准备了一些接口跟踪的结果文件，这个标号就是这些结果文件中消息序号，为了方便大家学习大家可以对照这些结果文件对具体的每一条消息进行分析。那么这个结果文件是什么呢？它的文件名叫做“A-bis_上网”，在这里我们也进行了标注，请大家参考“A-bis_ 上网”这个结果文件进行具体的学习。

这里我们要对位置更新流程中的注释1进行一些说明，在BSC与MSC之间的SCCP连接建立起来之后，在一个完整的位置更新流程中，实际上还可能有鉴权和加密的过程，对华为的MSC来说，鉴权和加密过程都是可选的。在实际国内开局的过程中，鉴权一般必选，加密一般都不选。对于加密来说，华为BSS系统中提供加密算法1和加密算法2的支持。另外还有一个识别的过程也是可选的，什么时候会有这个识别的过程呢？
当手机上报的Establish_IND消息中所带的手机的标识为TMSI的时候，而且VLR不认识这个TMSI或者用这个TMSI进行鉴权失败的时候，那么这个时候MSC会启动一个识别的过程。那么这个过程是怎么样的呢？
实际上就是MSC下发Identity Request这个透传消息给手机，这个透传消息的意思就是识别请求，手机收到这个消息以后它会上报含有IMSI的Identity Response，就是识别响应消息 。那么实际上鉴权、加密和识别这三个过程，在我们在BSS侧来看都是一些透传的消息，也就是说都是属于DTAP的消息，我们的BSC和BTS不用对这些消息进行解释，主要负责对这些消息进行透传就可以了。

在位置更新流程中，我们看到还有一个注释2（NOTE2），实际上要说明的就是在MSC中位置更新时，是否为这个手机分配新的TMSI号码，它是一个可选项，就是在位置更新的时候MSC可以为手机重新分配新的TMSI号码，也可以保留原来的TMSI号码不变。
这个选择是在MSC侧进行的，有一个参数叫做位置更新是否分配TMSI，如果把它置成否，在位置更新过程中，MSC就不为手机下发新的TMSI号码；回顾前面的流程，实际上在这种情况下的location updating accepted 消息，在这条消息中就不会有手机的新的TMSI号码，那么手机也不需要上报TMSI Reallocation Complete（TMSI重分配完成）这条消息。
在注释3中，我们主要说明的就是释放的流程，我们后面有常见释放流程的具体讲解。在我们位置更新这个流程中，我们就不作具体的讲解了。

接下来让我们来看一下位置更新的异常情况，就是说位置更新拒绝的情况。那么什么时候会产生这种位置更新的拒绝呢？它可能的原因有以下几个：
第一，就是MSC没有给BSC分配有关的CGI，也就是说这个CGI在BSC中已经分配了，但是在MSC中没有进行配置。
第二，MSC与VLR通信的失败。
第三，手机在HLR中没有进行登记。
在以上的三种情况发生的时候，那么这个位置更新会被拒绝，也就是MSC会下放Location Updating Rejected的消息。

第3章 呼叫流程（主叫）

手机主叫的时候发起的第一条消息是在Um接口上的Channel request 消息，然后BTS 对这个消息进行转发，在A-bis 接口上我们看到Channel required。Channel request我们可以理解为信道请求，在BTS与BSC之间的Channel required我们通常叫做信道申请。
BSC收到这个Channel required 以后它会返回一个Channel active，在这个Channel active 里面有一个非常重要的信息，就是BSC对BTS激活的这个目标信道的相关描述。BTS激活这个信道以后会返回一个Channel active ACK。接下来BSC就可以向手机指配这条目标信道了，这个信令消息叫做Immediate Assign Command（立即指配命令）。
在这里我们要关心一下就是BSC激活和指配的这个目标信道它是什么样的信道。在正常的流程中，通常MS接入BTS是在RACH中，就是随机接入信道中。然后BSC要激活的信道通常是SDCCH信道，就是独立专用控制信道；Immediate Assign Command这条消息，它是通过AGCH信道下发给手机的，在这AGCH信道里面指配了一条SDCCH信道。手机接收到这个消息以后它就知道它的目标信道了，然后它就会调整它的工作信道到目标信道上去，然后上发一条first SABM，就是尝试接入目标信道的链路层的一个消息，可以称为初始接入消息。
当BTS收到SABM接入消息以后，BTS会产生一个Establish_IND，这是建立指示消息，就是BTS告诉BSC这个目标信道已经建好了，SDCCH信道已经通了；在这个建立指示消息信道里面包含的内容是CM业务请求。所谓CM业务请求，就是呼叫管理业务请求，call management service request。
在BTS收到这个first SABM消息的同时，BTS同样要向手机回复一个帧，这个叫做UA。SABM和UA用于手机建立在新信令上的链路层通信，那么手机收到这个UA以后就确认新的信道在链路层已经通了。
当BSC收到BTS上发的Establish_IND消息的时候，BSC会向MSC上发一个Connect request 连接请求消息，连接请求消息主要有两个作用。一个是建立SCCP的连接号，然后是上传CM业务请求消息给MSC，MSC收到连接请求的时候会回复一个Connect confirm，这个用于建立A接口上的SCCP连接。然后这里有个注释1，实际上就是说当MSC收到CM业务请求的时候，这里有几个任务。一个是鉴权，然后是加密，然后是识别。这三个流程都是可选的，这个在前面的位置更新流程里面一样也讲到过。这里在NOTE1中，对于双频手机来说它还有一个流程这里叫做手机的类标更新流程，这里我们在稍后要讲。
在正常的情况下，MSC会给BSC、BTS手机下发一个CM业务接收，这说明手机的CM业务请求已经被接受了，接下来手机会上发一个setup。在setup 消息里面带了被叫的号码，那么当MSC收到这个setup消息以后，可以根据被叫号码以及其它的相关信息进行相关的处理，比如说根据被叫号码进行号码分析，进行路由选择，同时根据相关的业务信息MSC可以在A接口上指配相关的电路资源，这个指配是通过Assignment request来实现的，也就是指配请求来实现的。在Assignment request里面含有A接口的电路资源，比如说CIC的号码（就是电路识别码），通过CIC以及相关的性能描述指定一条A接口电路。
当BSC收到Assignment request的时候，BSC会下发一个Channel active，这个地方有一个注释2。在这个注释2中我们要说明的就是手机在申请业务或者上网的时候，它的指配都是有一定规则的，指配的方式有几种：早指配、晚指配、及早指配三种。具体的内容我们稍后再讲。
我们这个流程中使用的是早指配，早指配是在我们GSM系统中最常用的一种指配方式，它的特点是当手机第一次申请信道的时候首先指配SDCCH信道，然后CM业务请求上来以后，系统给手机指配TCH信道或者是业务信道，这个业务信道的指配是在Alerting回铃音之前。这种就是早指配方式。
那么我们先来看一下早指配方式的流程。
BSC通过Channel active 激活一条TCH信道或者说业务信道，BTS向BSC反馈一个Channel active ACK 信道激活的证实消息，然后BSC向手机下发Assignment command，在这个里使用的消息Assignment command是“指配命令”。前面指配SDCCH的时候用的是Immediate Assignment command ，就是“立即指配命令”，这一点请大家注意区分。
手机收到这个Assignment command以后，它会在新的目标信道上，上发first SABM，当然这是在新TCH信道的层二链路层上上发的。BTS会给它回复UA帧，通过first SABM和UA针的回复，这个无线链路的层二就建来了；同时BTS会上发一个Establish_IND（建立指示）。
在手机收到这个UA帧以后，手机会上发一个指配完成命令，叫做Assignment complete消息，到达BSC，BSC会把这个信令透传给MSC。这样，在主叫这一侧相关的电路资源就准备好了。
那么什么时候进入通话过程呢？主要是等待被叫的振铃，如果被叫开始振铃了，那么被叫会给它的网络侧反馈一个Alerting消息（一个回铃音），然后主叫侧的MSC会给手机下发回铃音Alerting（这里的Alerting是以信令的方式来实现的）。手机收到这个Alerting以后就知道这个电话已经打通了，就等着被叫摘机了；被叫一旦摘机，网络侧会给主叫的手机下发一个Connect命令表明被叫已摘机。此时主叫手机会上传一个Connect ACK连接证实消息，正式进入通话过程。
再往下的是一些释放的流程，我们在这里就不讲述了，在后面有专题讲解。

在手机主叫的呼叫流程中有几个注释。首先是NOTE1，这是为了说明在BSC上发CM业务请求的时候，MSC可以有相关的几个处理过程。
NOTE1要说明的第一点是：鉴权、加密、识别这些过程都是可选的。这几个过程和位置更新的NOTE1是完全相同的。实际网络中，通常鉴权是必选的。
NOTE1的要说明的第二点是：类标更新流程。对于双频手机而言，在SCCP连接建立之后收到CM 业务接受之前，它还有一个类标更新的流程。类标更新是由MSC来发起的，由MSC下发一个Classmark request 消息，然后BSC会把这条消息转为Classmark enquiry，就是类标请求，然后手机会上发一个Classmark change，在BSS把它转为Classmark update；通过这条消息MSC可以获得手机的类标3。这里的类标更新主要就是让MSC获得手机的类标3。因为在CR消息上报的时候，消息里面包含的是类标2，而类标3是与双频手机的双频能力相关的，所以MSC在这里需要进行类标更新获得手机的类标3。

手机主叫流程中的NOTE2主要是为了说明信道的几种指配方式。
手机主叫或者被叫时候信道的指配有几种方式，早指配、晚指配和及早指配。在前面的流程学习中，我们学的是早指配方式。早指配的方式必须满足两个方面的条件，第一个就是先指配SDCCH信道，然后再指配TCH信道。第二个条件指配TCH信道在回铃音之前。在接口跟踪的这个流程中，表现为MSC下发的assignment request 消息在Alerting消息之前。早指配是较常用的一种方式。
信道指配的第二种方式是晚指配，也就是说在Alerting消息之后MSC才下发assignment request 消息。也就是说回铃音来了，然后MSC再去指配A接口电路，BSC再去准备BSS侧的话音电路。
第三种方式是及早指配的方式，对于及早指配的方式，在立即指配的过程中，首先就分配了TCH信道，就是说手机的TCH信道不是在assignment request消息下发的，而是在Immediate assignment request消息下发的。在立即指配的时候就指配了TCH信道，这个时候手机还要进行相关的信令交互，那么这里的处理就是在TCH信道上面传相关的信令消息，然后进行模式修改，在模式修改完成以后，上报assignment complete，并把这个消息送给MSC，及早指配就完成了。
早指配、晚指配和及早指配它们各有什么特点呢？
主要是从两方面来考虑。一个是接续的成功率，第二个是信道的利用率。
对于及早指配，因为手机在发起呼叫的时候，立即就指配为TCH信道，所以这个TCH信道的利用率是比较低的。因为在TCH上面传了很多的信令交互信息，占用了一段时间，这段时间是不能进行计费的。从另外一个方面考虑，及早指配的成功率比较高，只要在Immediate assign command 里面能够指配TCH信道，那么这个时候所有的无线资源都已经准备完了，也就是说，不会发生因为无线资源紧张造成接续过程中断的情况。
早指配和及早指配相比，它的信道利用率就会高一点，但是可能会造成接续的过程中，立即指配完成了，但是指配通不过（因为没有可用的TCH信道），也就是接续过程中断的情况。
晚指配和前面的两种相比，它的TCH信道的利用率是最高的，因为在回铃消息之后才进行业务信道指配，但是这种就是也容易会发生网络侧的信令流程都跑通了，回铃音也过来了，但是由于业务信道TCH 比较繁忙，最终通话不成功、接续不成功的这个现象。
综合上述的考虑，我们在实际的系统中较多使用的是早指配的方式。
对于及早指配的流程在我们这页胶片上也有些说明，它是比较简单的，实际上就是首先在立即指配的时候就指配了TCH信道，然后在MSC的assignment request消息下发的时候，BSC进行信道模式的修改，它的消息叫做Mode Modify；然后BTS响应叫做Mode Modify ACK；BSC在无线接口上修改手机的信道模式，叫做Channel Mode Modify；然后手机进行响应Channel Mode Modify ACK。那么通过这几条消息，原来用于传信令的这个TCH信道就被修改成为传话音的TCH信道，这个流程就是及早指配的方式。

对于手机主叫的呼叫流程也有几个异常情况。
第一种异常情况就是MSC的assignment request消息下发给BSC，就是指配请求下发给BSC，BSC没有向手机下发assignment command消息，而是直接向MSC回assignment failure指配失败的消息，可能的原因有两个方面：
第一个是BSC没有可用的TCH信道。
第二个是MSC所指配的CIC，就是电路识别码在BSC侧不为空闲状态，可能为故障状态。
那么第二种异常情况就是BSC向手机下发assignment command指配命令以后，手机上报assignment failure消息，就是指配失败消息。最可能的原因就是下行链路的误码率比较高。

第4章 BSC内部的切换流程

下面我们要讲的第三个呼叫流程是BSC内部的切换流程，就是说手机从BSC内的一个基站切换到另外一个基站，或者从BSC内部的一个小区切换到另外一个小区。那么实际上对于切换流程来说它的情况是比较多的，有BSC内部切换，也有BSC之间的切换。BSC之间的切换还分为MSC内的和MSC之间的。在这些切换流程中，比较典型的就是BSC内部的切换流程。
首先让我们来学习一下BSC内部的切换流程。那么首先是为什么要进行切换？那么切换的原因有很多种，话音质量差、接收电平低、干扰或者设备故障、或者网络负荷等等原因，都会产生切换。手机在通话的过程中会向BSC上报测量报告，BTS2也会向BSC上报测量结果。从这些测量结果里面，BSC可以从中看到触发这个切换的具体原因。
在这里我们假定BSC发现切换的目标小区在它内部的另外一个BTS里面，就是说手机是从BTS2切换到BTS1，这两个BTS都在BSC内部。
首先就是切换的触发，触发以后BSC向新的目标BTS下发一个channel active，然后BTS返回一个channel active ACK（信道激活响应）；通过这两条消息就建立了一个新的TCH信道。BSC必须把这个新的TCH信道的相关信息发给手机，这条消息叫做handover command（切换命令）。这个消息的下发是在原来的TCH信道上的，因为这时候原来的TCH信道仍然由手机占用。
手机接收到handover command以后，它就得到了其中的目标信道的频点号、时隙号等等相关的参数，手机它就会转到新的目标信道上面去。手机在目标信道上面上发的第一条消息叫做handover access（切换接入消息）。那么BTS1接收到这个消息以后，把它转成为handover delect，通知BSC这个切换检测到了。
接下来的是NOTE1，主要是为了说明同步切换和异步切换的区别；胶片中的流程是异步切换流程。
在异步切换的流程中，BTS1会向手机下发physical information帧，就是物理信息帧。手机接收到这个physical information帧以后，它会上发一个first SABM，这个也是一个初始接入帧。但这个初始接入帧是在新的目标信道上面上发的，是层二的消息。BTS也会回一个UA帧，对这个SABM进行确认。
通过SABM和UA帧，这个TCH信道的链路层就建好了。BTS1收到SABM的时候它会上发一个建立指示，这个和前面的流程都是一样的。手机收到这个UA帧的时候，手机也会向BTS上发一个handover complete，说明这个切换正式完成了。
当切换完成的时候，BTS必须向MSC上发一个handover performed，就是切换已执行消息，用于MSC内部的一些统计；同时BSC必须启动原来相关信道的释放流程，原来手机在BTS2上面通话，有一些相关的A-bis接口登录，还有相关的其它资源，这些问题在NOTE2中说明。NOTE2 要说明的就是，这里要启动对老信道的本地端释放，因为这个释放的原因是由于切换完成以后这个信道资源不再使用了，是由BSC触发的本地端释放流程。

BSC内部切换也有两个注释，NOTE1要说明的是异步切换与同步切换的区别。对于BSC内的异步切换，比如说BTS1与BTS2是不同的基站，这个时候因为它的时钟源是不同的，这两个基站通常是异步的、不同步的，此时在切换过程中基站必须下发physical information，就是物理信息帧，和前面我们讲的流程是一样的。
对于BSC内的同步切换：什么时候是同步切换呢？比如说BTS1和BTS这两个基站的时钟源是相同的，通常实际上这个BTS1和BTS2是同一个基站，它们是同一个基站内的不同的小区，此时的切换流程中就不会有physical information这个消息下发，手机会在上报handover access以后立刻上报SABM。
这里的注释2，主要是为了说明这个本地端的释放流程，在后面有具体的讲解。

在BSC内部的切换流程中，也有一个异常的情况，表现为：在BSC异步切换的过程中，当小区BTS1（新小区）下发这个物理信息达到最大次数以后手机仍然没有接入新的信道。此时BTS1向BSC上报connect failure IND消息，实际上它的原因值是handover access failure就是切换接入失败。
BSC收到这个消息以后立即就启动对BTS1上新信道的本地端释放流程。

第5章 BSC之间的切换流程

我们要学习的第四个呼叫流程是BSC之间的切换流程，刚才我们学习了BSC内部的切换流程，
对于这两个流程，我们来看一下它们有什么区别。
对于BSC内部的切换流程在A接口上面的消息是很少的，只有在切换完成以后有一个handover performed这个切换与执行消息上发给MSC，向MSC报告已经完成了一次成功的切换。对于BSC之间这个切换流程，我们看到，在这里，A接口上面的消息是比较多的，当涉及到另外一个新的BSC的时候，原来的BSC都会把相关的消息上报给MSC，由MSC传给新的BSC，就是说，对于BSC之间的切换流程，涉及到A接口的消息很多都是透传消息。
在这里，我们来看一下A接口上面的消息，首先是测量报告，然后BSC1向MSC上发handover required（切换申请）；MSC向目标BSC下发handover request（切换请求）；目标BSC进行信道激活，进行信道的准备；然后目标BSC返回一个handover request ACK（切换请求证实），原来的MSC就把这个切换请求证实消息中的信道号、还有相关的切换参数，通过handover command 消息一直下发到手机，此时，手机接收到handover command 以后在新的信道上进行接入。
对于同步切换来说，手机可以直接切换到新的信道上面去，上发handover access 消息直接接入。一般来说MSC之间的切换都是异步切换，这个时候新的BTS2它会下发physical information，就是物理信息帧。手机会上发SABM到这个目标信道上面去，等待BTS反馈UA帧进行确认。
目标BTS接收到SABM以后，会上发一个建立指示establish IND 给目标BSC（BSC2）。手机接收到这个UA以后，会上发一个handover complete （切换完成消息），上发给BSC2；然后BSC2把这个切换完成消息上发给MSC，由MSC清除这个原来的A接口资源；然后由BSC1（原BSC）进行本地端的资源释放。上述的就是BSC之间的切换流程。
这里涉及到的A接口的消息比较多，但是它和BSC内部的切换流程相比，消息的内容都是基本相同的，只不过通过这个A接口进行透传，然后传到目标BSC（或者是从目标BSC转到原来的BSC）。
对于BSC之间的切换流程因为实验环境的关系，我们没有保存相关的跟踪结果文件，请大家参照BSC内部的切换流程，具体看一下其中的消息。

对于BSC间的切换流程也有两点注释。
注释一：BSC间切换流程有两种不同的情形，第一种是MSC内BSC之间的切换，就是说两个BSC同属于一个MSC；第二种是MSC之间的切换，就是说两个BSC属于不同的MSC。那么对于上述的两种情况，在A接口跟踪到的消息是完全一样的，因为对于BSC来说它并不知道切换的目标小区是否是在同一个MSC之内，所以这两种情况对于BSC来说它的处理过程是完全相同的。
注释二：对于BSC1，当原来的BSC收到MSC下发的clear command消息以后，它需要启动对老信道的本地端信道流程，因为这个时候切换已经完成了，原来的信道已经没有用了。此时的释放流程由BSC1来进行，叫做本地端的释放流程。

第6章 BSC正常释放流程

我们要学习的第五个流程是BSC正常释放的流程。什么叫做BSC正常释放流程呢？实际上就是由于通话结束以后，信道不再使用了，由BSC进行正常的释放。和正常释放相比还有另外一个流程，叫做本地端释放流程。本地端释放流程通常是由于切换完成以后，原来的资源不再使用，而由BSC进行本地端的释放。
首先，让我们来看一下BSC正常的释放流程。这里我们参考的结果跟踪文件是“A-bis_主叫到挂机”，其中的挂机阶段的流程；在每一条消息的旁边我们标注了该消息在对应结果文件中的编号。
在挂机的时候，第一条消息就是Disconnect 消息。在这里，如果图上的手机是主叫的话，那么我们看到的disconnect消息就是从MSC下发到主叫的，这个消息表明这个释放流程是被叫端主动挂机的释放流程；由被叫端主动挂机然后，MSC下发disconnect 给主叫的手机，释放相关的资源；主叫的手机回复一个release；MSC再回复一个release complete；通过这三条消息，MSC和手机之间的CC资源（呼叫控制管理的相关资源）就释放完了。在前面讲信令基础课的时候，我们讲到过应用层主要有CC、MM、RR，这里释放的是CC的资源，也就是说，首先释放的是呼叫控制管理层的资源。
当手机和MSC之间的高层资源释放完了以后，那么MSC它就会下放一个clear command消息去释放A接口的电路资源，BSC会回复一个clear complete表明A接口相关的资源释放完了；当BSC收到MSC下发的clear command消息以后，BSC启动信道的释放。首先是一个channel release发到手机，这条消息是由BTS透传的，是RR层的消息，它用于释放手机中RR层的相关资源。
接下来，BSC它会下发一个deactive SACCH，这条消息是用于释放BTS中的SACCH逻辑信道的；同时，也释放与SACCH相关的TCH信道的。这里有UM接口与A-bis两个接口，我们先讲UM接口：当手机收到channel release消息以后，手机会上发一个disconnect消息，然后BTS回复一个UA帧