苹果iPad造成PS域掉话的分析

2011-03-26韩永涛王瑞简君文

电信工程技术与标准化 2011年7期

韩永涛，王瑞，简君文

（1 中国联通福建分公司网优中心,厦门 361008；2 中兴通讯公司，深圳 518057）

1 问题的由来

某市苹果iPad同时连接WiFi和3G时，3G无线侧一天之内的PS域掉话次数在2000次左右，而这个iPad在同省XM时却没有掉话。某市和XM共用了中兴核心网CN（SGSN），但是某市使用了中兴的RAN（无线接入网），XM使用了华为的RAN。为何iPad只在某市出现这么大量异常掉话？

2 解决思路

苹果iPad对于我们是个黑盒子，无法抓取UE侧的任何信息，从失败的RNC信令并不能直接看出太多线索，并且iPad的内部处理机制都是需要去猜测和推理。我们想构造出iPad反复PDP激活去激活，然后掉话的场景，再用排除法一个一个验证到底哪个原因是造成iPad反复掉话。掉话都是反复“①PDP激活②PDP去激活③PDP激活④UE LOST掉话”这样的流程，并且规律性地间隔30s左右掉话一次。确认版本为3.2（7B367)的iPad，并且内部没有设置APN。对比了一下PS业务的正常信令和异常掉话信令：一个正常业务的释放会在PDP激活后，完成RAB Release，然后3s内如果没有其他操作，CN就会下发完成Iu_Release_Cmd，释放该连接。再看看失败信令流程，是我们在RNC侧跟踪得到的信令，iPad同时连接了WiFi和3G，没有配置APN，也没有任何人为操作。在13:13:59:090，iPad收到RNC下发的Radio Bearer Setup，属于第①个PDP激活流程。在13:14:00:440，iPad收到RNC下发的Radio Bearer Release，属于第②个PDP去激活流程。在13:14:01:340，iPad发出Radio Bearer Release Complete，表示第②个PDP去激活流程结束。在13:14:01:500，iPad收到RNC下发的Radio Bearer Setup，属于第③个PDP激活流程。在13:14:02:530，虽然第3个PDP激活成功了，但是UE上报了RRC Status，Node B报上行同步失败，然后RNC报UE LOST，主动请求释放，产生掉话。

3 分析过程

3.1 反复的PDP激活去激活的触发

为了研究反复的PDP激活去激活是由网络侧发起还是iPad自身行为，拿到一台官方正式版本号为4.2.1(8C148)的iPad，与某市使用的3.2(7B367)对比。做了如下验证：WiFi源：用联通数据卡在笔记本A拨号后，通过无线共享给iPad，来提供WiFi服务。3G源：iPad的本身内接测试SIM卡，注册到深圳实验室612的核心网下。iPad版本：官方最新版：4.2.1(8C148)。（1）先关闭WiFi，重新开机，3G这边有PDP激活，做了业务请求都是在访问Apple的网站。（2）再打开WiFi，3G这边过了5min才去激活，之后就一直没有再激活了。（3）再关闭WiFi，用3G登陆新浪，3G的PDP一直保持激活状态，没有去激活。（4）再打开WiFi，同时保持3G连接，无论是浏览网页还是登陆实验室的内网，业务全走WiFi。（5）将笔记本A的拨号断开，但iPad保持WiFi连接，再浏览网页过程，3G这边依然无动作，依然保持着第3步中的PDP激活状态。（6）iPad断开WIFI，继续浏览，数据分组从3G上来，之后不做任何操作，SAFARI内容清掉后，iPad没有去激活。（7）再连接WiFi后，运行很多软件，大部分业务都走了WiFi，但是3G这边发现，iPad偶尔从54895口往17.155.5.239端口发UDP分组，再从16384、16385端口往17.155.5.240的16386口发送分组，这些都是Apple的内网。（8）此时关闭WiFi，iPad还是会往Apple内网发UDP的分组（44byte）（9）重新开机后，只开3G，此时有PDP激活，但是还是没有PDP去激活。（10）再重新开机，只开3G，却没有PDP激活请求，也没有DETATCH，然后点了CrazyBird这个游戏，突然发生了PDP激活请求。

可得出结论：出现PDP激活，一定是iPad主动发起了业务请求，而且后台肯定有些软件发起请求。出现PDP去激活，一定是iPad主动发起去激活，但是去激活的原因与当前的数据量无关，而是iPad自己去判决，暂时没有查出某市出现的循环PDP激活—去激活—激活的规律。即使打开WiFi后，iPad也偶尔会通过3G往Apple的内网发UDP包。

3.2 WiFi打开是否会激发iPad掉话

在某市，iPad打开WiFi与关闭WiFi和PDP激活不带APN与带APN进行组合测试。

表1 iPad组合测试

