# 蔡瀚興-讀書會-21/08/04
## <font color="ff0000">Introduction</font>
本文探討是Initial attach，會根據不同的情況而有不同。它可以是
1. **EMM案例1**中的初始附著流程，在下文中解釋
2. **EMM案例11**（在另一個城市的初始附著），

也可以是其他類型，取決於用戶(UE)是否保留了他最後一次附著到網絡中使用的信息

## <font color="ff0000">Cases of Initial Attach</font>
當UE最初附著到網絡時，MME會根據這種附著的類型啟動不同的流程。

下面流程是MME收到 **Attach Request message** 後，傳送 **Attach Accept message** 前。
- **UE ID acquisition**
- **Authentication**
- **NAS security setup**
- **Location update**
- **EPS session establishment**

(Note)
不同Type有不同流程，但 **UE ID acquisition** 和 **EPS session establishment**在所有Type中都必存在

本文中，我們將使用以下標準來區分不同類型的初始附著流程
- UE使用何種類型的UE ID來進行初始附著 (IMSI or Old GUTI)
- UE是連接到先前的MME與否
- 網絡中是否還保留有效的UE context

- **Unknown UE:** 網路中無UE Last context
- **Known UE:** 網路中有UE Last context
### <font color="0000ff">Unknown UE</font>
#### **Attach Case 1: When a UE is attaching using an IMSI**
(此情況是UE及MME都沒有Last Context)
1. UE向MME發送附著請求報文，使用其IMSI作為UE ID。MME從該報文中獲得IMSI。

2. MME假設它不認識UE（因為發送了IMSI），啟動鑑權和NAS安全設置流程。

3. MME向HSS發送位置更新消息，告知HSS該UE已在其上註冊，並從HSS下載用戶的訂閱信息。

#### **Attach Case 2**
When a UE is attaching to the MME that it has attached to last time (New MME = Old MME), but the MME doesn’t have the valid Last UE Context of the UE
1. UE使用old GUTI給新的MME發送attach request消息 (Intergrity保護的)

3. 因為GUTI包含GUMMEI，新的MME就可以從old GUTI中知道這個舊的GUTI是從哪裡分配的。 新的MME查找上次UE上下文，但是沒有找到任何資訊
4. MME給UE發送identity request消息來請求IMSI。
5. UE給MME發送identity response消息提供請求的IMSI。
6. 現在，MME通過使用獲取的IMSI按照attach case-1的流程執行鑒權和NAS安全建立過程，接著發送UE位置更新消息給HSS
#### **Attach Case 3**
當UE附著到一個之前從來沒有附著過的MME上，且MME沒有有效的Last Context

1. UE使用old GUTI作為UE ID給新的MME發送attach request消息 (Intergrity保護的)

2. 當新的MME接收到這個消息，他從old GUTI知道來自哪裡。
3. 新MME向舊MME發送identification request(把舊的GUTI和attach request消息轉發給舊的MME) 通過這個消息，新的MME請求和舊的GUTI相關的上次UE上下文。
4. 一旦接收到這個消息，舊MME查找Last UE Context，但是沒有找到任何資訊。
5. 舊MME給新MME發送identification response消息，通知沒有找到UE上下文。
6. 從這兒開始開始和Attach Case 2相同，執行Attach Case 2的3/4/5

### <font color="0000ff">Known UE</font>
#### **Attach Case 4**
當UE附著到上次附著過的MME上，並且這個MME中包含valid Last UE Context

1. UE使用old GUTI作為自己的UE ID給new MME發送attach request消息 (Intergrity保護的)

2. 這個new MME從old GUTI中知道誰分配這個ID。 然後它查找old GUTI，找到 valid UE context（IMSI、UE-AMBR）
3. MME對attach request消息執行完整性檢查
i）如失敗，MME必須使用IMSI來鑒權使用者，並執行使用者的NAS安全建立過程。
ii）如通過，MME會略過鑒權和NAS安全建立過程。
#### **Attach Case 5**
當UE附著到之前~~沒有附著過~~的MME上，並且old MME具valid Last UE Context

1. UE使用old GUTI作為自己的UE ID給new MME發送attach request消息 (Intergrity保護的)

2. new MME從接收到的old GUTI上知道是誰分配的（old MME）。
3. new MME向old MME發送identification request（old GUTI，完整的attach request消息）。通過這樣，new MME請求和old GUTI相關聯的Last UE Context
4. 一旦收到這消息，old MME查找，找到和這個UE相關聯的IMSI和UE-AMBR。
5. old MME對attach request消息執行完整性檢查
6. old MME把完整性檢查的結果通過identification response消息發給new MME
i）如果完整性檢查失敗，情況和Attach Case 3相同。
ii）如果完整性檢查通過，類似Case 4 (不同於new MME需要和HSS更新UE的位置資訊)。

## <font color="ff0000">Simplified Call Flow in Each Case</font>
1. **UE ID Acquisition**
UE ID可以是IMSI和old GUTI

2. **Authentication**
如果MME通過attach request消息獲取IMSI或者old GUTI作為UE ID，但這消息的完整性檢查敗，網路檢查是否需執行EPS AKA過程來允許UE附著。

3. **NAS Security Setup**
一旦完成，產生了在UE和MME之間用於NAS消息安全傳輸的NAS安全秘鑰。

4. **Location Update**
MME只有當，以下情況才會執行位置更新
i ） UE使用IMSI作為UE ID時
ii ）MME沒有有效的上次UE上下文資訊
iii）MME沒有關於使用者的任何簽約資訊
iv）UE上次從其他MME上去附著

5. **EPS Session Establishment**
EPS session 和 default EPS bearer 建立