厦门PS掉话问题初步分析

厦门PS掉话初步分析

背景 (2)

测试环境 (2)

测试情况 (2)

测试过程记录 (3)

<测试1> 短呼测试(short call) (3)

<测试2> 长呼测试(long call) (5)

<测试3> 长呼测试(long call) (9)

<测试4> UserA，UserC短呼测试，UserB 长呼测试 (11)

<测试5> UserA，UserB，UserC长呼测试 (13)

<测试6> UserA，UserB，UserC异常（人为故意模拟）测试 (15)

附测试基站当天的OMC统计 (17)

小结 (19)

背景

由于现场OMC统计鼎桥区域PS drop rate非常高，60%，从之前RNC的Iu trace看，主要原因都是RABrelease和IuRelease，而信令里面带的原因都是”Unspecific error”。此外与研发的电话会议中，研发多次强调干扰的可能性，为此，外场在2009/2/29号进行外场测试：目的想探查Iu口发起rabrelease和Iu release真正原因，同时验证PS相关计数器OMC统计是否正确。

测试环境

无线环境：为了屏蔽无线环境的影响和周围其它基站的干扰，我们挑了一个室内孤站(O3)，其附近没有其它室外站，且测试地点就在室内分布天线的正下方，此外通过OMC统计，该站一个月几乎没有任何话务量，因此除了测试人员外，也不存在其它R4或者H业务影响，因此该基站无线环境已经接近或等同绝对理想化情况。

测试情况

时间：2009/2/19 10:00~15:00,

为了和OMC上同步，每次测试按整点进行分组，为了控制临街时间段，测试的

起点是每小时07分左右，终点是每小时的55分钟；

终端（HSDPA卡）：

UserA（尾号99700）：大唐永胜

UserB（尾号28876）：新邮通

UserC（尾号28875）：大唐DT5731

测试过程记录

<测试1> 短呼测试(short call)

建立PS业务后保持5~15秒不等，断掉连接后，间隔10秒左右重新接入；

时间段：2009/1/19 (10：40~10：55 AM)

测试1--外场人员手动测试记录

UserB 从10:40:49~10:55:42进行17次成功RAB建立，但在第7次时在RAB释放时发生错误

没有拨打

RNC统计：RAB Request：34次RAB Response（succ）：34次（Fail）0次RAB Release(异常): 1次：在RAB成功建立42秒后异常RAB release

Iu Release（异常共4次）：都在用户“断掉连接”时产生

疑问：按照RNC trace的分析，应该是17+17=34次RAB Attempt，17+17=34次RAB 成功建立；而因为UserA（由于disconnect时，导致发起的Iu release 4次）和UseB（RAB 刚成功建立后RNC发起的RAB release 1次），如果按照理解RNC主动发起的rabrelease和Iurelease就算掉话的话，应该是总共5次掉话，和OMC统计的7次相差2次。然后从OMC 原因分类看，UseB的那次RAB relase（原因应为misc: 0x73 (115): unspecified failure）被算成RAB.RelReqPS.RbReset。UserA导致的4次Iu Release（原因应为radioNetwork: 0xe(14):failure in the radio interface procedure）在子原因中没有，总和上有，但不知为什么在总数上OMC统计多两次。

注：确认除了测试用户外无其它用户。

<测试2> 长呼测试(long call)

建立PS业务后保持45分钟不变，过程中3用户进行IE网页浏览，ftp下载等，如果连接断掉后，手动重新连接。主要是模拟普通用户长时间上网过程：

时间段：2009/1/19 (11：07~11：50 AM)

测试2--外场人员手动测试记录

测试2--后台人员RNC trace分析

UserA大唐永胜分析：

与在现场测试用户感觉不同（接入成功后，一直就没有断，能正常上网），但RNC上看发生多次失败：

第一次：RAB release 原因“misc: 0x73 (115): unspecified failure“

RAB建立19分钟后，RAB异常释放

第二次：IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为鉴权Reject而发起异常Iu release？？

第三次：IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure Cell update完成后马上rnc发起 Iu release？？？

UserB新邮通分析：

与在现场测试用户感觉不同（接入成功后，一直就没有断，能正常上网），但RNC上看发生多次失败：

第一次：IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure Cell update完成后马上rnc发起 Iu release？？？

第二次：IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure Cell update完成后马上rnc发起 Iu release？？？

UserC大唐5731分析：

与在现场测试用户感觉不同（接入成功后，一直就没有断，能正常上网），但RNC上看发生多次失败：

第一次：RAB release 原因“misc: 0x73 (115): unspecified failure“

第二次：RAB release 原因“misc: 0x73 (115): unspecified failure“

RAB建立5分钟后，RAB异常释放

第三次：IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为鉴权Reject而发起异常Iu release？？

第四次：IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为RL Fail，异常Iu release？？

