MS被叫过程分析

一.查询过程

当主叫端信令链路建立起来之后，主叫端将把初始化地址消息（IAI）发送给其关口局MSC（GMSC），因为在该IAI消息中含有被叫用户的MSISDN，GMSC就可以根据其MSISDN号码分析出其被叫归属HLR的七号信令识别号，于是GMSC就可向该HLR发出一条送路由消息（SEND_ROUTING_INFORMATION）的报文，HLR收到该消息后，将检查用户的记录，然后根据记录内容采取不同的步骤并给GMSC相应的应答。

其一：在正常的情况下，HLR在这时只知道该用户目前所在VLR的部分识别号（如CCS7地址或通用的标志）。为了能使该呼叫获得到达该MSC的最终路由信息，HLR将向被访VLR发送一条提供漫游号码（PROVIDE ROAMING_ NUMBER）的报文，该报文中含有用户的IMSI等信息，来请求VLR给该次呼叫提供一个MSRN号码，当被访MSC/VLR收到此消息后，将从空闲号码中选择出一个漫游号码，并将其同IMSI临时联系起来，并通过回送漫游号码结果（PROVIDE_ROAMING_NUMBER_RESULT)的报文将分配给该次呼叫的MSRN号码发换给HLR作为应答。当HLR收到被访的VLR提供的MSRN后，将以一条回送路由信息结果（SEND_ROUTING_INFORMATION_RESULT）的报文将消息转到发起呼叫的GMSC。此时GMSC就可以通过获得的MSRN号作为地址来找到被访的VLR并向其发送初始化地址消息IAI，当被访MSC收到该消息后可通过MSRN从其存储器记录中中恢复该移动用户的IMSI，来进行寻呼该移动台的过程。当呼叫完全建立起来后，就可以释放该漫游号码以供其它用户所使用。

其二：通过被叫VLR发回的消息指示，若被叫用户记录被设置为闭锁全部来话（BAIC）或闭锁漫游情况下的来话（BIC_roam）且目前该用户正处于漫游中。此时HLR将对该呼叫进行处理（放相关录音等）。

其三：用户记录被设为无条件前转（CFU），HLR将该转移号码发回到原GMSC再由GMSC分析此号码来重新定义路由。

其四：当该呼叫不可及即没有该用户目前所在的VLR号码，而且又没有设置呼叫前转，此时将给GMSC发回出错的消息（ERROR）。

二.寻呼过程

当被叫MSC收到GMSC发来的IAI消息后，将向其VLR发送一条入局呼叫消息（SEND_INFO_I/C_CALL）,VLR在收到该消息后，来分析被叫的号码（在VLR中有各种号码分类的信息，它会检查看是否有指向该号码的能力）和网络本身的资源能力等等来核对是否能接纳这种需求，若某些项目不能通过将通知主叫端呼叫建立失败。在正常的情况下VLR将向MSC发送寻呼（PAGING）的MAP消息，该消息中含有该移动台所在的位置区（LAI）以及被寻呼用户的IMSI或TMSI的号码，来通知MSC开始执行寻呼该移动台的过程。

 

当MSC从VLR中获得移动台目前所处的位置区后，将向这一位置区中的所有BSC发出寻呼（PAGING）的报文，该报文中含有寻呼所需的必须发寻呼消息的小区列表及TMSI和IMSI信息，其中IMSI有两个用处，一个是可以用来通过小区的寻呼信道来寻呼移动台，一个是为了处理不连续接收所所被用来确认寻呼子信道的。

BSC将对依据表中所定义的该位置区的所有小区发出寻呼命令（PAGING COMMAND）在该报文中将含有所属寻呼子信道组的号码和所占用的时隙号（通过IMSI号码的后三位、寻呼子信道总数和该小区用于寻呼时隙的总数计算所得）。

当小区收到该寻呼命令时，将该寻呼所属的寻呼子信道上发出寻呼请求消息（PAGING REQUEST），在该消息中携带有被寻呼用户的IMSI或TMSI号码。

此时，被叫移动台若在其守侯的寻呼子信道上，通过对寻呼消息的解码，若发现是对自己的寻呼，则将发出信道请求（channel request）来触发初始化信道分配过程（详见第二节），当收到网络对它的立即指派命令时，则通过SABM帧在所被指派的信道上发回寻呼应答（PAGING RESPOSE）的初始化报文。此后再通过一系列的鉴权加密，TMSI重新分配过程，就进入了被叫的呼叫建立过程。

图示  寻呼

三.被叫的呼叫建立过程

当MSC完成了对移动台的TMSI重新分配后，就会向移动台发一条启动（SETUP）的消息，其中包括了呼叫所必须的细节（如请求的业务类别和主叫号码等），被叫移动台收到此消息后，则将该消息进行核实，如果移动台能处理主叫请求的业务类别，就返回一条呼叫核准（CALL CONFIRMED）消息，在该消息中，还将携带着移动台选定的参数，如移动台可选用哪一种速率的信道（全速率TCH及半速率TCH）和选定的业务类别。

当MSC收到呼叫核准的消息后，将向BSC发起指派请求，来给被叫用户分配话音信道。指派过程完成消息后，被叫移动台将向网络发出待命（ALERTING）的消息，此时被叫移动台将出现震铃提示，MSC在收到该指示后，则向主叫方发出地址完成的消息（ACM），主叫端在收到该消息后也会将该提示发给主叫用户。

