I.導語

。用户在經歷了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資源是如何釋放的。