6.6 去附着功能

爱卫生

6.6 去附着功能
  GPRS去附着功能允许：
- MS通知网络侧它不再需要访问基于SGSN的业务；以及
- 网络侧通知MS它不再有基于SGSN的业务。
  去附着功能允许MS通知网络侧它需要执行一个GPRS 和/或 IMSI去附着，并允许网络侧通知MS，它已经被网络侧执行了GPRS或IMSI的去附着。
  不同类型的去附着包括：
- IMSI去附着；
- GPRS去附着；以及
- 联合的GPRS/IMSI去附着（只能MS发起）
MS可以显式或者隐含的去附着：
- 显式去附着：网络或MS显式地请求去附着.
- 隐式去附着：网络侧在不通知MS的情况下，对MS执行去附着，取决于一个在mobile reachable计时器超时后启动的和配置相关的计时器，或者在一个不可恢复的因为空口错误导致的逻辑链路断开之后。
在显式去附着的例子里，一个detach request（原因代码）由SGSN发给MS，或者MS发给SGSN。
  MS可以根据它是否已经GPRS附着，来发起一个IMSI去附着：
- 一个已经GPRS附着的MS发送去附着请求消息给SGSN，来指示一个IMSI的去附着。这可以和GPRS去附着捆绑完成。
- 一个还没有GPRS附着的MS执行的IMSI去附着，已经在A/Gb模式或Iu模式定义。
  在MS发起的去附着消息中，有一个指示如果是因为关机原因或不是。这个指示需要知道，来决定附着接受消息是否应该返回。
  在网络侧发起的去附着消息，有一个指示告诉MS，对之前激活的PDP上下文，请求发起GPRS附着和PDP上下文激活流程。

6.6.1 MS发起的去附着流程
  MS发起的去附着流程参考图例23。

Figure 23: MS-Initiated Combined GPRS / IMSI Detach Procedure
   注释：除了步骤2的所有步骤对基于Gn/Gp的GGSN还是基于S4接口的和S-GW/P-GW的交互，都是公共的架构。对于基于S4的接口，和S-GW/P-GW的交互，流程步骤（A）在6.6.3定义。
1）MS发送去附着请求（去附着类型，P-TMS,P-TMSI签名，关机指示）给SGSN。附着类型指示是一个GPRS去附着，IMSI去附着还是一个联合的去附着.关机指示指明这个去附着是否因为关机引起.去附着消息包含了P-TMSI和P-TMSI签名.P-TMSI签名用于检查去附着请求消息的合法性.如果P-TMSI签名不正确或没有包含,则不能执行鉴权流程.
   如果SGSN通过一个CSG小区并带的关机参数指示这个去附着不是由于关机引起的,并且CSG签约数据中没有这个CSG ID或已超时，SGSN应该触发一个SGSN发起的去附着流程，在6.6.2.1描述。
2) 如果是GPRS去附着,在GGSN上的关于这个MS的已激活的PDP上下文将被去激活---由SGSN发送delete pdp context request(TEID)给GGSN发起.GGSN通过delete PDP context response消息（TEID)确认。
3）如果是IMSI去附着,SGSN发送IMSI去附着指示消息给VLR。
4）如果MS要保持IMSI附着，只做GPRS去附着，SGSN发送一个GPRS 去附着指示（IMSI)消息给VLR。VLR删除和SGSN的关联，并在处理寻呼和位置更新时不经过SGSN。
5）如果关机指示表明这不是因为关机引起的,SGSN发起哦那个detach accept给MS.
6）如果MS是GPRS去附着，那么3G-SGSN将释放PS的信令连接。
CAMEL流程应该执行；参考TS23.078
C1)CAMEL_GPRS_PDP_Context Disconnection
这个流程将被执行多次：每个PDP上下文一次.流程返回做为结果是“Continue".
C2)CAMEL_GPRS_Detach和CAMEL_PS_Notification
它们按照以下次序发起：
- CAMEL_GPRS_Detach发起.流程返回作为结果是“Continue".
- CEMEL_PS_Notification发起.流程返回作为结果是“Continue".

