51学通信技术论坛

标题: GTP的N3/T3计时器及Echo探测机制 [打印本页]

作者: 爱卫生    时间: 2011-2-8 19:12:18     标题: GTP的N3/T3计时器及Echo探测机制

本帖最后由 爱卫生 于 2012-10-8 21:25 编辑

  N3-REQUESTS计数器保存GTP发送请求消息的最大重发次数。推荐值为是5。

  T3-RESPONSE定时器定义请求消息等待响应的最长时间。

  T3-TUNNEL定时器定义原SGSN给新SGSN转发PDU的时间。当原SGSN收到GTP SGSN上下文请求消息且至少存在一个激活的PDP上下文时启动该定时器。当定时器到期时,GTP应向上层协议发指示。推荐的定时器值为20秒。

  也就是说如果SGSN发创建PDP上下文请求给GGSN,如果GGSN没有响应的话,SGSN会重试N3次,每次间隔T3秒。如果还不行的话,SGSN将尝试从DNS返回来的GGSN list里的下一个GGSN进行PDP的创建。


作者: 爱卫生    时间: 2011-5-9 22:29:10     标题: GTP Echo探测机制

本帖最后由 爱卫生 于 2012-10-8 21:29 编辑

SGSN上路径探测包括通过命令配置T3/N3参数,对于ECHO消息,T3范围1~20秒(默认5秒),N3范围1~6次(默认3次)

ECHO探测分两种场景:

1、如果此GTPC路径从建立起,就没有连通过,则以V1和V0版本交替探测发ECHO消息。先以V1版本T3间隔探测N3次,然后是V0版本,直到路径通后确定路径版本。

2、如果此GTPC路径在建立后,已经通了,则路径版本肯定已确定是V1或者V0。后续探测时,固定以此路径版本发ECHO消息,即使不通,也不会更改路径版本进行探测。   如果T3*N3 > 4秒,则整个1轮探测的总时长是2*T3*N3秒(1轮探测的概念:未确定路径版本时,是1轮V1探测+1轮V0探测;如果已确定路径版本是V1或者V0,则仅有1轮V1探测或者1轮V0探测)。

以上面两个场景举例,假设T3是5秒,N3是3次,2*T3*N3就是30秒。

- 场景1、路径断时,V1 ECHO每隔5秒发一次,连续发送3次,总长15秒。然后下一个5秒时就发送V0 ECHO,连续发3次,总长15秒。这样1轮探测总耗时就是30秒,当然由于定时器可能有误差,在GTPC接口跟踪上看到的ECHO间隔可能是4秒或者6秒,但是总共1轮的探测时间肯定是30秒。

- 场景2、假设路径已确定是V1版本,则V1 ECHO每隔5秒发一次,连续发3次,这时由于1轮的总时长是30秒,后面的15秒就不会发ECHO消息了,直到第一个V1 ECHO发送30秒后,才开始下一轮V1 ECHO的探测。


作者: qiandl    时间: 2012-3-6 16:44:19

爱总,您说的这个T3-TUNNEL定时器对应到规范中是具体哪一个?T3350?我看24.008中定义的Timer有好几个。求解答,谢谢
作者: qiandl    时间: 2012-3-6 17:36:38

刚从29.060中找到了T3 Timer的说明和描述了,哈哈
作者: gaoyang_fei    时间: 2012-10-8 10:51:40

爱卫生 发表于 2011-5-9 22:29
SGSN上路径探测包括通过命令配置T3/N3参数,对于ECHO消息,T3范围1~20秒(默认5秒),N3范围1~6次(默认3次 ...

场景二中 对于已经建立的pdp上下文 一对GSN,如果发了3次 echo request都收不到 回应,GSN会隐形删除ip承载路径上的所有pdp上下文吗?还有为什么是2倍的N3*T3

作者: decembersn    时间: 2013-7-31 10:45:47

有个问题,请教楼主。
在最新的TS29.060英文版协议中,对echo request的描述是这样的:
Echo Request messages may be sent for each path associated with at least one of the active PDP context, or MBMS UE context, or MBMS bearer context. When and how often an Echo Request message may be sent is implementation specific but an Echo Request shall not be sent more often than every 60 s on each path. Even if the path is not associated with any active PDP contexts, or MBMS UE contexts, or MBMS bearer contexts, a GSN or RNC shall be prepared to receive an Echo Request at any time and it shall reply with an Echo Response.  
每个路径上至少有一个激活的PDP上下文或MBMS UE上下文或MBMS承载上下文,才有可能发送echo请求消息。即使路径上没有任何激活PDP上下文,那么GSN也应该随时准备接收echo request。
这句话如何理解,感觉有些矛盾。而且跟上面描述的保活机制也有些冲突。发echo请求还必须要存在PDP上下文么?

作者: hycl5410    时间: 2013-8-1 09:26:37

decembersn 发表于 2013-7-31 10:45
有个问题,请教楼主。
在最新的TS29.060英文版协议中,对echo request的描述是这样的:
Echo Request me ...

那就要看发ECHO的目的是什么咯。
echo就是为了探测某一条path是否是好的,是活着的,最终还是为了保证这个path下的PDP都可以被正常服务。
如果某GSN端认为一个path上没有任何的PDP,那么发echo又有什么意义呢?

作者: MarsLiu    时间: 2014-1-5 16:48:25

“如果还不行的话,SGSN将尝试从DNS返回来的GGSNlist里的下一个GGSN进行PDP的创建。”


假设在某个GGSN出了故障路由不可达,当SGSNecho一次完后发现此GGSN有问题,那后续再有PDP请求时,SGSN是否还会过去进行一个30秒的询问?还是直接跳过该GGSN,然后有另外的一个计时器来探测GGSN何时恢复?

作者: ccc123    时间: 2014-2-9 23:15:44

学习了。。。。
作者: ccc123    时间: 2014-2-16 14:16:41

学习了,感谢楼主。。。。。




欢迎光临 51学通信技术论坛 (http://www.51xuetongxin.com/bbs/) Powered by Discuz! X2