关于每次通话结束后会发起RAU的问题

cmcc_demon

问题：这段时间发现每次通话结束后都会发起一次RAU，如果这样遇到无线环境不好时，就可能存在因RAU更新导致未接通现象。特此更大家一起分享讨论，共同进步哈。
后面查了下GSM03.60规范，里面提到以下四点情形会发生RAU，
A routeing area update takes place when a GPRS-attached MS detects that it has entered a new RA, when the periodic RA update timer has expired, or when the MS indicates changed access capabilities to the network, or when a suspended MS is not resumed by the BSS (see subclause "Suspension of GPRS Services")
通话结束发生RAU的话，与 when a suspended MS is not resumed by the BSS 原因可能性比较大。
我们知道B类手机做语音业务时，就无法作GPRS业务（占用GPRS信道），为此在呼叫时有一条GPRS挂起的消息（手机需要通知SGSN将其暂时挂起，手机发送Suspend消息）。当呼叫结束后，手机要恢复GPRS正常状态，这时BSC/PCU会向SGSN发送恢复的消息，如果成功，则BSS给手机下发的channel release中包含了resume标志，表示BSC/PCU成功请求SGSN完成GPRS手机恢复操作。如果没有这个resume标志，就表示BSC/PCU请求SGSN完成恢复操作失败。这时手机就只有主动来作RAU的更新了，这就出现了呼叫一结束立刻现做路由区更新的问题。
对于出现这种现象，我们这边初步怀疑是motoBSC/PCU设备不支持给MS发送resume标志，导致MS主动做RAU。
不知道分析得对不对，请各位指教分析。
另外，请教一下两个问题共同讨论
1、如果在测试过程中，测试手机在不附着到GPRS网络/按需连接上网前提下，会不会发生RAU呢？
2、虽然概率很小，但也有存在的可能：主叫发起寻呼，被叫做正在做RAU时，能否响应寻呼呢？会不会导致未接通呢？我们这边经测试发现这样一种机制：寻呼请求会等待RAU更新，后传送至被叫。是否真如此？

爱卫生

cmcc_demon 发表于 2011-6-12 11:17
问题：这段时间发现每次通话结束后都会发起一次RAU，如果这样遇到无线环境不好时，就可能存在因RAU更新导致 ...

    我先说说我的理解。请大家拍砖。
    这个Suspend 流程在TS23.060（V10.2.)的16.2.1章节---“Suspension of GPRS Services”也中也有描述。
    但出现上面的现象，也不一定代表motoBSC/PCU设备不支持给MS发送resume标志，导致MS主动做RAU。（呵呵，我不是moto的人，只是根据规范来说明一下）。
流程图为：

Suspend 流程

   规范中关于第5步和第6步的说明如下：

Suspension of GPRS Services
5) If the circuit switched radio channel is to be released, the BSS sends an RR Channel Release (Resume) message to the MS. The Resume message indicates whether the BSS has successfully requested the SGSN to resume GPRS services for the MS, i.e., whether Resume Ack was received in the BSS before the RR Channel Release message was transmitted. The MS leaves dedicated mode.
6) The MS shall resume GPRS services by sending a Routeing Area Update Request message to the SGSN:
- if the BSS did not successfully request the SGSN to resume GPRS services,
- if the RR Channel Release message was not received before the MS left dedicated mode,
- if the MS locally determines that the conditions for the GPRS suspension have disappeared
   The Update Type depends on the mode of operation of the network in use e.g. in mode I Combined RA/LA Update is made and in mode II or III Routeing Area Update is made.

   所以，第6步明确指出来，如果下列三种条件产生，MS将被动的发送一个RAU Request消息给SGSN来重新继续它之前的GPRS业务。

   这三种条件是：

1）BSS没有成功的请求SGSN来resume GPRS业务。这就是楼主所怀疑的情况，即“初步怀疑是motoBSC/PCU设备不支持给MS发送resume标志，导致MS主动做RAU”。

但还有两种情况：

2）在MS离开专有模式之前，RR信道释放消息没有收到。（即第5步的消息）

3）MS本地决定GPRS业务监管的条件消失了。这个就说的很含糊了，并没有说明MS是怎样来自己判断的。请大家拍砖。

     所以，也不能肯定是BSC的问题。

     个人理解，谨供参考。

gprssanling

讨论：

0、“通话结束RAU的问题”：通话应该是CS域，而RAU是PS域的吧。你分析的是Gs接口上的问题，不知道现网中是否开通了Gs接口？
1、“手机不GPRS附着，是否RAU？”：很简单的场景，一个公交司机驾驶的时候，他手机揣在口袋里，不打开UC浏览网页、不收发彩信、也没有UC桌面可能会定时的联网更新数据诸如此类，是不GPRS附着的吧，而他此时驾车穿梭于个路由区之间，能不RAU吗？他开机的，用的也不是联通定制的苹果186号啊。
2、个人理解同0。期待高人加入讨论。

cmcc_demon

首先现网没开通Gs接口。依我个人理解，通话结束后发起的RAU，我想是与B类手机Suspend和Resume有关，对规范而言是统一的，而我们发现我们现网不同设备下，有的会RAU,有的不会RAU，所以我觉得一方面跟设备是否有关，另一方面会不会跟我测试过程中测试手机PS业务是否附着有关。
期待大虾看法～～

爱卫生

cmcc_demon 发表于 2011-6-12 11:17
问题：这段时间发现每次通话结束后都会发起一次RAU，如果这样遇到无线环境不好时，就可能存在因RAU更新导致 ...