6.6.2 网络发起的去附着流程
  网络发起的去附着参考图例24

Figure 24: SGSN-Initiated GPRS Detach Procedure
    注释：除了步骤2的所有步骤对基于Gn/Gp的GGSN还是基于S4接口的和S-GW/P-GW的交互，都是公共的架构。对于基于S4的接口，和S-GW/P-GW的交互，流程步骤（A）在6.6.3定义。
1）SGSN通知MS它已经被去附着了，通过发送去附着请求（去附着类型）给MS。去附着类型指示MS是否为之前激活的PDP上下文去请求发起一个新的附着和PDP上下文激活。如果是，那在去附着流程执行完后，应该发起一个附着流程。
   如果去附着是由于MS的去附着请求通过一个CSG小区但MS不允许接入码例如CSG签约信息不包含这个CSG ID或超时了,SGSN应发送一个去附着请求给MS，并指示一个合适的原因代码来指示MS不允许接入这个CSG.
2) 如果是GPRS去附着,在GGSN上的关于这个MS的已激活的PDP上下文将被去激活---由SGSN发送delete pdp context request(TEID)给GGSN发起.GGSN通过delete PDP context response消息（TEID)确认。
3）如果MS是IMSI和GPRS同时附着了,SGSN发送一个GPRS 去附着指示（IMSI)消息给VLR。VLR删除和SGSN的关联，并在处理寻呼和位置更新时不经过SGSN。
4）在步骤一完成的任何时候,MS发送detach accept消息给SGSN。如果MS从SGSN收到从一个CSG小区来的去附着请求并指示MS不允许接入这个CSG,MS应从允许的CSG列表中删除这个CSG ID.
5）在接收到detach accept消息后,如果去附着类型不要求MS执行一个新的附着,那么3G SGSN将释放PS的信令连接.
CAMEL流程应该执行；参考TS23.078
C1)CAMEL_GPRS_PDP_Context Disconnection
这个流程将被执行多次：每个PDP上下文一次.流程返回做为结果是“Continue".
C2)CAMEL_GPRS_Detach和CAMEL_PS_Notification
它们按照以下次序发起：
- CAMEL_GPRS_Detach发起.流程返回作为结果是“Continue".
- CEMEL_PS_Notification发起.流程返回作为结果是“Continue".

6.6.2.2 HLR发起的去附着流程
  HLR发起的去附着流程去由HLR发起的.HLR使用这个流程，是因为一些运营商决定的因素，需要请求在SGSN中删除用户的MM和PDP上下文.HLR发起的去附着流程在图例25描述.
  对于有紧急PDP上下文的MS,SGSN不应发送去附着消息给MS.作为替代,SGSN应去去激活所有的非紧急PDP上下文.
  
Figure 25: HLR-Initiated GPRS Detach Procedure
    注释：除了步骤2的所有步骤对基于Gn/Gp的GGSN还是基于S4接口的和S-GW/P-GW的交互，都是公共的架构。对于基于S4的接口，和S-GW/P-GW的交互，流程步骤（A）在6.6.3定义。

爱卫生

1）如果HLR需要请求立即删除SGSN上的用户的MM和PDP上下文，HLR应发送一个cancel location（IMSI,Cancellation type）消息给SGSN，并且cancellation type设置为subscription withdrawn（签约信息收回）。
2）SGSN通知MS它已经被去附着了--通过发送detach request（detach type）给MS。detach type应该指示这个MS不请求执行一个新的附着和PDP上下文激活。
3）在GGSN上的关于这个MS的已激活的PDP上下文将被去激活---由SGSN发送delete pdp context request(TEID)给GGSN发起.GGSN通过delete PDP context response消息（TEID)确认。
4）如果MS是IMSI和GPRS同时附着了,SGSN发送一个GPRS 去附着指示（IMSI)消息给VLR。VLR删除和SGSN的关联，并在处理寻呼和位置更新时不经过SGSN。
5）在步骤2完成的任何时候,MS发送一个detach accept消息给SGSN。
6）SGSN通过cancel location ACK(IMSI)消息进行MM和PDP上下文的删除确认。
7）在接收到detach accept消息后,如果去附着类型不要求MS执行一个新的附着,那么3G SGSN将释放PS的信令连接.
CAMEL流程应该执行；参考TS23.078
C1)CAMEL_GPRS_PDP_Context Disconnection
这个流程将被执行多次：每个PDP上下文一次.流程返回做为结果是“Continue".
C2)CAMEL_GPRS_Detach和CAMEL_PS_Notification
它们按照以下次序发起：
- CAMEL_GPRS_Detach发起.流程返回作为结果是“Continue".
- CEMEL_PS_Notification发起.流程返回作为结果是“Continue".

