Authentication重发过多！

望到天那边

现象：MS向SGSN发起Attach request后,SGSN连续发起多条Authentication and Ciphering Req，MS都没有响应SGSN，然后MS再次发起Attach request，一直这样循环着，造成网络中有大量的Authentication重传包。
详细信令如下：


问题：
1、SGSN上的T3360 鉴权加密定时器为6S,可从信令里面看，每次重发Authentication and Ciphering Req均不到1S或者在1S左右，这是什么原因呢?
2、导致这种Authentication不断重发的原因可能有哪些呢？
3、如果MS没有收到SGSN的Authentication and Ciphering Req，是不是应该在等待GPRS附着接受定时器超时后再发呢？
4、信令中伴随着LLC-DISCARDED和RADIO-STATUS，怀疑跟无线有关，可要是无线不行的话，可为什么只体现在下行方向？
期待高人解答！谢谢！

admin

说下我的想法。

1 这个应该不是等T3360超时后的重传。

2 正常的超时重传就是因为没有收到MS返回的Authentication and Ciphering response。

3 MS重发附着请求由Timer T3310来控制，默认15秒，发出attach request启动，收到attach accept中止。最大重发4次。

4 先纠正一个概念。LLC-Discard PDU通知SGSN有丢帧，这里的丢帧都是指下行，不是指上行。上行不存在丢不丢，如果没发给BSC，BSC也不知道有LLC帧丢失，如果发给了BSC，那BSC不需要缓存直接发给SGSN就可以了。规范中的解释是这样的：“This PDU indicates that a number of buffered LLC-PDUs in a cell for an MS have been deleted inside the BSS (because of PDU Lifetime expiration or radio outage for example). "。这里提到的buffer只针对下行。

但这里的问题不见得一定是无线侧的问题，个人感觉SGSN也有很大的嫌疑。因为本例中，MS采用的是用IMSI附着，根据规定，在BSSGP层中应采用一个随机TLLI（及前5个bit为01111）来标识自己，看附着请求确实是这样。但SGSN却连续发了3个Authentication and Ciphering request消息，这3个消息中BSSGP层的TLLI都不一样，只有第一个TLLI和MS附着请求的TLLI是一样的。后面两个感觉是SGSN急不可耐的分配了新的随机TLLI，但正常来说，新TLLI的生效要等到附着完成后分配了新的P-TMSI后才可以的。

这里附上一个用IMSI来附着的例子，没有附着成功CC7。关键是对比下BSSGP层中的随机TLLI应该是一直不变的。。

hycl5410

mark一下。从没见过SGSN还可以变着random TLLI发下行的，这个case很有意思。
这是哪家的SGSN啊？怎么会这样发呢。。。

望到天那边

是华为的SGSN9810，SGSN变化random TLLI发下行可能跟SGSN重发Authentication and Ciphering Req的间隔时间有关（T3360 鉴权加密定时器）！我对比了正常成功附着的信令流程，有重发都会间隔6秒，可这里间隔时间却很短！
不知道为啥，查规范也没查出个所以然。
猜想一：SGSN的T3360 鉴权加密定时器，时而生效时而不生效，可在什么情况下会不生效呢？
猜想二：T3360 鉴权加密定时器没生效时，SGSN就会改变TLLI重发Authentication and Ciphering Req？
找了规范也没有相关说明，这问题现在成了死点！

hycl5410

望到天那边 发表于 2012-9-24 14:43
是华为的SGSN9810，SGSN变化random TLLI发下行可能跟SGSN重发Authentication and Ciphering Req的间隔时间有 ...

对这种信令监控系统的抓包分析不是太信任。
建议用H SGSN内部的user trace来抓包分析，如果需要开工单找他们分析的话，他们也只会认user trace的。

qgdage

这个感觉是无线侧下行链路故障导致，故障可能是：PCU->MS一路上网元拥塞，无线拥塞，干扰，弱覆盖，根据本贴实例来看，感觉像是弱覆盖