3GPP 24.008 Cause汇总

目录

24008 #9 (MS identity cannot be derived by the network);

24008 #10隐式分离

24008 #17(Network failure)

24008 #33 Requested service option not subscribed

24008 #96:Mandatory information element error

24008 #111: Protocol error, unspecified.

---

24008 #9 (MS identity cannot be derived by the network);

# 9 (MS identity cannot be derived by the network);

＃9（MS身份不能由网络导出）;
MS应将GPRS更新状态设置为GU2 NOT UPDATED（并根据子条款4.1.3.2存储），进入状态GMM-DEREGISTERED，并删除任何P-TMSI，P-TMSI签名，RAI和GPRS加密密钥 序列号。 如果被拒绝的请求不是用于发起针对紧急承载服务的PDN连接，则MS可以随后自动地发起GPRS附着过程。 如果MS中支持S1模式，则MS应当处理跟踪区域的情况下的3GPP TS 24.301 [120]中规定的EMM参数EMM状态，EPS更新状态，GUTI，上次访问的注册TAI，TAI列表和KSI 更新过程被拒绝，EMM原因具有相同的值。

 

按照规范的解释，该拒绝原因是网络无法从 P-TMSI、 P-TMSI Signature、RAI 等 MM 上下文中标识的参数来识别 MS ID，MS 进入 GMM-DEREGISTERED的状态。
根据以往的经验出现MS id cannot be derived by network主要会因为在ATTACH或是RAU过程中Old SGSN没有保留MS的信息，而导致New SGSN无法从Old SGSN获得MS的MM上下文， New SGSN需要通过对MS重新发起Identity流程来获取MM上下文。 由于这种原因产生的MS id cannot be derived by network需要得到Gn接口的数据支持。 

 

另一种在 ATTACH 过程中产生 MS id cannot be derived by network 的原因是某些 MS 使用了保留的 LAC 发起 ATTACH Request 请求。
典型问题流程如下：

MS 使用 LAC 65534 发起 ATTACH Request 请求， SGSN 拒绝这些请求，原因是 MS ID can’t not be derived by the network。 ATTACH Request 中的 LAC合法长度是 2 字节， FFFE（ 65534）是保留的 LAC 值（ 3GPP TS23.003），在特定状态下当 MS 中没有合法的 LAI 时才会使用。估计是 MS 当时所处的小区性能存在问题， MS 自行删除了原来的小区信息。

24008 #10隐式分离

原因值= 10隐式分离
如果网络已隐含地分离MS，则将该原因发送到MS。 在移动可达定时器期满之后的一些时间，或者如果与订阅相关的GMM上下文数据不存在于SGSN中。 因为SGSN重新启动，或者由于周期性路由区域更新请求被路由到新的SGSN。

＃10（隐式分离）;
如果更新类型是“周期性更新”，则在网络操作模式I中以MS操作模式A或B操作的GPRS MS对于网络中的GPRS和CS服务都是IMSI分离的。 MS应进入状态GMM-DEREGISTERED.NORMAL-SERVICE。如果被拒绝的请求不是用于发起针对紧急承载服务的PDN连接，则MS应当执行新的附着过程。 MS还应该激活最初由MS激活的PDP上下文以替换任何先前的MS激活的PDP上下文。 MS还应执行所需的过程以便激活任何先前活动的多播服务。如果在MS中支持S1模式，则当跟踪区域更新过程由于具有相同值的EMM原因而被拒绝时，MS应当处理3GPP TS 24.301 [120]中规定的EMM状态。注4：在某些情况下，可能需要用户交互，然后MS不能自动激活PDP和MBMS上下文。

从以上流程可看出用户在向 SGSN 发起 Routing area update Request 之后， SGSN 先是拒绝用户的请求，并且回送了 Cause 为 Implicitly Detached。紧接着手机重新发起了一起 ATTACH，并且 SGSN 在收到 ATTACH 请求消息之后发起了一次 Identity Check 过程，即向手机发起 Identity Request 消息，要求重新获取手机的 IMSI，之后手机回应了包含 IMSI 的 Identity Response 消息。从规范中定义的流程我们知道，正常的情况下，新的 SGSN 在收到手机发出的outing area update Request 之后，应该根据 outing area update Request 消息里面包含的 Old RAI 来查询 DNS，得到老的 SGSN 的地址，然后给老的 SGSN发送 SGSN Context Request 消息获取 MS 的 MM 上下文。只有在新的 SGSN无法获取老的 SGSN 的地址或者老的 SGSN 也没有该手机的 MM 上下文的情况下，新的 SGSN 才会直接给手机发起 Identity Check 过程来获取 IMSI，完成之后的路由区更新。这足以证明在老的 SGSN 上已没有了该用户的信息，并将其置为 Implicitly Detached 状态。请见下图标准 RAU 流程所示：

 

一般来说， MS 发送 Routing Area Update Request 请求消息中会包含使用的 TLLI， PTMSI/PTMSI Signature 和 RAI 信息， SGSN 接到请求后检查比对MS 的状态和 RAU 请求中的 TLLI， PTMSI/PTMSI Signature。在 SGSN 中为每个 MS 保存着 Reachable Timer，如果 Reachable Timer 超时而 MS 没有做路由区更新， SGSN 会把该 MS 的状态设为 Detached。所以如果当 MS 被置为Detached 状态后再次向 SGSN 发起路由区更新请求时， SGSN 会拒绝 MS 的请求，并且在拒绝消息中 Cause 为 Implicitly Detached；如果 Reachable Timer没有超时而某些异常的 MS 发送路由区更新请求中的 TLLI， PTMSI/PTMSISignature 与 SGSN 中保存的该 MS 先前的 GMM 信息无法对应， SGSN 也会拒绝请求，拒绝消息中附带 Cause 为 Implicitly Detached。

