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資源是如何釋放的。