Purge流程及实例

爱卫生

Purge功能允许SGSN来通知HLR,它已经删除了一个去附着的MS的MM和PDP上下文。

规范中的流程图如下：

1）在删除已经去附着的MS的MM和PDP上下文后,SGSN发送Purge MS(IMSI)消息给HLR。
    2) HLR将MS状态设置为MS Purged并通过Purge MS Ack消息确认。

一般来说Purge流程是在SGSN上通过相应的指令将MS的MM和PDP上下文删除所触发的。另外，同时触发的，可能还会有一个去附着流程。下面来看一个实例。

#1和是一个SGSN发起的去附着请求，这也是由SGSN上通过命令将MS的MM和PDP上下文删除所触发的。SGSN同时会将这个MS/UE的MM状态设置为IDLE或PMM-DETACHED。

#2是SGSN给HLR发的Purge消息，通知HLR这个用户已经不在我的服务范围了，我已经不再为这个用户提供服务了。如下图所示。在消息中，包含了SGSN的地址信息以及MS的IMSI等信息。

#1和#2的顺序其实没有先后，基本上是同时发出的。#2并不用等待#1发出后再发。

#3是HLR回的一个Purge MS Ack消息。对Purge MS进行确认。同时，HLR要做的操作是，将关于这个MS/UE的服务SGSN地址信息清除。这样，HLR和SGSN的状态就同步了。下次，如果HLR收到了别的SGSN过来的位置更新请求消息，HLR就不会给这个原来的SGSN发cancel location了。消息如下图所示。

#4附着接受消息是MS回的一个确认。这样MS中的状态也变成了IDLE，和网络侧完成了同步。下一次MS要上网的话，就要先发附着请求，而不能直接发PDP激活请求了。

爱卫生

  谢谢gprssanling大侠补充了Purge流程触发的场景。上面翻译成中文就是----Purge在SGSN和HLR做位置更新失败，或者SGSN的内存快溢出的时候产生。在第二种情况下，SGSN这时候会将去附着时间最长的MS进行Purge，来释放一定的内存空间。（因为即使这个用户去附着，它的一些MM上下文信息包括鉴权参数仍会在SGSN上保存一段时间，这样做是为了在下次用户附着的时候，减少和HLR的信令交互，降低Gr接口的负荷，特别是当Gr接口是窄带SS7承载的时候）。