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
- UE关机
- UE中的USIM卡被移走
- UE不使用EPS网络服务
2）Detach Case 2：MME-initiated Detach
MME发起的去附着可以进一步分为显式去附着和隐式去附着。在显式去附着的情况下，MME事先通过发送Detach Request消息通知UE去附着，并通知UE在去附着后是否要重新连接网络。但在隐式去附着的情况下，由于UE没有能力与MME进行通信，MME在没有通知的情况下（即没有发送Detach Request报文）就启动去附着程序。
i) 显式去附着：
- 运营人员维护运营的原因
- 重鉴权失败
- lMME无法提供资源
ii) 隐式去附着：
- 因为无线信号质量很差而无法与UE通信
3）Detach Case 3：HSS-initiated Detach
- HSS中用户数据变更，因此MME中保存的用户数据也需要变更
- 运营人员设置某些非法用户无法访问网络
接下来的三章(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 <- PCRF] Acknowledging EPS Session Termination
PCRF通过发送CCA (CC-Answer)给PGW响应：用户的PCC规则已经被删除了。
11) [S-GW <- P-GW] Responding to EPS Session Release Request
当PGW从PCRF接收到CCA消息后，向SGW发送Delete Session Response消息作为步骤6)的响应。
12) [P-GW] Deleting EPS Bearer Context
PGW在发送Delete Session Response消息后，删除用户的承载上下文参数。
13) [MME <- S-GW] Responding to EPS Session Release Request
SGW从PGW接收到Delete Session Response消息后，向MME发送Delete Session Response消息作为步骤4)的响应。
14) [UE <- MME] Acknowledging Detach
一旦接收到Delete Session Response消息，MME就认为用户资源的释放已经被PCRF认证了。因此，MME向UE发送Detach Accept消息作为步骤1)的响应。只有在非关机引起的去附着流程中才会回复Detach Accept消息(即Detach Request中的Switch Off=0)。如果是关机引起的去附着，MME不会发送Detach Accept消息。
(2) S1 Signaling Connection Release
在向UE发送Detach Accept消息后，MME和eNB释放所有用户相关的剩余资源(S1信令连接、RRC连接和eNB中的UE上下文)。
15) [eNB <- MME] Acknowledging S1 Signaling Connection Release
MME向eNB发送UE Context Release Command消息，来释放S1信令连接。
16) [UE <- eNB] RRC Connection Release
eNB向UE发送RRC Connection Release消息来释放RRC连接。
17) [eNB] Deleting UE Context
eNB删除所有与UE相关的信息。
18) [eNB -> MME] RRC Connection Release Complete
最终，eNB向MME发送UE Context Release Complete消息作为步骤15)的响应。
IV.MME触发的去附着
图3显示了MME发起的显式去附着是如何执行的。MME向UE发送一个Detach Request消息。当先前分配给UE的EPS会话的资源被释放后，该过程结束。
❶ Detach Triggering by MME
以下是MME检测到去附着触发后，在执行EPS会话终止程序之前，需要执行的程序。如果用户此时处于Idle状态，MME需要执行寻呼，建立S1信令连接。如果是隐式去附着，MME不会发起Paging消息和Detach Request消息。
1) [UE <- MME] Detach Request
作为显示去附着，MME向UE发送Detach Request消息。消息参数如下：
| Detach Request (Detach Type(Re-attach required or not), Cause) Ÿ Detach Type: indicates whether UE is required to be re-attached or not after detach ◦001: Re-attach required ◦010: Re-attach not required Ÿ Cause: indicates why detach is caused
|
如果是隐式去附着，则MME不会向UE发送Detach Request消息。
2) [MME] Handling Security Context
MME向UE发送Detach Request消息后，MME会保存当前NAS安全上下文。下次UE再附着时，MME可以使用保存的安全上下文以便跳过鉴权流程和NAS安全设置流程。
3) [UE] Noticing Detach Intent and Handling Security and Bearer Contexts
UE在接收到MME发送的Detach Request消息后，知道MME即将进行去附着。UE检查去附着的类型来确定之后是否需要再附着。然后保存当前NAS安全上下文，删除承载上下文。
❷ EPS Session Termination
一旦MME在去附着触发时存储了NAS安全上下文，它就会请求PGW终止用户的EPS会话。该请求触发PCEF（P-GW）发起EPS终止，释放分配给用户的所有网络/无线资源，如下文所述：
(1) EPS Bearer Release and PCC Rule Removal
通过步骤4)~13)，MME请求用户的EPS会话终止。如III章的步骤4)~13),PCRF根据请求删除PCC规则，释放S5承载资源。如果去附着类型是要求再附着，则MME在步骤5)中保存UE-AMBR参数，以便UE再附着时可以更快建立EPS承载。
14) [UE -> MME] Acknowledging Detach
如步骤1)，在接收到MME发送的Detach Request消息并保存了NAS安全上下文并删除了EPS承载上下文后，UE发送Detach Accept消息作为步骤1)的响应。
如果是隐式去附着，则跳过步骤1),14)和16)。
(2) S1 Signaling Connection Release
在这个阶段，MME在接收到UE发送的Detach Accept消息和SGW发送的Delete Session Response消息后删除所有剩余的资源(S1 signaling connection, RRC connection and UE context left in the eNB)。这个阶段的步骤同第III章的步骤15)~18)，除非去附着类型是“再附着”，UE在RRC连接释放后再发起再附着。
V.HSS触发的去附着
图4展示了HSS触发去附着的流程：
❶ Detach Triggering by HSS
如果取消签约，HSS就会触发去附着，HSS立刻尝试删除用户MM上下文和承载。
1) [MME <- HSS] Detach Request
HSS和MME通过S6a接口的Diameter协议通信。HSS通过向MME发送带有以下参数的Cancel Location Request (CLR)消息来触发去附着：
| Cancel Location Request (IMSI, Cancellation Type) Ÿ IMSI: ID of the user to be detached (i.e. the user whose MM Context and EPS bearer are to be deleted) Ÿ Cancellation Type1 = Subscription Withdrawn: indicates the reason for detach
|
❷ EPS Session Termination
MME从HSS接收到Cancel Location Request (CLR)消息后，会释放之前分配给用户的所有资源。这里的流程步骤同第III章中MME-initiated detach(图3)，除了步骤2)的MME请求动作。MME需要向HSS发送Cancel Location Answer消息作为步骤1)的响应。
2) [MME -> HSS] Responding to Detach Request
MME接收到UE的Detach Accept消息和SGW的Delete Session Response消息后，向HSS发送Cancel Location Answer消息作为步骤1)的响应。
VI.EPS实体信息：去附着前/后
本章解释了EPS实体中的信息在执行 "EMM案例2：去附着 "程序后如何改变EPS实体中的信息。每个实体中的所有信息都分为UE ID、UE位置、安全性和EPS会话/earer信息（详见[2]）。
6.1 去附着前
根据EMM案例2的情况，用户在去附着或去附着网络之前，保持在ECM/RRC-Connected状态。因此，在去附着之前，所有的EPS实体在EMM情况1中的初始附着后都有相同的信息。图5列出了每个EPS实体在去附着前存储的信息。
6.2 去附着后
分离后，可用于用户下次快速安全连接的信息被存储在UE和MME中。其他与用户相关的所有上下文，如NAS安全上下文、MME分配的GUTI和TAI信息等都被删除。图6列出了在 "EMM情况2：删除 "程序后，每个EPS实体中存储的信息元素。图6中，删除后要删除的信息元素用灰色表示，保留的信息元素用黑色表示，下一次附着中使用的信息元素用蓝色表示。
存储保留的用于下一次附着的参数信息:
UE:
- UE ID: GUTI---MME在初始附着/TAU时分配
- UE Location: 去附着前UE访问的最后一个TA
- Security: NAS安全上下文信息
MME:
- UE ID: IMSI，GUTI
- UE Location: 去附着前UE访问的最后一个TA，TAI list可能也会保留.
- Security: NAS安全上下文信息
- EPS Session/Bearer: UE注册位置信息时从HSS获得的签约数据、承载创建时MME分配的UE-AMBR、可能还有APN-AMBR值。
HSS:
- E Location: 去附着前UE访问的最后一个TA
VII.结语
我们了解了用户在连接到LTE网络时，是如何从LTE网络中去附着/被去附着）。我们根据检测到去附着触发的实体，对去附着的情况进行了分类，并研究了每个情况下的去附着流程。我们还检查了 detach 之后，在 UE、MME 和 HSS 中存储了哪些信息元素，以备下次 attach时使用。后面的文档将讨论当用户在初始附着后，在一定时间内保持不活动时，S1资源是如何释放的。