6.6.3在去附着流程中,SGSN基于S4接口的交互

Figure 25A: SGSN interaction when using S4
   注释1：步骤A和D对于基于GTP的S5/S8和基于PMIP的S5/S8接口是公共的架构.对于一个PMIP的S5/S8，流程步骤A1在TS23.402定义.步骤B和C是关于基于GTP的S5/S8.
A)对每一个PDN连接, 和这个MS相关的EPS承载被去激活---由SGSN发送delete session request给SGW。这个消息可以包含一个指示所有的属于这个PDN连接的承载应该被释放.
B)SGW发送delete session request给PGW.PGW可能需要和PCRF(参考TS23.203)进行交互.
C)PGW通过发delete session response给SGW来确认承载的去激活.
D) SGW通过delete session response消息确认.
  更多的由于ISR和在SGW---PGW之间的消息在TS23.401的5.3.8“去附着流程”描述.

Albert

去附着部分有几个地方版主笔误了。
SGSN-Initiated GPRS Detach Procedure部分第五步，“如果去附着类型不要求MS执行一个新的去附着”
HLR-Initiated GPRS Detach Procedure部分第七步，“如果去附着类型不要求MS执行一个新的去附着”
都多了个“去”

爱卫生

回复 Albert 的帖子

   非常感谢，已经更正了。为了方便大家查阅，后续的翻译将采用中英对照的方式，先原文，后翻译的方式。这样也可以方便大家帮忙鉴别我的错误。

Albert

呵呵，今天刚好配合版主的中文版，看TS23.060英文文档.看到这里。

Albert

“一个已经GPRS附着的MS发送去附着请求消息给SGSN，来指示一个IMSI的附着。这可以和GPRS去附着捆绑完成。”貌似版主笔误漏个，来指示一个“去”IMSI的附着。

1.为什么MS在不是关机时才会有detach accept的消息返回呢？

2.发现去附着的第一步里也会有鉴权，但是流程里为什么没提嘞？

3.看前面版主的视频，国内未开放到VLR的Gs接口，对于MS要保持IMSI附着，而去除GPRS附着这种情况下，SGSN是怎么发送一个GPRS 去附着指示（IMSI)消息给VLR。这是怎么实现的。

4.在网络侧去附着的流程中说到在步骤一完成的任何时候。MS发起Detch accpet给SGSN,意思是不是去附着和删除PDP context是两个相对独立的过程。

爱卫生

回复 Albert 的帖子

1.为什么MS在不是关机时才会有detach accept的消息返回呢？
  答：如果你的detach type是因为关机触发的，你已经关机了。网络侧给你发detach accept消息你是接收不到的。没有意义。所以就不发了。发detach accept消息的目的本身是为了同步网络侧和MS关于移动性的状态，如果你是非关机触发的，网络侧将你标记成idle状态后，要发送detach accept消息个MS，MS收到后也将自己的状态标记为IDLE，这样双方状态就同步了。不同步会有很多意外情况。
例如MS认为自己不在IDLE，就会不发附着消息而直接发上行数据报文了。当MS关机了，网络侧已将你标记为IDLE，MS关机后肯定也是IDLE，所以网络侧也没有必要给你发detach accept了。
2.发现去附着的第一步里也会有鉴权，但是流程里为什么没提嘞？
  答：不需要啊。规范里提高除非是P-TMSI签名不匹配，才需要鉴权。就像我们的日常生活中一样。很多高级写字楼，进去要登记，确认你的身份，但你走可以随便走一样。例如还有演唱会、电影都是，来验票，走随便走。中途离场都可以。因为进来你对我有威胁或要享用我的服务，所以要确认你的身份，但你走的话，对我没有任何影响。我巴不得你快点走，这样我可以更安全或者空出一些资源来。
