通信人家园
标题: 语音提示问题分析与定位步骤 [查看完整版帖子] [打印本页]
时间: 2014-2-8 09:11
作者: huanght
标题: 语音提示问题分析与定位步骤
1 问题表象
GSM的语音提示是由GSM网络中的MSC控制的，向主叫用户播放。MSC根据消息的不同原因值以及数据配置，播放语音板相应通道、预先录制的提示音。其中比较典型的语音提示问题有以下具体表象：
1、被叫用户在空闲状态下，提示“您拨打的用户正忙”或“您拨打的用户已关机”
2、被叫用户在空闲状态下，提示“您拨打的用户已出服务区”
3、被叫用户在空闲状态下，提示“您拨打的用户暂时无法接通”
产生上述现象的原因主要有以下几点：NSS侧用户状态管理出现异常、取漫游号码失败及寻呼无响应。
2 原因分析语音提示问题的具体原因有以下一些：
2.1 NSS侧用户状态管理若NSS侧用户状态管理出现异常，请联系NSS相关技术专家解决。
2.2 取漫游号码失败NSS网络侧问题，如：MSC至HLR的七号链路出现高误码、信令点不可达、未配置路由数据等等。若语音提示对应的原因值为“取漫游号码失败”，请联系NSS人员，检查NSS相关部分。
2.3 寻呼无响应即经常遇到的“您拨打的用户已出服务区”问题：这是一个系统级的问题，与GSM系统的每一个产品MSC、BSC、BTS、MS或站点分布、工程质量等有关，需要进一步定位。详细内容请参考“2.2产生用户已出服务区现象的原因分析”。需要注意的是：
2.3.1、在GSM网络中，由于无线信道的拥塞、无线信号的覆盖不充分等原因，偶尔出现用户寻呼无响应现象是必然的，也是正常的，这一点应向局方解释清楚。
2.3.2、请注意不同基站版本的测量报告电平测量值的偏移量是不同的，具体的参数设置原则请向中研BTS接口人索取。
2.4 语音提示问题与BSCBSC可以通过维护台跟踪所有有关寻呼以及寻呼响应的消息，跟踪方法简便成熟。通过现场大量拨测、并对所有跟踪到的语音提示问题进行了分析（包括用MA10跟踪到的ABIS口消息），结果表明BSC的处理是正确的。
注：“用户已出服务区”和“用户暂时无法接通”，分别对应于“寻呼无响应”和“取漫游号码失败”两种原因。由于各局的语音板版本不同，参数配置及录音不同，两者之间的对应关系可能出现交错。
目前MSC对这两种情况的语音提示没有一个明确的标准，从网上的实际应用来看（包括国外厂商的设备），各地的标准也不一样：对于寻呼无响应，有的网络送“用户已出服务区”提示音，有的网络送“用户暂时无法接通”的提示音。
一般情况下，“用户已出服务区”对应的原因值为“寻呼无响应”，“用户暂时无法接通”对应的原因值为“取漫游号码失败”。为便于描述，下面均按照此对应关系进行分析。
3 对用户已出服务区问题的分析3.1寻呼策略产生“用户已出服务区”问题的根本原因是寻呼响应超时或寻呼无响应，有必要对寻呼规程进行分析。目前我司的寻呼策略按照MSC，BSC，BTS划分，由下述三部分组成：
1、MSC寻呼重发和寻呼方式选择
MSC最多可重发4次寻呼，如果没有收到上一次寻呼的寻呼响应，则会进行重发。重发的时间间隔分别为3秒，3秒，2秒，2秒，最后一次寻呼下发后2秒，即第1次寻呼下发12秒后，如果寻呼响应没有上报，则MSC认为寻呼响应超时，并报用户不在服务区的语音提示。MSC可选择采用TMSI寻呼和IMSI寻呼两种方式。
2、BSC寻呼组计算和寻呼消息模块间转发
BSC收到MSC下发的Paging Request后，根据IMSI的最后三位以及某个小区的CCCH信道配置和寻呼块的配置，计算某个寻呼所属的寻呼组，然后向该小区下发Paging Command。在多模块情况下，还需要将该寻呼命令在不同的模块间转发。
3、BTS寻呼排队和寻呼合并
BTS收到BSC下发的Paging Command后，将该寻呼存放在Paging Command所指明的寻呼组队列中，每隔相同寻呼间帧周期下发该寻呼组的寻呼内容，目前BTS每个寻呼组队列长度为9。在一个寻呼保留块中，可以下发2个IMSI寻呼或者4个TMSI寻呼，因此每次下发寻呼时，BTS要针对队列中的寻呼消息类型完成寻呼的合并。
MS也参与寻呼的流程
4、MS的寻呼侦听和寻呼响应
空闲状态下手机除了接收广播信道上的系统消息，同时还侦听在自己所属的寻呼子信道上（Paging Subchannel)。因此手机接收到对自己的寻呼之后，将向网络侧发出信道请求，完成一次立即指配过程。如果此次立即指配成功，则在指配到的SDCCH信道上上报寻呼响应（Paging Response），同时完成呼叫的接续过程。
以上关于寻呼的4个环节中，任何一个环节出现异常，都将导致用户已出服务区问题产生。
3.2 寻呼流程空闲状态下，手机都驻留在某一个小区中，每个小区属于一个位置区，手机的位置区信息保存在VLR中。当一个手机做被叫时，MSC从VLR里读取该手机的位置区和状态信息，如果是“附着，空闲”状态时，就向该位置区所属的BSC发起寻呼请求（Paging Request），BSC计算出该手机的寻呼子组，构造寻呼命令（Paging Command），向该位置区所有小区下发寻呼命令。空闲状态下手机除了接收广播信道上的系统消息，同时还侦听在自己所属的寻呼子信道上（Paging Subchannel)。因此手机接收到对自己的寻呼之后，将向网络侧发出信道请求，完成一次立即指配过程。如果此次立即指配成功，则在指配到的SDCCH信道上上报寻呼响应（Paging Response），同时完成呼叫的接续过程。
注：寻呼响应消息在建立指示Establishment Indication中上报
以大理联通网络目前的配置为例来说明，整个大理州的小区属于同一个位置区，各小区公共控制信道参数配置如下：
一个非组合的CCCH
相同寻呼间帧数：6
接入保留块数： 1
这样，每个小区中有6*（9-1）= 48个寻呼组，各手机根据自己的IMSI号最后三位以及寻呼组的数量确定所属的寻呼组，然后侦听在相应的子信道上。如13013362000的手机，对应IMSI号为460013361000037，IMSI号最后三位是037，它的寻呼子组是37。该手机在空闲状态下始终侦听在37号寻呼组所对应的寻呼子信道上。如果有用户拨打13013362000，将在大理州各小区中发送对该用户的寻呼。该手机收到对460013361000037的寻呼后，将发起信道请求，并根据网络侧的立即指配完成一次立即指配规程。如果小区中有空闲可用的SDCCH信道，将分配给该手机一个SDCCH信道，手机在此信道上建立连接，并上报寻呼响应。
3.3 用户已出服务区现象的原因分析产生用户不在服务区问题的原因是手机对寻呼的响应超时或者无响应，从寻呼响应上报的流程以及实际处理的案例分析，出现这种现象主要有以下几个原因：
3.3.1 MSC用户状态管理如果MSC用户状态管理出现问题，寻呼请求无法下发给BSC，则MS无法收到寻呼，也无法做出响应，就会出现寻呼响应超时。在实际的处理中，出现过MSC没有下发寻呼的情况。此外还出现过用出现问题的被叫用户做主叫，出现3 Tick释放的异常情况。这种情况比较难重现。可通过MSC维护台的GSM用户接口跟踪确认此问题，详细步骤见后。
3.3.2 基站接收部分如果基站的接收部分，包括DSP、TRX、天馈等部分存在问题，无法有效检测到手机的接入脉冲，或者无法在指定时间内和手机建立联系，则无法向BSC上报寻呼响应（实质上是建立指示消息），就会出现寻呼响应超时或者无寻呼响应。例如，我们在大理发现T2688上网慢，在去除功放、天馈后，上网速度提高至少10秒。由于这种情况牵涉到空中接口，并且有时是由于MS的问题造成的，因此较难定位，需要基站专家用专门的仪器设备来定位解决。
3.3.3 手机假上网与寻网模式的差异按照协议规范，MS进行开关机操作必须进行位置更新，并且按照系统的要求进行IMSI分离。而有一些手机（主要是Ericsson手机），在开关机时有可能不进行上述操作。例如开机时没有进行位置更新，手机显示已经上网，而实际没有任何消息上报，用户状态没有发生改变，拨打该用户就仍然会提示关机；又例如在关机时没有进行IMSI分离，则用户状态仍然是“附着”，拨打该用户时仍然会下发对该用户的寻呼，超时后会提示用户已出服务区。
不同手机掉网后寻网模式与速度的差异，导致掉网后很长时间无法上网，因而出现用户已出服务区问题。 在GSM 02和03系列协议中规定，手机掉网后将根据尽快找网和节省电池的两个原则搜索网络。手机将按照接收信号的强度递减的顺序选择频点尝试上网。900M手机将搜索30个频点，1800M手机将搜索40个BCCH频点，双频手机将搜索70个频点。在尝试失败后，手机将根据自己的算法决定下一次尝试什么时候启动。各个型号的手机有不同的算法。例如在Motorola某些款式的手机中可以设置查找网络的频度，在慢速找网模式下，手机掉网并重新进入覆盖区后上网的时间为50分钟左右。此外不同厂家的手机在选网模式上有所区别。某些手机在连续几次找网均失败时，将在后续的很长一段时间内停止找网。因此，此问题与用户的手机行为有关，可以通过手机关电、开电解决。
3.3.4无线链路上下行不平衡无线信号根据传播方向分为上行和下行两个方向，在理想情况下上下行链路是平衡的，即在任何区域基站侧和手机侧均可以同时收到对方的信号，或者同时无法收到对方的信号。由于无线信号传播路径的不确定性以及实际环境的差异，在整网范围内完全实现无线链路上下行平衡是不可能的。因此网络中必然存在下行信号可以覆盖而上行信号无法覆盖到的区域，在这些区域内，用户可以收到网络侧的消息而网络侧无法收到用户手机上报的消息，包括寻呼响应。因此在这些区域内也很容易出现用户已出服务区的现象。对于这种情况的用户已出服务区现象，首先可以通过调整无线参数，“RACH忙门限”、“RACH错误门限”、“MS最小接入电平”、“RSSI校正”等值来优化上下行平衡关系，此外尤其要注意不同基站版本的测量报告电平测量值的偏移量是不同的，参数设置原则请向BTS中研接口人索取。
3.3.5 SDDCH拥塞手机收到寻呼命令后，会向网络侧发起信道请求，如果没有可用SDCCH信道，或者在SDCCH信道建立连接过程中失败，寻呼响应无法送到网络侧，就会出现“用户已出服务区”问题。SDCCH拥塞产生的原因一般为SDCCH占用遇全忙、随机出现的无线链路失败等。对于SDCCH占用遇全忙的情况，应适当调整该小区的覆盖范围，以减少SDCCH拥塞。对于其它原因引起的拥塞，如随机出现的无线链路失败，地面链路失败等，要结合具体情况来解决。
3.3.6 PCH过载网络中的寻呼消息是随机的，由于无线信道的结构的限制，寻呼命令发送的能力有限，因此就有可能出现某个寻呼组过载，而导致某些寻呼消息不能及时发送，并且重发的寻呼无法在有效时间内得到响应，就会出现“用户已出服务区”问题。
对于这种情况，首先可以通过修改CCCH配置参数“相同寻呼间帧数”，“接入保留块数”，“CCCH信道配置”来改善。适当减少“接入保留块数”可以增加PCH子信道数，从而提高了寻呼信道的容量；减小“相同寻呼间帧数”可以提高寻呼消息发送的频度；增加小区的CCCH信道的个数可以大大提高系统的寻呼能力，但此时将减少TCH的配置个数，一般不采用。其次，如果PCH过载现象非常严重，就需要减小位置区的大小，从而降低寻呼消息的流量。
3.3.7 手机质量有些手机因为射频模块损坏，天线松动，或电池故障等原因，接收灵敏度降低、上行信号质量差，对寻呼命令的接收、接入网络的能力下降，因此这类手机很容易出现用户已出服务区现象。对手机质量的确认有时需要专门的仪器。手机问题表现在如下几个方面：
1、手机电源问题：导致上行发射功率不足，上行无法接入
2、手机软件问题：导致手机异常掉死，无法对寻呼消息进行响应
3、手机射频部分存在问题：导致无线接收、发射不稳定，或者在某些频段内频偏较大
在我们处理的“用户已出服务区”问题投诉中，手机问题占有很大的比例。如：NOKIA 5110，Ericsson GA628，Panasonic，Motorola L2000、Seimens 3508等手机用户的投诉，都属于用户手机问题。手机质量问题也是一个不容忽视的重要因素。
3.3.8覆盖不全面在无线信号覆盖不好的区域，一般是在室内，容易出现用户信号不好，甚至掉网的现象。由于此时VLR中的用户状态并未改变，因此当对该用户进行呼叫时，网络侧可以正常下发寻呼消息，但是用户无法收到寻呼消息，无法对寻呼做出响应；或者由于信号质量的原因，寻呼响应无法送达网络侧。此时出现用户已出服务区是属于正常现象。对于这种情况的用户已出服务区现象，通过增加站点，完善覆盖可以得到很大的改善。
在实际的投诉案例中，由于覆盖问题造成的用户不在服务区问题占有相当的比例。
3.3.9补充说明在无线网络中，由于无线信道的拥塞、无线信号的覆盖等原因，出现“寻呼无响应”的现象是必然，偶尔出现用户寻呼无响应现象是正常的，这一点应向局方解释清楚。
在某些覆盖不好的区域，由于信号质量不好会出现寻呼或寻呼响应消息无法送到对端，出现用户已出服务区现象。
如：由于SDCCH信道的短时拥塞，无法给MS指配SDCCH信道，寻呼响应无法上报，出现第一次拨打提示用户已出服务区，第二次拨打却可能接通的情况；多次拨打某一特定用户，由于该用户在某一个小区中所处的寻呼子信道是固定的，因此该用户对应的寻呼子信道过载的概率大大增加，多次拨打中就可能偶然出现一次用户已出服务区现象。这些现象都属于正常的寻呼无响应。
只有长时间、多次尝试拨打某一信号很好的空闲被叫用户，均提示为“用户已出服务区”才是异常现象。
4 出现用户已出服务区的定位步骤1、在OMC浏览器上输入超级口令“ThisIsTony”
2、打开MSC维护台，进入GSM用户接口跟踪，输入主叫、被叫的用户MSISDN号码，如8613013442000，注意将内部接口选上，以便于MSC分析内部信令，这个窗口的信令可以点击鼠标右键，选择“保存消息”保存；同时打开GSM用户跟踪和用户基本信息两个窗口，这两个窗口的信息可以通过的拷屏的方式保存
3、如果有MA10，将MA10接到拨测用户所在小区的基站Abis接口，跟踪该小区（站点）所有RSL链路。如果没有MA10，请打开BSC维护台，选择 [跟踪/GSM跟踪/GSM接口跟踪] ，输入拨测用户所在的小区号，在消息过滤中去除TRX管理消息
注：由于Abis接口的消息比较多，在必要的情况下可以在消息过滤中去除测量报告
4、拨打被跟踪的用户，观察MSC的用户接口跟踪，如果主叫方的消息中有寻呼响应消息，而此时提示音对应的原因值仍然为“寻呼无响应”，则问题在MSC侧；如果主被叫方都没有寻呼消息，则说明MSC没有下发寻呼，问题出在MSC侧；如果有寻呼消息而没有寻呼响应消息，则观察BSC维护台
5、在观察BSC维护台前，请首先先查找被叫用户的IMSI号码，以查找被叫用户的寻呼消息是否正常下发；其次要在BSC数据管理台上检查该小区的系统消息配置数据：[小区/系统消息数据表中的“接入允许保留块数”、“相同寻呼间帧数”和“CCCH配置”，由这两个参数计算寻呼组的个数，具体算法为 ：寻呼组 =（IMSI的最后三位） mod （寻呼组个数）： 寻呼组个数 = （相同寻呼间帧数 * （9 - 接入允许保留块数）） * CCCH配置个数。例如相同寻呼间帧数为5，接入允许保留块数为2，则寻呼组的个数为35。观察BSC维护台的Abis接口跟踪，寻找是否存在对被叫用户的寻呼消息（通过IMSI查找），以及对该被叫用户的寻呼组计算是否正确。寻呼组的计算方法为：例如IMSI为46001133650054的用户，在接入允许保留块数为2，相同寻呼间帧数为5，CCCH配置为1个非组合CCCH的小区，它的寻呼组为54 mod 35 = 19，对应16进制为13。如果从Abis接口观察到了对被叫用户的寻呼消息，而且寻呼组计算正确，则说明BSC已经正确下发了寻呼消息
注：Abis接口跟踪的寻呼组是以16进制表示的
6、继续观察BSC维护台Abis接口跟踪，查找被叫用户的寻呼响应。查找的方法为：根据被叫的IMSI号码，查找这段时间内的建立指示消息（EST_IND），SDCCH上该消息包含这次建立指示的IMSI号码。如果在Abis接口上观察到了被叫的建立指示，而同时在MSC用户接口跟踪上没有观察到寻呼响应消息，则说明BSC没有向MSC送寻呼响应；如果Abis接口上没有观察到被叫的建立指示，则说明BSC确实没有收到被叫的寻呼响应
7、如果排除了MSC，BSC的问题，可以确认是BTS或者MS的问题。请参考后面的一些典型案例
8、最后，可以用出现问题的被叫用户做主叫，观察MSC用户接口以及BSC维护台Abis接口跟踪，看能否打通电话
重要：遇到语音提示问题后首先应该截获信令并保存，包括MSC的用户接口跟踪以及BSC的Abis接口跟踪，千万不要立刻进行开关机操作
| 通信人家园 (https://www.txrjy.com/) |
Powered by C114 |