从表1可以看到，WiFi是否打开与iPad掉话与否无关。

3.3 384kbit/s/64kbit/s业务子类的功率控制参数是否有问题

在RNC的网管上查询（下行/上行）384kbit/s/64kbit/s业务子类的功控参数都存在，索引也没问题，并且与其他地市没什么缺漏，设想如果该参数有问题，RAB指派应该也是不会成功的。为了进一步打消猜疑，在某市网络下，用某市的SIM卡，插入到数据卡中，配置空白的APN，速率也适配到了（下行/上行）384kbit/s/64kbit/s，但是不会发起频繁PDP激活去激活请求，也没有掉话。事实证明，功控参数是没有问题的。怀疑点还是放在iPad与网络的兼容性上面考虑。

3.4 iPad内部自动触发业务

经过以上分析，只有iPad会主动发起多次PDP激活去激活的请求。以下是深圳和某市对比测试，目的是验证是否所有的iPad都会有某个内部软件自动触发业务。深圳实验室，4.2.1版本的iPad：将RNC用户面的参数配置错误，故意构造一个用户面不通的场景，打开“通知”，配置空白APN，此时出现频繁地PDP激活去激活，但是从SGSN侧没有发现iPad发出的上行包，也没有掉话。将RNC用户面的参数配置正确，故意构造一个用户面正常的场景，打开“通知”，配置空白APN，此时没有出现PDP激活去激活现象，从SGSN侧发现iPad发了很多上行的UDP分组。某市现网，用3.2(7B367)版本的iPad，发现频繁的PDP激活去激活是由“通知”功能引起，只要“通知”功能打开，就会频繁地发生掉话，关闭后就只有PDP激活，然后转Idle释放的信令。本次排查的结论有三个：（1）“通知”功能，是导致iPad自动发起业务请求的直接原因。（2）在深圳，虽然发生了频繁的PDP激活去激活现象，但是从SGSN看，iPad本身没有数据分组上来，说明业务面不通，也是导致iPad重发多次业务请求的原因之一。（3）深圳的iPad即使发生了多次PDP激活去激活也没有掉话，说明这个iPad版本有可能即使在某市的场景下也不会掉话。暂时无法确认是否只有3.2(7B367)才有这个问题。但从全国来看，并非所有城市都出现iPad掉话现象，且3.2（7B367)的版本的终端已经很少（只有未升级的水货有），怀疑和iPad版本也是有关系的。

3.5 CN（SGSN）的APN策略是否有什么限制

APN更正功能不属于协议标准流程，首先来看图1的PDP激活信令流程。

图1 PDP激活信令流程

当SGSN收到的PDP激活请求时，会对其中携带的APN进行检查，如APN检查不通过就会发PDP激活拒绝。在实际商用网络中，有很多用户由于终端的问题，比如很多持有水货手机（外国运营商定制手机），其APN不允许修改或不允许新建，导致持这样手机根本无法使用PS网络；另外，即使有的手机APN可以修改，很可能用户尝试了几个不同的APN之后发现依然无法上网，就不愿意继续尝试了。APN更正功能主要是针对此类问题的提出的，当启用APN更正功能后，在激活过程中APN检查不通过时根据配置会发起APN的更正。APN更正策略一般而言有两类：第一种是更正为用户对应HLR签约的第一个APN，好处是用户即使未设置APN，当该用户上网时还是能使用其签约APN一样的QoS。第二种是由运营商指定的APN，好处是运营商设置方便，但对大部分用户来说，当发起PS业务没有设置APN而被使用默认APN时，该用户使用的QoS往往和其签约的不同，可能签约了高速率，但实际上指派的速率比签约的低很多。深圳的情况：iPad不设置APN以及设置签约APN进行PS拨号后的信令对比看RAB指派中速率都为交互类2Mbit/s/7.2Mbit/s并且其它QoS选项都一样，由此可见深圳APN更正设置采用的是用户签约APN，即上面所说的第一种策略。某市的情况：采用第二种策略，iPad在某市不设置APN时被指派的APN为Uniwap，被指派的速率为交互类64kbit/s/384kbit/s，而采用签约APN（3gnet）时，指派速率为交互类2Mbit/s/7.2Mbit/s，显而易见，某市APN更正时选择的不是用户签约的APN，应该是运营商统一指定的APN。那么，比较两者的情况，总结有以下两点不同，并且针对这两点不同之处进行了有针对性的分析测试。指派速率不同：在实验室进行了64kbit/s/384kbit/s与2Mbit/s/7.2Mbit/s同样场景下的验证测试，测试结果正常，排除了指派速率不同的影响；APN映射的地址池对应的出局方式不同：有以下两种：（1）通过WAP网关，终端侧必需要设置上网代理网关地址与端口才能访问网页，否则就无法访问网页。（2）不通过WAP网关，终端侧无需设置上网代理网关地址与端口，直接可访问网页。诚然，某市采用了第1个方式，深圳采用了第2个，通过WAP网关使用WAP上网方式对用户和运营商来说都是好处的，是考虑到很多WAP类网站可免费访问，而NET类网站收费，若改为更正为NET，会导致大量投诉。但是若采用WAP类APN的话，终端侧却需要增加网关和端口的设置，很多客户不知道要如何设置，或者觉得设置繁琐，这时终端就不能浏览网页了。为此我们又进行了表2所示的对比测试。

