Attach Reject前是否应该进行鉴权？

cubbear

在分析GPRS附着失败时，发现因“GPRS services not allowed”导致的Attach Reject 有两种情形，一种是Attach Request后直接 Attach Reject 占80%左右，另一种是Attach Request后，进行鉴权和加密，然后才Attach Reject 占比20%。是在同一个BSC下面出现这两种情形，并且同一个用户多次附着的结果都是一样的，要么是第一种情形，要么是第二种情形。为什么会有这样的差别，只有Gb口信令的情况下，该如何进一步定位原因？ 谢谢！

ES_492

同问~~~@爱卫生

hycl5410

第一种（不找HLR）情形目前我能想到的就是非本网（PLMN）且无漫游关系的IMSI试图ATTACH，那么就肯定不会去找HLR，关键是也没有HLR可找。
其他可能欢迎大家补充~


第二种（找HLR）情形，那就一定是有HLR可找，但是HLR签约中无GPRS服务。这种情况的判断还是挺明确的。

cubbear

hycl5410 发表于 2013-1-9 11:09
第一种（不找HLR）情形目前我能想到的就是非本网（PLMN）且无漫游关系的IMSI试图ATTACH，那么就肯定不会去找 ...

从第一种（无鉴权）用户的IMSI看都属于本网用户，且这部分占比80%。

hycl5410

cubbear 发表于 2013-1-9 11:47
从第一种（无鉴权）用户的IMSI看都属于本网用户，且这部分占比80%。

在不能单用户trace或者联合Gr抓包的情况下，那就比较麻烦了。可能就涉及到设备实现方面的事情了。
比如，设备是否有某种功能可以记住没签约GPRS的用户，然后启动某个timer，在timer未超时前都不去查HLR，而是直接ATTACH reject。好处就是可以减少Gr负荷。

当然更有可能是别的原因只不过我没想到。

hrbqby

Attach Reject前是否应该进行鉴权 ?  

主要取决于厂家SGSN的鉴权参数组请求次数的设置, 该参数由VLR/MME/SGSN控制，在鉴权请求的vector number中由VLR/MME/SGSN上报HSS/HLR。HSS/HLR根据取值范围为1-5.CMCC现网设置一般是3或4.每次鉴权请求，要求HSS/HLR下发3组鉴权组。第一组在当前使用，MSC/SGSN/MME保存剩下的2组。在用完前，VLR/SGSN/MME不会向HLR/HSS再要鉴权组。当在鉴权请求中设置为5，可以降低C/D Gr/S6信令，但增加了VLR/SGSN/MME负荷。设置为1，增加C/D Gr/S6信令。

VLR/SGSN会向HLR请求鉴权数据，发送消息SendAuthenticationInfo给HLR，
其中的参数numberOfRequestedVectors指示VLR/SGSN希望得到的鉴权数据的数量。
协议3GPP TS29.002中说明，numberOfRequestedVectors是1-5之间的整数。
对于三元组，请求的数量为7减去未使用的个数，
对于五元组，请求的数量为4减去未使用的个数。
五元组一次消息只能回复一个，若请求多个，需多次请求，多次回复。

PS.最好还是有GR口的信令消息来定位问题,还需要HLR的兄弟帮忙看看吧!

ES_492

会不会有这种情况，就是这张卡都是注销的IMSI号，SGSN解析不了HLR，无法取鉴权参数，从而reject

oliverchang

6楼解释的很正确，并不是手机每次attach的时候都要去鉴权的，在CMCC中Gb是每5次要进行鉴权1次，所以说进行鉴权的比例是20%，不进行鉴权的比例就是80%了~~~，对于Iu则是每10次要鉴权1次，即鉴权比例是10%

ES_492

ES_492 发表于 2013-1-9 10:56
同问~~~@爱卫生

针对第二种找HLR的情况，有没有这样一种情况，就是如果HLR签约里面无GPRS服务，但是如果能进行CS域的服务，那么Attach的时候会不会鉴权？因为这时候是有鉴权三元组的

ES_492

hycl5410 发表于 2013-1-9 11:09
第一种（不找HLR）情形目前我能想到的就是非本网（PLMN）且无漫游关系的IMSI试图ATTACH，那么就肯定不会去找 ...

