2 MS未离开当前RA,附着成功后关机再重新附着

爱卫生

    这种情况也非常普遍。很多用户的习惯是白天开机，晚上关机。早上再开机。这样，至少在这个用户起床到出门到到达上班地点之前，都是没有离开这个RA的。RA的范围其实很大，甚至你可能到了上班地点，也还是和家里在同一个RA。如果以后SGSN POOL的应用更多的话，那可能整个城市都在同一个SGSN的服务覆盖区。这是后话了。   

我们这里需要探讨的就是这样一个流程。   

当一个MS开机附着成功后，然后晚上关机睡觉了。白天再开机进行附着的流程。   

由于之前这个用户附着成功，所以网络侧一定已经给它分配了一个P-TMSI，用于在这个RA内唯一标识它。同时，由于它晚上关机了（假设是正常的关机）。那一定给网络侧发了去附着的请求，这时SGSN会把用户的状态切换到idle。但实际上除非SGSN主动去删这个用户的签约数据和鉴权参数，这个用户的签约数据和鉴权参数将会一直保存在SGSN的缓存中（大多数厂家的做法）。这样做的目的可以减少Gr接口的信令交互，另外用户体验也更好。   

根据这个已知条件，我们得出用户的附着流程如下，信令流程图也如下所示：

  

图例 MS附着成功后关机，在当前RA重新开机附着流程

1 MS发送附着请求给SGSN。身份标识为P-TMSI。实际上由于用户未移动，这个P-TMSI也就是当前这个SGSN分配的。

2 SGSN收到请求后，由于这个P-TMSI是自己分配的，所以能够识别。另外，由于缓存中用户的IMSI信息，还有鉴权参数信息，另外签约数据也都有。所以SGSN在这一步可以直接向手机发起鉴权请求。

3 MS回送鉴权应答。

4 SGSN检查两边算出来的鉴权结果是否一致，一致则鉴权成功。否则将reject附着。

5 SGSN发送attach accept消息给MS。标识网络侧认可附着已经成功。并且分配新的P-TMSI给用户。

6 MS回送attach compelete消息并将SGSN下发的信息存储起来，完成整个附着流程。  

爱卫生

  确实，按照TS24.008的说明，MS在收到CC10后应采取的动作是：
  "The MS shall change to state GMM-DEREGISTERED.NORMAL-SERVICE. The MS shall then perform a new attach procedure. The MS should also activate PDP context(s) to replace any previously active PDP contexts."
  但并不是所有的手机都是按照这个规范来做的。这里就有个例子，http://www.gprshome.com/forum.php?mod=viewthread&tid=287&extra= “修改SGSN Cause Code值解决少数手机乒乓选网问题”。
  如果MS老是这样做循环的RAU（还挺有规律，每15秒1次，这个规范里应该没提），看是否在SGSN能修改CC来解决问题。
  另外，TS23.060中还提到了MS应该在什么时候发起RAU的十种场景如下，都没有提到漫游失败后RAU尝试的例子。
- that it has entered a new RA (except for the case of an MS configured to perform GPRS Attach with IMSI when entering an RA in a new non-equivalent PLMN in RRC-IDLE mode);
- when the periodic RA update timer has expired;
- when the MS has to indicate changed access capabilities or DRX parameters to the network;
- for a UE supporting CS fallback, or configured to support IMS voice, or both, a change of the UE's usage setting or voice domain preference for E-UTRAN;
- for an SR-VCC capable MS, the MS has changed its MS Classmark 2, or MS Classmark 3, or Supported Codec information;
- for A/Gb mode, when a suspended MS is not resumed by the BSS (see clause "Suspension of GPRS Services");
- when the MS reselects GERAN/UTRAN with the TIN indicating "GUTI";
- the RRC layer in an E-UTRAN capable UE informs the UE's NAS layer that an RRC connection failure occurred in E-UTRAN and this led the MS to select a GERAN/UTRAN cell;
- when the UE Network Capability and/or MS Network Capability are changed; or
- that it is registered for IMS voice and has moved from a RAT that supports IMS voice over PS sessions (see clause 5.3.8 for more information) to one that does not, or vice versa. It shall be possible using Device Management or initial provisioning to configure the UE to apply/not apply this particular exception.
  所以，我个人感觉应该还是手机的问题。
  这里，论坛还有一篇帖讨论了常见的RAU Reject的CC，包括CC9、CC10、CC17等。谨供参考。http://www.gprshome.com/forum.php?mod=viewthread&tid=368&extra=#pid1261 “RAU reject code”分析。

爱卫生

小丙张嘎 发表于 2012-6-27 17:51
这个流程是不是有些小问题？
根据之前的帖子介绍，不管用户如何重新附着，信令流程中缺少的应该只是SGNS向 ...

这个帖子的流程没问题的。参考http://www.gprshome.com/portal.php?mod=view&aid=56关于TS23.060章节6.11.1 Subscriber Management流程的介绍，当HLR上的签约数据变更时，HLR会主动通过该流程要求SGSN进行更新。