表2 对比测试

用深圳和某市的SIM卡在某市的网络下，分别向百度做路由trace，可以看出，深圳的SIM卡即使漫游到了某市的网络下，出局路由依然是在深圳的GGSN那边。这也是为什么深圳的SIM卡在配置了空白的APN后，依然可以上网的原因。得出结论：因为空白的APN导致某市的SIM卡无法直接浏览网页，无法满足iPad内部的一些软件的访问因特网需求，所以iPad不断发起业务请求，触发PDP激活去激活场景，目的就是希望能够接入，所以CN（SGSN）的APN策略也是影响某市iPad掉话的要因之一。

3.6 iPad版本3.2（7B367)在PDP激活去激活的间隔上的问题

将新版本iPad带到某市对比旧版iPad，新版iPad的PDP激活和去激活间隔时间比较长，一般都会等到CN下发Iu_Release_Cmd，释放掉连接之后才发起下一个PDP激活请求，所以就没有问题。旧版本的iPad掉话次数很多，它一般是第②步与第③步骤之间间隔不到200ms，导致IU还没来得及释放，iPad就抢到第③步，然后报UE LOST掉话，而且从SGSN侧没有抓到用户数据，说明此时业务面是没有通的。怀疑正是因为配置了空白的APN导致实际无法访问Internet，所以SGSN这一直没有收到UE的分组，要是UE的分组到达了，也就会很快地激活。新版本的iPad没有掉话，它在某市网下也会不定期地发起PDP激活和去激活请求，但是它第③步来得比较晚，一般大于3s，所以CN能及时的将IU连接释放掉。旧版本iPad和新版本iPad配置正确的APN后，都不会发生①②③④这样的往返，怀疑数据面如果是通的，iPad就不会主动多次尝试业务发去激活和激活流程。XM是华为的RAN，中兴的SGSN，就没有报掉话的现象，但是从目前分析，掉话需要同时满足3个条件才会发生：空白的APN导致无法上网；iPad版本比较旧，PDP激活去激活间隔小；iPad开启了“通知”功能，会主动尝试业务请求。需要在XM进行对比测试，构造出iPad高频率的激活去激活场景，来复现掉话的现象，如果XM不掉话，则问题肯定出在RAN侧。

3.7 RAN侧是否有问题

XM与某市共用中兴的CN，但是RAN是华为的，用3.2版本的iPad，配置空白的APN，在XM也无法直接浏览Internet，并且在SGSN没有抓到用户分组，构造出了高频率的激活去激活场景，但是始终没有掉话。说明某市iPad掉话问题，还是与某市的RAN有关。经过与XM局方沟通，从局方工程师那里将XMRAN侧的码流全部拷贝出来。查看XM的信令流程，可以看出，3.2版本的iPad在这个网络下，激活—去激活—激活也是完全连着的，并且激活与去激活的间隔也是几百毫秒。（注：每一次PDP激活，伴随着RB_SETUP流程，而PDP去激活，伴随着RB_REL流程）。XM的信令：①PDP激活—②PDP去激活之后，CN没有下发Iu释放，再次PDP激活和去激活多次都成功。某市的信令中，iPad再次PDP激活成功后，会报RRC Status，表示此时状态不对了；对比两个信令：在PDP去激活时，某市网络在Radio Bearer Release消息填下了如下字段，而XM没有：

radioBearerRelease.u.later_than_r3.criticalExtensions.u.criticalExtensions.u.r5.radioBearerRelease_r5.m.signallingConnectionRelIn dicationPresent＝1

radioBearerRelease.u.later_than_r3.critical Extensions.u.criticalExtensions.u.r5.radioBearer Release_r5.signallingConnectionRelIndication＝ps_domain

从协议331解释看出，在PDP去激活的Radio Bearer Release 消息中的字段signaling Connection Rel是释放PS域的信令连接，在处理完这条消息后PS域的信令连接被RNC释放了，UE也会remove the signaling connection，并且告诉高层。是否UE对这条信元的理解有问题？下面再分析某市的iPad信令，在成功完成PDP激活—PDP去激活的流程后，再一次PDP激活的流程里，iPad收到了CN下发的downlinkDirectTransfer，是PDP激活接受，其中还是带了cn DomainIndentity= ps_domian这个字段。跟着400ms后，UE就报了RRC Status，提示与接收到的状态不对，如下所示：TRRC_UL_DCCH_Message.message.u.rrcStatus.protocolErrorInformation.diagnosticsType.u.type1.u.messageNotCompatible WithReceiverState.rrc_TransactionIdentifier = 0

