主叫位置更新对接通率影响-案例分析.doc

技术案例主叫位置更新对接通率影响_案例分析【现象描述】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_25697g286261_125626261_12562g356305_8786g246262_300336253_20513g336262_28754g35从表中可见，这4次block中主叫手机都发生了不同msc/vlr之间的location update，属于同一类型的问题。情况2正常情况分析（重选到不同lac，但属于相同msc/vlr）另外一种情况是手机在channel request之前正好从old lac重选到new lac（但是属于相同msc/vlr），还没有来得及进行lu、tmsi重分配，就发起呼叫。由于重选前后的小区属于同一msc/vlr，所以msc仍可通过tmsi查询到此手机的支持业务等。如此，呼叫流程正常进行，不会受到lu的影响。【总结建议】在短拨打测试中（每次通话时长100秒，呼叫间隔20秒），一次通话结束后，如果主叫手机从old lac重选到new lac（属于不同msc/vlr），还没有来得及进行lu、tmsi重分配，就发起新的呼叫，此时手机的tmsi号码仍然是由old vlr分配的，手机当前所在的new msc根据tmsi在new vlr中查询，将无法查询到与该tmsi号码相关的数据，于是msc发送cm service reject（causeimsi unknown in vlr），以拒绝该用户的主叫业务，随后释放sdcch信道，呼叫流程结束，统计为block。由于现在网络中一般是一个msc下带一个vlr、若干个lac，所以情况1在路测中还是有一定的机率存在。特别是在上海中心城区，msc/vlr覆盖区域较小，加上双频网基站分属不同