3.看前面版主的视频，国内未开放到VLR的Gs接口，对于MS要保持IMSI附着，而去除GPRS附着这种情况下，SGSN是怎么发送一个GPRS 去附着指示（IMSI)消息给VLR。这是怎么实现的。
  答：对于国内的现网，确实没有开放Gs接口，因此国内的网络是不支持联合附着的。联合去附着也不支持。
4.在网络侧去附着的流程中说到在步骤一完成的任何时候。MS发起Detch accpet给SGSN,意思是不是去附着和删除PDP context是两个相对独立的过程。
  答：对。可以这样理解。也就是说第4步可以在第2步之前。只不过为了方便我们理解和做图方便，分了1/2/3/4步。但实际上，你在抓包的时候，你有可能会抓到，从MS过来的detach accept消息在SGSN发给GGSN的去激活消息之前，但一般来说没有这么快，因为一般来说，在SGSN上，1和2步的消息有可能是同时发。但如果真出现刚才说的情况，也不用惊讶，这是规范允许的。因为MS在网络侧发起的去附着的过程中，并不关心网络侧何时删除我的PDP上下文。因为detach是一个断网的信号，我收到后就应立即断网，再讨论PDP上下文就没有意义了。

  最后，还得再感谢你帮我做免费的翻译校验啊！谢谢啊！欢迎欢迎！已更正！

tobino1

回复 爱卫生 的帖子

实际中看到好多 网络发起的detach，cause为MS reachable timer expiry 这个说明什么？

爱卫生

回复 tobino1 的帖子

  cause code是多少呢？看了下24008，没找到这个cause值啊。或者有没有抓的包？类似的只有CC10=Implicitly detached。可以参考这一篇http://www.gprshome.com/portal.php?mod=view&aid=134。

tobino1

回复 爱卫生 的帖子

哦 我找到相关描述：
In the case of a periodic GPRS Routing Area Update, the procedure is controlled in the MS by the Periodic RAU T3312 timer. The network supervises the procedure with the Mobile Reachable timer which is longer than the RA update timer. When the Mobile Reachable timer expires, the network stops sending paging messages to the MS and starts a Standby timer. After the timer expires, the network performs an implicit Detach. If a Routing Area Update Request message is recieved during the Standby timer, the Mobile Reachable timer is started and the Standby timer is reset. In GSM, the Mobile Reachable timer is reset and started with its initial value when the READY timer stops or expires. The Mobile Reachable timer is stopped and set to its initial value for the next time the READY timer is started. If the READY timer value is set to zero after a READY timer negotiation, the Mobile Reachable timer is reset and started with its initial value. If the initial READY timer value is zero, the Mobile Reachable timer is reset and started with its initial value when the Routing Area Update Request message is received.

cause process 为Implicitly detached
cause code为0x33

tobino1

回复 爱卫生 的帖子

哦 我找到了：
In the case of a periodic GPRS Routing Area Update, the procedure is controlled in the MS by the Periodic RAU T3312 timer. The network supervises the procedure with the Mobile Reachable timer which is longer than the RA update timer. When the Mobile Reachable timer expires, the network stops sending paging messages to the MS and starts a Standby timer. After the timer expires, the network performs an implicit Detach. If a Routing Area Update Request message is recieved during the Standby timer, the Mobile Reachable timer is started and the Standby timer is reset. In GSM, the Mobile Reachable timer is reset and started with its initial value when the READY timer stops or expires. The Mobile Reachable timer is stopped and set to its initial value for the next time the READY timer is started. If the READY timer value is set to zero after a READY timer negotiation, the Mobile Reachable timer is reset and started with its initial value. If the initial READY timer value is zero, the Mobile Reachable timer is reset and started with its initial value when the Routing Area Update Request message is received.

cause process 为Implicitly detached
cause code为0x33

爱卫生