此时，被叫用户在听到提示，作应答后，即将发送给MSC一条接通（CONNECT）的消息，MSC在收到此消息后接通全部传输链路，用户端到端的传输正式建立。

 

问题研究：

1、寻呼请求报文种类：

    为了与寻呼所用的识别符大小相适配，GSM将寻呼报文分为三类，分别称为PAGING REQUEST TYPE1、TYPE2和TYPE3。TYPE1能携带两个任意种类的识别符（即可承载两个IMSI）；TYPE2能承载两个TMSI和一个任意种类的识别符；TYPE3可承载4个TMSI。

2、寻呼重发：

为了防止移动台可能在一次寻呼内没能对给它的寻呼消息准确解码，或        做信道  请求时，由于种种等缘故也没有被网络所解码，造成寻呼失败，因而GSM引入了寻呼重发机制。在北电小区参数中，提供了三个参数控制呼叫重发，分别是noOfRepeat(基站对移动台的寻呼消息的重发次数)、delayBetweenReTrans（同一寻呼命令的两次重发之间相隔的寻呼子信道周期）、retransDuration（同一寻呼命令的首次发送和末次发送所间隔的最大寻呼子信道块数）。在设置此类参数时应注意不要造成，用户很快挂机后的二次寻呼。典型的重发次数是3次。

3、  呼叫转移对路由的影响

在补充业务中对呼叫路由影响最大的要算呼叫转移的功能，有许多的原因会引起呼叫转移，其中分为无条件前转（CFU）、遇忙前转（CFB）、呼叫不可及前转（CFNRc）、呼叫无应答前转（CFNRy），系统对它们的处理办法也是不一样的，下面让我们具体讨论一下其路由选择的过程。

（1）无条件前转（CFU）

当GMSC向HLR发路由请求消息(SEND_ROUTING_INFORMATION)后，如HLR发现该用户有无条件转移的功能后，将在回送路由结果消息(SEND_ROUTING_INFORMATION_RESULT)直接把该转移号码发回到原GMSC再由GMSC分析此号码来重新定义路由。

（2）遇忙前转（CFB）

    当GMSC通过从HLR中得到的被叫的漫游号码MSRN找到VMSC/VLR后，却发现被叫用户正忙，且有遇忙转移CFB的功能，则由其VMSC/VLR完成该转移号码的呼叫转接，送至第三方。当未发现有CFB的功能时，将直接对该呼叫进行处理（如发用户忙的录音等）。此时并不执行寻呼过程。

（3）呼叫不可及前转(CFNRc)

     该功能要根据网络端如何判断被叫不可及的方法，其处理的办法也不同。

     一种情况是当被叫用户最后一次在某地理区域进行位置登记时没有成功，在HLR中记录了这种情况，已经知道无法接到该移动用户，于是就可以自己做出呼叫不可及前转的判决。

     另一种情况是当HLR中没有这种登记时，呼叫仍按正常的过程进行，直到MSC对该用户进行寻呼，而在规定的时间内没有得到用户的发回的寻呼响应（PAGING RESPOSE），则判定该用户不可及，而MSC则将该呼叫前转。这种情况发生的原因很多，一种原因是在该用户进入了盲区或移动台掉电，此时因VMSC对IMSI附着的用户还未做定期的查询，因而无法判断该移动台的状态，而导致对它们的寻呼失败。还有一种原因是该移动台正在LAC边界进行着频繁的位置更新活动而无法去响应寻呼或当去申请信道时因网络无信道资源或指派不成功，而导致寻呼超时。    

     还有一种情况是该移动用户关机造成的（IMSI分离），由于这种标志是在VLR而不是在HLR，因而由此引起呼叫前转只能由VMSC/VLR发起。

（4）呼叫无应答前转（CFNRy）

    当VMSC对该用户寻呼成功，而且被叫端向系统发回了待命（ALERTING）的消息，但在系统规定时间内，被叫用户并没有应答，即回发连接（CONNECT）消息，而且VMSC发现该用户激活了呼叫无应答前转的功能，则由此引起呼叫前转。

    在此大家应值得注意的是，在激活呼叫转移功能后，对于主叫用户只收取GMSC以内的路由的费用，而对于被叫用户却不同了，因为他将要承担第二路由的费用，假如被叫用户在国外而前转的对象在国内，这时原来一次国内通信可解决的问题，将变为两次国际呼叫。为了避免该问题的发生，在这种情况下最好设为无条件前转。

4、  呼叫等待（CW）和呼叫保持（HOLD）：

   在补充业务中，GSM有一个呼叫等待的业务。当MSC收到主叫端对它发来的IAI消息后，当发现被叫用户正在进行另一个通信时，且该用户激活了呼叫等待功能，则MSC则可跳过寻呼过程及移动台和MSC之间低层的建立过程，将利用它们之间已存在的信令方式，直接移动台发出SETUP的报文。如当激活了呼叫保持功能后，就可在两者之间切换通话。

   当遇忙前转（CFB）和呼叫等待同时被激活时，当另一个呼叫到来时，也会先启动呼叫等待的业务，当再有一个呼叫到来时才启动呼叫遇忙前转的业务。