《主叫位置更新对接通率影响-案例分析》由会员分享，可在线阅读，更多相关《主叫位置更新对接通率影响-案例分析（6页珍藏版）》请在金锄头文库上搜索。
1、技术案例编制：李剑峰 Page 1 of 6 日期：2011-03-02 主叫位置更新对接通率影响_案例分析【现象描述】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 是由于主叫手机在建立
2、呼叫过程中发生 CM Service Reject。被叫手机 Location Update 造成 BLOCK 分别发生在内环线（顺时针外圈）近金沙江路、淮海中路（西向东）近汾阳路、南北高架（南向北）近北京路、天目中路恒丰路口。CM Service Reject 造成的 BLOCK 情况如下表所示地点 发生时间 LAC/CI 所属 MSC北京路近浙江路 7/8 10:03 6245/22017 G29漕溪北路近南丹路 7/11 9:54 6240/25697 G28天目中路恒丰路口 7/11 17:10 6305/8786 D24西康路近新闸路 7/12 11:38 6253/20513 G3
3、3【原因分析】接通的定义在城市忙时采用手机相互拨打的方式，手机拨叫、接听、挂机都采用自动方式。每次通话时长 100秒，呼叫间隔 20 秒；如出现未接通或掉话，应间隔 20 秒进行下一次试呼。接通率定义：接通率接通总次数/试呼总次数 100说明： 试呼次数：以 channel request 和 CM service request 同时出现来确定试呼开始。(立即指配完成) 接通次数：当一次试呼开始后出现了 Connect，Connect Acknowledge 消息中的任何一条就计数为一次接通。 接通率总 Connect（Connect Acknowledge）数/总 Channel Requ
4、est 数100 接通率取主叫双频测试手机的统计结果。技术案例编制：李剑峰 Page 2 of 6 日期：2011-03-02 未接通现象：“一次接通”从主叫手机 Channel request 开始， 一直到被叫手机的 TCH 分配完成、Alerting、Connect。在此过程中，任何的信令中断都是“未接通” 。在路测中遇到的未接通原因主要有： 主叫手机 Location Update ，主叫手机在不同的 LAC 小区（属于不同的 MSC/VLR）之间重选后，来不及进行 Location Update 而自动进行呼叫，会收到 CM service reject； 对被叫手机开始 pagin
5、g Request 时，如果被叫手机正进行 Location Update，则无法寻呼到； TCH Assignment Failure； LOCATION UPDATE 引起的呼叫未接通在实际的路测过程中，我们观察到手机的 LU 过程会在相当程度上影响呼叫的正常流程。主要有以下两种情况： 主叫手机：重选后，来不及做 Location Update，就开始呼叫，接收到 CM Service Reject。 被叫手机：呼叫被叫时，该手机正在 Location Update。被叫手机位置更新对接通率的影响大家都比较熟悉，这里不作详细分析，下面我们重点来看看主叫手机位置更新对接通率的影响。主叫手机的
6、 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，无法接通。之后主叫手机正常完成位置更新，一切恢复正常。技术案例编制：李剑峰 Page 3 of 6 日期：2011-03-02 测试路线图信令流
7、程如下图所示：技术案例编制：李剑峰 Page 4 of 6 日期：2011-03-02 发生未接通时信令分析图呼叫正常流程：当 MS 要做主叫时，首先需要在空中接口申请信令信道 SDCCH。这个过程大致是：MS通过 RACH 在向 BSS 发出分配请求（CHANNEL REQUEST） ，正常情况下 BSS 会立即回应一个立即分配信道信息（IMM ASSIGNMENT） ，其中包含有关 SDCCH 的信息。然后 MS 在该 SDCCH 上会发送第一个 CM 消息 CM SERVICE REQUEST（SERVICE TYPE：NORMAL CALL） 。CM SERVICE REQUEST（该
8、消息中包含有该手机的 TMSI 信息、申请的业务类型等内容）是 MS 请求某种服务而连接到相应管理层的消息，例如常规的手机呼叫，紧急呼叫，短讯，还有一些辅助服务等（如 CALL WAITNG）在收到 CM 消息后，BSS 会建立一条 MS 到 MSC 的虚拟信令链路。BSS 在发起消息中加了一些信息（如服务小区信息等） ，通过 COMPLETE LAYER3 发送给 MSC。MSC技术案例编制：李剑峰 Page 5 of 6 日期：2011-03-02 会回连接确认 CC（CONNECT CONFIRM）的消息。MSC 收到 COMPLETE LAYER3 后，将向相关联的 VLR 进行数据查
9、询。查询的依据是 CM Service Request 中的“TMSI 号码” 。通过 TMSI 号码，在 VLR 数据库中可以查询到该用户的业务支持类型、LAC 区域等相关内容。在正常情况下，在 VLR 中可以查询到该 TMSI 的用户，并且支持的业务。如正常，随后信令流程进行鉴权、加密等正常进行。【处理过程】情况 1异常情况分析（重选到不同 LAC，且属于不同 MSC/VLR）此处提到的异常情况是主叫手机在 Channel request 之前正好从 old LAC 重选到 new LAC（属于不同 MSC/VLR） ，还没有来得及进行 LU、TMSI 重分配，就发起呼叫。一般是在 LU
10、时，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 us
11、ed 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 中查询。由于该手机
12、根本还没有在此 New VLR 中登记，所以仍然不能查询到相关数据。此时网络侧认为不能支持该用户申请的业务，于是 MSC 发送 CM Service Reject（CauseIMSI unknown in VLR） ，以拒绝该用户的主叫业务，随后释放 SDCCH 信道。呼叫流程结束，统计为“未接通” 。在本案例中，小区 6253_20513 属于 G33，重选后占用的小区 6262_28754 属于 G35，二者分属不同的 VLR，此时主叫手机进行的呼叫过程将受到 LU 的影响。同样的，我们对网测期间发生的 4 次由于 CM Service Reject 造成的 Block 现象逐一进行了详细
13、分析，参见下表：前次通话结束时占 遇 BLOCK 时占用 所属 遇 BLOCK 时主叫位置更新 所属技术案例编制：李剑峰 Page 6 of 6 日期：2011-03-02 用小区 小区 MSC 后占用小区 MSC6305_8547（起呼） G24 6245_22017 G296377_8243 6377_8243 G26 6240_25697 G286261_12562 6261_12562 G35 6305_8786 G246262_30033 6253_20513 G33 6262_28754 G35从表中可见，这 4 次 Block 中主叫手机都发生了不同 MSC/VLR 之间的 Lo
14、cation 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 L
15、AC（属于不同 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 覆盖区域较小，加上双频网基站分属不同的 MSC/VLR，路测中在 MSC/VLR 交界处发生跨 MSC 的小区重选时遇到此类问题的可能性更大。对于这种情况，解决起来比较困难，可以考虑对 MSC/VLR 覆盖区域重新进行划分，把重要道路和热点区域尽可能的规划在同一 MSC/VLR 下，尽量减少网测时遇到跨 MSC 重选的可能性。但重新划分MSC/VLR 将会带来很大的工作量，工程实施也有较大难度，需要从全局来权衡决策。
