王道春
【摘要】 针对目前所用软交换设备，对主叫呼叫流程进行阐述，并运用实例对由于放音问题引起的障碍进行分析处理。
【关键词】 主叫呼叫流程 端局放音
运营商之间或者运营商内部均使用了不同厂家软交换端局设备，这样设备对接时就会存在信令、放音等的协调配合等数据要求。一些特殊参数理解的不一致以及执行行业数据规范不到位，都会造成用户投诉出现，网络感知度受到一定的影响。下面就这一障碍进行论述。
1、首先阐述移动终端的呼叫流程，这样有助于我们对后续问题的分析处理。
主叫流程，移动用户做主叫时的信令过程是从MS向BTS请求信道开始，到主叫用户的TCH指配完成为止。主叫经过四个阶段：接入阶段，鉴权加密阶段，TCH指配阶段，取被叫用户路由信息阶段。接入阶段手机和BTS建立了暂时固定的关系；鉴权加密阶段完成对主叫用户的身份确认；TCH指配阶段实现主叫用户的话音信道的确定；取被叫用户路由信息阶段主要包括：MSC向HLR请求路由信息；HLR向VLR请求漫游号码；VLR回送被叫用户的漫游号码；HLR向MSC回送被叫用户的MSRN。MSC通过路由信息对被叫用户的路由信息分析，得到被叫用户的局向，然后进行话路接续。
当用户输入被叫号码进行呼叫时， MS将在随机接入信道向BSS发送信道请求专用信道消息。BSC为其分配相应的信道并通知MS；随后MS将在为其分配的SDCCH上发送业务类型为移动发起呼叫CM请求消息。该消息被BSS透明的传送至MSC，MSC收到CM业务请求消息后，通过处理接入请求消息通知VLR；由VLR在数据库中查询该MS是否有鉴权三参组；如果有，将直接向MSC下发鉴权命令； MSC收到VLR发送的鉴权命令后，通过BSS向MS下发鉴权请求，在该命令中含有鉴权参数，MS收到鉴权请求分析得出鉴权结果；通过鉴权响应消息送达MSC，再由MSC鉴权结果回送VLR，由VLR 核对MS上报的鉴权结果和从HLR取得的鉴权参数中的结果。鉴权通过后，VLR将向MSC下发加密命令，并通知MSC该MS此次接入请求已获通过，MSC通过BSS通知MS业务请求获得通过，然后MSC向MS下发加密命令；MS收到此命令并完成加密后，回送加密完成消息，到此MS完成了 整个接入阶段的工作。
经过接入阶段和鉴权加密过程，主叫用户合法身份得到确认，并接入网络。MS会发送呼叫建立消息；MSC收到此消息后向VLR查询该用户的相关业务信息，由VLR决定此次呼叫可以继续；通过完成呼叫消息向MSC回送该用户数据；MSC收到该信息后，通过呼叫继续消息，经BSS通知MS呼叫在继续处理之中，并向BSC发送指配请求消息指派接口电路；由BSC向BTS、MS指定无线资源，MS收到该指令后，占用成功回送分配完成消息，到此TCH指配阶段完成本局的无线资源和接口电路均已成功分配。MSC收到指配完成消息进行被叫分析，发送路由请求消息；HLR收到该消息后，根据被叫IMSI获取被叫所在的VLR，并向其请求漫游号码；被叫所在的VLR收到请求漫游号码消息为对应的MS分配MSRN，，然后在请求漫游号码响应消息中回送给HLR；HLR得到该MSRN后，向主叫所在MSC发送路由信息响应消息，MSC从该消息中得到被叫的MSRN；根据MSRN进行局间中继选路，并向被叫所在的MSC发送IAI消息。这样主叫信令流程基本结束。
2、对呼叫流程我们已经有了一个比较全面的认识。下面阐述一列由于没有按照规范的流程放音造成的障碍。此次障碍仅涉及到本端发起端局至对端落地端局的信令交互和话音搭建部分，涉及到主叫呼叫流程的部分环节。
用户现象描述为：近日频繁出现本网用户投诉拨打疆内异地电话，手机上显示“用户忙”，但是用户听不到任何提示音。我们对各种被叫情况进行了深入细致的拨打测试，结果显示属于交换提供的录音通知问题。问题具体详实描述是用户拨打本局用户，用户正忙或者拒绝，本局可以正常索引录音通知，主叫用户可听到提示音“您拨的用户正忙，请稍后再拨”；对于被叫用户是疆内非本局用户（主要是本网其他端局下用户），当被叫用户正忙或者拒绝时，主叫用户听不到任何语音提示，电话中断。
我们针对四种情况分本端局放音消息、对端局放音消息，分用户正忙和用户拒接进行信令跟踪，同时我们联系T局工程师同步进行跟踪。我们对4种情况进行了信令消息的对比；本局时均能正常听到正确的语音提示，而在对端局时存在问题。T局工程师给出了呼叫消息过程，并进行了问题定位。
对端端局给T局回ACM消息指示被叫局放音，同时消息中携带有被叫用户忙的原因值，告诉了用户正确的状态，如图1所示。
对端端端局没有被叫放音消息回复，然后续发送REL消息给T局要求拆线，如图2所示：
故障定位：T局工程师根据捕捉到的信令消息，确定故障为对端端局原因。依据通信行业相关数据规范规定：一般对于被叫用户状态应由落地局交换机进行放音，而对端局因为自身的某些问题，将其设置由被叫用户状态放音改为由主叫局进行放音。虽然此种由本端局进行放音，双方信令消息协调好在规范中也是可行的；但是由于对端局交换发给本端局的消息类型格式与本端局不匹配，造成本端局无法识别处理，不能正确提供主叫用户有效放音提示。影响现象就是——本端局用户拨打疆内对端局下用户（该用户正在通话中或者拒接），主叫用户听不到“被叫用户忙”的录音通知，直接退出呼叫状态。
解决方法：一是由对端局将被叫用户状态放音改回由对端局局放音；二是对端局严格按照ISUP消息信令格式指示本端局进行放音，使这个问题得到有效解决。但是解决此问题需要上级主管部门进行协调两家设备供应商才能得到有效地执行。因此我局就这一障碍形成文上报主管部门并及时地得到了解决。
通过这个实例我们能够认识到，要想进一步提高核心网维护技能，应该扎实掌握各种呼叫流程，准确理解所包含消息的含义；同时严格按照数据规范进行数据制作，对故障定位要能熟练运用信令跟踪，从而及时的排除故障。
【摘要】 针对目前所用软交换设备，对主叫呼叫流程进行阐述，并运用实例对由于放音问题引起的障碍进行分析处理。
【关键词】 主叫呼叫流程 端局放音
运营商之间或者运营商内部均使用了不同厂家软交换端局设备，这样设备对接时就会存在信令、放音等的协调配合等数据要求。一些特殊参数理解的不一致以及执行行业数据规范不到位，都会造成用户投诉出现，网络感知度受到一定的影响。下面就这一障碍进行论述。
1、首先阐述移动终端的呼叫流程，这样有助于我们对后续问题的分析处理。
主叫流程，移动用户做主叫时的信令过程是从MS向BTS请求信道开始，到主叫用户的TCH指配完成为止。主叫经过四个阶段：接入阶段，鉴权加密阶段，TCH指配阶段，取被叫用户路由信息阶段。接入阶段手机和BTS建立了暂时固定的关系；鉴权加密阶段完成对主叫用户的身份确认；TCH指配阶段实现主叫用户的话音信道的确定；取被叫用户路由信息阶段主要包括：MSC向HLR请求路由信息；HLR向VLR请求漫游号码；VLR回送被叫用户的漫游号码；HLR向MSC回送被叫用户的MSRN。MSC通过路由信息对被叫用户的路由信息分析，得到被叫用户的局向，然后进行话路接续。
当用户输入被叫号码进行呼叫时， MS将在随机接入信道向BSS发送信道请求专用信道消息。BSC为其分配相应的信道并通知MS；随后MS将在为其分配的SDCCH上发送业务类型为移动发起呼叫CM请求消息。该消息被BSS透明的传送至MSC，MSC收到CM业务请求消息后，通过处理接入请求消息通知VLR；由VLR在数据库中查询该MS是否有鉴权三参组；如果有，将直接向MSC下发鉴权命令； MSC收到VLR发送的鉴权命令后，通过BSS向MS下发鉴权请求，在该命令中含有鉴权参数，MS收到鉴权请求分析得出鉴权结果；通过鉴权响应消息送达MSC，再由MSC鉴权结果回送VLR，由VLR 核对MS上报的鉴权结果和从HLR取得的鉴权参数中的结果。鉴权通过后，VLR将向MSC下发加密命令，并通知MSC该MS此次接入请求已获通过，MSC通过BSS通知MS业务请求获得通过，然后MSC向MS下发加密命令；MS收到此命令并完成加密后，回送加密完成消息，到此MS完成了 整个接入阶段的工作。
经过接入阶段和鉴权加密过程，主叫用户合法身份得到确认，并接入网络。MS会发送呼叫建立消息；MSC收到此消息后向VLR查询该用户的相关业务信息，由VLR决定此次呼叫可以继续；通过完成呼叫消息向MSC回送该用户数据；MSC收到该信息后，通过呼叫继续消息，经BSS通知MS呼叫在继续处理之中，并向BSC发送指配请求消息指派接口电路；由BSC向BTS、MS指定无线资源，MS收到该指令后，占用成功回送分配完成消息，到此TCH指配阶段完成本局的无线资源和接口电路均已成功分配。MSC收到指配完成消息进行被叫分析，发送路由请求消息；HLR收到该消息后，根据被叫IMSI获取被叫所在的VLR，并向其请求漫游号码；被叫所在的VLR收到请求漫游号码消息为对应的MS分配MSRN，，然后在请求漫游号码响应消息中回送给HLR；HLR得到该MSRN后，向主叫所在MSC发送路由信息响应消息，MSC从该消息中得到被叫的MSRN；根据MSRN进行局间中继选路，并向被叫所在的MSC发送IAI消息。这样主叫信令流程基本结束。
2、对呼叫流程我们已经有了一个比较全面的认识。下面阐述一列由于没有按照规范的流程放音造成的障碍。此次障碍仅涉及到本端发起端局至对端落地端局的信令交互和话音搭建部分，涉及到主叫呼叫流程的部分环节。
用户现象描述为：近日频繁出现本网用户投诉拨打疆内异地电话，手机上显示“用户忙”，但是用户听不到任何提示音。我们对各种被叫情况进行了深入细致的拨打测试，结果显示属于交换提供的录音通知问题。问题具体详实描述是用户拨打本局用户，用户正忙或者拒绝，本局可以正常索引录音通知，主叫用户可听到提示音“您拨的用户正忙，请稍后再拨”；对于被叫用户是疆内非本局用户（主要是本网其他端局下用户），当被叫用户正忙或者拒绝时，主叫用户听不到任何语音提示，电话中断。
我们针对四种情况分本端局放音消息、对端局放音消息，分用户正忙和用户拒接进行信令跟踪，同时我们联系T局工程师同步进行跟踪。我们对4种情况进行了信令消息的对比；本局时均能正常听到正确的语音提示，而在对端局时存在问题。T局工程师给出了呼叫消息过程，并进行了问题定位。
对端端局给T局回ACM消息指示被叫局放音，同时消息中携带有被叫用户忙的原因值，告诉了用户正确的状态，如图1所示。
对端端端局没有被叫放音消息回复，然后续发送REL消息给T局要求拆线，如图2所示：
故障定位：T局工程师根据捕捉到的信令消息，确定故障为对端端局原因。依据通信行业相关数据规范规定：一般对于被叫用户状态应由落地局交换机进行放音，而对端局因为自身的某些问题，将其设置由被叫用户状态放音改为由主叫局进行放音。虽然此种由本端局进行放音，双方信令消息协调好在规范中也是可行的；但是由于对端局交换发给本端局的消息类型格式与本端局不匹配，造成本端局无法识别处理，不能正确提供主叫用户有效放音提示。影响现象就是——本端局用户拨打疆内对端局下用户（该用户正在通话中或者拒接），主叫用户听不到“被叫用户忙”的录音通知，直接退出呼叫状态。
解决方法：一是由对端局将被叫用户状态放音改回由对端局局放音；二是对端局严格按照ISUP消息信令格式指示本端局进行放音，使这个问题得到有效解决。但是解决此问题需要上级主管部门进行协调两家设备供应商才能得到有效地执行。因此我局就这一障碍形成文上报主管部门并及时地得到了解决。
通过这个实例我们能够认识到，要想进一步提高核心网维护技能，应该扎实掌握各种呼叫流程，准确理解所包含消息的含义；同时严格按照数据规范进行数据制作，对故障定位要能熟练运用信令跟踪，从而及时的排除故障。
【摘要】 针对目前所用软交换设备，对主叫呼叫流程进行阐述，并运用实例对由于放音问题引起的障碍进行分析处理。
【关键词】 主叫呼叫流程 端局放音
运营商之间或者运营商内部均使用了不同厂家软交换端局设备，这样设备对接时就会存在信令、放音等的协调配合等数据要求。一些特殊参数理解的不一致以及执行行业数据规范不到位，都会造成用户投诉出现，网络感知度受到一定的影响。下面就这一障碍进行论述。
1、首先阐述移动终端的呼叫流程，这样有助于我们对后续问题的分析处理。
主叫流程，移动用户做主叫时的信令过程是从MS向BTS请求信道开始，到主叫用户的TCH指配完成为止。主叫经过四个阶段：接入阶段，鉴权加密阶段，TCH指配阶段，取被叫用户路由信息阶段。接入阶段手机和BTS建立了暂时固定的关系；鉴权加密阶段完成对主叫用户的身份确认；TCH指配阶段实现主叫用户的话音信道的确定；取被叫用户路由信息阶段主要包括：MSC向HLR请求路由信息；HLR向VLR请求漫游号码；VLR回送被叫用户的漫游号码；HLR向MSC回送被叫用户的MSRN。MSC通过路由信息对被叫用户的路由信息分析，得到被叫用户的局向，然后进行话路接续。
当用户输入被叫号码进行呼叫时， MS将在随机接入信道向BSS发送信道请求专用信道消息。BSC为其分配相应的信道并通知MS；随后MS将在为其分配的SDCCH上发送业务类型为移动发起呼叫CM请求消息。该消息被BSS透明的传送至MSC，MSC收到CM业务请求消息后，通过处理接入请求消息通知VLR；由VLR在数据库中查询该MS是否有鉴权三参组；如果有，将直接向MSC下发鉴权命令； MSC收到VLR发送的鉴权命令后，通过BSS向MS下发鉴权请求，在该命令中含有鉴权参数，MS收到鉴权请求分析得出鉴权结果；通过鉴权响应消息送达MSC，再由MSC鉴权结果回送VLR，由VLR 核对MS上报的鉴权结果和从HLR取得的鉴权参数中的结果。鉴权通过后，VLR将向MSC下发加密命令，并通知MSC该MS此次接入请求已获通过，MSC通过BSS通知MS业务请求获得通过，然后MSC向MS下发加密命令；MS收到此命令并完成加密后，回送加密完成消息，到此MS完成了 整个接入阶段的工作。
经过接入阶段和鉴权加密过程，主叫用户合法身份得到确认，并接入网络。MS会发送呼叫建立消息；MSC收到此消息后向VLR查询该用户的相关业务信息，由VLR决定此次呼叫可以继续；通过完成呼叫消息向MSC回送该用户数据；MSC收到该信息后，通过呼叫继续消息，经BSS通知MS呼叫在继续处理之中，并向BSC发送指配请求消息指派接口电路；由BSC向BTS、MS指定无线资源，MS收到该指令后，占用成功回送分配完成消息，到此TCH指配阶段完成本局的无线资源和接口电路均已成功分配。MSC收到指配完成消息进行被叫分析，发送路由请求消息；HLR收到该消息后，根据被叫IMSI获取被叫所在的VLR，并向其请求漫游号码；被叫所在的VLR收到请求漫游号码消息为对应的MS分配MSRN，，然后在请求漫游号码响应消息中回送给HLR；HLR得到该MSRN后，向主叫所在MSC发送路由信息响应消息，MSC从该消息中得到被叫的MSRN；根据MSRN进行局间中继选路，并向被叫所在的MSC发送IAI消息。这样主叫信令流程基本结束。
2、对呼叫流程我们已经有了一个比较全面的认识。下面阐述一列由于没有按照规范的流程放音造成的障碍。此次障碍仅涉及到本端发起端局至对端落地端局的信令交互和话音搭建部分，涉及到主叫呼叫流程的部分环节。
用户现象描述为：近日频繁出现本网用户投诉拨打疆内异地电话，手机上显示“用户忙”，但是用户听不到任何提示音。我们对各种被叫情况进行了深入细致的拨打测试，结果显示属于交换提供的录音通知问题。问题具体详实描述是用户拨打本局用户，用户正忙或者拒绝，本局可以正常索引录音通知，主叫用户可听到提示音“您拨的用户正忙，请稍后再拨”；对于被叫用户是疆内非本局用户（主要是本网其他端局下用户），当被叫用户正忙或者拒绝时，主叫用户听不到任何语音提示，电话中断。
我们针对四种情况分本端局放音消息、对端局放音消息，分用户正忙和用户拒接进行信令跟踪，同时我们联系T局工程师同步进行跟踪。我们对4种情况进行了信令消息的对比；本局时均能正常听到正确的语音提示，而在对端局时存在问题。T局工程师给出了呼叫消息过程，并进行了问题定位。
对端端局给T局回ACM消息指示被叫局放音，同时消息中携带有被叫用户忙的原因值，告诉了用户正确的状态，如图1所示。
对端端端局没有被叫放音消息回复，然后续发送REL消息给T局要求拆线，如图2所示：
故障定位：T局工程师根据捕捉到的信令消息，确定故障为对端端局原因。依据通信行业相关数据规范规定：一般对于被叫用户状态应由落地局交换机进行放音，而对端局因为自身的某些问题，将其设置由被叫用户状态放音改为由主叫局进行放音。虽然此种由本端局进行放音，双方信令消息协调好在规范中也是可行的；但是由于对端局交换发给本端局的消息类型格式与本端局不匹配，造成本端局无法识别处理，不能正确提供主叫用户有效放音提示。影响现象就是——本端局用户拨打疆内对端局下用户（该用户正在通话中或者拒接），主叫用户听不到“被叫用户忙”的录音通知，直接退出呼叫状态。
解决方法：一是由对端局将被叫用户状态放音改回由对端局局放音；二是对端局严格按照ISUP消息信令格式指示本端局进行放音，使这个问题得到有效解决。但是解决此问题需要上级主管部门进行协调两家设备供应商才能得到有效地执行。因此我局就这一障碍形成文上报主管部门并及时地得到了解决。
通过这个实例我们能够认识到，要想进一步提高核心网维护技能，应该扎实掌握各种呼叫流程，准确理解所包含消息的含义；同时严格按照数据规范进行数据制作，对故障定位要能熟练运用信令跟踪，从而及时的排除故障。
