Detach Type(去附着类型)

爱卫生

在TS24.008（V7.1.0）的10.5.5.5中描述。用于指示MS请求的去附着类型。如果是网络侧到MS方向发起的去附着，还用于指示为什么Detach Request需要发送的原因。本IE通常在MS或SGSN发起的去附着流程的Detach Request消息里携带。

通常为4个bit。其中第1个bit为Power off指示，不分方向。后3个bit的含义根据方向（MS发起到网络侧还是网络侧发起到MS）的不同，含义有所不同。

第1个bit为Power off指示。不分方向。取值

00 代表 normal attach

01 代表 power switched off，即因MS关机原因引起的去附着。

后3个bit如果是MS发起的去附着，则含义为：

001 代表 GPRS detach。即仅从PS域去附着

010 代表 IMSI detach。即仅从CS域去附着

011 代表 Combined GPRS/IMSI detach。即联合区附着，同时从CS域和PS域去附着。

如果是网络侧(SGSN)发起的去附着，则含义为：

001 代表re-attach required。即网络侧希望MS在完成去附着流程后立即重新发起附着流程。

010 代表re-attach not required。即MS在完成去附着流程后不需要立即重新发起附着流程。

011 代表IMSI detach。代表从CS域去附着。

以下截图为MS因关机原因发起的去附着流程中，Detach Request消息中的Detach Type IE。

从图中可以看出，Wireshark解码出对应的Detach Type十六进制值为09。转换为二进制为0000 1001。Detach Type占后4个bit，因此是1001。第1个bit为1代表Power off位置1，后3个bit取值为001，并且这个去附着是MS发起的，因此含义为仅从PS域去附着。

Kaka』

爱卫生老师，我想问下，现在有个例子是用户发起attach请求后，网络没有accept，也没有reject，用户attach请求以后，终端开始detach，然后detach accept，然后再attach请求，一直这样情况

Kaka』

附上一张图吧，

Kaka』

Kaka』 发表于 2012-8-22 14:48
附上一张图吧，

Kaka』

能看到么，帮忙看看问题吧，我这边猜测的原因也是终端的问题，可能是进行了某些设置导致这种问题的发生？

爱卫生

Kaka』 发表于 2012-8-23 10:11
能看到么，帮忙看看问题吧，我这边猜测的原因也是终端的问题，可能是进行了某些设置导致这种问题的发生？

能抓包吗？感觉SGSN没有回Attach Accept。但实际上SGSN是收到了attach request并且给MS发了indentity request并收到了response，从而将MS的MM状态置成了Ready。这样后续MS发detach request后才会回detach accept消息。

这个SGSN为什么不回attach accept可能是个问题。但规范里有说MS在没有收到attach accept消息后，可以重发attach request，但有个最大次数。超过次数限制，将停止发送并将之前分配的P-TMSI等信息删除。所以说MS在没有收到attach accept的情况下就发detach request应该是不合规范的。因为MS的MM状态应该此时还是在Idle状态的。

skyever

学习一下！！！

Kaka』

爱卫生 发表于 2012-8-23 10:42
能抓包吗？感觉SGSN没有回Attach Accept。但实际上SGSN是收到了attach request并且给MS发了indentity req ...

这个图的包是没有啦，等会我弄个类似的包吧，不过前面奇怪的是，attach请求刚发起，sgsn就发起identity请求，ms还没有进行响应，ms就发起detach了，而且网络还接受了，下发了detach accept，有点怪哦

pang1688

我来提过提供这样的一个包吧，感觉我看到的和你们说的问题比较像，，麻烦看看怎么解释这样的流程？