51学通信技术论坛

 找回密码
 立即注册
搜索
查看: 9084|回复: 8
打印 上一主题 下一主题

CC111 Protocol Error,Unspecified的问题 [复制链接]

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

跳转到指定楼层
楼主
发表于 2011-6-14 16:16:00 |只看该作者 |倒序浏览
一键分享 一键分享
版主有空给我们举例解析一下cc111 protocol error,unspecified产生的原因,多谢!

Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7Rank: 7

版主

沙发
发表于 2011-6-14 17:46:45 |只看该作者
CC111可以导致attach失败,也可以导致PDP激活失败。

分析:
1、在W网络中,SGSN下发"Security Mode Command"消息,RNC回复""消息中携带CauseCode111。可能是SGSN中IuC的配置错误,或许是Iu接口问题。
2、在G/W网络,Ril3消息错误,SGSN认为附着请求消息就存在语法错误。需要抓包分析请求消息。

使用道具 举报

Rank: 9Rank: 9

懒

板凳
发表于 2011-6-14 19:46:14 |只看该作者
  我补充一点,关于TS24.008上关于CC111的说明。可以参考TS24.008(V10.1.0)的附录H.6.8关于CC111的描述。它是属于协议错(未知消息)这个大类的。涵盖了CC96---CC102和CC111都属于同一大类即协议错这个大类。
  关于CC111的具体定义是“This cause is used to report a protocol error event only when no other cause in the protocol error class applies.”说白了就是,如果是协议错,但又不能算到CC96---CC102的,统统都算做CC111。

  没有抓到的包,但摘录一个现网的优化报告,是在附着失败出现的CC111。
——————————————————————————————————————————————————
ATRJ Cause Value = Protocol error, unspecified
数据收集时段,这种附着请求失败次数占失败总次数的5.10%。
按照规范MS在没有从网络侧获得TLLI时,使用自身产生的随机的TLLI向SGSN发送附着请求。然而在数据分析过程中发现,网络中有一定数量的MS使用相同的TLLI(11e1111e)同时向SGSN发送大量的附着请求由于这时已经有一个11e1111e在使用,所以产生“Protocol error, unspecified”。
统计中共50次“Protocol error, unspecified”,其中有49次是由同一个TLLI-11e1111e产生的,怀疑这些手机是同一款存在问题的手机,可通过IMSI查出手机号验证。
——————————————————————————————————————————————————

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

地板
发表于 2011-6-14 19:54:41 |只看该作者
谢谢两位的解答,我这里有一个lab环境下抓的gb+gr数据,跟你们分享一下,也请你们分析一下原因,非常感谢!
附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册

使用道具 举报

Rank: 9Rank: 9

懒

5#
发表于 2011-6-14 21:45:48 |只看该作者
本帖最后由 爱卫生 于 2011-6-15 09:37 编辑

回复 heropoet 的帖子

  例子给出的是Iu-C口和Gr口的包,不过上层的GMM消息都差不多的。
  从抓包来看,我个人感觉,应该和上面我给出的例子比较类似。我给的例子是手机带上的TLLI相同。
  假设例子中的MS叫MS-A。
  在这个例子中,#13,SGSN收到HLR发过来的MS的签约数据后,应该回一个ACK,但没有回,因此代表SGSN意识到了什么。初步分析,我个人感觉应该是这个用户已经在SGSN上附着成功了。也只有重,才有可能是回CC111 protocol error。但在Lab里面,IMSI是不会重的(除非你特意找得假冒的IMSI的手机)。那重的只有可能是MSISDN,在#13里关于HLR告知SGSN,MS的MSISDN(即手机号)是8612301000017(当然,肯定没有123号段的手机,但这个不是关键)。我怀疑HLR上为另外一台手机假设是MS-B也配置了相同的MSISDN,那这个MS-B已经在MS-A发附着请求之前就已经附着成功了。所以SGSN看到有两个MS的手机号都相同,因此就把后来的这个MS-A的附着拒掉了,并给MS-A回了一个CC111。
  所以,麻烦检查下SGSN上,是不是有一个MSISDN为8612301000017的用户已经附着成功,就真相大白了。
  否则,如果是其他情况,我觉得SGSN怎么都应该给HLR回一个ACK,并且CC都不应该是CC111。
  所以,我的理解就是,这个例子里的问题是:HLR上为两个MS的签约数据配置了相同的MSISDN。
  个人理解。谨供参考。

www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

6#
发表于 2011-6-14 23:27:06 |只看该作者
这个确实是IU-PS+Gr的数据,回贴时写错了,版主说这种情况,我看能不能找人核实一下.多谢版主细心的讲解!

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

7#
发表于 2012-1-19 11:18:16 |只看该作者
这个案例非常受用,但在现网时却遇见了这样的问题:按照流程,SGSN会向HLR发送LOCATIONUPDATE的消息,其中带的是IMSI,然后HLR会向SGSN回送MSISDN,也就是说,这个(IMSI,MSISDN)的关系是唯一的,因为现网抓包用户非常多,我怎么样在这么多的消息中取得到特定IMSI对应的MSISDN。貌似同一用户的上下信令流间没有共性的地方

使用道具 举报

Rank: 1

8#
发表于 2012-5-18 15:25:25 |只看该作者
恩 ,同意爱卫生的说法 我今天遇到了,用同样的TLLI

使用道具 举报

Rank: 2Rank: 2

9#
发表于 2012-9-10 11:20:42 |只看该作者
好贴,学习了

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-5-29 11:46 , Processed in 0.030972 second(s), 14 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部