OMCR组日常工作流程

OMCR系统组工作流程TOC\o"1-3"\h\z一拥塞坏社区解决流程 21空闲＆接入状态时的参数设立 21.1RACH_TA_Filter＆Rxlev_acess_min＆Homargin的设立 21.2启动超忙社区CRO 22启动半速率信道 23启动TrafficHO(涉及话务负荷设立) 34启动fasttrafficHo＆T11，T11_forced 45减少BS_TXPWR_MAX基站发射功率 56根据路测组的天馈调整状况＆工程组替换站型等实际情况做出判决: 5二干扰坏社区解决流程 51减少MS_TXPWR_MAX基站发射功率 52具体高干扰性社区分析 62.1外部干扰OR内部干扰 62.2是否带有直放站等设备 6三新建站评估流程(新站评估人员归属于OMCR系统组) 61新站评估流程图 62人员配置和工作内容 73新站测试组基本工作内容 7四新站异常情况及解决流程 84.1OMCR组各种异常情况解决流程 94.2新站测试组各种异常情况解决流程 9五平常坏社区解决流程 105.1TCH分派失败解决流程 105.1.1TCH拥塞导致的失败 105.1.2硬件准备分派失败 115.1.3无线口接入分派失败 115.2切换成功率解决流程 125.3TCH掉话解决流程 145.3.1设备掉话解决 155.3.2传输故障掉话解决 165.3.3切换掉话解决 165.3.4空中链路掉话解决 18由近期NOSS指标来看，掉话坏社区、切换成功率等指标均处在良好的水平，OMCR组下阶段工作重要围绕集团公司巡检及拥塞坏社区、干扰社区及新建站3个重点来展开。总负责人：胡渊OMCR组：刘畅、李元琛、张开奥、赵留栓、王峰、刑灵均、敖猛、赵磊一拥塞坏社区解决流程负责人：王峰、李元琛、刑灵均、敖猛、刘畅目的：NOSS指标保持在0.25%(拥塞社区要做到0.15%,意味天天的拥塞坏社区必须做到7个以下,按照目前的网络实际状况来看,有难度,且晚忙时往往不可控;现网能控制到0.25%还是可行的,力争做到0.15%)拥塞社区解决方法:1空闲＆接入状态时的参数设立1.1RACH_TA_Filter＆Rxlev_acess_min＆Homargin的设立抬高RxLev_Access_Min来提高对社区接入的规定以平衡话务量。一般建议在一些基站密度较高、无线覆盖较好的地区调整RXLEV_ACCESS_MIN来均衡社区的业务量.增长切入拥塞社区的HOMargin来提高切入规定，减少服务社区的话务流入.减小切出拥塞社区的HOMargin,以利于切出，让服务社区的话务分流到社区.RACH_TA_Filter一般都是64,可以适当限制,把那些过覆盖的试呼滤除,可以起到适当减少话务负荷的作用。.建议值:根据网络实际情况调整1.2启动超忙社区CRO通过调整CRO、PT来改变社区重选，鼓励移动台尽量重选到话务量较低的社区。建议值：超忙社区的PT设成inactivity,则C2=C1-CRO,CRO越大，则本社区C2越低,更易重选到话务负荷不大的邻区.也就是说用提高CRO的值来加强移动台对邻社区的倾向性，CRO越大，对邻社区倾向越大。2启动半速率信道采用半速率社区的无线资源分派方式与服务社区的话务负荷有关。用来表达社区话务负荷的变量为LOAD_SV1，LOAD_SV1的值将决定是否把半速率话音信道分派给MS，调节半速率的门限值以使半速率社区优先占用半速率信道，尽量减少突发性的拥塞情况.OMCR缺省值为70%,90%,建议值THR_FR_LOAD_L_SV10%THR_FR_LOAD_D_SV10%,这样就能优先占用半速率信道.附半速率具体算法:LOAD_SV1的值为false，即社区话务负荷较低，社区将一方面分派全速率信道；若LOAD_SV1的值为True,即社区负荷较高，社区将一方面分派半速率信道;评估时候与LOAD_SV1的初始值也有关系.PreviousstateAV_LOADLOAD_SV1=FALSELOAD_SV1=TRUEAV_LOADTHR_FR_LOAD_L_SV1LOAD_SV1=FALSELOAD_SV1=FALSETHR_FR_LOAD_L_SV1AV_LOADTHR_FR_LOAD_U_SV1LOAD_SV1=FALSELOAD_SV1=TRUETHR_FR_LOAD_U_SV1AV_LOADLOAD_SV1=TRUELOAD_SV1=TRUE3启动TrafficHO(涉及话务负荷设立)TrafficHO是针对当前的高话务社区和周边的低话务社区而言的，由相邻的低话务社区来分担当前高话务的服务社区的话务量,以期达成减小拥塞,话务均衡的目的,这是一种临时解决拥塞的措施.从trafficHO发生的条件我们可以看出，只要当前社区处在HIGH_TRAFFIC_LOAD而邻社区处在LOW_TRAFFIC_LOAD，就可用发生trafficHO的切换,建议值：将话务忙的服务社区High_traffic_load设成60％，邻社区Low_traffic_load设成50％。附；TrafficHO具体算法DELTA_HO_MARGIN(0,n)<0dbANDPBGT(n)>HO_MARGIN(0,n)+offset_HO_Margin_inner+DELTA_HO_Margin(0,n)ANDEN_Traffic_HO(0,n)=ENABLE必要时可打开社区的Generalcapture(综合捕获切换),缓解该社区的话务负荷压力4启动fasttrafficHo＆T11，T11_forced结合T11的排队时长和FASTTRAFFICHANDOVE功能的启动，可以有效的减少社区拥塞。FTHO在所有通过PBGT_filter后的邻区中选择合适社区进行切换。只要邻区的BCCH信号足够的好，可以使服务社区中的MS话务及时切换到邻社区，空出的TCH时隙，使队列中的话务进入服务社区服务。当一个呼喊规定分派业务信道而社区又没有空闲的业务信道时，假如队列功能是打开的且有空闲位置，分派请求(AssignmentRequest)可以被排在队列中档待空闲的业务信道。呼喊在队列中档待的最大时间由定期器T11决定。加大T11和T11_Forced，也许会增长手机的呼喊等待时间，但可以减少社区的拥塞情况。建议值：EN_FAST_TRAFFIC_HO=TRUET11/T11_forced:14″or17″BTS_Q_LENGTH:64附FTHO具体算法:CAUSE=28(FasttrafficHO)AV_RXLEV_NCELL(n)>L_RXLEV_NCELL_DR(n)+max(0,[MS_TXPWR_MAX(n)-P])forn=1,...,BTSnum(HO-26)andt(n)>FREElevel_DR(n)andEN_CAUSE_28=enable队列中的电话队列中的电话对于FTHO的切换是没有‘乒乓效应’的。由于被选择执行FTHO的手机是在考察过目的社区无线环境较好的情况下发生的，那么它是不会发起紧急切换回到原服务社区的。5减少BS_TXPWR_MAX基站发射功率减少功率的目的就是减少社区的覆盖范围.建议值:根据现网实际情况,以2dB步长递减.6根据路测组的天馈调整状况＆工程组替换站型等实际情况做出判决:是否话务拥塞由以上两种因素导致,必要时需实地测试,新站或替换硬件导致的天馈问题定位后需立即告知工程组解决二干扰坏社区解决流程负责人：张开奥（OMCR）、徐华,胡卫明(现场扫频)目的：尽力查找干扰源,由于长春的网络结构导致底噪较高，要在短时期内减少干扰社区指标暂时有难度，现只能一个一个社区的解决。1减少MS_TXPWR_MAX基站发射功率减少手机功率的目的就是减少全网的低噪.建议值:根据现网实际情况,以2dB步长递减.2具体高干扰性社区分析2.1外部干扰OR内部干扰外部干扰：现场扫频，将干扰源位置提交局方。内部干扰：载频及ANC、ANY等硬件问题、频点问题、天馈问题。2.2是否带有直放站等设备检查直放站设备。三新建站评估流程(新站评估人员归属于OMCR系统组)负责人：赵留拴(OMCR)、赵磊(OMCR)DT测试人员：刘宏伟、张驰目的：不漏掉评估社区1新站评估流程图2人员配置和工作内容OMCR组，新站评估1涉及3小时评估和后续异常话务、指标分析等内容；2新旧数据对比；涉及比对天天的PRC数据3新站AbisTrace，包含同站的G网社区；DT组:新站评估测试，带塔工一名，便于现场调整；现场解决方位角与设计值不符(天线接反,方位角错误等情况)3新站测试组基本工作内容新站评估报告模版：PART1数据一致性核查核查项目一致性核查项目一致性核查项目一致性CellName一致BCCH一致NbrSDCCHLAC一致RaColorNbrTCHCI一致RaCodeGPRSNCC一致HopModeEN_EGPRSBCC一致Hardware_BSCMAX_PDCHTRX一致Hardware_BTSMin_PDCHBSC一致Hardware_SectorHopMode说明：社区信息基本数据同数据库吻合。PART2现场测试A、基站位置Longitude125.38639Latitude43.86886B、天线方位角Sector1Sector2Sector3注：非扇区型基站此项略C、天线照片Sector1Sector2Sector3D、天线型号（塔工抄录）Sector1：Sector2：Sector3：E、环基站DT测试切换情况：RxQualRxLevPART3整改规定及案例图如阻挡、接反需要工程重新实行的部分PART4其他问题及案例图可以现场完毕的部分，如机械参数不合理需要调整、参数设立不合理，覆盖区域不合理等。4.解决及复测跟踪情况四新站异常情况及解决流程负责人：赵留拴(OMCR)、赵磊(OMCR)DT测试人员：刘宏伟、张驰目的：第一时间发现异常新社区并整改4.1OMCR组各种异常情况解决流程边远新站开通前准备工作：RNP提供要开的边远新站，OMCR做G网的AbisTrace，得出其话务模型及热点话务分布情况；3小时评估机制中，一旦发现话务或者指标异常，即刻进行忙时AbisTrace，进行问题的初步定位，是否为硬件问题、TA分布问题等，这样可以给后期DT现场测试提供大体的分析思绪；测试组如碰到话务量较小的因素是由于方位角或下倾角引起，OMCR组等测试组现场调整完毕之后，即刻观测信道占用情况以及观测下小时话务记录情况，是否正常吸取话务；新站选择思绪问题：本次评估中发现少数覆盖农村的新站，各种天馈硬件均没有问题，但吸取不到话务，跟踪信令发现900M的话务分布在TA较大的区域，分析因素为D网的途径损耗有关，导致D网覆盖达不到G网覆盖区域，这种问题可否考虑农村等边远地区通过其他手段解决拥塞。4.2新站测试组各种异常情况解决流程各种天馈下倾角/方位角问题，现场调整、完毕复测，同时和OMCR组沟通观测调整后信道占用情况是否按预期变化等，并在现场等待观测结果，如所需等待时间较长，可以先做下一个较近的新站点；天馈接反问题：配合180数据及现场测试数据，判断接反类型，明确接反的扇区，做好社区占用连线图，告知移动用户接口，等待整改完之后复测；天线安装错误但天馈所连接硬件对的：此类问题现场发现之后，反映给用户接口和OMCR组，观测现场是否可调，如有调整余地，现场直接调整方位角并等待OMCR组观测并复测；天线类型问题：使用了不合理的天线如电倾天线等，现场告知OMCR组和移动，制定调整方案或者等待更换天线；各种阻挡、基站高度不合理，需要拍摄较为清楚可以说明问题的照片，并及时提交给局方进行整改；现场测试的其他问题：如以前没有碰到过的问题，现场测试发现需要立刻和OMCR组及移动沟通，争取做到现场解决。五平常坏社区解决流程5.1TCH分派失败解决流程负责人：王峰、李元琛、刑灵均、敖猛、刘畅目的：平常解决目前社区TCH分派失败记录为AssignmentRequest到AssignmentComplete之间的损耗。社区分派失败率定义为：100*(MC140a-MC718-MC142e-MC142f)/MC140a。其中140a为AssignmentRequest次数，718为AssignmentComplete次数，142e+142f为直接重试次数。定义网络分派失败率，是为了考察MS在TCH接入阶段系统和无线接口质量。根据信令流程分段，分派失败可以分为三部分：5.1.1TCH拥塞导致的失败其中拥塞分为以下几种情况：MC６１２A：未排队情况下的拥塞次数，有两种情况：MC６１２B：允许排队，但队列已满导致的拥塞。MC６１２C：允许排队，但在队列中档待时间超过T11仍未分派到资源的拥塞。MC６１２D：允许排队，但在排队过程中被更高优先级别的呼喊从等待队列中清除。其中MC612c相应的A口消息为ClearRequest，其余三种情况相应的A口消息为AssignmentFailure。假如社区记录中拥塞次数较高导致分派失败，且MC612a不为0，说明网络中没有启动TCH指配排队功能。排队功能在无线侧是以BSC为单位启动的。通常情况下，互换侧会打开排队指示功能，BSC的排队等待时间T11不设为0的情况下，当无可用TCH资源供分派时，即进入排队等待缓冲区。当互换侧未打开TCH排队功能时，也可以在无线侧启动强制排队开关QueueAnyway。同时，排队等待时长timer由T11改为T11_Forced。加大T11和T11_Forced，可以减少社区的拥塞情况，但也许会增长手机的呼喊等待时间。假如网络已经启动排队功能，仍存在较高的拥塞，则可以通过话务切换，调整覆盖等手段来均衡话务；假如已经没有调整余地，则需要提交给RNP方面进行社区扩容或者社区分裂来吸取话务，减少社区的拥塞次数。5.1.2硬件准备分派失败硬件准备分派失败记录公式如下：mc140a-mc718-746b-812，其中746b为空中接口接入时的分派失败次数，812为各种拥塞的综合。TCH分派假如由硬件故障导致，通常表现为社区中某些载频占用时常过短。解决此类问题，可以通过lock/unlock载频，lock/unlockTCU来观测分派失败变化情况，问题拟定后更换硬件，并重新调试。5.1.3无线口接入分派失败无线接口的分派失败次数为746b。通常情况下，社区分派时比率应保持在5%以下。TCH分派失败解决流程解决如下：对下发AssignmentCommand到AssignmentComplete之间的损耗，重要有以下几种因素：基站天馈系统存在鸳鸯线基站过覆盖基站弱覆盖上下行干扰网内存在二次中继设备，而此设备对某些频段不兼容，例如某些直放站不支持EGSM。解决TCH分派失败，需要通过多种手段，涉及参数分析调整，DT测试，信令跟踪，RNP频率分析等。5.2切换成功率解决流程负责人：王峰、李元琛、刑灵均、敖猛、刘畅目的：平常解决切换成功率也是考核网络性能的一个重要指标，通常切换成功率应保持在95%以上。切换失败重要分为两部分：切换准备失败和切换执行失败。对于切换准备失败，BSC内的因素重要有目的社区拥塞，硬件问题等，其解决方法和BSC硬件分派失败相同。对于跨MSC的切换，涉及E口信令转换，编码方式沟通等因素，需要信令跟踪分析，参见BSC切换成功率的解决。以下仅对切换执行失败的重要解决流程进行说明。切换失败解决流程如下：解决切换失败，一方面区分是BSC内切换失败还是BSC间切换失败。判断方法根据110报告中的相关counter，参见BSC切换准备失败解决中的表格。当切换执行失败重要为跨BSC间切换时，需要跟踪信令排除信令配合问题。另一方面，检查切换失败是切入失败还是切出失败，或者切入切出成功率均低。假如切入切出均低，一般该切入切出成功率均在75%以下，同时本社区的分派失败又不高，通常是由于BTS时钟偏移导致，更换SUMP板或者调整时钟即可。假如仅切入成功率低，检查180报告，该报告针对每一条切换关系进行记录，记录内容包含切换切入请求MC400，切换尝试MC401及切换成功MC402。通过检查这几个counter来拟定切入失败是集中在某几条切换关系还是所有的切入都差。假如所有切换失败都差，则参见社区分派失败率流程进行解决。假如只有某几条切换失败较高，需要RNP核查，看是否有同BCCH，BSIC的误切换发生。假如切出成功率差，同样检查180报告，切出差是集中在某几条切换关系还是所有切换关系。对集中在某几条切出差的情况，根据分派失败的解决流程检查目的社区。对所有切出均差的情况，需要检查社区覆盖，社区硬件性能，及上下行干扰等，参见社区切换成功率的解决。5.3TCH掉话解决流程负责人：王峰、李元琛、刑灵均、敖猛、刘畅目的：平常解决TCH掉话率反映了TCH成功建立后的呼喊保持能力，是衡量网络质量的一个重要指标。集团公司的对掉话坏社区的考核门限是3%。TCH掉话，从记录上分为四块：设备故障掉话，相应counter为MC14C传输故障掉话，相应counter为MC739切换掉话，相应counter为MC621空中链路掉话，相应counter为MC736掉话解决的框架图如下：5.3.1设备掉话解决减少和减少设备掉话率，需要提高设备平常维护质量。最常见的设备掉话解决流程如下：通常设备掉话重要和TRE，TCU，SWITCH三个单元相关。当设备掉话集中在某一个载频上时，更换该载频；当设备掉话集中在几个载频上，且这几个载频共属同已块TCU管理，则更换TCU；假如一个BSC下有多个社区存在设备掉话，且分布均匀，则需要对该BSC进行硬件调测，一般该设备掉话由SWITCH模块故障导致。5.3.2传输故障掉话解决解决传输掉话，一方面检查传输链路的告警。建议在网络优化工程中，定期（例如一周）对网络中出现频次较多的传输链路进行统一检查和整治。5.3.3切换掉话解决切换掉话是当手机接受到系统下发的切换命令handovercommand后，向目的信道转换，在限定的时间内，既没有成功切入目的信道，也没有安全返回本来信道。切换掉话可以根据切换的种类分为三部分，如下：MC621（切换掉话）=MC648（跨BSC切换掉话）+MC658（BSC内切换掉话）+MC663（社区内切换掉话）。BSC内切换掉话：当BSC向手机发出切换命令handovercommand时，T3103开始计时，在BSC收到来自切换目的社区的切换完毕handovercomplete或者来自源社区的切换失败handoverfailure时将T3103复位，假如handover下发后，T3103逾时仍未收到以上两条消息，则记为一次BSC内切换掉话。社区内切换掉话：社区内切换掉话与TCH分派失败无返回SDCCH类似。跨BSC切换掉话：与BSC内切换掉话类似，只是T3103变为T8。切换掉话解决流程如下：社区内切换的过程和SDCCH到TCH之间的信道转换过程类似，一般出现高掉话的因素重要有载频硬件故障和上下行干扰严重。社区间的切换，一方面需要检查切换关系定义是否正常，然后检查切换参数，切换门限等，此外可以通过检查180报告和实际的地理位置信息，察看实际发生的切换是否合理。假如这些均正常，说明这些切换的发生是必要的，其切换掉话重要因素还是无限链路恶化导致的。跨BSC的切换，假如涉及到跨MSC的情况，其流