求解：GTP Recovery IE的实际作用

yonka

7.7.11    Recovery

The Recovery information element indicatesif the peer GSN has restarted. The Restart Counter shall be the value describedin the section Restoration and Recovery.

Figure 19: Restart Counter Information Element

规范里只是简单的一句带过，确实不是很清楚实际的作用。
E的GGSN中每块GGSN-C卡好像都是有一个计数器的，板卡重启时重置该计数器。

问题是peer GSN要知道自己的peer GSN是否重启的意义是？


谢谢

爱卫生

图没有显示。还是很有用的。

爱立信Alex里的一段原文如下：

“SGSN supports the following categories of GTP signaling traffic:

Path Management messages (signaling and control planes)

-The main purpose of these messages is to supervise a UDP/IP path to ensure that a connectivity failure can be detected in a timely manner. Typically, a path is an IP connection between two processors managed by frequently sending GTP echo or echo response packets between the GTP peers. Detection of path failure in the SGSN triggers an alarm, but no action is taken on affected PDP contexts.

To inform the GGSN about lost connections when a failure results in a large restart or node restart, the restart counter is increased and the new value is sent to the GGSN. The restart counter enables the GGSN to be informed when connections for a group of subscribers have been lost. At large restart and node restart, the restart counter will be increased.”

综上所述，该信息元素可以用于主动通知对方该GTP隧道的用户都已丢失，并且原因是本端发生了重启所导致的，对方收到了以后就可以释放掉该GTP隧道上所有的用户资源了（可能不只一个用户，因为GTP Echo消息并没有携带TEID）。否则的话，SGSN需要发送很多的delete pdp context request消息去释放，但可能根本来不及完成整个delete流程，因为它马上就要重启了。

另外，该参数也用于性能统计的目的。

个人理解供参考。

yonka

爱卫生 发表于 2012-11-4 14:51
图没有显示。还是很有用的。 爱立信Alex里的一段原文如下： “SGSN supports the following categories of  ...

3Q!
我大约也是这么理解的。
但总觉得比较奇怪，标准里边考虑到节点/板卡的设计似乎不多...

imwoohan

爱卫生 发表于 2012-11-4 14:51
图没有显示。还是很有用的。 爱立信Alex里的一段原文如下： “SGSN supports the following categories of  ...

从对等的GSN接收到Echo响应的GSN应比较先前为那个对等GSN存储的重启动计数器值。如果以前没有为这个对等GSN存储重启动计数器值，就为该GSN存储从Echo响应消息中收到的这个值。

先前为这个对等的GSN存储的重启动计数器值可能与Echo响应中收到的值不同，这时收到Echo响应的GSN应认为发Echo响应的GSN重启动了，并用新的重启动计数器值代替旧值。

若GGSN发Echo响应，SGSN收Echo响应，那么SGSN应认为使用这个GGSN的所有PDP上下文都去活了。SGSN应采取的进一步行动参考3GPP TS 23.007规范[16]。若SGSN发Echo响应，GGSN收Echo响应，那么GGSN应认为使用这个SGSN的所有PDP上下文都去活了。GGSN应采取的进一步行动参考3GPP TS 23.007规范[16]。
规范上是这么说的，其实不仅是sgsn和ggsn之间要删除tunnel，如果使用3GDT直连的话，RNC和GSN之间的tunnel也应该被删除吧？

imwoohan

规范的7.3.1章节里面还有提到

假如SGSN是第一次与GGSN联系或最近重启动了SGSN且还没有把新的重启动计数器值指示给GGSN ，SGSN将在创建PDP上下文请求消息中包含恢复IE。GGSN收到这个IE时，应按处理Echo响应消息的同样方式处理。创建PDP上下文请求消息应被看做是对包含在这个消息中的PDP上下文的有效的激活请求。

也即是说，如果sgsn发送的pdp上下文里面带了恢复IE的话，那么ggsn要回复一次echo响应，一次pdp上下文创建响应了。

hycl5410

爱卫生 发表于 2012-11-4 14:51
图没有显示。还是很有用的。 爱立信Alex里的一段原文如下： “SGSN supports the following categories of  ...

The restart counter enables the GGSN to be informed when connections for a group of subscribers have been lost. At large restart and node restart, the restart counter will be increased.”

否则的话，SGSN需要发送很多的delete pdp context request消息去释放，但可能根本来不及完成整个delete流程，因为它马上就要重启了。

这里好像有点问题哦，我理解应该是在重启后才会置位Recovery，而不是重启前。。。

cnc20399

这个也没有看懂啊。