完整主被叫呼叫的信令流程
一次完整GSM主被叫通话的信令流程
一次完整GSM主被叫通话的信令流程1.一次完整主叫通话的信令流程Mobile Station NetworkSystem information type 1Channel RequestImmediate AssignmentCM Service RequestClassmark Change控制参数更改CM Service AcceptAuthentication Request鉴别请示Authentication ResponseCiphering Mode Command 计算类型命令Ciphering Mode CompleteSetupCall ProceedingAssignment CommandAssignment CompleteAlerting 发信号ConnectConnect acknowledge 确认DisconnectReleaseRelease CompleteChannel Release2 需要注意的几点信令(1)在被叫时的Paging Request 与Idle时的Paging Request 的区别在于前者在寻呼时包含有TMSI(临时用户识别码),如果为主叫起呼,则从Channel Request信令开始计算(2)Ciphering Mode 为加密模式(3)在Setup之后若手机为主叫则是Call Proceeding,手机为被叫则是Call Confirmed(证实)。
一次完整被叫通话的信令流程MobileStation NetworkPaging RequestChannel RequestImmediate AssignmentPaging ResponseClassmark ChangeAuthentication RequestAuthentication ResponseCiphering Mode CommandCiphering Mode CompleteSetupCall ConfirmedAssignment CommandAssignment CompleteAlertingConnectConnect acknowledgeDisconnectReleaseRelease CompleteChannel Release2 需要注意的几点信令(1)在被叫时的Paging Request 与Idle时的Paging Request 的区别在于前者在寻呼时包含有TMSI。
volte信令流程
VOLTE_MO_MT 流程1. VoLTE 语音呼叫路由原则1.1:VoLTE 主叫(1)VoLTE 用户附着在LTE,如果被叫是VoLTE 用户,则将呼叫路由至被叫归属IMS 域,由被叫归属IMS 进行被叫域选,根据域选结果进行后续路由;(2)VoLTE 用户附着在LTE,如果被叫是CS 用户,则呼叫从主叫归属IMS 域直接进入CS 域,由CS 域完成后续呼叫;(3)VoLTE 用户附着在CS,如果被叫是VoLTE 用户,通过被叫锚定方案将语音接续到被叫归属IMS 域,由被叫归属IMS 进行被叫域选,根据域选结果进行后续路由;(4)VoLTE 用户附着在CS,如果被叫是CS 用户,呼叫同现网CS 用户呼叫CS 用户。
1.2:VoLTE 被叫(1)主叫是VoLTE 用户,附着在LTE,被叫是VoLTE 用户,则将呼叫路由至被叫归属IMS 域,由被叫归属IMS 进行被叫域选,并根据域选结果进行后续路由;(2)主叫是VoLTE 用户,附着在CS,被叫是VoLTE 用户,通过锚定方案将语音接续到被叫归属IMS 域,由被叫归属IMS 进行被叫域选,根据域选结果进行后续路由;(3)主叫是CS 用户,被叫是VoLTE 用户,通过锚定方案将语音接续到被叫归属IMS 域,由归属IMS 进行被叫域选,根据域选结果进行后续路由;1.3:Precondition建立媒体PDP 上下文的过程称为资源预留。
对于双方的UE 而言,建立PDP 上下文的执行过程是相互独立的。
这意味着在资源被成功预留之前,根本无法保证所协商的媒体会话是否可以建立起来。
因此,Precondition 作用主要是为了保证在确认本地和主叫方的资源预留都已成功之前,被叫方不应振铃,以最大程度减少被叫方振铃但接听电话又失败的情况1.4:VoLTE 信令包过渡(((diameter or sip or gtpv2 or megaco or dns or camel or bicc or gsm_map) && !(diameter.cmd.code == 280)) && !(diameter.cmd.code == 257)) && !(diameter.cmd.code == 282)2.VoLTE 用户(LTE 附着)呼叫VoLTE 用户(LTE/CS 附着)2.1VoLTE 用户呼叫VoLTE 用户,主被叫均附着在LTE1主叫用户UE(O)的呼叫请求发送到主叫PCSCF。
volte信令流程
VOLTE_MO_MT 流程1. VoLTE 语音呼叫路由原则1.1:VoLTE 主叫(1)VoLTE 用户附着在LTE,如果被叫是VoLTE 用户,则将呼叫路由至被叫归属IMS 域,由被叫归属IMS 进行被叫域选,根据域选结果进行后续路由;(2)VoLTE 用户附着在LTE,如果被叫是CS 用户,则呼叫从主叫归属IMS 域直接进入CS 域,由CS 域完成后续呼叫;(3)VoLTE 用户附着在CS,如果被叫是VoLTE 用户,通过被叫锚定方案将语音接续到被叫归属IMS 域,由被叫归属IMS 进行被叫域选,根据域选结果进行后续路由;(4)VoLTE 用户附着在CS,如果被叫是CS 用户,呼叫同现网CS 用户呼叫CS 用户。
1.2:VoLTE 被叫(1)主叫是VoLTE 用户,附着在LTE,被叫是VoLTE 用户,则将呼叫路由至被叫归属IMS 域,由被叫归属IMS 进行被叫域选,并根据域选结果进行后续路由;(2)主叫是VoLTE 用户,附着在CS,被叫是VoLTE 用户,通过锚定方案将语音接续到被叫归属IMS 域,由被叫归属IMS 进行被叫域选,根据域选结果进行后续路由;(3)主叫是CS 用户,被叫是VoLTE 用户,通过锚定方案将语音接续到被叫归属IMS 域,由归属IMS 进行被叫域选,根据域选结果进行后续路由;1.3:Precondition建立媒体PDP 上下文的过程称为资源预留。
对于双方的UE 而言,建立PDP 上下文的执行过程是相互独立的。
这意味着在资源被成功预留之前,根本无法保证所协商的媒体会话是否可以建立起来。
因此,Precondition 作用主要是为了保证在确认本地和主叫方的资源预留都已成功之前,被叫方不应振铃,以最大程度减少被叫方振铃但接听电话又失败的情况1.4:VoLTE 信令包过渡(((diameter or sip or gtpv2 or megaco or dns or camel or bicc or gsm_map) && !(diameter.cmd.code == 280)) && !(diameter.cmd.code == 257)) && !(diameter.cmd.code == 282)2.VoLTE 用户(LTE 附着)呼叫VoLTE 用户(LTE/CS 附着)2.1VoLTE 用户呼叫VoLTE 用户,主被叫均附着在LTE1主叫用户UE(O)的呼叫请求发送到主叫PCSCF。
主被叫叫流程
主叫,若一MS处于激活且空闲状态,客户A 要建立一个呼叫,他只要拨被叫B 客户号码,再按“发送”键,MS便开始启动程序。
首先,MS通过随机接入控制信道(RACH)向网络发第一条消息,既接入请求消息,MSC 会分配它一专用信道,查看A客户的类别并标注此客户忙。
若网络容许此MS接入网络,则MSC发证实接入请求消息。
接着,MS发呼叫建立消息及B客户号码,MSC根据此号码将主叫与被叫所在MSC连通,并将被叫号码送至被叫所在MSC(B客户为移动客户时)或送入固定网(PSTN)的交换机(B客户为固定客户时)中进行分析。
一旦通往B客户的链路准备好,网络便向MS发呼叫建立证实,并给它分配专用业务信道TCH。
至此,呼叫建立过程基本完成,MS等待B客户的证实信号。
若MS作被叫,以PSTN的固定客户A呼叫GSM的移动客户B的呼叫建立过程, 如图24所示。
B客户号码为139H l H2H3ABCD。
A客户拨打B客户,拨MSISDN(0139H l H2H3ABCD)号码。
本地交换机根据A客户所拨B 客户号码中国内目的地代码(139)可以与GSM网的GMSC(GSM网入口交换机)间建立链路,并将B客户MSISDN号码传送给GMSC。
GMSC分析此号码,根据H l H2H3ABCD,应用查询功能向B客户的HLR发MSISDN号码,询问B客户漫游号码(MSRN)。
HLR将B客户MSISDN号码转换为客户识别码(IMSI),查询B客户目前所在的业务区MSC(如他已漫游到广州),向该区VLR发被叫的IMSI,请求VLR分配给被叫客户一个漫游号码MSRN,VLR 把分配给被叫客户的MSRN号码回送给HLR,由HLR发送给GMSC。
GMSC有了MSRN,就可以把入局呼叫接到B客户所在的MSC(郑州-广州)。
GMSC与MSC 的连接可以是直达链路,也可由汇接局转接。
VLR查出被叫客户的位置区识别码(LAI)之后,MSC将寻呼消息发送给位置区内所有的BTS,由这些BTS通过无线路径上的寻呼信道(PCH)发送寻呼消息,在整个位置区覆盖范围内进行广播寻呼。
信令流程-主叫被叫
主叫信令细解✓1、CHANNEL_REQUEST–Channel request信息包含3bits的建立原因,5bits手机随机选取的Random Reference–建立原因包含呼叫响应、紧急呼叫或其他业务如主叫、短消息或位置更新–Random Reference 用来区分同时请求接入网络的手机✓2、CHANNEL_REQUIRED–包含Channel request的所有信息、TDMA frame number 、Access Delay–Access Delay 是BTS预估的第一次timing advance✓3、CHANNEL_ACTIVATION–收到channel-required 后BSC要分配给该呼叫SDCCH–信息包含DTX control, channel description, mobile allocation, 手机和基站的最大power levels ,BSC计算出的timing advance✓4、CHANNEL_ACTIVATION_ACK–channel activation 的响应–BTS收到该消息后收发就用SACCH✓5、IMMEDIATE_ASSIGNMENT_COMMAND–BSC告知BTS要用的SDCCH信道特征✓6、IMMEDIATE_ASSIGNMENT–BTS在AGCH上通知手机SDCCH信道特征–参数包括the page mode, SDCCH channel 描述, SACCH, hopping indicator, 初始timing advance, mobile allocation (假如开启了跳频)–还包括手机原先发送的request reference (random reference和TDMA frame number),用来识别相应的手机–手机可以开始启用SDCCH✓7、CM_SERVICE_REQUEST–手机在SDCCH发送layer2信令SABM (Set Asynchronous Balanced Mode)给BTS–SABM包括一个layer3服务请求信息,用来向网络侧指示服务类型✓8、ESTABLISH_INDICATION–BTS通过Establish Indication消息应答Immediate Assignment Command–Establish Indication有两个用处,一是在本阶段通过BTS表明手机已经占用上了SDCCH,二是BTS识别主信令信道,以便加入layer3信息✓9、CM_SERVICE_REQUEST–送到MSC✓10、UA–BTS应答手机发送的SABM✓11、PROCESS_ACCESS_REQUEST–把手机的接入请求向VLR发送✓12、AUTHENTICATE–VLR发起鉴权请求✓13、AUTHENTICATION_REQUEST–MSC在DT1 (Data Form 1)上发送Authentication Request ,消息包含RAND✓14、AUTHENTICATION_REQUEST–BSC经BTS发送给手机✓15、AUTHENTICATION_RESPONSE–手机应答Authentication Request ,包含SRES–鉴权有两种算法A3和A8,算法和32位密钥Ki存在SIM卡中,鉴权中心(AuC) 也有相同的信息。
(个人整理)主叫被叫呼叫信令流程
主叫:1、rrc连接请求(UE—RNC、RACH)可看出业务类型(speech(12.2k)、video(64k));包含UE标识:TMSI、LAI=MCC+MNC+LAC;请求原因:主叫会话、被叫会话、短信发送、短信接收、FTP下载、注册;UE能力:是否支持GSM等。
2、RNC要求NODEB建立无线链路,准备无线资源(建立在DCH上才有)RL建立请求、RL建立响应、DL SYNC、UL SYNC。
3、rrc连接建立(RNC—UE、FACH)包含rrc建立的链路消息(建立在公共信道或DCH)、频点、上行最大发射功率等;RNC侧还可以看到UE的IMSI、TMSI、P-TMSI,功率步长等。
4、rrc连接建立完成(UE—RNC、DCCH)UE上报自己的能力:功率支持等级、是否支持GSM、多载波、FDD/TDD。
5、CM服务请求(初始直传消息、RNC—UE、DCCH)业务请求:呼叫、紧急呼叫、短消息等。
6、初始化UE消息(RNC—UE)7、直传消息(鉴权请求消息、CN—RNC)8、直传消息(鉴权请求消息、RNC—UE)9、直传消息(鉴权响应、UE—RNC—CN)10、安全模式建立过程,同鉴权过程11、身份认证请求(RNC—UE)12、身份认证响应(UE—RNC)13、SETUP(UE—RNC)包含UE支持的语音编码及被叫号码。
14、呼叫进程启动(RNC—UE)表明请求的呼叫已被接受。
15、Rab指派请求(CN—RNC)Rab建立是为了UE与CN间传送语音、数据及多媒体业务,rrc建立则是为了建立UE—RNC—CN之间的信令连接。
16、无线链路重配置准备(RNC—NODEB)NODEB建立DCH来承载rab。
17、无线链路重配置完毕(NODEB—RNC)18、rb建立(RNC—UE)建立一个新的物理承载,包含扩频因子信息。
19、rb建立完成(UE—RNC)表明请求的呼叫已被接受。
20、rab指派响应(RNC—CN)表明rab建立完成。
手机作主叫及被叫的信令流程.doc
手机作主叫的信令流程:手机作被叫的信令流程:MOC第3层信令过程:Uplink Channel Request---------------RACH Downlink Immediate Assignment-------AGCHUplink CM Service Request-----------SDCCH Downlink Authentication Request--------SDCCH Uplink Authentication Request--------SDCCH Downlink Ciphering Mode Command----SDCCH Uplink Ciphering Mode Complete-----SDCCH Uplink Setup----------------------------SDCCH Downlink Assignment Command--------SDCCH Uplink Assignment complete-----------FACCH(TCH) Downlink Alerting-------------------------FACCH Downlink Connect-------------------------FACCH Uplink Connect Acknowledge--------FACCH--------------------通话------------------------------Uplink Disconnect---------------------FACCH Downlink Release--------------------------FACCH Uplink Release Complete--------------FACCH Downlink Channel Release----------------FACCHMTC第3层信令过程:Downlink Paging request type 1--------PCHUplink Channel Request---------------RACH Downlink Immediate Assignment-------AGCHUplink Paging response----------------SDCCH Downlink Authentication Request--------SDCCH Uplink Authentication Request--------SDCCH Downlink Ciphering Mode Command----SDCCH Uplink Ciphering Mode Complete-----SDCCH Uplink Setup----------------------------SDCCH Downlink Assignment Command--------SDCCH Uplink Assignment complete-----------FACCH(TCH) Uplink Alerting-------------------------FACCHUplink Connect-------------------------FACCH Downlink Connect Acknowledge--------FACCH--------------------通话------------------------------Uplink Disconnect---------------------FACCH Downlink Release--------------------------FACCH Uplink Release Complete--------------FACCHDownlink Channel Release----------------FACCH请详细说一下位置更新的流程及每一步所传送的消息当手机发现当前小区的位置区识别码LAC与SIM卡中存储的LAC值不一致时就发起一次位置更新请求。
通信呼叫流程信令资料
6Issue 3.3第1章呼叫过程的信令分析对一次发生在移动用户间的呼叫来说,信令流程可以分为三个相对独立的部分:●主叫移动用户部分●被叫移动用户部分●拆线部分1.1 主叫信令流程移动用户做主叫时的信令过程从MS向BTS请求信道开始,到主叫用户TCH指配完成为止。
一般来说,主叫经过几个大的阶段:接入阶段,鉴权加密阶段,TCH指配阶段,取被叫用户路由信息阶段。
接入阶段主要包括:信道请求,信道激活,信道激活响应,立即指配,业务请求等几个步骤。
经过这个阶段,手机和BTS(BSC)建立了暂时固定的关系。
鉴权加密阶段主要包括:鉴权请求,鉴权响应,加密模式命令,加密模式完成,呼叫建立等几个步骤。
经过这个阶段,主叫用户的身份已经得到了确认,网络认为主叫用户是一个合法用户,允许继续处理该呼叫。
TCH指配阶段主要包括:指配命令,指配完成。
经过这个阶段,主叫用户的话音信道已经确定,如果在后面被叫接续的过程中不能接通,主叫用户可以通过话音信道听到MSC的语音提示。
取被叫用户路由信息阶段主要包括:向HLR请求路由信息;HLR向VLR请求漫游号码;VLR回送被叫用户的漫游号码;HLR向MSC回送被叫用户的路由信息(MSRN)。
MSC收到路由信息后,对被叫用户的路由信息进行分析,可以得到被叫用户的局向。
然后进行话路接续。
6Issue 3.3主叫过程的信令流程如后面的图所示。
注意:应该注意的是:从VLR到HLR/AUC取鉴权集的过程不是必须的。
VLR到HLR/AUC取鉴权集时,HLR每次送5组,本次使用一组,另外4组保存在VLR中供后续的鉴权过程使用。
只有当VLR中的鉴权集使用完毕,VLR才发起向HLR/AUC取鉴权集的过程。
另外,如果MSC通过对被叫用户的MSRN的分析得知被叫用户是本局用户,那么就不会向其它MSC发送初始地址消息(IAI/IAM),而是根据被叫用户的位置区直接通知本局BSC对被叫用户发起寻呼。
如果被叫用户非本局用户,则通过信令路由分析,通过适当的链路向目的MSC发IAI消息,以建立话路。
VOLTE信令流程(精)
,VOLTE_MO_MT流程1 . VoLTE语音呼叫路由原则1.1:VoLTE 主叫(1 VoLTE 用户附着在 LTE ,如果被叫是 VoLTE 用户,则将呼叫路由至被叫归属IMS 域,由被叫归属 IMS 进行被叫域选,根据域选结果进行后续路由;(2 VoLTE 用户附着在 LTE ,如果被叫是 CS 用户,则呼叫从主叫归属 IMS 域直接进入 CS 域,由 CS 域完成后续呼叫;(3 VoLTE 用户附着在 CS ,如果被叫是 VoLTE 用户,通过被叫锚定方案将语音接续到被叫归属 IMS 域,由被叫归属 IMS 进行被叫域选,根据域选结果进行后续路由;(4 VoLTE 用户附着在 CS ,如果被叫是 CS 用户,呼叫同现网 CS 用户呼叫 CS 用户。
1.2:VoLTE 被叫(1 主叫是 VoLTE 用户, 附着在 LTE , 被叫是 VoLTE 用户, 则将呼叫路由至被叫归属 IMS 域, 由被叫归属 IMS 进行被叫域选,并根据域选结果进行后续路由;(2主叫是 VoLTE 用户,附着在 CS ,被叫是 VoLTE 用户,通过锚定方案将语音接续到被叫归属 IMS 域,由被叫归属 IMS 进行被叫域选,根据域选结果进行后续路由;(3 主叫是 CS 用户,被叫是 VoLTE 用户,通过锚定方案将语音接续到被叫归属IMS 域, 由归属 IMS 进行被叫域选,根据域选结果进行后续路由;1.3:Precondition建立媒体 PDP 上下文的过程称为资源预留。
对于双方的 UE 而言, 建立 PDP 上下文的执行过程是相互独立的。
这意味着在资源被成功预留之前,根本无法保证所协商的媒体会话是否可以建立起来。
因此, Precondition 作用主要是为了保证在确认本地和主叫方的资源预留都已成功之前,被叫方不应振铃 , 以最大程度减少被叫方振铃但接听电话又失败的情况1.4:VoLTE 信令包过渡(((diameter or sip or gtpv2 or megaco or dns or camel or bicc or gsm_map&& !(diameter.cmd.code == 280 && !(diameter.cmd.code == 257&& !(diameter.cmd.code == 2822. VoLTE用户(LTE 附着呼叫 VoLTE 用户(LTE/CS附着2.1 VoL TE 用户呼叫 VoL TE 用户,主被叫均附着在 LTE1 主叫用户 UE(O的呼叫请求发送到主叫 PCSCF 。
主叫与被叫的信令过程
附录A 一次呼叫典型流程B.1 概述本章将分别给出主叫流程和被叫流程的例子,以示一次通话过程中UTRAN的典型流程。
B.2 主叫流程主叫流程是指UE呼叫其它用户(例如PSTN用户)的过程。
具体流程如图B-1所示,主叫流程大体经过了如下几个过程:(1)RRC连接建立为了成功进行呼叫,UE将发起RRC连接建立过程,建立起与RNC之间的信令连接。
详细信息请参见“4.3 RRC连接建立流程”描述。
(2)信令连接建立RNC建立起与CN之间的信令连接。
详细信息请参见“4.4 直传消息流程”描述。
(3)RAB建立CN响应UE的业务请求,要求RNC建立相应的无线接入承载,建立成功后,对方应答,双方通话。
详细信息请参见“4.6 RAB建立流程”描述。
(4)信令连接释放通话过程结束,首先释放RNC和CN之间的信令连接。
详细信息请参见“4.7 业务释放流程”描述。
(5)RAB释放释放无线接入承载。
详细信息请参见“4.7 业务释放流程”描述。
(6)RRC释放如果该RRC连接没有其他的IU信令连接,将释放UE和RNC之间的RRC连接。
详细信息请参见“4.7 业务释放流程”描述。
图B-1 主叫流程B.3 被叫流程被叫流程是指网络侧有寻呼请求呼叫UE,UE响应寻呼的过程。
UE接收到寻呼消息后,将发起RRC连接建立过程。
被叫流程大体经过如下几个过程:(1)寻呼网络侧寻呼UE。
详细信息请参见“4.2 寻呼流程”描述。
(2)RRC连接建立UE应答呼叫,发起与RNC之间的RRC连接建立过程。
详细信息请参见“4.3RRC连接建立流程”描述。
(3)信令连接建立及直传过程RNC建立起与CN之间的信令连接。
详细信息请参见“4.4 直传消息流程”描述;(4)RAB建立CN要求RNC建立相应的无线接入承载。
建立成功后,UE和CN交互信令,应答进入通话状态。
详细信息请参见“4.6 RAB建立流程”描述;(5)信令连接释放通话结束,释放RNC与CN之间的信令连接。
手机主被叫信令流程
通话建立(手机作被叫)
RR层连接建立 信令过程 CCCH—DL:PAGING_REQUEST RACH—UL:CHANNEL _REQUEST
AGCH—DL:IMMEDIATE_ASSINGMENT SDCCH—UL:PAGING_RESPONSE SDCCH—DL:AUTH_REQUEST SDCCH—UL:AUTH_RESPONSE SDCCH—DL:CIPHERING_REQUEST SDCCH—UL:CIPHERING_COMPLETE CC层连接的建立 SDCCH—UL:SETUP SDCCH—UL:CALL _CONFIRMED SDCCH—UL:ALERTING SDCCH—UL:CONNECT SDCCH—DL:ASSIGNMENT_COMMAND SDCCH—UL:ASSIGNMENT_COMPLETE SDCCH—DL:CONNECT_ACKNOWLEDGE
通话建立(手机作主叫)
RR层连接建立 信令过程 RACH—UL:CHANNEL _REQUEST 说明 内容:建立原因和随机参考值(RAND) 原因:MS发起呼叫、紧急呼叫、呼叫重建和寻呼响 应等; RAND:有5 位,用来区别不同MS所发起的请求。 AGCH—DL:IMMEDIATE_ASSINGMENT CCCH—UL:CM SERVICE_REQUEST SDCCH—DL:AUTH_REQUEST SDCCH—UL:AUTH_RESPONSE SDCCH—DL:CIPHERING_REQUEST SDCCH—UL:CIPHERING_COMPLETE CC层连接的建 立 SDCCH—UL:SETUP SDCCH—DL:CALL _PROCEEDING SDCCH—DL:ALERTING SDCCH—DL:ASSIGNMENT_COMMAND SDCCH—UL:ASSIGNMENT_COMPLETE SDCCH—DL:CONNECT SDCCH—UL:CONNECT_ACKNOWLEDGE 在Um 接口建立MS与系统间的无线连接(分配 SDCCH) RR连接建立 请求业务如电路交换连接、短信业务等 鉴权请求 鉴权响应 加密命令 加密完成 请求建立呼叫 内容:呼叫请求的业务种类及MS发送方式、编码标 准等 系统接受请求后开始处理呼叫 振铃音 分配TCH 分配确认 用户摘机或连接消息 连接确认,表示MS接受连接
主被叫信令流程总结
主被叫信令流程总结第一篇:主被叫信令流程总结主被叫信令流程总结截一张主被叫信令流程,可以对比进行学习。
对比,我们可以看出:1、被叫比主叫多一条PagingType。
2、主叫RRC建立好后上发CM Service Request,而被叫是上发RR Paging Response。
3、主叫有鉴权加密过程,而被叫只有加密过程,无鉴权过程。
4、主叫的Setup消息是UE上发给RNC,而被叫的Setup则是RNC下发给UE。
Setup里可以看UE号码。
5、Setup之后主叫是收到Call proceeding,而被叫则上发Call confirmed。
6、alerting、connect和connect ACKnowledge消息主被叫上下相反。
此外我们还可以看出:1、RRC建立过程一般为0.6s左右。
2、RB建立过程一般也为0.6s左右。
3、主叫从RRC请求开始到接通为9s左右,被叫为7s左右。
4、一般主叫收到Call proceeding时,被叫就发起RRC建立,两者几乎同步。
这个可以用来分析因被叫位置而引起的主叫未接通。
流程步骤是固定的,我想问的是,用不同软件进行测试的时候,在软件上看到的信令触发时间是有不同,而且出现的主被叫时间不统一,比如主叫上发的Connect Acknowledge时刻比被叫收到下发的Connect Acknowledge的时刻晚,正常来说应该是主叫比被叫时刻先,同样CC Disconect消息也是如此,而且可能上发和下发的触发机制不一样,手动挂断,定时挂断以及软件停止执行,主被叫都呈现出一种不规律情况。
第二篇:volte主被叫信令流程小结VOLTE呼叫流程介绍:A和B均在IDLE模式,A用户(主叫Caller)呼叫B用户(被叫Callee)流程图;A、B均在MME附着,已在AS服务器注册;VOLTE呼叫业务流程VOLTE呼叫业务流程VOLTE呼叫业务流程备注:黑色,正常消息描述,包括Rrc、S1信令和普通描述等;红色,NAS标准信令;蓝色SIP标准信令;上述A和B均是IDLE模式,互相拨打的方式是实际应用场景中最常见的一种方式,具体流程如下:1.用户A和用户B在注册成功后,无业务触发,MME发起上下文释放,将A和B均置为IDLE模式。
SIP完整信令解析
主叫与被叫之间的SIP呼叫业务流程如下:2. SIP信令完整解析:(1).用户A ,摘机对用户B发起呼叫,用户A首先向AS服务器发起INVITE请求。
(2).AS服务器回复100 Trying给用户A说明收到INVITE请求。
(3).AS服务器通过认证确认用户认证已通过后,向被叫终端B转送INVITE请求。
(4).用户B向AS服务器送呼叫处理中的应答消息,100 Trying。
(5).用户B向AS服务器送183 Session Progress消息,提示建立对话的进度信息。
(此时被叫QCI1专用承载建立)(6).AS服务器向主叫终端A转送183 Session Progress消息,终端A了解到整个Session的建立进度消息。
(7).终端A向AS服务器回复临时应答消息PRACK,表示收到183 Session Progress消息。
(此时主叫QCI1专用承载建立)(8).AS服务器向被叫终端B转送临时应答消息PRACK,终端B了解到终端A收到183 Session Progress 消息。
(9).被叫终端B向AS服务器发送200 OK消息,表示183 S essi o n Progre ss请求已经处理成功。
(10).AS服务器向主叫终端A转送200 OK消息。
(11).主叫终端A向AS服务器发送UPDATE消息,意在与被叫终端B协商相关SDP信息。
(12).AS服务器向被叫终端B转送UPDATE消息。
(13).被叫终端B向AS服务器发送200 OK消息,表示UPDATE请求已经处理成功。
(14).AS服务器向主叫用户A转送200 OK消息,通知用户A UPDATE请求已经处理成功。
(15).被叫用户B振铃,用户振铃后,向AS服务器发送180 Ringing振铃信息。
(16).AS服务器向主叫终端A转送180 Ringing振铃信息。
(17).被叫终端B向AS服务器发送200O K消息,表明主叫最初的I N V I T E请求已经处理成功。
主被叫信令流程
1.移动主叫图1 移动主叫流程图1.1CM业务请求这条CM业务请求消息被送往移动交换中心。
1.2鉴权请求作为CC(连接证实)消息,移动交换中心发送一条鉴权请求消息给BSC。
这条消息包括随机数RAND。
1.3鉴权响应为了完成鉴权过程,从MS来的SRES的值在消息内部被送回VLR。
1.4加密模式命令MSC要求BSC从无线通路开始加密。
假如网络想要在无线接口开始加密,需要在A接口发送消息。
如果网络使用加密,那么MS在接收到此消息以后开始加密。
1.5加密模式完成如果加密被使用,那么这是在空中接口中的第一条加密的消息。
BSS确认加密命令,通知MSC移动台已经开始加密并开始以加密模式发送消息。
1.6TMSI再分配命令TMSI再分配的目的是提供身份的保密性。
TMSI的再分配通常至少在每次位置更新时执行。
MSC通过发送TMSI再分配命令消息给MS发起TMSI再分配过程。
TMSI再分配命令消息包括TMSI与由网络分配的LAI的组合;或者如果正在使用的TMSI将被删除,就包括一个LAI和IMSI。
通常,通过应用加密模式的RR连接,TMSI再分配命令被送往MS。
1.7TMSI再分配完成TMSI再分配完成消息送往MSC。
1.8建立BSC向MSC发送建立消息来告知MSC将要执行的呼叫。
1.9呼叫进程MSC对建立消息的响应。
1.10指配请求这条消息开始了TCH(话音信道)的分配。
在A接口,MSC是主控者,它为A接口上的这次呼叫寻找一个可使用的电路。
这条消息根据GSM规范包括了一些可选项。
这些可选项是:呼叫的优先权、下行的不连续传输(DTX)、无线信道的识别和可用的干扰带。
1.11指配完成BSS向MSC证实获取TCH信道。
1.12提醒MSC发送提醒消息给BSS。
1.13连接MSC通过BSS发送一连接消息给MS。
此消息向MS表明已经通过网络建立连接。
1.14连接证实此消息被送往MSC。
1.15拆链拆链消息发往MSC。
1.16释放实际的释放将来自MSC,真正的呼叫才结束。
信令流程详解
信令流程详解1 信令分析在分析问题时,请参照正确的流程,逐步检查到底哪一条消息没有收到,并且分析上一条消息里面携带的内容,从而定位原因所在。
1.1 主被叫呼叫建立流程1.1.1正常信令在分析接入问题时,请参照上图所示正确的流程,逐步检查到底哪一条消息没有收到,且分析上一条消息里面携带的内容,从而定位原因所在【注】Abis-BTS setup消息里面,携带了接入的小区、扇区、walsh码、频点。
关键点1:BSC向MSC发送CM Service Request后,是否收到Assignment Request。
如果没有收到MSC发的Assignment Request,等到6s后定时器超时,基站会给手机发送release order.这种情况是A1接口失败。
关键点2:BTS是否向BSC发送Abis-BTS Setup Ack。
Abis如有问题,如误码高、信令链路带宽不足等,将会体现为Abis无法建链成功,话统原因“指配资源失败”关键点3:是否发送ECAM(扩展信道指配消息)消息。
如Abis 正常建链,但却没有发送ECAM消息,在话统里面会体现为“指配资源失败”,可能原因是walsh、CE、power不足。
关键点4:是否在F-DSCH发送order message,如没有收到,说明捕获业务信道前导帧失败。
关键点5:是否发送Assignment complete。
如发送表明呼叫建立成功。
如没有收到,在话统里面体现为“信令交互失败”。
被叫流程与主叫几乎完全一致,被叫中的Paging Response相当于主叫的origination message。
1.1.2典型异常信令1、A1接口失败。
2、传输误码率高导致指配资源失败3、信令交互失败引起信令交互失败一般是空口原因,本案例比较特殊,该基站下面呼叫全部失败,通过结合CSL分析,发现存在大量0x0c8b (SDU_ADD_LINK_FAIL)接入失败,怀疑FMR 板有故障,在征得客户同意基础上复位IP框后(该框下仅有这一个基站)解决。
主、被叫过程流程
移动台作为起始呼叫者,在与网络端接触以前拨被叫号码,然后发送,网络端会向主叫用户作出应答表明呼叫的结果.一、接入阶段:手机与BTS(BSC)之间建立了暂时固定的关系。
1、信道请求,2、信道激活,3、信道激活响应,4、立即指配,5、业务请求。
二、鉴权加密阶段:主叫用户的身份已经确认,网络认为主叫用户是一个合法用户。
1、鉴权请求,2、鉴权响应,3、加密模式命令,4、加密模式完成,5、呼叫建立。
三、TCH指配阶段:主叫用户的话音信道已经确定,如果在后面被叫接续的过程中不能接通,主叫用户可以通过话音信道听到MSC的语音提示。
1、指配命令,2、指配完成。
四、取被叫用户路由信息阶段:MSC接到路由信息后,对被叫用户的路由信息进行分析,得到被叫用户的局向,然后进行话路接续。
1、向HLR请求路由信息,2、HLR向VLR请求漫游号码,3、VLR回送被叫用户的漫游号码,4、HLR向MSC回送被叫用户的路由信息。
五、END。
移动台作被叫时,其MSC通过与外界的接口收到初始化地址消息(IAI)。
从这条消息的内容及MSC已经存在VLR中的记录,MSC可以取到如IMSI、请求业务类别等完成接续所需要的全部数据。
MSC 然后对移动台发起寻呼,移动台接受呼叫并返回呼叫核准消息,此时移动台振铃。
MSC在收到被叫移动台的呼叫校准消息后,会向主叫网方向发出地址完成(ADDRESS COMPLETE)消息(ACM)。
一、接入阶段:手机与BTS(BSC)之间建立了暂时固定的关系。
1、手机收到BTS的寻呼命令后,2、信道请求,3、信道激活,4、信道激活响应,5、立即指配,6、寻呼响应。
二、鉴权加密阶段:经过这个阶段,被叫用户的身份已经确认,网络认为被叫用户是一个合法用户。
1、鉴权请求,2、鉴权响应,3、加密模式命令,4、加密模式完成,5、呼叫建立。
三、TCH指配阶段:被叫用户的话音信道已经确定,主叫听回铃音,被叫振铃。
如果被叫用户摘机,则进入通话状态。
主叫、被叫信令流程
主叫、被叫信令流程今天我和大家一起探讨一下关于网优掉话的相关问题,但是在讲解掉话问题之前,我想首先给大家介绍一下简单的通话过程和手机作为被叫和主叫的信令接续过程,然后再和大家探讨一下怎样处理掉话方面的问题。
MSISDN IMSI MSCIMSI MSRN下例是一个北京的固定电话用户拨打广州的一个移动用户的呼叫接续过程中各种识别码的应用过程。
1、主叫拨号。
北京市话用户A拨打广州GSM用户B的MSISDN号码,PSTN网络的交换机分析MSISDN号码,得知B用户为移动用户,它把呼叫转到GSM网络上距它最近的一个具有入口功能的移动业务交换中心GMSC。
2、GMSC分析被叫号码。
GMSC分析该号码为广州位置寄存器HLR的用户后将MSISDN号码送至广州HLR,要求查询有关该被叫用户目前所在的位置信息。
3、HLR申请漫游号码MSRN。
HLR把MSISDN号码转换成IMSI后查出用户目前处于哪个MSC并将该IMSI发至该MSC,向该MSC申请分配一个漫游号码。
4、选定漫游号码MSRN。
MSC收到IMSI后临时给被叫用户B分配一个漫游号码并将此号码送回HLR,再由HLR发给GMSC使用。
5、连接呼叫至被叫所在的MSC。
GMSC收到MSRN后,用此号码选择一条出中继路由至MSC。
MSC将负责本次呼叫的建立和计费功能。
6、令被叫所在位置区内的所有基站发寻呼信息。
被叫MSC发出寻呼命令到MS所在位置区内的所有无线基站,再由基站向被叫用户B发呼叫信号。
7、基站寻呼被叫用户B。
基站收到寻呼命令后,将该寻呼消息(含有MS的IMSI)通过无线控制信道发射。
MS接收到寻呼后向基站发回响应信号。
8、呼叫连接。
MS响应信号经BTS、BSC送回MSC,经鉴权、设备识别后认为合法,则令BSC给该MS分配一条TCH,接通MSC至BSC的路由,并向主叫送回铃音,向被叫振铃。
当被叫摘机应答,则系统开始计费。
以上的只是比较简单的粗略的说明了一下我们大家在打电话的时候所经过的过程。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
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 requestDL: Immediate assignment(SDCCH)试呼:UL:CM service request(如果后面直接收到System Information Type1,则视为起呼失败)DL: CM service RequestDL: CM service acceptDL: AUTHENTICATION REQUESTUL: AUTHENTICATION RESPONSEDL: CIPHER MODE COMMANDUL: CIPHER MODE COMPLETEDL: TMSI REALLOCATION COMMANDUL: TMSI REALLOCATION COMPLETEUL: SETUPDL: CALL PROCEEDINGDL: ASSIGNMENT COMMANDUL: ASSIGNMENT COMPLETE (TCH)DL: ALERTING成功起呼:DL: CONNECT(呼叫成功的标志,)UL: CONNECT ACKNOWLEDGEDL: SYSTEM INFORMATION TYPE 5(5bis,5ter):邻近小区BCCH频点描述(扩展邻近小区BCCH频点描述)DL: SYSTEM INFORMATION TYPE 6:CI,LAI,小区参数设置UL: MEASUREMENT REPORTDL:Handover CommandDL:Physical InformationUL:Handover Complete(切换成功的标志)DL:Physical InformationDL: SYSTEM INFORMATION TYPE 6UL: MEASUREMENT REPORTDL:Disconnect(收到该条消息或Release中的任何一条,则视为正常释放,如果两条消息均未收到,而是直接收到System Information Type1,则视为一次掉话)UL:ReleaseDL:Release CompleteDL:Channel ReleaseUL:Release Complete2.2一次正常的LAR&RAU信令流程:DirectionTypeLayer 3 MessageULRRChannel RequestDLRRImmediate AssignmentULMMLocation Updating RequestULRRClassmark ChangeULRRGPRS Suspension RequestDLMMAuthentication RequestULMMAuthentication ResponseDLMMIdentity RequestULMMIdentity ResponeDLMMLocation Updating acceptULMMTMSI Realocation CompleteDLRRChannel ReleaseULGPRS MMRouting Area Update RequestULRRChannel RequestDLRRImmediate AssignmentDLGPRS MMRouting Area Update AcceptULGPRS MMRouting Area Update Complete2.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→Channel Request→Immediate Assignment→CM Service Request→CM Service Accept→Setup→Assignment Command→Assignment Complete→Alerting→Disconnect→Release→Release Complete→Channel Release²呼叫失败: Paging Request→Channel Request→Immediate Assignment→CM Service Request→System Information Type1(在一次呼叫过程中,若连续出现多个CM Service Request,则视为一次呼叫失败)²呼叫成功:Paging Request→Channel Request→Immediate Assignment→CM Service Request→CM Service Accept→Setup→Assignment Command→Assignment Complete→Connect/Alerting²切换成功:Handover Command→Handover Complete²切换失败:Handover Command→Handover Failure2.4常见Disconnect / Release Cause Value: Cause ValueReason31BSS or MSC problem34(beforeAssignmentCommand)TCH Blocking34(after Assignment Complete)MSC Blocking41(after Assignment Command)BSS problem, especially DRI problem41(after Assignment Complete)MSC problem42MSC Congestion44BSS problem, especially the CIC blocking111BSS or MSC problem2.5 两个MS通话的流程MS1 Uplink Channel RequestMS1 Downlink Immediate AssignmentMS1 Uplink CM Service RequestMS1 Downlink CM Service Accept SDCCH分配成功MS1 Uplink SetupMS1 Downlink Call ProceedingMS1 Downlink Assignment CommandMS1 Uplink Assignment Complete TCH分配成功MS2 Uplink Channel RequestMS2 Downlink Immediate AssignmentMS2 Uplink Paging Response SDCCH分配成功MS2 Downlink SetupMS2 Uplink Call ConfirmedMS2 Downlink Assignment CommandMS2 Uplink Assignment Complete TCH分配成功MS2 Uplink AlertingMS1 Downlink AlertingMS2 Uplink ConnectMS2 Downlink Connect AcknowledgeMS1 Downlink ConnectMS1 Uplink Connect AcknowledgeMS1 Uplink DisconnectMS1 Downlink ReleaseMS1 Uplink Release CompleteMS2 Downlink DisconnectMS2 Uplink ReleaseMS1 Downlink Channel ReleaseMS2 Downlink Release CompleteMS2 Downlink Channel Release3. 案例介绍3.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,由此可以判断出此例并非是位置更新。