CC7- GPRS Service not allowed

爱卫生

Cause Code7- GPRS Service not allowed

说明在HLR上没有关于这个用户的签约数据信息。这种情况需要检查的就是HLR的配置问题。比如一些新开通的用户，还没有来得及在HLR上更新配置的，就有可能出现这种情况。但需要注意的是，出现这个CC，代表Gr接口的网络层的连通性并没有问题，map消息都能正常的接收和发送。所以不需要去检查IP骨干网的路由，这些都是好的，否则如果SGSN收不到HLR的应答，会给MS回另外一个CC。暂且不提。

以下通过两个实验来验证。

1 CC7_Attach_reject_in_SGSN(No_subscried_apn_in_HLR).pcap文件。

#1 MS发起附着请求给SGSN，并携带自己的IMSI。
    #2至#5是SGSN向HLR请求了两组鉴权参数，用于鉴权MS等安全功能。  
    #6和#7是SGSN与MS之间的鉴权操作，完成对MS身份的确认。
    #8至#11 为SGSN和HLR完成关于用户的位置更新以及SGSN从HLR获取用户签约数据的过程。
    其中从#10 为HLR给SGSN返回的关于此MS的GPRS签约数据。从签约数据中可以看出，用户已经签约了GPRS业务（签约状态为Service Granted）。这并不是一个错误的应答，而是一个正确的应答。但从签约数据里并没有找到用户签约的APN信息。也就是说用户没有一个可以允许访问的外部网络。所以还轮不到用户做PDP激活，在附着阶段就把用户的附着请求给拒了。回的是CC7。下图展示了10号报文，HLR返回给SGSN关于MS的签约数据信息。

2 另外一个例子是CC7_Attach_reject_in_HLR(GPRS_Service_Not_Allowed_in_HLR)_new.pcap.这个例子是在HLR上没有开通用户的GPRS服务。而不是针对特定的APN。这在HLR上是一个0和1的开关可以来控制。

#1是附着请求。

#2 SGSN向HLR请求鉴权三元组对用户执行鉴权等安全功能，消息中携带了用户的IMSI信息。

#3是HLR回的error，这个error指示SGSN，这时一个未知的签约用户，因为通过相关指令在HLR上将用户的GPRS业务关闭了。如下图所示：

#4是SGSN给MS回的附着拒绝。

爱卫生

  在现网中，CC7的出现机率是很大的。这主要是因为用户原因，没有开通GPRS业务所造成的。
  以下是一个现网抓包截图，为CC7，用户未开通GPRS业务或GPRS业务关闭所造成的。

CC7-GPRS Service not allowed案例

shengm

很不错，受益了

DUT_RAY

现网中有一些运营商用户欠费停机，或者预付费用户余额不足附着也会被CC7拒绝

leering

非常棒。结合实例很清晰！

爱卫生

示例：  如何在爱立信SGSN上触发一个CC7？
  当SGSN上没有和这个用户相关的IMSINS，则无法完成GT翻译，进而GT寻址找到HLR。则会回一个CC7。在Lab里很容易实现CC7。通过命令行将和这个用户相关的IMSINS删除即可。
gsh delete_subscriber -imsi xxx

爱卫生

另外，如果这个用户没有开通GPRS服务。自然就没有这个用户的签约数据。因此只需要在HLR上将此用户的GPRS服务取消就可以制造CC7。以爱立信HLR为例：
命令是：Cancel GPRS service:  HGPDE:MSISDN=xxx,PDPID=ALL；

yonka

2012-05-24 11:16:03 IntRoam Event name: attach_completed ; Event details: Attach type gprs_attach ; Cause value: - ; IMSI: 283058000068011 ; MSISDN: 37493962378 ; NSAPI: - ; RAI: 460-01-54530-2 ; CGI: - ; Radio Access Type: WCDMA

2012-05-24 11:16:04 IntRoam Event name: detach ; Event details: Detach type -, hlr_initiated ; Cause value: #7 (gprs_services_not_allowed) ; IMSI: 283058000068011 ; MSISDN: 37493962378 ; NSAPI: - ; RAI: 460-01-54530-2 ; CGI: - ; Radio Access Type: WCDMA

2012-05-24 11:16:04 IntRoam Event name: ms_leaves_node ; Event details: - ; Cause value: - ; IMSI: 283058000068011 ; MSISDN: 37493962378 ; NSAPI: - ; RAI: 460-01-54530-2 ; CGI: - ; Radio Access Type: WCDMA

2012-05-24 11:21:19 IntRoam Event name: detach_success ; Event details: Detach type re_attach_not_required, sgsn_initiated_without_reattach ; Cause value: #7 (gprs_services_not_allowed) ; IMSI: 283058000068011 ; MSISDN: 37493962378 ; NSAPI: - ; RAI: 460-1-21762-1 ; CGI: 460-1-21762-19811 ; Radio Access Type: GSM

2012-05-24 11:21:19 IntRoam Event name: ms_leaves_node ; Event details: - ; Cause value: - ; IMSI: 283058000068011 ; MSISDN: 37493962378 ; NSAPI: - ; RAI: 460-1-21762-1 ; CGI: 460-1-21762-19811 ; Radio Access Type: GSM




比较奇怪的是，用户附着上来以后附着成功了。竟然SGSN还下发去附着CC7。
这个是什么原因呢？

爱卫生

没看到你的GSM下的附着成功的log啊。只有一个WCDMA的附着成功log。所以不知道你在GSM下是什么时间附着的，和WCDMA的附着成功间隔了5分钟，也就表示可能MS是个双模手机，可能已经被W网络踢掉后，附着到GSM网络有5分钟了，然后被去附着，那就可以看成正常啊。除非能有log看到是什么时候附着到GSM的。

WGPRSJIAYUAN

能不能由HLR或SGSN发起一次Detach流程，携带原因值“re-attach not requird ”呢。这样是不是就避免了一些用户频繁的发起Attach Request消息呢。

爱卫生

WGPRSJIAYUAN 发表于 2012-8-28 20:27
能不能由HLR或SGSN发起一次Detach流程，携带原因值“re-attach not requird ”呢。这样是不是就避免了一些用 ...

有道理，可以试试。但不见得有用。youka的log里好像也有SGSN发起去附着并带上re-attach not required的标志了。碰上不规范的手机就别讲规范了，讲不清。规范里规定了MS是不应该频繁发起附着请求的。