第五次：IuRelease 原因radioNetwork: 0xe(14):failure in the radio interface procedure 因为RAB建立失败（失败原因也是failure in the radio interface procedure）导致IuRelease

按照trace统计在11：00-12：00这个小时中，共发起12次RAB Request，其中2次失败，10次成功；3次异常RAB Release，7次异常Iu Release。

注：确认除了测试用户外无其它用户。

结论：这一次测试结果显示OMC统计结果和RNC trace统计相差很大，几乎觉得OMC 统计完全错误！！！

<测试3> 长呼测试(long call)

建立PS业务后保持45分钟不变，过程中3用户不进行任何操作，如果连接断掉后，手动重新连接。主要是模拟普通用户长时间不上网但一直挂着（保持连接建立）的情况：时间段：2009/1/19 (13：07~13：50 AM)

测试3--外场人员手动测试记录

测试3--后台人员RNC trace分析

UserA：大唐永胜异常分析

异常Iu Release失败3次，情况一样，都是cell update流程结束后RNC发起Iu Release

UserB：新邮通异常分析

异常Iu Release失败1次，和UserA一样也是cell update流程结束后RNC发起Iu Release

UserC：大唐5731异常分析（无）

测试3-长呼测试事件记录（根据RNC Trace）

建立成功；4次异常Iu Release掉话。

按照RNC Trace，共6次RAB建立请求，6次RAB

结论：考虑到UserA大唐永胜在13：02不小心拨了一次，因此OMC统计比RNC多一次正常，此次RAB建立次数和成功次数和RNC一致。但掉话OMC统计为0次，RNC trace上看应该为4次，OMC在本次测试中掉话相关计数器仍然不准！！！

<测试4> UserA，UserC短呼测试，UserB 长呼测试

目的：a：通过短呼测试继续比较OMC统计

b：在测试3中，UserB异常掉死，因此UserB依旧进行长呼（不作任何操作，保持无数据流量）

RNC统计：

RAB Request：88次RAB Response（succ）：86次（Fail）2次

RAB Release(异常): 2次

Iu Release（异常共12次）：鉴权过程（无RAB过程）中3次

RAB建立后，隔几秒就IuRelease 6次

CN几乎在同时又RAB请求又RAB释放，有2次IuRelease

RAB请求后，RAB建立失败（Fail），但同时也出现1次IuRelease 测试4--OMC后台统计

结论：尝试次数仍然统计偏高；RAB release这次争取；IuRelease依旧不对，同时也疑惑OMC统计的SRBReset 3次到底是对应RNC信令哪3次？

<测试5> UserA，UserB，UserC长呼测试

目的：a：通过短呼测试继续比较OMC统计

b：3个UE不作任何操作，保持无数据流量

RNC统计：

RAB Request：6次RAB Response（succ）：6次（Fail）0次RAB Release(异常): 0次

Iu Release（异常共3次）：都在cell update流程中失败

结论：OMC统计中RAB建立次数和成功次数和UE trace一致，但只统计一次掉线；由于只有UserA发生3次Iu release，如果一定要比较3个不同，就是UE trace上看到的3次Iu_release中，第1次IU_release，面前的信令流程中出现了PDP 激活并成功，但在第2、3次IU_release，面前的信令流程中并没有出现PDP 激活请求，只有RABAssignmentReq。那么：

1、业务建立成功是否以PDP激活成功为准？

2、OMC统计PS掉线时，是否只统计在PDP激活成功后，出现IU_release或RAB_release

次数？

3、假如UE trace中的3次IU release都应该计算为PS掉线，OMC统计与UE trace的

结果不一致。

<测试6> UserA，UserB，UserC异常（人为故意模拟）测试

目的：a：通过测试继续比较OMC统计

b：3个UE分别进行一些特殊动作，不是正常使用软件的“Disconnect”分别是：?连接状态下通过电脑右下角连接右键“断掉连接”

?直接拔出H卡（直接从USB口拔出）

?在没有断开连接的时候，将笔记本合上

?在没有断开连接的时候，直接windows关机

从这些人为（模拟外场可能发生的行为）的异常释放动作，发现：

1：“从电脑右下角连接图标释放”和关机是正常的释放动作，和直接用H卡的拨号软件释放相同，都是“normal release”，因此这两个动作不会影响PS掉话；

2：但是H卡直接从电脑USB接口拔出（在连接状态下），【USB接口不稳定比较松，虽然外场没模拟这个，但应该和直接拔卡是一样的】肯定会导致RAB Release或Iu Release（Iu Release 6次，RAB Release 3次）；

3：在H卡连接的情况下，把电脑盖合上产生的影响3个UE 3种不同情况；UserA大唐永胜产生了第一次产生Iu Release，但自动重拨上，第二次合盖的时候正常；UserB新邮通合电脑盖2次都没有影响，打开盖依然能继续上网；UserC大唐5731则会产生正常的释放动作“normal release”

