问：SGSN/GGSN故障时的信令流程以及对用户的影响

yonka

1、GGSN 突然down掉或者相关路由口down掉时，到该GGSN的Gn口不可达
这时候，SGSN的PDP上下文的地址应该还是该GGSN，数据应该还是会往该GGSN发
这时候有什么机制可以检测、恢复、纠正呢

能否讲一下其中的信令流程，对终端用户的影响是什么呢？


2、SGSN突然故障或相关Gb/Iu路由口down掉时
对于未组pool的SGSN，应该直观表现为用户不能上网，想问下网络侧有没有什么机制/规范来提示用户重附着/重激活？


对于组pool的SGSN
    顺便问一下，BSC---SGSN的寻址方式是通过什么寻址到SGSN的呢？RNC---SGSN呢？
组pool的SGSN其中某台down掉时，业务恢复的信令流程是怎么样的？

hycl5410

1. 这时候，SGSN的PDP上下文的地址应该还是该GGSN，数据应该还是会往该GGSN发
这句话看不懂。
只能按照个人理解来说。SGSN/GGSN都可以配置GTP path检测，通过GTP ECHO消息来检测path是否是活着的。具体的机制和算法就是设备实现层面的事了（没去查3GPP，个人感觉不会规定这么细）。当path down时，alarm是一定会有上报的，GSN动作（忽略或者去激活这个patch下所有pdp或其他）则又是vendor specific了。

2. SGSN down了，那就全废了。还有必要重新附着/激活么？

对于组pool的SGSN
    顺便问一下，BSC---SGSN的寻址方式是通过什么寻址到SGSN的呢？RNC---SGSN呢？

应该是配置的，不管是动态还是静态配置。

组pool的SGSN其中某台down掉时，业务恢复的信令流程是怎么样的？

这个没接触过，同求答案~~

爱卫生

前面两个问题完全赞同H大侠的观点。至于组POOL上BSC的配置，分几种情况。看用户是根据TLLI还是IMSI附着，如果是IMSI，在按照BSC上配置的POOL内各SGSN的容量比例来选择POOL内的SGSN，例如如果SGSN1支持10万用户，SGSN2支持20万用户。则BSC上配置容量比例为1：2来为分发不同的IMSI用户到POOL内的SGSN。IMSI附着后网络侧会分配TLLI给用户，TLLI包含了NRI，BSC收到后建立NRI和SGSN的绑定关系，后续用户会用TLLI做后续的信令和用户面消息，那BSC就根据NRI和SGSN的绑定关系选择SGSN，只要用户在这里POOL里，始终是由同一个SGSN提供服务。当然还有一个特例是，SGSN发起了用户迁移流程。

后面那个问题，如果服务的SGSN down了，也要分几种情况。主要看MS是否在IDLE状态。（假设MS已经注册到了SGSN1，但现在SGSN1的Gb口down了）

1）如果正在上网过程中SGSN down了，这种情况应该就比较麻烦了，业务是肯定受影响的。并且关键是MS没有得到网络侧的任何通知，甚至MS的PDP上下文将一直处于Active的状态，那MS可能就不会重新做附着或RAU切换到POOL内别的SGSN了。这种情况下可能要关机才行吧，求解。

2）MS没有active 的PDP上下文，但已经附着成功处在standy状态。这种情况和1）个人感觉结局差不多。MS应该会不断的尝试做PDP上下文激活又不断的被拒绝（可能是CC111)，根据24008的说明，MS的PDP激活被拒后，只是将PDP上下文置成inactive状态，并不要求重新做附着，这样估计也得要重新开机才会好吧。

3）如果MS在IDLE状态（比如是关机了）可能要好一点，这时BSC可以通过NS层协议定义的Test流程发送NS-Alive消息探测Gb接口是否可用。如果接下来MS又发起了附着，则BSC会选择新的POOL内的SGSN为MS服务。第一次会话建立可能失败，原因为SGSN返回“TLLI unknown”），但后续会话建立成功。

yonka

爱卫生 发表于 2012-6-19 21:02
前面两个问题完全赞同H大侠的观点。至于组POOL上BSC的配置，分几种情况。看用户是根据TLLI还是IMSI附着，如 ...

前面两个问题完全赞同H大侠的观点。