TRRC_UL_DCCH_Message.message.u.rrc Status.protocolErrorInformation.diagnosticsType.u.type1.u.messageNotCompatibleWithReceiverSta te.receivedMessageType = downlinkDirectTransfer

再查看331协议里关于RRC Status的描述，推断应该是UE觉得上一个Downlink Direct Transfer中提到的PS域的信令连接已经没有了，所以会上报了RRC Status，并且会认为这条下行直传有问题，提示Protocol error，原因是Message not compatible with receiver state。下面追溯一下关于这个信令连接的状态变化过程：第①个UE发的PDP激活请求之前有个service request，里面有如下字段，提示PS域的信令连接请求TRRC_UL_DCCH_Message.message.u.initialDirectTransfer.v3a0NonCriticalExtensions.laterNonCriticalExtensions.v590NonCritical Extensions.initialDirectTransfer_v590ext.establishmentCause = originatingHighPrioritySig nalling。第②个UE发的PDP去激活后，RNC下发了signallingConnectionRel，将PS域的信令连接释放了。第③个UE发的PDP激活请求中面还是带了cn_DomainIdentity = ps_domain字段，但是此时PS域的信令连接已经释放了，iPad也没有发信令连接请求。signaling Connection Rel Indication这个信元是可选字段，并且XM网络也没有，所以需要对比测试下，不填写这个该信元看看效果。刚好深圳联通有两个RNC，一个RNC是V3.07版本的，包含了这个字段，另外一个RNC是V3.09版本的，不包含这个字段。所以将某市的3.2版本的iPad带到深圳，分别在V3.07和V3.09版本的RNC下通过手工修改iPad的APN的方式，来触发多次PDP激活PDP去激活PDP激活的场景，用于复现某市iPad掉话的环境。测试情况如下，证明3.07版本的RNC在PDP去激活的时候，不应该同时把PS域也释放掉。在3.09版本下，新旧版的iPad都能够正常地发起多次PDP激活—PDP去激活—PDP激活的流程，没掉话。在3.07版本下，旧版本的iPad复现了和某市一样反复①PDP激活—②PDP去激活—③PDP激活—④UE LOST掉话的流程，而新版本的iPad每次PDP去激活后，都会等待CN释放IU连接，依然不会掉话。

PDP去激活时RNC下发的Radio Bearer Release中有signallingConnectionRelIndication＝ps_domain这条信元，会将iPad的PS域信令连接释放，然而某市联通的旧版本iPad可能没有理解这个字段，在200ms后又发起PDP激活请求，CN这边也认为iPad只是PDP去激活了，PS域信令连接还留着，所以保留有iPad相关的MM上下文，所以第二次PDP激活会成功。但其实此刻iPad的PS域信令连接已经被释放了，并且也没有重新申请信令连接。所以iPad会报RRC Status说明与网络的状态不一致，关闭上行功率，之后Node B无法找到iPad，上报Radio Link Failure，然后RNC主动释放IU连接，报UE LOST，产生掉话。如果将signallingConnectionRelIndication＝ps_domain这条信元去掉，即使iPad频繁地发起PDP激活去激活流程，也不会掉话。

3.8 最终结论与解决方案

因为版本为3.2的iPad没有设置APN，所以CN适配到了不恰当的APN，导致无法直接浏览Web，该iPad就会在3G下频繁地发起PDP激活PDP去激活PDP激活的流程，来不断地尝试接入Web，并且PDP去激活后200ms以内就立刻发起PDP激活，间隔很短；并且某市V3.07版本的中兴RNC在PDP去激活时，会通过signallingConnectionRelIndication＝ps_domain这条信元将UE的PS域信令连接释放掉；并且旧版本的iPad在理解这条信元上有问题，依然立刻发起了第二次PDP激活，导致iPad与网络状态不一致。空白APN、打开通知功能、PDP激活去激活太频繁、PDP去激活后释放PS域，当且仅当这四种偶然纠缠在一起的时候，就会发生一次必然的PS域掉话。

方案1，中兴可以出一个RNC的补丁，删除Radio Bearer Release信令里的可选字段signalling ConnectionRel Indication = ps_domain。方案2，可以在CN通过修改APN策略，让空的APN也能映射到HLR优选的APN，使得iPad内部的软件的Web请求能够满足，来减少PDP激活去激活次数，来规避掉话的问题。方案3，可以通知客户升级iPad。方案4，可以通知客户关闭通知功能。方案5，可以通知客户设置正确的APN。