12-LTE EMM - EMM Procedure - 2. Detach(中文翻译)

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资源是如何释放的。