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

爱卫生

前面两个问题完全赞同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”），但后续会话建立成功。