至于组POOL上BSC的配置，分几种情况。看用户是根据TLLI还是IMSI附着，如果是IMSI，在按照BSC上配置的POOL内各SGSN的容量比例来选择POOL内的SGSN，例如如果SGSN1支持10万用户，SGSN2支持20万用户。则BSC上配置容量比例为1：2来为分发不同的IMSI用户到POOL内的SGSN。IMSI附着后网络侧会分配TLLI给用户，TLLI包含了NRI，BSC收到后建立NRI和SGSN的绑定关系，后续用户会用TLLI做后续的信令和用户面消息，那BSC就根据NRI和SGSN的绑定关系选择SGSN，只要用户在这里POOL里，始终是由同一个SGSN提供服务。当然还有一个特例是，SGSN发起了用户迁移流程。

1、我有一点 不太了解，BSC怎么根据用户来决定发往的SGSN呢？BSC会查看GMM层的消息来判断是IMSI附着还是P-TMSI(TLLI)？

2、还有就是按我的理解，BSSGP层是BSC和CN之间的，那MS怎么觉得使用哪一种TLLI呢？

3、你说的“如果是IMSI，在按照BSC上配置的POOL内各SGSN的容量比例来选择POOL内的SGSN”是指在BSC上预先配置好了吗？ 执行的是随机算法（根据SGSN容量来决定概率）还是轮询（比如SGSN1、2的容量为1:2，那么先发一个请求到SGSN1再发2个到SGSN2，再发一个到SGSN1...）呢？

4、TLLI一般是根据P-TMSI转化而来，那在组pool的情况下，”TLLI包含了NRI“是不是表示TLLI的构成方式以及格式发生了变化呢？是否有相关的帖子介绍？

5、有没有组pool情况下完成的附着流程的样包?

后面那个问题，如果服务的SGSN down了，也要分几种情况。主要看MS是否在IDLE状态。（假设MS已经注册到了SGSN1，但现在SGSN1的Gb口down了）

1）如果正在上网过程中SGSN down了，这种情况应该就比较麻烦了，业务是肯定受影响的。并且关键是MS没有得到网络侧的任何通知，甚至MS的PDP上下文将一直处于Active的状态，那MS可能就不会重新做附着或RAU切换到POOL内别的SGSN了。这种情况下可能要关机才行吧，求解。

1、也就是说BSC对这种情况并没有合适的办法？即使是组pool的情况下BSC建立了NRI---SGSN的关联，当NS-TEST发现SGSN不可达时也无法通知用户？终端也没有相应的机制发起重新（IMSI）附着？

2、周期性RAU是否可以恢复上网功能？

2）MS没有active 的PDP上下文，但已经附着成功处在standy状态。这种情况和1）个人感觉结局差不多。MS应该会不断的尝试做PDP上下文激活又不断的被拒绝（可能是CC111)，根据24008的说明，MS的PDP激活被拒后，只是将PDP上下文置成inactive状态，并不要求重新做附着，这样估计也得要重新开机才会好吧。

1、会有PDP激活拒绝消息吗？如果只是PDP激活无响应的话MS会有什么样的反应？

3）如果MS在IDLE状态（比如是关机了）可能要好一点，这时BSC可以通过NS层协议定义的Test流程发送NS-Alive消息探测Gb接口是否可用。如果接下来MS又发起了附着，则BSC会选择新的POOL内的SGSN为MS服务。第一次会话建立可能失败，原因为SGSN返回“TLLI unknown”），但后续会话建立成功。

1、还是之前的问题，TLLI应该是出现在BSC和CN之间的BSSGP层，那BSC通过什么途径得知MS使用的TLLI呢？总不可能真去查看GMM层内容吧？

不好意思，疑问较多

shanyy11

    由于BSC只能处理到BSSGP层，再上层的信息就直接透传给SGSN，所以BSC是一个比较傻的设备（相对SGSN而言）。如果SGSN不入pool，对于MS发来的数据，BSC稍微处理下转给它上联唯一的SGSN就可以了；而当SGSN入pool后，BSC向SGSN转发时就有个选择问题了，此时BSC就会去读取在BSSGP层传输的TLLI，找到NRI信息，再与BSC上配置的NRI-----SGSN对应表进行比较，这样就可以传给相应的SGSN了。之所以说BSC傻，是因为对于MS发来的数据，BSC并不知道这些数据是干嘛用的，是附着，PDP激活还是对PDN网络的访问，BSC是一无所知的，不是BSC不想知道，是因为BSC没这个能力知道。
   
    当pool内的一台SGSN down掉后，不管MS处在哪种MM状态，BSC处理的过程应该是一样的：提取TLLI中包含的NRI信息，查找到NRI对应的SGSN信息，由于对应的SGSN down掉了，路由不通，BSC只能随机转发给pool内其它的SGSN，怎么个随机法说不了。个人理解啊