1 附着到PS是RAU的前提条件，也就是说如果要做RAU，MS一定是在Standby状态。在规范里有。TS23.060 6.1.1/6.1.2关于Idle/Standby状态的定义。Idle状态是这样说的：“The subscriber-related mobility management procedures are not performed.
The MS performs PLMN selection and cell selection and re-selection.Data transmission to and from the mobile subscriber as well as the paging of the subscriber is not possible. The GPRS MS is seen as not reachable in this case."。所以，所有和移动性管理相关的信令流程都是不能执行的。而在Standby状态是这么说的：“Pages for data or signalling information transfers may be received. It is also possible to receive pages for the CS services via the SGSN. Data reception and transmission are not possible in this state.
The MS performs GPRS Routeing Area (RA) and GPRS cell selection and re-selection locally. The MS executes mobility management procedures to inform the SGSN when it has entered a new RA. The MS does not inform the SGSN on a change of cell in the same RA. ”。

2 主叫发起寻呼。在PS中，可能是QQ服务器有消息要和QQ手机终端通信。如果MS正在做RAU的话，那这时候的寻呼可能需要分成几种情况吧。
   假设MS从BSC1服务的RA1移动RA2，甚至有可能从SGSN1移动到SGSN2
1）MS正在从RA1移动到RA2，BSC1收到寻呼请求，在RA1中寻呼MS，那MS可能收不到。
2）MS已经从RA1移动到RA2，BSC1收到寻呼请求，但这时RAU还没有完成，寻呼请求是无法在RA2中发送的。因为BSC下发的寻呼请求是通过P-TMSI来寻呼的，而RAU没有完成的话，MS将分配不到新的P-TMSI（每次RAU ，SGSN都会给MS分配一个新的P-TMSI）。这就是先有鸡还是先有蛋的问题了。
   所以如果真碰到这种情况，那一定要先等RAU完成，否则寻呼是不能成功的。

cmcc_demon

这边把前两天关于通话结束后发生RAU问题的验证测试结果拍砖下，具体跟厂家设备有关，由于我们这边没有一些抓包的信令工具，只能通过简单测试来验证，希望接下来有条件的朋友能进一步验证。
（以我们这边moto bsc32和华为bsc6000的设备为例）
    1）CQT测试，moto32/华为6000站下，通话前后MS所在小区一致的情况，通话结束后不会发起RAU。
    2）DT测试，在moto32/华为6000站下，通话前后MS所在BSC一致，小区不一致的情况，通话后不会发起RAU。
    3）DT测试，通话前后MS所在BSC不一致时，通话过程中MOTO BSC1->MOTO BSC2，通话结束后发起RAU；通话过程中MOTO BSC1->HUWEI BSC2和HUWEI BSC2->MOTO BSC1，通话结束后会发起RAU。
    4）DT测试，通话过程中跨华为BSC，通话结束后不会发起RAU。
    5）具体以集团自动路测的log为分析（moto BSC32），分析结果为：a、通话过程发生BSC切换,最终驻留在另外BSC,RA信息不一致，结束后发起RAU ;b、通话过程发生BSC切换,最终驻留在另外BSC,RA信息一致，结束后发起RAU ;c、通话过程发生BSC切换,最终驻留在原BSC,RA信息一致，结束后发起RAU（无论中间切换的BSC的RA信息是否一致） d、通话过程发生未BSC切换,发生小区切换,RA信息一致，结束后未发起RAU 。

hendouse

“附着到PS是RAU的前提条件，也就是说如果要做RAU，MS一定是在Standby状态。”、“如果MS正在做RAU的话，那一定要先等RAU完成，否则寻呼是不能成功的。”  个人觉得是本贴的关键！

cmcc_demon

问题终于有了答案。谢谢爱总无私的解答，帮助不小哈。
摩托BSC进行了跨BSC切换测试表明在相同RA下，通话结束后会发起RAU。
"got confirmation from DEV that from the code level and requirement level, BSS doesn't support resume feature during inter-bss handover. BSC shall ignore GPRS Suspend information if it is included in Old BSS to New BSS info IE in Handover Request received from MSC, i.e , MS will not be marked as suspended and consequently no RESUME will be initiated by BSC"

从Code确认MOTO的BSS不支持跨BSS切换后的BSS发起的GPRS Resume功能.如果BSC从MSC收到的Handover Request信息中的Old BSS to New BSS信息元素中包括了GPRS Suspend信息, BSC也会忽视此信息,手机不会被标成Suspend, 从而也就不会有BSC发起的GPRS Resume。

华为BSC进行了跨BSC切换测试表明在相同RA下，通话结束后不会发起RAU。
{ If the MS performs an inter-BSC handover while suspended, the TLLI, RAI and SRN should be transferred as BSC-to-BSC information in the Handover Required and Handover Request messages }
BSC跟踪：gprs-suspend-information: FF C5 6B 01 7C 64 F0 00 60 3A 8F 30 3F 00 00 E1 00
交换跟踪：handover required (源BSC到交换）
old-bss-to-new-bss-information:04 11 FF C5 6B 01 7C 64 F0 00 60 3A 8F 30 3F 00 00 E1 00
交换跟踪：handover request（交换到目标BSC）
old-bss-to-new-bss-information:04 11 FF C5 6B 01 7C 64 F0 00 60 3A 8F 30 3F 00 00 E1 00
华为设备在跨BSC切换时Handover Required and Handover Request有相关消息，与前面的解释一致。

爱卫生

  呵呵。有了答案就好。也谢谢你的分享哈，我也学到了很多东西。{:soso_e100:}

scrapersky

从这篇帖子，学到了很多，在此谢谢了，希望我以后也能给大家分享

feile99

我有一篇文章正好是说这个问题的。。。。

爱卫生

回复 feile99 的帖子

  谢谢啦，非常感谢！多交流哈！