1、  BSC的作用就是把此次呼叫分配的相关的信息，比如小区信息等，然后OMC对这些信息稍加的处理，并根据自己的实现方式调用存储过程把这些处理后的性能数据入库到相关的数据库，以供报表等使用。

2、  OMC可以看到原始的性能数据、失败的原因等；

3、  一般的查询过程：

1）  性能数据怎样，哪些指标偏低了。

2）  查询失败原因，看主要是什么失败原因的，主要分布在哪些小区/物理单板上的。

3）  查看一下历史告警信息，看一下哪些告警信息和这些失败原因相关的。

4）  根据实际情况进行相应的处理。

4、  比如：

1）  切换方面：看是不是相关资源分配不出来的？是否功率过载了？临区配置错误了？PN重用不合理？

2）  无线方面：小区功率过载了？载频配置不合理？RSSI值是否不合理？

3）  单板/资源方面：CE是否有、SVE/SDE是否没有？信道板/ SDM(分发板)有不好的单元？

4）话务量方面：主要是看释放的用户多少来决定话务量的，而不是根据呼叫的用户的。因为在呼叫建立过程中，时间很短的，总的话务量很小的；只有用户通话这段时间，特别是上网的时候，贡献的话务量就很可观的。

5、  可以加以辅助工具：

1）  进行信令跟踪，拨测一下，看是否这样的。

2）  进行业务观察，看一下都有哪些失败的。

小结：综合以上，可以分析一些问题了，对于比较繁琐的问题，只好另外处理了。这里只是提供一般性的指导。

和大家分享一下我近来处理的一个关于短信没有寻呼响应的问题：

一、短信的流程：

1、  MS发起起呼请求；

2、  BSC收到该消息后，进行一番简短的处理，给MSC发送CMServiceRequest；

3、  MSC进行合法性等的处理后，回指派请求消息；

4、  BTS建立好基本信道；

5、  捕获手机、信令握手、业务协商；

6、  BSC给MSC发送指派完成消息；

7、  MS发送短消息内容；（如果是控制信道，则不需要建立业务信道，直接发送）

8、  BSC转发给MSC；

9、  MSC转发给与之相连的SC(短信中心)；

10、              SC发送给MSC；

11、              MSC寻呼用户；

12、              BSC收到寻呼消息，开始寻呼用户；

13、              用户回响应，下面的过程和前面的起呼差不多，不再说了。

二、问题所在：

1、  短信的寻呼没响应次数很多，但是语音的却很少；

2、  查看BS侧的信令，发现无线环境不好，PN强度变化比较大（衰落比较快）；

三、问题分析过程：

1、  短信二次发送的时候，是从SC开始重新发送，对于MSC来说，是另一个新的呼叫；

2、  语音二次寻呼的时候，是从MSC开始的，对于MSC来说，是二次寻呼的；

3、  对于MSC来说，只要收到清除完成消息后，该用户状态就是空闲的；MSC此时可以直接寻呼该用户了。如果空中无线环境不好，导致MS释放的时候，比实际释放要稍微迟后一些。在这个过程中，用户由于状态不正确，不会回寻呼响应的，只好再次寻呼了。