针对第二种找HLR的情况，有没有这样一种情况，就是如果HLR签约里面无GPRS服务，但是如果能进行CS域的服务，那么Attach的时候会不会鉴权？因为这时候是有鉴权三元组的

zyzai605

这个根据SGSN的设置不同，这个鉴权的比例不同

cubbear

zyzai605 发表于 2013-1-11 14:06
这个根据SGSN的设置不同，这个鉴权的比例不同

之前我也认为是否和鉴权设置有关，但从统计看应该不是。全部因“GPRS Services not allowed”失败的Attach reject 有505次，其中只有123次是有鉴权流程的，但这123次有鉴权流程的用户并没有出现无鉴权的情况。其中有个用户1小时内出现37次Attach reject 每次都有鉴权流程，另一个用户有35次Attach reject，每次都没有鉴权。如果只是1/5的要鉴权，但不应该都是同一个用户要么鉴权，要么不鉴权。

再问个问题：用户附着在SGSN时，HLR对该用户进行了GPRS业务的修改（如apn或关闭GPRS业务），这种修改是否会立即同步到原来的SGSN？还是说要等到用户再次attach时到HLR去查询才知道这种更新？如果用户已经detach了，HLR对该用户进行了GPRS业务的修改，又是什么情况呢？

爱卫生

cubbear 发表于 2013-1-11 17:22
之前我也认为是否和鉴权设置有关，但从统计看应该不是。全部因“GPRS Services not allowed”失败的Attac ...

没有那么傻的。如果HLR上修改了数据，它会发insert subscriber data消息给SGSN通知SGSN更新用户的签约数据。如果HLR发现用户已经关闭了GPRS业务，会直接发detach request将用户踢掉。另外，这和用户是否附着没有关系，即使没有附着，HLR更新数据后就给SGSN发送insert subsciber data消息，SGSN收到后更新就好了。等到下次用户直接开机附着就可以用了。LTE/EPC网络里也是这么用的。

hycl5410

之前我也认为是否和鉴权设置有关，但从统计看应该不是。全部因“GPRS Services not allowed”失败的Attach reject 有505次，其中只有123次是有鉴权流程的，但这123次有鉴权流程的用户并没有出现无鉴权的情况。其中有个用户1小时内出现37次Attach reject 每次都有鉴权流程，另一个用户有35次Attach reject，每次都没有鉴权。如果只是1/5的要鉴权，但不应该都是同一个用户要么鉴权，要么不鉴权。

先查配置咯，ATTACH鉴权比例是多少，看一下配置就知道了啊。然后再进一步分析。
1）如果100%鉴权，那么就不用Gr抓包了，肯定就是没去找HLR直接回了reject
2）如果非100%鉴权，那就需要跟Gr匹配了，看看是不是SGSN没有找HLR就直接回了reject

确定以上情况之后，再想办法查是不是其他什么配置或者feature会允许SGSN直接这么做，或者也可以在SGSN上查查是否有这些用户的数据。

cubbear

hycl5410 发表于 2013-1-14 09:49
之前我也认为是否和鉴权设置有关，但从统计看应该不是。全部因“GPRS Services not allowed”失败的Attach  ...

SGSN上配置的是每次ATTACh都要鉴权。那为什么还会有80%左右的用户没有进行鉴权就直接attach reject了？

hycl5410

cubbear 发表于 2013-1-16 17:27
SGSN上配置的是每次ATTACh都要鉴权。那为什么还会有80%左右的用户没有进行鉴权就直接attach reject了？
...

1）确认没有鉴权就reject的cause code是not subscribed这类，而不是network failure这类

2.1）在SGSN上查询没有鉴权的那些用户的信息，如果有，打印出来看看
2.2）在SGSN上查询有鉴权但是reject的那些用户的信息，如果有,打印出来看看

3.1）如果2.1）为否，查询SGSN是否有某些特殊的功能，对确认没有GPRS的签约用户，在短期内不去查HLR就直接reject
3.2）如果2.1）为否，查询SGSN是否有某些功能，可以将其他cause code（或者某些场景）map成GPRS serrvice not subscribed

4）某些厂商可能会有一些其他的记录MM信息的log，比如EBM或者CHR这类，如果有，可以尝试查询。