CC33 - Requested service option not subscribed

爱卫生

CC33 - Requested service option not subscribed
   这个CC说明的是MS在PDP请求的消息中请求的信息和用户的签约信息不符。所以根据这个说明，可以推断出以下几点。
1）用户其实已经附着成功，并且SGSN也已经得到了HLR过来的用户签约信息。
2）这些不符的信息可能包括请求的地址类型，QOS，APN不符等等。

例一：MS请求的APN和签约数据不符，简单的说，用户并没有开通对这个APN的访问服务，如cmwap包月，不能访问blackberry。
1)#3是HLR返回给SGSN的签约信息。点开看，发现在MAP消息里，MS的签约数据里包含的签约APN为：0554455....。当然这是16进制，在右边的wireshark解码区其实已经解析出来，是testj.bj。
2)#6是附着成功的消息。因为在附着阶段并不违反任何规则。
3)#8是MS发起的激活请求，请求的APN是eetest。
4) #9这个MS请求的APN明显没有包含在签约数据中，所以SGSN回了CC33的拒绝激活消息给MS。

例二：用户请求静态IP，和签约数据不匹配。
这个例子和用户请求静态IP1.1.1.1，但签约数据只允许用户使用动态IP。所以激活失败。

hendouse

最近我们这边研究了下这个原因值，发现用户的GPRS数据在HLR上被删除的话，他发起的PDP激活也是以这种原因值发起的。
因此，这种原因值还包括 “用户的GPRS数据在HLR上被删除的”。

爱卫生

回复 hendouse 的帖子

  恩，我也觉得应该是这样的。签约数据如果在HLR上被删除了。那就代表SGSN根据就取不到用户的签约数据了，或者换言之SGSN就会认为用户根本没有签约即开通GPRS业务，所以回CC33也是合理的。谢谢补充！

onlyybj

哎，我这儿出现过行业APN的静态IP激活失败 但是是归结在CC28里面了

aclee

在例二的包中没有看到“只允许用户使用动态IP”的描述， 在例一的#3里也没有找到对于用户可以使用的IP的描述，是我找错位置了还是有别的原因吗？

爱卫生

aclee 发表于 2012-6-29 14:51
在例二的包中没有看到“只允许用户使用动态IP”的描述， 在例一的#3里也没有找到对于用户可以使用的IP的描述 ...

有的。是CC33_static_address_not_allowed_new.pcap这个抓包。里面activate pdp context request消息里带了静态PDP地址1.1.1.1激活，但GGSN侧没有配置该静态IP，所以后面PDP激活就拒绝了！

huwei284986

这个有点意思。

paul

不错，好好学习学习。