位置更新影响TD接通率问题解决方案(主被叫位置区更新).docx

位置更新影响td接通率问题解决方案1概述52位置更新对接通率的影响分析53减少位置更新次数63.1合理规划lac区边界63.1.1问题描述63.1.2解决办法1（推荐）73.1.3解决办法273.2合并多个相邻rnc到同一msc下73.2.1问题描述73.2.2解决办法73.32g/3g共msc83.3.1问题描述83.3.21）相比msc内的位置更新，msc间位置更新增加了居间用户数据插入过程，因此会导致位置区更新时间增加大约1.5s。83.3.3解决办法83.4msc pool解决方案83.5调整3g/2g切换重选门限参数83.5.1问题描述83.5.2解决办法94缩短位置更新流程时间94.1提升gsm系统消息下发效率94.1.1问题描述94.1.2解决办法94.2ue/bsc实现fast return104.2.1问题描述104.2.2解决办法105优化寻呼策略105.1设置核心网寻呼等待机制105.1.1问题描述105.1.2解决办法105.2增加msc/rnc寻呼次数115.2.1问题描述115.2.2解决办法115.3实现msc系统间寻呼115.3.1问题描述115.3.2解决办法115.42g bsc启用cs/ps联合寻呼125.4.1问题描述125.4.2解决办法126主叫位置更新对接通率影响_案例分析12【现象描述】12cm service reject造成的block情况如下表所示12【原因分析】12location update引起的呼叫未接通13【处理过程】16【总结建议】17 td接通率提升解决方案keywords 关键词：td-scdma 接通率 位置更新 寻呼abstract 摘 要：本文主要有效减少位置更新次数、缩短位置更新流程时间、优化寻呼策略角度，提出可行的方案，以解决由于位置更新导致的接通率低问题。list of abbreviations 缩略语清单：abbreviations缩略语full spelling 英文全名chinese explanation 中文解释td-scdmatime division syncronized code division multiple access时分同步码分多址mscmobile switching center移动交换中心ggsngateway gprs support node网关gprs支持节点sgsnservice gprs support node服务gprs支持节点rncraido network controler无线网络控制器bscbase station controler基站控制器1 概述接通率是移动集团重点关注的网络指标。根据移动集团多次路测以及我司网络路测结果统计，由于位置更新导致的接通失败占了接通失败总数的40左右，其中既有系统间切换导致的位置更新，也有系统内（跨rnc）切换导致的位置更新。本文主要介绍如何有效控制位置更新对td接通率的影响，有效提升td接通率指标。2 位置更新对接通率的影响分析由于ue在位置更新过程种无法接收寻呼消息，因此位置更新过程中ue基本属于脱网状态，在位置更新过程中，ue必然无法被寻呼到而影响寻呼成功率，位置更新影响寻呼成功率进而影响接通率是g/c/w/t所有移动网络普遍存在的问题。位置更新可以分为3种：td系统内msc内位置更新、td系统内跨msc位置更新、td-gsm跨msc位置更新。可从3个方面来减小位置更新对接通率的影响，每个方面的具体措施详见下述位置更新影响td接通率问题解决措施分析： 1）减少位置更新次数和频度 2）缩短位置更新流程时间 3）优化寻呼策略图1 减小位置更新对td接通率的影响措施分析图3 减少位置更新次数3.1 合理规划lac区边界3.1.1 问题描述目前td现网都一般是一个rnc一个lac区设置（gsm一般也是一个bsc一个lac），这样，在用户跨rnc移动中，势必会带来位置更新，导致接通率下降。下图为成都某次空闲态测试的位置区更新分布情况，可见由于市中心区的rnc覆盖范围较小，发生位置更新非常密集。3.1.2 解决办法1（推荐）避免以主干道为rnc的分界线，这样会导致终端在路上频繁进行rnc间重选及位置更新。如果存在类似情况，需尽可能将覆盖道路的nodeb割接到同一rnc下。适用场景：非城市核心的密集街道区域。3.1.3 解决办法2调整rnc覆盖区域，一个rnc覆盖的范围不宜太小。适用场景：城市核心区域。主要缺点：从业务发展角度，用户量大幅增加后会增加重新规划的难度。 3.2 合并多个相邻rnc到同一msc下3.2.1 问题描述部分城市为提高网络可靠性，rnc为插花式布置，这样rnc间的位置更新成为msc之间的位置更新，由于msc之间无法做位置更新时的寻呼等待，也不能进行联合全网寻呼，因此接通率降低。另外，由于msc间的位置更新时间比msc内的位置更新时间要长1.5s左右，也会进一步造成接通率的下降。3.2.2 解决办法调整网络结构，将相邻rnc尽量放在同一msc下面，尤其是边界较长的相邻rnc。3.3 2g/3g共msc3.3.1 问题描述3.3.2 1）相比msc内的位置更新，msc间位置更新增加了居间用户数据插入过程，因此会导致位置区更新时间增加大约1.5s。2）由于2g/3g核心网分设，系统间重选时，无法实现如3.2节描述的同一msc内的寻呼等待功能，也无法实现3.3节描述的msc内开全网寻呼功能。3.3.3 解决办法2g/3g共msc组网，减少系统间重选时位置更新的时延。主要问题及建议：由于共msc组网后，一个msc下可以挂接的rnc数量或bsc数量减少了，因此，此方案虽然可以减少系统间位置区更新时间，也可以支持同一msc内系统间重选时的寻呼等待功能，但同时也会增加系统内位置更新时间，减少了系统内同一msc内寻呼等待功能的效果。因此，应用时需要根据路测和kpi分析的结果，权衡是否有必要实施共核心网。这一问题根本的解决方案是msc pool。3.4 msc pool解决方案mscpool可以管理全网的所有lac，通过在全网实施msc pool，ue在msc pool内移动将不再需要进行频繁的位置更新，从而从根本上解决位置更新影响接通率的问题。由于目前td/gsm融合组msc pool还未有完备的现网测试，因此近期无法支持二期网络的性能提升。3.5 调整3g/2g切换重选门限参数3.5.1 问题描述每发生一次td-gsm切换重选，ue就需要分别在2g和3g网络内各进行1次位置更新，更新时间长达30秒，这段时间ue脱网无法接收寻呼，势必影响接通率。3.5.2 解决办法调整3g-2g切换重选门限参数，降低td-gsm跨msc位置更新的次数，进而降低ue脱网的时间，提升接通率。4 缩短位置更新流程时间4.1 提升gsm系统消息下发效率4.1.1 问题描述部分厂商可能gsm网络的系统消息效率较低，终端需要花费较长的时间读取系统信息，典型的如我司gsm网络，配置6个td邻区的情况下，目前需要14s多才能读完系统消息（已知爱立信、北电、moto的gsm网络系统效率较高，一般可以在5s多完成系统消息下发）。由于路测车速可能较快，还存在终端在一个小区尚未读完系统消息时，有搜索到一个信号更好的小区，这时由于尚未驻留，终端会重新读取更好小区的系统消息，进一步恶化重选时间。4.1.2 解决办法优化gsm系统消息；优化gsm邻区关系，在一片区域中，尽量只设置一个信号较强的主小区，减少终端移动状态时驻留网络的时间。主要问题及建议：由于目前多数二期、三期城市的gsm网络属于友商，存在协调难度，另外对gsm网络的改动难度也较大。但此类问题仍然要给客户指出来，避免把主要矛盾集中在我司身上。4.2 ue/bsc实现fast return4.2.1 问题描述目前的实现机制下，ue从td网络切换的gsm网络后，在gsm网络内进行一次位置更新，如果此时ue所在的区域依然有td信号，根据优选td网络的参数配置，ue又会尝试重选回td网络，这样，ue整个切换过程的位置更新常常包含2次位置更新，时间长达30秒，严重影响接通率。4.2.2 解决办法后续的ue和bsc通过实现fast return，在2g内通过一次位置更新快速返回3g网络，大大缩短了3g-2g切换后的位置更新时间，将有效降低系统间间位置对接通率的影响。5 优化寻呼策略5.1 设置核心网寻呼等待机制5.1.1 问题描述按照核心网一般默认设置，对位置更新流程和寻呼流程是分开处理的，核心网下寻呼时不考虑被叫终端是否正在做位置更新，则被叫位置更新期间势必无法接通。5.1.2 解决办法将软参p1100的比特1修改为0，功能如下：一个是如果先有被叫终端的位置更新消息上来，这时如果主叫的呼叫流程进入到寻呼流程，则不会立即下寻呼，而是等被叫位置更新完成后，再下寻呼，这时候下寻呼的lac将是被叫所在的准确的lac如果先进入寻呼流程，之后被叫进行了位置更新，则第一次下寻呼的lac寻呼不到ue，但第二次下寻呼依旧会等待被叫位置更新完成后再下寻呼，第二次会在被叫位置更新之后的lac下寻呼，是可以寻呼到的。5.2 增加msc/rnc寻呼次数5.2.1 问题描述位置更新后，若msc二次寻呼失败，则ue仍然无法接通，势必影响寻呼成功率和接通率。5.2.2 解决办法通过在rnc和msc上增加寻呼次数，在二次寻呼失败的情况下通过iu口和uu口下发多次寻呼，提高被叫寻呼成功率，进而提升接通率。5.3 实现msc系统间寻呼5.3.1 问题描述当用户处于msc边界区域时，受无线环境等周围诸多因素影响，可能会发生频繁的登记流程。如果此时该用户做被叫，就有可能出现被叫流程开始时用户数据在msc1下，但当流程进行到msc1向该用户进行寻呼请求时，该用户已经登记到相邻msc2下的情况。这样在msc1下就寻呼不到用户，造成寻呼失败。5.3.2 解决办法ispaging功能也叫系统间寻呼，英文全称是intersystem paging，开通ispaging后，如果在msc1寻呼不到该用户时，msc1就会向相邻的多个msc同时发送inter system page消息。而相邻msc收到该消息以后会根据数据配置在其指定的lac（lai）下寻呼，只要有一个带有tldn的响应通过inter system page返回消息传回msc1，msc1就会立即中断与其他相邻msc的寻呼。同时，将呼叫接续到用户实际所在的msc。这样就大大提高了边界msc区域的寻呼成功率。目前td现网的核心网还没有实现该功能。5.4 2g bsc启用cs/ps联合寻呼5.4.1 问题描述终端在gsm网络进行路由更新期间及做ps业务过程一般不能做被叫，降低了接通率。5.4.2 解决办法bsc上开cs/ps联合寻呼功能。华为成都网络已经成功应用半年多时间，终端在路由更新及ps业务时可以被叫。6 主叫位置更新对接通率影响_案例分析【现象描述】gsm dt接通率为97.53%，在发生的13次未接通中，被叫手机位置更新4次，主叫手机在建立呼叫过程中发生cm service reject（imsi unknown in vlr）4次，其他情况5次。这里我们重点对“imsi unknown in vlr”的情况进行详细分析。网测block汇总此次网测共发生13次block，其中4次是由于被叫手机正在进行location update造成的，还有4次block是由于主叫手机在建立呼叫过程中发生cm service reject。被叫手机location update造成block分别发生在内环线（顺时针外圈）近金沙江路、淮海中路（西向东）近汾阳路、南北高架（南向北）近北京路、天目中路恒丰路口。cm service reject造成的block情况如下表所示地点发生时间lac/ci所属msc北京路近浙江路7/8 10:036245/22017g29漕溪北路近南丹路7/11 9:546240/25697g28天目中路恒丰路口7/11 17:106305/8786d24西康路近新闸路7/12 11:386253/20513g33【原因分析】接通的定义在城市忙时采用手机相互拨打的方式，手机拨叫、接听、挂机都采用自动方式。每次通话时长100秒，呼叫间隔20秒；如出现未接通或掉话，应间隔20秒进行下一次试呼。接通率定义：接通率接通总次数/试呼总次数100说明：l 试呼次数：以channel request和cm service request同时出现来确定试呼开始。(立即指配完成)l 接通次数：当一次试呼开始后出现了connect，connect acknowledge消息中的任何一条就计数为一次接通。l 接通率总connect（connect acknowledge）数/总channel request数100l 接通率取主叫双频测试手机的统计结果。未接通现象：“一次接通”从主叫手机channel request开始， 一直到被叫手机的tch分配完成、alerting、connect。在此过程中，任何的信令中断都是“未接通”。在路测中遇到的未接通原因主要有：l 主叫手机location update ，主叫手机在不同的lac小区（属于不同的msc/vlr）之间重选后，来不及进行location update而自动进行呼叫，会收到cm service reject；l 对被叫手机开始paging request时，如果被叫手机正进行location update，则无法寻呼到；l tch assignment failure；l location update引起的呼叫未接通在实际的路测过程中，我们观察到手机的lu过程会在相当程度上影响呼叫的正常流程。主要有以下两种情况：l主叫手机：重选后，来不及做location update，就开始呼叫，接收到cm service reject。l被叫手机：呼叫被叫时，该手机正在location update。被叫手机位置更新对接通率的影响大家都比较熟悉，这里不作详细分析，下面我们重点来看看主叫手机位置更新对接通率的影响。主叫手机的lu影响案例：西康路近新闸路时间：7月12日 11:38前次呼叫结束后，主叫手机在空闲状态下从小区6262_30033（(s)静安区人民政府_1）重选到小区6253_20513（(s)云峰_1），手机即将起呼时从小区6253_20513重选到小区6262_28754（(s)新胶_2），主叫刚刚重选到不同lac的小区，来不及进行lu，就开始发起呼叫channel request，最终收到cm service reject，无法接通。之后主叫手机正常完成位置更新，一切恢复正常。测试路线图信令流程如下图所示：发生未接通时信令分析图呼叫正常流程：当ms要做主叫时，首先需要在空中接口申请信令信道sdcch。这个过程大致是：ms通过rach在向bss发出分配请求（channel request），正常情况下bss会立即回应一个立即分配信道信息（imm assignment），其中包含有关sdcch的信息。然后ms在该sdcch上会发送第一个cm消息cm service request（service type：normal call）。cm service request（该消息中包含有该手机的tmsi信息、申请的业务类型等内容）是ms请求某种服务而连接到相应管理层的消息，例如常规的手机呼叫，紧急呼叫，短讯，还有一些辅助服务等（如call waitng）在收到cm消息后，bss会建立一条ms到msc的虚拟信令链路。bss在发起消息中加了一些信息（如服务小区信息等），通过complete layer3发送给msc。msc会回连接确认cc（connect confirm）的消息。msc收到complete layer3后，将向相关联的vlr进行数据查询。查询的依据是cm service request中的“tmsi号码”。通过tmsi号码，在vlr数据库中可以查询到该用户的业务支持类型、lac区域等相关内容。在正常情况下，在vlr中可以查询到该tmsi的用户，并且支持的业务。如正常，随后信令流程进行鉴权、加密等正常进行。【处理过程】情况1异常情况分析（重选到不同lac，且属于不同msc/vlr）此处提到的异常情况是主叫手机在channel request之前正好从old lac重选到new lac（属于不同msc/vlr），还没有来得及进行lu、tmsi重分配，就发起呼叫。一般是在lu时，vlr将启动tmsi重分配过程。所以当手机重选到不同msc/vlr，如果没有进行lu，此手机的tmsi号码仍然是由old vlr分配的。我们上文提到的呼叫异常情况时，手机所在的new msc根据tmsi在new vlr中查询，很明显是查询不到与该tmsi号码相关的数据的。此时，网络侧怀疑手机发来的tmsi存在问题，为了验证手机发送的tmsi是否有问题，网络侧将启动identity request过程。identity过程是为了向手机查询一些必要的数据，比如imsi、imei。the identification procedure is used by the network to request a ms to provide specific identification parameters to the network e.g. international mobile subscriber identity, international mobile equipment identity (cf. gsm 03.03).手机收到identity request后，将发回identity response（其中包括imsi）。new msc将根据新收到的imsi号码再次在new vlr中查询。由于该手机根本还没有在此new vlr中登记，所以仍然不能查询到相关数据。此时网络侧认为不能支持该用户申请的业务，于是msc发送cm service reject（causeimsi unknown in vlr），以拒绝该用户的主叫业务，随后释放sdcch信道。呼叫流程结束，统计为“未接通”。在本案例中，小区6253_20513属于g33，重选后占用的小区6262_28754属于g35，二者分属不同的vlr，此时主叫手机进行的呼叫过程将受到lu的影响。同样的，我们对网测期间发生的4次由于cm service reject造成的block现象逐一进行了详细分析，参见下表：前次通话结束时占用小区遇block时占用小区所属msc遇block时主叫位置更新后占用小区所属msc6305_8547（起呼）g246245_22017g296377_82436377_8243g266240_