I.导语

 本文讨论了我们之前的文档《EMM场景中的11个EMM案例》中定义的EMM案例2的去附着流程。在这个阶段，用户从所连接的网络中去附着/被去附着。用户在经历了EMM案例1中的初始附着流程后，在EMM-Registered状态下使用LTE业务。用户在使用服务后，在ECM/RRC-Connected或ECM/RRC-Idle状态下，用户可能会被网络或UE去附着。在任何情况下，一旦去附着流程完成后，用户的EPS承载被释放，其状态被清除。

本文是关于LTE网络中的detach流程的介绍，具体内容如下。第II章根据触发去附着的位置确定了去附着类型。第III章到第V章描述了每种类型的detach所需的detach流程。在第VI章中，我们将研究EMM案例2中的detach程序后，每个EPS实体中的哪些类型的信息被改变。

II.去附着场景

用户通过初始附着流程创建EPS会话和默认EPS承载后，使用LTE服务。在某些情况下，用户在使用完服务后可能会去附着网络。在其他情况下，用户在使用服务的同时，可能会被网络去附着，无法再与网络保持连接。

一旦用户从网络去附着，该用户所有的EPS会话和承载建立的相关资源就会被释放。这次释放会删除用户的MM上下文和所有EPS实体中的承载信息。这个时候，EMM状态从Registered转到De-Registered。如果用户正常去附着，那么该用户相关的GUTI、NAS层面的User ID还有安全上下文都会在UE和MME中继续保留，以便下次继续使用它们连接网络。

去附着可以由UE或者网络侧发起。网络侧发起的去附着一般是由MME或者HSS引起。根据去附着的发起实体，去附着可以被分为以下几种场景：

1）Detach Case 1：UE-initiated Detach

2）Detach Case 2：MME-initiated Detach

MME发起的去附着可以进一步分为显式去附着和隐式去附着。在显式去附着的情况下，MME事先通过发送Detach Request消息通知UE去附着，并通知UE在去附着后是否要重新连接网络。但在隐式去附着的情况下，由于UE没有能力与MME进行通信，MME在没有通知的情况下（即没有发送Detach Request报文）就启动去附着程序。

i) 显式去附着：

ii) 隐式去附着：

3）Detach Case 3：HSS-initiated Detach

接下来的三章(III、IV、V)描述了上述三种去附着情况下需要的不同去附着流程。在这三种情况下，均假设用户在去附着前处于EMM-Registered、ECM-Connected和RRC-Connected状态，仅通过默认承载提供服务。图1说明了去附着前和去附着后，UE和MME在用户/控制面上处于什么状态，建立了哪些连接。在去附着前，默认承载及其相关的控制链路(GTPC)建立，用户处于EMM-Registered、ECM-Connected和RRC-Connected状态。然后，去附着后，默认承载和所有的信令连接被释放，用户进入EMM-Deregistered、ECM-Idle和RRC-Idle状态。

III.UE触发的去附着

图2显示了用户发起的detach是如何执行的。这种类型的去附着过程在UE侧触发去附着时开始的。因此UE发送一个Detach Request报文。当UE收到来自MME的Detach Accept报文时，该流程就结束了，除非用户关闭UE。

❶ Detach Triggering by UE

当UE要去附着时，UE和MME两个实体将开始以下流程：

1) [UE -> MME] Detach Request

UE向MME发送Detach Request报文请求去附着。Detach Request报文参数的解释根据报文的发送方向不同而不同。如果是由UE向MME发送，则报文参数如下。

Detach Request (GUTI, KSIASME, Detach Type(Switch Off))

Ÿ GUTI: User ID assigned by MME at the time of network attach

Ÿ KSIASME: KSI value that is being used by UE

Ÿ Detach Type: Indicates a detach type

◦Switch Off: Indicates whether the case is normal detach (0) or switch off (1)

◦Type of Detach: EPS detach

2) [UE] Handling Security and Bearer Contexts

在发送Detach Request报文后，UE存储其当前的NAS安全上下文、GUTI和TA信息，然后删除其EPS承载上下文。

3) [MME] Noticing Detach Intent and Handling Security Context

在收到UE发出的Detach Request消息后，MME会意识到UE请求去附着。它存储用户当前的NAS安全上下文，并检查去附着类型（是正常去附着，还是关闭设备）。通过这样做，MME会发现它是否需要发送一个Detach Accept消息。

❷ EPS Session Termination

一旦MME感知到UE发起去附着并存储了用户当前的NAS安全上下文，它就请求终止已激活的EPS会话。该请求触发PCEF（P-GW）启动的EPS终止，释放分配给用户的所有网络/无线资源，如下文所述。

(1) EPS Bearer Release and PCC Rule Removal

4) [MME -> S-GW] Requesting EPS Session Release

MME和S-GW通过S11接口使用GTP协议（GTP-C）进行通信。MME通过向S-GW发送Delete Session Request消息，删除用户的EPS会话和默认承载。这时，默认承载ID和UE位置信息（ECGI、TAI）被传送。

5) [MME] Deleting EPS Bearer Context

MME在发送Delete Session Request消息后，删除用户承载上下文。

6) [S-GW -> P-GW] Requesting EPS Session Release

SGW和PGW通过S5接口GTP协议通信。SGW转发MME发起的Delete Session Request消息给PGW。

7) [S-GW] Deleting EPS Bearer Context

SGW在发送Delete Session Request消息后，删除用户承载上下文。

8) [P-GW -> PCRF] Notifying of EPS Session Termination

PGW和PCRF通过Gx口使用Diameter协议通信。PGW向PCRF发送一个CCR (CC-Request)消息，通知用户已经完成网络使用。从而触发EPS会话终结流程。

9) [PCRF] Deleting RCC Rule

PCRF从PGW接收到CCR消息后就立刻删除了用户的PCC规则。

10) [P-GW