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 的帖子

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

爱卫生

回复 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 的帖子

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

爱卫生

回复 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