位置更新引起未接通的分析

上海贝尔阿尔卡特股份有限公司
ASB SSM-ISE 工程服务部
位置更新引起未接通的分析
ASB 工程服务部 外协工程师 赵枫
一,接通率的定义
根据 CMCC 的 2005 年测试规范中规定:在城市忙时采用手机相互拨打的方式,每次通 话时长 100 秒,呼叫间隔 20 秒;如出现未接通,应间隔 20 秒进行下一次试呼. 接通率,定义:接通率=接通总次数/试呼总次数×100%; 说明: 试呼次数:以 channel request 和 CM service request 同时出现来确定试呼开始. 接通次数:当一次试呼开始后出现了 Connect,Connect Acknowledge 消息中的任何一条 就计数为一次接通. 接通率=总(Connect 或 Connect Acknowledge)数/总(channel request 和 CM service request)数×100% 接通率取主叫测试手机的统计结果.
二,未接通现象:
"一次接通"从主叫手机 Channel request 开始, 一直到被叫手机的 TCH 分配完成, Alerting,Connect.在此过程中,任何的信令中断都是"未接通" . 从信令流程上分析,可分为以下几种情形: 1.起呼后没有 IMMEDIATE ASSIGNMENT 消息 定位:RACH 冲突或者 AGCH 拥塞 建议:查看与 RACH 相关的参数――最大重发次数和发送分布时隙数以及与 AGCH 相 关的参数――接入准许保留块数 2.IMMEDIATE ASSIGNMENT REJECT 导致未接通 定位:SDCCH 拥塞 建议:检查 SDCCH 配置,查看相关小区 SDCCH 话务量 3.IMMEDIATE ASSIGNMENT FAILURE 导致未接通 定位:SDCCH 指配失败 建议:排除无线方面原因后,应从交换侧寻找问题原因
ASB2005GSM001
移动通信经验交流汇编
1/5

上海贝尔阿尔卡特股份有限公司
ASB SSM-ISE 工程服务部
4.在 SDCCH 上信令突然中断转为 IDLE 模式 定位:SDCCH 掉话或者 TCH 拥塞 建议:查看是否启用 SDCCH 信道上的切换,查看相关小区话务量和 TCH 配置,在排 除无线方面原因后,应跟踪 Abis 接口,A 接口信令从交换侧寻找问题原因 5.ASSIGNMENT COMMAND 失败 定位:TCH 指配失败 建议:排除无线方面原因后,应从交换侧寻找问题原因 6.位置更新过程中起呼或起呼后即进行位置更新 建议:查看位置更新定时器和位置区设置 7.小区重选过程中起呼或起呼后即进行小区重选 建议:查看相关小区的小区重选参数 8.被叫方未收到 PAGING 建议:查看和 PCH 相关的参数――接入准许保留块数和寻呼信道复帧数,排除无线方 面原因后,应从交换侧寻找问题原因
三,位置更新(Location Update) 引起的呼叫未接通
在实际的路测过程中,我们观察到手机的 LU 过程会在相当程度上影响呼叫的正常流 程.主要有以下两种情况: ◆ 主叫手机: 重选后, 来不及做 Location Update, 就开始呼叫, 接收到 CM Service Reject. ◆ 被叫手机:呼叫被叫时,该手机正在 Location Update. 3.1 主叫手机因位置更新引起的呼叫未接通 3.1.1 主叫手机正常流程 当 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 会回连接确认 CC MSC 收到 COMPLETE (CONNECT CONFIRM) 的消息. 送给 MSC. LAYER3 后,将向相关联的 VLR 进行数据查询.
2/5
移动通信经验交流汇编
ASB2005GSM001

上海贝尔阿尔卡特股份有限公司
ASB SSM-ISE 工程服务部
查询的根据是 CM Service Request 中的"TMSI 号码" .通过 TMSI 号码,在 VLR 数据 库中可以查询到该用户的业务支持类型,LAC 区域等相关内容.在正常情况下,在 VLR 中 可以查询到该 TMSI 的用户,并且支持的业务.如正常,随后信令流程进行鉴权,加密等正 常进行. 3.1.2 未及时位置更新造成未接通 主叫手机在 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. 手机收到 Identity Request 后,将发回 Identity Response(其中包括 IMSI) .New MSC 将 根据新收到的 IMSI 号码再次在 New VLR 中查询. 由于该手机根本还没有在此 New VLR 中 登记,所以仍然不能查询到相关数据! 此时网络侧认为不能支持该用户申请的业务,于是 MSC 发送 CM Service Reject(Cause =IMSI unknown in VLR) ,以拒绝该用户的主叫业务,随后释放 SDCCH 信道.呼叫流程结 束,统计为"未接通" ! 另外假如主叫手机在 Channel request 之前正好从 old LAC 重选到 new LAC(但是属于 相同 MSC/VLR) ,还没有来得及进行 LU,TMSI 重分配,就发起呼叫.由于重选前后的小 区属于同一 MSC/VLR,所以 MSC 仍可通过 TMSI 查询到此手机的支持业务等.如此,呼 叫流程正常进行,不会受到 LU 的影响. 3.2 被叫手机因位置更新引起的呼叫未接通 3.2.1 被叫手机正常流程 正常流程中,主叫手机在收到 ASSIGNMENT COMPLETE 消息,TCH 分配完成之后, 就开始通过 GMSC 向被叫手机的 HLR 索取 MSRN.这个过程在接口是用 MAP 消息来完成 的.一个直观的结果就是 MSC 用一个用户的 E164 ISDN 的号码换得了一个同样 E164 编码 的动态漫游号码. 被叫端的呼叫建立时,主叫手机所在 MSC 会从 HLR 中取得动态漫游号码 MSRN(MS ROAMING NUMBER) ,经过再一次进行字冠分析后,定位被叫手机关联的 MSC/VLR 中. 接下去,要执行的动作就是要在 VLR 中找到该用户.
ASB2005GSM001
移动通信经验交流汇编
3/5