RNC统计：

RAB Request：21次RAB Response（succ）：21次（Fail）0次

RAB Release(异常): 3次Iu Release（异常共7次）

结论：RAB统计多2次；PS掉话总次数这次对了，但RAB和IU释放各相差一次附测试基站当天的OMC统计

结论：从OMC一天统计看，除了测试时间其它时间段没有任何用户，因此OMC的统计应该和RNC的trace一致才对，但总是或多或少有出入。

小结

从19号的测试中我们发现一下特点，有些是需要研发人员确认。

1：数据卡在拨通后从用户感觉是一直在线，几乎不会断（他没有需要手动拨号的情况，在我们测试一天的情况下，软件连上后基本不断），但是（可能是H卡的一种策略）H卡在后台（当RNC发起异常IU release或RAB release后）自动重拨。因此实际用户的感受比较好，但PS掉话统计结果很差。个人感觉，H卡的自动重拨策略是对的，一方面，从实际用户感受，必须这样，不然实际用户总需要手动拨号，会大大恶化用户感受；另外一方面，即使H 卡不自动重连，也解决不了PS掉话率高的问题，因为前者在后台隐秘拨号，可能用户在一小时使用中断了10次，重连10次，掉话应为100%，不采用自动拨号策略，这10次也要用户自己手动拨，仍然是10次，100%掉话，如果用户拨烦了，本想用1小时，结果拨了2次懒得拨了，可能就不用了，但统计结果也是2次拨号，2次失败，仍然是100%掉话率，因此H卡自动重拨功能无可厚非。要不这么做，不仅移动投诉KPI差，实际用户更会投诉。因此问题关键是解决为什么会发起IU和rab release

2：从当天的测试（1~6个）项目看，一般用户可能是长时间上网，不会如CS一样1分钟左右就释放了，所以因为PS业务特点，现在看来很容易掉话，但是有几点需要注意：

?短呼的情况

其实这在实际中比较少见，很少上网在10几秒就断的，主要是为了验证OMC统计正确性，但也发现一个现象：Iu release经常发生在RAB Request（释放）的时候，即当用户手动按“disconnect”，RNC trace经常发起Iu release；

RABAssignmentRequest（原因“normalrelease”）

RABAssignmentRes（失败原因是failure in radio interface procedure）同时还会发起IuRelease（原因也是失败原因是failure in radio interface procedure）

个人觉得这肯定有问题，一是这种信令现象有问题；二是如果这个IuRelease也算掉话那就有问题，因为没有成功建立的RAB，一里一外PS掉话率恶化不少；不知道在拆RAB 时导致的Iu和RAB是否算电话，如果目前算掉话的话，RNC人员可以考虑一点，是否可以不算，因为拆RAB的时候，是用户主动想断掉连接的，用户期望就是网络断掉，对RNC trace而言，应该是CN主动Iu释放，也可能由于信令某原因是RNC发起Iu或RAB release，但不管怎样，这两种情况下的链路都是成功的被释放掉了，达到用户想拆连接的目的，因此只要收到最后消息RNC→CN的Iu release complete，就算拆连接成功了（而不用管是RNC

（对应信令RABAssignmentReq 还是CN发起的Iu release），这样在外场用户点“断掉连接后”

“normal release”）到拆链完成后RNC→CN的Iu release complete中间的RNC发起的IU 和RAB release就直接忽略掉。

?长呼的情况（有流量和无流量）

这种情况实际中主要发生；不管有无流量（用户上网或挂在网上）就发现在1中说的一个现象：RNC会经常发起Iu release/RAB Release，然后卡自动重新接入；由于在文中开头说过测试环境已经非常单一（几乎接近理想实验室环境），但几乎每次都在40分钟内或多或少会发起几次Iu或RAB释放，平均10分钟左右一次，而实际用户上网时，时间可能比40分钟更长，因此需要探究真正的原因。如果这个站都这样，在实际网络中，当用户量上升，R4业务的干扰，那就更无法保证网络质量了。

OMC统计问题

正好利用这个站无用户的特点，我们通过测试验证OMC统计PS掉话的正确性。并且考虑到OMC可能与RNC有几分钟时间差，测试开始都从每小时7分中开始，在54分粥之前结束，即使这样OMC的统计结果除了RAB尝试，建立次数（但每次测试也比实际高几次，但每次都高几次，至少有点规律）还有点像之外，PS的掉话次数统计即电话分类就无法看懂。急需RNC和OMC人员进行解释。我们之前理解只要RNC发起Iu release和RAB Release 就算掉话，但从测试中好像不是这样，且统计次数忽高忽低，希望能有解释。

附：每项测试对应log，请帮忙分析定位一下问题。谢谢