24008 #17(Network failure)

attach reject：

＃17（网络故障）
如果MS仍在运行，则MS将停止定时器T3330，并且将进入状态MM-IDLE。路由区更新尝试计数器应递增。如果路由区更新尝试计数器小于5，并且存储的RAI等于当前服务小区的RAI，并且GMM更新状态等于GU1 UPDATED：
- MS应保持GMM更新状态GU1 UPDATED，并将状态更改为GMMREGISTERED.ATTEMPTING-TO-UPDATE-MM。 MS应启动定时器T3311。当定时器T3311期满时，再次触发指示“具有IMSI附着的组合RA / LA更新”的组合路由区更新过程。
如果路由区更新尝试计数器大于或等于5：
- MS应启动定时器T3302，并改变到状态GMM-REGISTERED.ATTEMPTING-TOUPDATE-MM;
- 在MS操作模式A中操作的GPRS MS然后应当进行适当的MM特定过程;在MS操作模式B中操作的GPRS MS然后可以进行适当的MM特定过程。
MM子层将充当网络操作模式II或者只要组合的GMM过程不成功并且不输入新的RA即可。

 

 根据以往的优化项目经验， Network failure 这种 Reject 主要与 Gr 接口通畅度以及厂家 HLR 上用户数据配置以及与漫游用户的 HLR 路由是否能否正确连接有关。如果用户数据配置错误或者漫游用户的 HLR 返回的响应消息中显示不支持 GPRS 的所需的MAP 版本，这种用户大多数可能为外地手机。从这种情况说明当时 MAP 请求信令没有正常回应或 SGSN 无法进行 IMSI 分析处理。 可能该 IMSI 所归属的公司没有与中国移动签约，类似这些未签约的漫游客户将不允许接入移动 GPRS 网络。关于此部份内容，建议下阶段通过跟踪 Gr 接口信令来具体定位。
 

 RAU reject

MS 发起 RAU 请求，然后 SGSN 要求同 MS 协商LLC 连接。 SGSN 下行发送 U Exchange Identification(XID)命令，要求同 MS进行 LLC 协商，但 BSS 没有将 XID 消息下传给 MS， BSS 删除了 LLC 协商消息，向 SGSN 发送 LLC-Discarded。 SGSN 在 5 秒钟后再次发送 XID 命令，要求同 MS 进行 LLC 协商， BSS 仍然将其删除，并通过 LLC-Discarded 消息通知SGSN。如此往复数次。当 MS 能够同 SGSN 建立 LLC 连接时， SGSN 拒绝MS 的请求，原因是 Network Failure。

分析其中由于估计当时 MS 所处的小区无线环境很差，造成 BSS 多次丢弃LLC 帧， SGSN 接收到多次 LLC-Discarded 消息后，相应软件模块不能继续处理 MS 的请求，返回 Network Failure。
 

24008 #33 Requested service option not subscribed

Cause value = 33 Requested service option not subscribed
This cause is sent when the MS requests a service option for which it has no subscription.

这种拒绝原因主要是由于用户对手机的设置行为不当，如：对手机设置了静态 IP 地址、设置了空或错误的 APN、以及受限制的漫游用户等等都会造成的PDP 上下文激活失败，这些拒绝是网络很难以控制的。

 

 

 用户的请求消息 GMMSM 中设置了错误的 APN：

其中有部份用户设置了 cmwap 及 cmnet 的 APN，但是由于用户误将手机的 IP 地址设成了诸如 10.0.0.172 或 10.214.241.225 这样的静态 IP，导致在使用 cmwap 发起 PDP 激活时出现被网络拒绝

如下是用户设置了空的 APN 遭到拒绝的典型流程：

 

 Requested service option not subscribed也可能是在 SGSN 或 HLR 上未给这些用户定义.gzjtxx01.GD 的APN 数据导致出现拒绝的现象。

24008 #96:Mandatory information element error

24008 #96:Mandatory information element error

Invalid mandatory information这种Reject一般产生的原因主要是：用户手机未正常发送IMSI信息进行ATTACH请求，而是在ATTACH请求消息中使用IMEI，而引起ATTACH请求的失败。手机终端使用IMEI做ATTACH REQUEST是规范所允许的，但是使用IMEI进行ATTACH在当前网络是不允许的，我们怀疑的一种可能性是当前广州移动对新老用户均已默认开通了GPRS功能，用户用IMEI进行ATTACH请求可能由于部份用户开机时没有插入SIM卡或是插入未注册的SIM卡，而导致终端无法获取IMSI信息，从而用手机的IMEI进行ATTACH请求，如果是出现类似于这样的情况我们认为应该是属于正常范筹的。但也不排除网络中存在一些问题终端默认使用IMEI进行ATTACH请求的可能性。

24008 #111: Protocol error, unspecified.

#111: Protocol error, unspecified. 

Protocol error, unspecified 这种拒绝在现网出现的比例很低，出现的原因是按照 3GPP 规范如果终端在没有从网络侧获取到 TLLI 时，便会使用自身随机产生的 TLLI 向 SGSN 发送附着请求。如果 SGSN 检测到 MS 随机产生的 TLLI在现网中已分配给其它用户，则会拒绝接受附着请求，产生 Protocol error,unspecified 的 Reject，但现网中存在小部份终端被网络拒绝附着后仍然使用相同的 TLLI 继续发起附着请求的现象，如下图流程所示：

从中可看出同一 IMSI 的用户较短时间用相同的 TLLI 进行附着请求而导致出现这种原因的拒绝。认为主要还是由于部份终端的设计不符合规范所造成。