GSM网络SDCCH掉话分析报告.doc_第1页
GSM网络SDCCH掉话分析报告.doc_第2页
GSM网络SDCCH掉话分析报告.doc_第3页
GSM网络SDCCH掉话分析报告.doc_第4页
GSM网络SDCCH掉话分析报告.doc_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

gsm网络sdcch掉话分析报告综述:本次工作任务旨在对sdcch掉话的机理及其对网络的影响进行分析。在分析过程中,力求做到采用多途径及综合手段进行验证及分析,报告在最后部分针对当前发现的问题,提出了相应的优化和改进建议,希望能对移动公司的网络性能改善起到积极的作用。 omc部分的初步分析(bsc级):从p_nbsc_service,p_nbsc_traffic,p_nbsc_cc三个数据表中的bsc级测量统计来看,p_nbsc_cc中的phase 1下的clear code 21(corrupted establish_indication)的次数为9011次,p_nbsc_service中的t3101超时计数为9023次,p_nbsc_traffic中sdcch_abis接口掉话值为9283(也包括其它一些clearcode导致的掉话,由于nokia obs测量数据不可用,暂时无法通过causecode精细验证)。这三组数据具有比较明显的吻合性,初步证明t3101超时是导致sdcch abis接口掉话的主要原因。t3101的超时原理如下图表示:figure 1: t3101超时原理 如上图所示,在bsc下发imm_assign_cmd之后,在t3101的时限内如果没有收到上行的establishment_indication建立指示,则由系统下发强制sdcch拆线指令,以及时释放sdcch资源。 案例:梧田社保局 cellid:10552,bsc15,bts22,trx-2 过程描述:分别在3月10日,15日进行了两次abis接口挂表信令跟踪(bts22的trx2,bcch载频),通过对结果的观察分析,有如下发现: 1.实际捕获的sdcch占用请求次数为803次,拥塞2次,立即指配命令下发为801次。 2.有9次存在“trx having “error indication”case”错误提示。 该问题在信令分析仪中已有明确说明,为lapd链路计数器t200超时导致,由于该部分占sdcch掉话的比重很小,不再做具体分析。 3.有128次存在“trx where assigned sdcch are not used”错误提示。 详细分析信令内容,发现在系统发送imm_assign_cmd之后没有收到上行的establish_ind消息,而是直接对sdcch资源进行释放。观察imm_assign_cmd至channel_rel之间的时长,全部为5秒。检查bsc15的t3101设置值为5秒,基本确定目前几乎所有的sdcch_abis掉话均为t3101超时导致。符合先前依据nokia的omc统计的分析结果。同时观察无上行建立指示情况下的测量报告中(系统强制释放sdcch资源以前),观察到的所有的上行质量测量均为7(ber12.8%),场强也普遍较弱(基本在-100dbm左右)。 这部分由t3101超时导致的sdcch abis掉话在请求业务类型上的分配比例如下图所示:figure 2: sdcch掉话原因分类(nettest结果) *在主叫的sdcch占用失败中,需要考虑由于重发导致的再次掉话,这在信令中已经观察得到。sdcch needed目前没有确定是何种业务类型。 由上图可见,挂表的结果显示超过一半的sdcch_abis接口掉话发生在位置更新过程。 上图为梧田社保局在3月15日早忙时的omc数据,第二部分和第三部分的差值453次基本反映了sdcch_abis掉话的量值,当日同时段依据传统公式计算出来的sdcch_abis掉话次数为449次,表明了在此中间也有4次的失败事件并非由t3101超时引起。进一步分析omc数据: 在omc的countersdcch_moc_seiz_att无法区分位置更新请求次数和主叫请求次数,但是可以得知被叫请求次数,按主被叫概率基本相同来考虑,位置更新请求次数约为1886次,和成功的位置更新请求个数sdcch_loc_upd来对比,相差400次左右(abis掉话),可以认为449次sdcch_abis掉话中,位置更新过程中的掉话占了主要部分,这也和figure 2中挂表采集的信令中的观察结果相一致。同时,大致计算该基站位置更新过程中sdcch_abis的掉话率为400/1800=22%。 采取的实验措施: 1.调整同bcch同bsic。 2.开启sdcch切换。 3.将cbch信道转移到mbcch上。 效果不明显,该站客观存在13级的带外干扰,上行q0也很差。后续建议请参考后面总结部分的内容。 附加图示: figure 3: sdcch掉话率 vs 平均通话距离 figure 4: sdcch掉话率 vs 下行误码率figure 5: sdcch掉话率 vs 上行误码率figure 6: sdcch掉话率 vs 上行场强figure 7: sdcch掉话率 vs 下行场强 结论: 1.目前网络主要的sdcch掉话集中在abis接口。 2.abis接口的绝大部分掉话为t3101超时导致,比例在80%左右。 3.t3101超时的主要原因是立即指配过程中收不到上行的建立指示。 4.在无上行建立指示的测量报告中,观察到的所有的上行质量测量均为7(ber12.8%),场强也普遍较弱(基本在-100dbm左右)。 5.弱覆盖或网内外干扰是导致sdcch掉话的主要原因。 6.sdcch掉话行为主要发生在location update过程,并且在此过程中sdcch的掉话率也明显高于主被叫过程。 7.目前统计到的sdcch掉话不会对主被叫过程的客户感知度造成明显的影响。 建议: 1.有效控制网内干扰。 温州城区的站点密度较大,站高相对较高,同时基站全部为满功率发射,再加上建筑地形比较复杂,由此产生的越区覆盖容易导致孤岛效应并造成弱场强服务区或频率冲突,将对网络性能产生比较明显的负面影响。目前可以通过如下手段来控制该负面因素: a.充分利用功率控制,总体上降低网内上行发射水平。如目前温州的质量原因下降功率控制难以触发。 b.优化rach及ho access过程中的初始功率发射水平,通过popt,lev,levd等参数可以达到优化目的。 *温州以前的popt实验没有开启mspwroptlevel的feature,因而实际是无效的,建议重新开始该方面的实验工作。 c.合理控制天线下倾,避免严重越区覆盖的问题出现。

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论