回复 tobino1 的帖子

  谢谢，不过能再帮忙找下这个code 0x33的出处吗？我又看了下，还是没有在24008里发现这个caude code值啊。全在这了，如下，算下来0x33=十进制49，没找到对应的49有值啊。
8 7 6 5 4 3 2 1  
0 0 0 0 0 0 1 0  IMSI unknown in HLR
0 0 0 0 0 0 1 1  Illegal MS
0 0 0 0 0 1 0 1  IMEI not accepted
0 0 0 0 0 1 1 0  Illegal ME
0 0 0 0 0 1 1 1  GPRS services not allowed
0 0 0 0 1 0 0 0  GPRS services and non-GPRS services not allowed
0 0 0 0 1 0 0 1  MS identity cannot be derived by the network
0 0 0 0 1 0 1 0  Implicitly detached
0 0 0 0 1 0 1 1  PLMN not allowed
0 0 0 0 1 1 0 0  Location Area not allowed
0 0 0 0 1 1 0 1  Roaming not allowed in this location area
0 0 0 0 1 1 1 0  GPRS services not allowed in this PLMN
0 0 0 0 1 1 1 1  No Suitable Cells In Location Area
0 0 0 1 0 0 0 0  MSC temporarily not reachable
0 0 0 1 0 0 0 1  Network failure
0 0 0 1 0 1 0 0  MAC failure
0 0 0 1 0 1 0 1  Synch failure
0 0 0 1 0 1 1 0  Congestion
0 0 0 1 0 1 1 1  GSM authentication unacceptable
0 0 0 1 1 0 0 1  Not authorized for this CSG
0 0 1 0 1 0 0 0  No PDP context activated
0 0 1 1 0 0 0 0  }
to   } retry upon entry into a new cell
0 0 1 1 1 1 1 1  }
0 1 0 1 1 1 1 1  Semantically incorrect message
0 1 1 0 0 0 0 0  Invalid mandatory information
0 1 1 0 0 0 0 1  Message type non-existent or not implemented
0 1 1 0 0 0 1 0  Message type not compatible with the protocol state
0 1 1 0 0 0 1 1  Information element non-existent or not implemented
0 1 1 0 0 1 0 0  Conditional IE error
0 1 1 0 0 1 0 1  Message not compatible with the protocol state
0 1 1 0 1 1 1 1  Protocol error, unspecified

karcsija

回复 爱卫生 的帖子

貌似0x33对应的十进制应该是49，对应110011，但是也没找到，晕

karcsija

回复 tobino1 的帖子

请问你在哪个规范里找到这些的啊？我在23060-820中没找到。如能回复，不胜感激，呵呵

iscehsj

我稍微纠正一下，
0x33对应的十进制应该是51；另外，在24.008中规定，cause#10 为Implicitly detached，其对应的十六进制应该为0x0a

8 7 6 5 4 3 2 1  
0 0 0 0 0 0 1 0  IMSI unknown in HLR
0 0 0 0 0 0 1 1  Illegal MS
0 0 0 0 0 1 0 1  IMEI not accepted
0 0 0 0 0 1 1 0  Illegal ME
0 0 0 0 0 1 1 1  GPRS services not allowed
0 0 0 0 1 0 0 0  GPRS services and non-GPRS services not allowed
0 0 0 0 1 0 0 1  MS identity cannot be derived by the network
0 0 0 0 1 0 1 0  Implicitly detached
0 0 0 0 1 0 1 1  PLMN not allowed
0 0 0 0 1 1 0 0  Location Area not allowed
0 0 0 0 1 1 0 1  Roaming not allowed in this location area
0 0 0 0 1 1 1 0  GPRS services not allowed in this PLMN
0 0 0 0 1 1 1 1  No Suitable Cells In Location Area

Cause value = 10 Implicitly detached
This cause is sent to theMS either if the network has implicitly detached the MS, e.g. some while afterthe Mobile reachable timer has expired, or if the GMM context data related tothe subscription dose not exist in the SGSN e.g. because of a SGSN restart.

skyever

学习一下。。。

ccc123

解释很详细，学习了。谢谢。。。。

zxtcinderella

讲解的很好，感谢！