2.2 WiMAX認證架構
2.2.6 Key 產生過程
Figure2-8 Key hierarchy and derivations of 802.16e
SK=PRF(SecurityParameters.master_secret, "ttls keying material",
m) ([6]) 公式 1
2.3.1 MS/BS initiated HO
MS 在一開始(initial network entry)與 serving BS 認證成功之後，若發現Receive
re2-8描述key的產生及演進過程。經過上述EAP authentication認證(此處以 single EAP為例)成功後，透過pseudo random function產生出一把 512-bit的MSK (公 式 1)；擷取(truncate)MSK的 160bits為PMK，再由PMK帶入key distribution function (公 式 2)產生AK。獲得AK之後根據MAC模式(mode)參照公式 3 或公式 4 產生一把KEK。
S
Stteepp 11
StSteepp 22
StSteepp 33
資料來源：[2]
M
SecurityParameters.client_random + SecurityParameters.server_rando
AK=Dot16KDF(PMK, SS MAC Address | BSID | “AK＂, 160) 公式 2
KEK=Dot16KDF(AK, SS MAC Address | BSID | “CMAC_KEYS+KEK”, 384) 公式 3
KEK=Dot16KDF(AK, SS MAC Address | BSID | “HMAC_KEYS+KEK”, 448) 公式 4
2.3 HO procedure
Signal Strength Indicator(RSSI)、Carrier-to-Interference-and-Noise Ratio(CINR)過低或 Bit ate (PER)過高或其他因素超過原先制定的門檻 (pre-provision)，則可由 MS 或 BS 觸發換手動作(handover)程序。
參照 ，在 程序之前 首先會去聽
neighbor B 溝通，以取得更精確的資訊。
收集到 週遭
，則
)，則 BS 傳送 MOB_BSHO-REQ
Download Channel Descriptor (DCD) message 知會 MS，由 MS 傳送 MOB_MSHO-REQ 程序。
當 選 擇 要 與 哪 幾 台 neighbor BS 會 將 候 選 名 單 填 入
Q，透過 訊息給 ，由
負責與後端 溝通。待 收到 發送的
，分析 封包裡的下列欄位可以瞭解周遭 BS 的目前狀態，包括：
Neighbor BSID：radio resource controller (RRC) 的 有哪些；
Error Rate (BER)、Packet Error R
Figure2-9 MS或BS決定啟動HO ，MS serving BS定期發 送的Neighbor Advertisement (MOB_NBR-ADV)訊息。透過MOB_NBR-ADV 可以知道：
1) Operator ID NAP
Neighbor BSID：serving BS BS(neighbor BS)；
3) Mobility features supported：哪些 neighbor BS 提供 handover 4) HO Process Optimization
MS 可以利用 MOB_SCN-REQ 向 serving
做進一步的訊息交換。MS 在接收到 serving BS 回傳的 Scanning Interval Allocation Response(MOB_SCN-RSP)message 後，可以得知目前 neighbor BS 的 scanning type scan duration、interleaving interval 等相關資訊，知道如何(how) (when)
S
MS serving BS neighbor BS 的相關資訊後，可以了解 neighbor BS 的目前狀態。因此，若由 MS 觸發 HO (MS initiated) MS 傳送 MOB_MSHO-REQ
訊息給 BS。若由 BS 觸發 HO (BS initiated 給 MS。
甚至 BS 可以透過
來啟動 HO
MS 聯 絡 時 ， MS
MOB_MSHO-RE MOB_MSHO-REQ message serving BS serving BS (backhaul) MS serving BS MOB_BSHO-RSP message (parsing)
1) 建議HO BS
2) Service level prediction：MS可以從BS獲得哪些服務；
3) HO process optimization：neighbor BS提供哪些HO最佳化服務。
MS保有最後的決定權，在MS決定哪一台BS為target BS後透過HO Indication (M
BS et BS連接。
rangi
之間
OB_HO-IND) message，告知serving BS最終的決定，由serving BS負責通知target
，MS也透過Ranging Request (RNG-REQ) message開始嘗試與targ
MS handover 時發出 RNG-REQ 給 target BS，若不需重新做競爭(initial ng)，且 MS 欲連接的 target BS 需做認證授權服務，則 MS 發送 RNG-REQ 會 帶有 HMAC 或 CMAC，此時 target BS 需要有原先 serving BS 的 AK 來驗證 MS 的身 分，若身分驗證成功後 MS 與 target BS 得需要再重新取得一把新的 AK，作為兩者
的共同金鑰。
Target BS
MS Serving BS
MOB_MSHO-REQ
MOB_BSHO-RSP/MOB_BSHO-REQ
MOB_HO-IND MOB_NBR-ADV
MOB_SCN-REQ
RNG-REQ (HMAC/CMAC) MOB_SCN-RSP
HO_ASSOC_REQ HO_ASSOC_REQ
HO Request HO Response
HO Confirm
Figure2-9 802.16e HO procedure
資料來源：[4]
在介紹完前端(MS與BS)的認證授權過程後，接下來探討後端(backhaul)網路對於認 證授權的處理方式與運作流程。[4]描述後端在處理HO過程時，有三種考慮的環 境，接下來會針對不同的環境介紹封包的傳送流程。
2.3.2 Intra-ASN HO
[4] MS BS HO backhaul network Figure2-10 HO procedure in Intra-ASN model ASN
中描述當 或 啟動 時， 端的認證流程如何運作。如
所示，在 的環境下，MS在一開始
成功後，MS與BS1 會共用一把AK1，而當時為BS1 處理
EAP認證訊息並產生AK r。當MS移動到BS2
的覆蓋範圍而欲與BS2 ，BS1 同時傳送HO Req 息 S2，並
提供M 關 。BS2 收 Request之後，若MS傳送帶有HMAC/CMAC的 RNG-REQ給BS2 時，為了能夠解析確認HMAC/CMAC的正確性，BS2 會送Context Request訊息給anchor authenticator，要求anchor authenticator提供MS當時在BS1 的AK Context (表格 A-5)，anchor authenticator會將有關於MS安全性的資料(AK Context)，
透過Context Report (表格 A-3)訊息回傳給BS2。當MS handover 到target BS後，兩者 之間因需要一把新的AK2，為了加快HO的速度，[2]明白指示在NAP的環境底下不 做re-authentication，而是利用anchor authenticator原先與MS認證成功所產生的 PMK，為targ 產生一把新的AK2。因此當target BS發送AK Request訊息給anchor authenticator，要求提供一把新的AK2 時， anchor authenticator會由現有的PMK運算 產生新的AK2 及相關安全性資料後，儲存至AK Context，透過AK Transfer封裝後回 傳給target BS。值得注意的是，若ASN的涵蓋範圍很大，當MS持續的往前行而不斷 做HO時(如Figure2-10中MS移動到BS3)，隨著BS與anchor authenticator距離的越拉越 長，因anchor authenticator不會更換，造成兩者之間訊息傳送的延遲時間也隨距離變 長，這對即時應用程式來說會有延遲反應。本論文稍後會針對這點提出一套解決 方法。
(network entry)與BS1 認證
1 的authenticator稱為anchor authenticato
聯繫時 uest(表格 A-1)訊 給B
S的相 資訊 到HO
需要
et BS再
MSS / AK3 / AKID / Life Time/ SN / EIK
ASN Reference Modal
Anchor Authenticator
Context Request/Context Report HO Request
AK Request/AK Transfer
MSS / AK2 / AKID / Life Time/ SN / EIK MSS / AK1 / AKID / Life Time/ SN / EIK
Context Request/Context Report AK Request/AK Transfer AK1
R8
R8
R6
R6
R4 R4 AK1
AK2
AK2 AK3
HO Request
R6 BS1
BS2
BS3
Figure2-10 HO procedure in Intra-ASN model
2.3.3 Inter-ASN HO
若MS在HO時所連接的target BS與serving BS跨越不同的ASN (Inter-ASN)，但 還是屬於相同的NAP (Intra-NAP)時，如Figure2-11所示，MS在BS1 的覆蓋範圍移動 至BS2 的覆蓋範圍時，與Intra-ASN不同的是，serving BS (BS1)無法直接傳送HO Request給target BS (BS2)，而是得由BS1 經由ASN-GW1、ASN-GW2 最後再傳至target BS (BS2)。另外，anchor authenticator並不因跨越不同的ASN而改變，因此還是由原 先的authenticator為anchor authenticator。另外，target BS為取得MS原先在BS1 的AK Context ， 發 出 Context Request 訊 息 給 anchor authenticator ， 其 行 經 路 線 為 BS2ÆASN-GW2ÆASN-GW1 。 anchor authenticator 在 收 到 訊 息 後 將 MS 舊 有 的 AK Context資訊透過Context Report訊息，經由ASN-GW1ÆASN-GW2 回傳到BS2。同樣 的，為取得屬於MS與target BS之間的一把新的且共用的AK，target BS會發送AK Request訊息給anchor authenticator，其行經路線為BS2ÆASN-GW2ÆASN-GW1。待 anchor authenticator計算出AK後填入AK Context欄位，借由AK Transfer封裝後經 ASN-GW1ÆASN-GW2 最後傳送給BS2。
Mobility Domain (NAP)
ASN ASN HO Request
ASN-GW2 ASN-GW1
BS2
AK Request/AK Transfer Context Request/Context Report
R6
R6 BS1
Anchor Authenticator
R4
Figure2-11 HO procedure in Inter-ASN model
2.3.4 Inter-NAP HO
如Figure2-12，若MS在HO時所連接的target BS與serving BS是跨越不同的NAP (mobility domain)，與前面兩者不同的是，不同的NAP為不同的operator，兩者之間 可能沒有信任關係(depend on license agreement)，而且[4]僅針對mobility domain下 的HO提出說明。另外，在不同的NAP之間的reference point (RP4)沒有安全性的保 障。因此當MS由BS1 移動至BS2 後，無法由之前的anchor authenticator (此處為 ASN-GW1)為BS2 產生一把AK。於是在BS1 傳送HO Request給BS2 時 (經由 BS1ÆASN-GW1ÆASN-GW2ÆBS2)，BS2 經判斷為不同的NAPID，決定重新做full authentication。
ASN ASN
Mobility Domain (NAP) Mobility Domain (NAP)
Mobility Domain (NAP) Mobility Domain (NAP)
ASNASN
HO Request HO Request
ASN ASN--GW1GW1
ASN ASN--GW2GW2 BS1BS1
BS2BS2
Authenticator Authenticator
Authenticator Authenticator R6
R6
R4
Figure2-12 HO procedure in Inter-NAP model
2.3.5 AK在HO時產生的時間點
前面的章節介紹完MS端的認證處理方式以及backhaul端對於認證的運作處理 模式後，接下來要探討的是觸發AK產生的時間點，執行AK Assignment流程。NWG 裡[4]提出 3 種觸發AK Assignment的時間點(Figure 2-13)：
1) MS發送MOB_MSHO-REQ給serving BS：為使得MS在handover能達到無接 縫(seamless)的效果，讓MS移動到target BS時不需因backhaul端的一連串處理過程 過於冗長。因此[4]提出hackhaul端允許AK的產生流程越早進行越好。所以當MS發 出MOB_MSHO-REQ時，在MS尚未決定target BS(只有建議名單時)之前，即要求各 個候選的BS (candidate target BSs)開始產生新的AK。因此各個候選的BS會向anchor aut enti ator提出要AK的需求(request)，這加重了anchor authenticator的負擔，因為 anchor authenticator幫助可能不是最終target BS的候選者計算AK (畢竟只有target BS 的AK有用)。這也加重了 candidate target BSs 為了可能不會進來涵蓋範圍的MS去產 生AK而增加額外的負擔。
h c
2) MS 發送 MOB_MSHO-IND 給 serving BS：當 MS 決定 target BS 後，發出
MOB_HO-IND 訊息給 serving BS，由 serving BS 負責通知 target BS 去產生 AK Assignment。相較於前一項 AK Assignment 的時機點，anchor authenticator 不會因為 替 candidate target BSs 產生 AK 而增加負擔，candidate target BSs 也不須為 MS 產生 AK 而增加 overhead。
3) MS發送RNG-REQ給target BS：[4]允許MS移動到target BS後才要求AK Assignment，但這種情形有可能導致handover的延遲時間會比上述兩者還長，因為 前兩者是由servering BS還在服務MS的情況下由serving BS負責通知target BS去提出 AK需求(request)，target BS在還沒服務MS之前可以有充裕的時間去申請新的AK，
所以當MS發出RNG-REQ給target BS後，target BS就已經擁有新的AK了；但第三種 情況為因MS欲連結target BS時才由target BS發出AK Assignment需求，MS必須等待 target BS獲得新的AK後MS才可以繼續往下執行，這會導致換手的延遲時間拉長。
因此本論文稍後提出的解決方案，將不會在這種狀況下要求AK Assignment。
MS Serving BS
MOB_MSHO-REQ
MOB_MSHO-RSP/MOB_BSHO-RSP
MOB_HO-IND
Target BS
RNG-REQ (HMAC/CMAC) MOB_NBR-ADV
MOB_SCN-REQ
MOB_SCN-RSP
HO_ASSOC_REQ HO_ASSOC_REQ
HO Request HO Response
HO Confirm
1) AK Assignment 1) AK Assignment
3) AK Assignment 3) AK Assignment 2) AK Assignment 2) AK Assignment
Figure 2-13 AK 產生的時間點
2.4 AK在HO時的產生流程
經過前面2.3.5介紹MS在handover過程中AK產生的三個時機點後，本節針對這 三種時機點詳述完整的訊息傳送過程：
1) 第一種情形參照Figure 2-14描述MS在發出MOB_MOB-REQ訊息後，其中訊 息欄位包含MS MAC Address與可能的相鄰BS連結的候選名單(candidate target BSs，此例為neighbor BS1 與neighbor BS2)。待serving BS收到之後，透過HO_Request (表格 A-1)封包傳遞給neighbor BS1 和neighbor BS2；此時neighbor BS1 和neighbor BS2 可以選擇在這準備階段(preparation phase)傳送Context Request (表格 A-2)給 anchor authenticator，要求anchor authenticator提供MS在與serving BS連結時所使用 的AK Context。Context Request若選擇不在這個時機點發出，則必須等到行動階段 (action phase) 才 能 發 送 訊 息 。 當 neighbor BS1 和 neighborBS2 接 收 到 anchor authenticator所發出的Context Report (表格 A-3)之後，neighbor BS1 再透過 AK Request向anchor authenticator要求MS與neighbor BS1 之間的一把新的AK2，而 neighbor BS2 也向anchor authenticator要求一把MS與neighbor BS2 之間的一把新的 AK3。anchor authenticator在收到AK Request訊息後，判斷是否仍保有該MS的 PMK。若有，則anchor authenticator將新的AK2 及AK3 填入AK Context，經AK Transfer 封裝後各自回傳給 neighbor BS1 和neighbor BS2，完成AK的產生過程。
根據上述的流程，可以定義出AK Assignment機制包含 Context Request、Context Report、AK Request 和 AK Transfer。
MS Serving BS MOB_MSHO-REQ (MS, BS list)
HO_Request(MS, BS list)
Context Request (MS, Target BS1) Context Report
AK_Request(MS)
AK_Transfer(AK2)
AK2 Generation
Context Request (MS, Target BS2) Context Report
AK_Request(MS)
AK_Transfer(AK3) AK3 Generation
HO
Candidate BSs always have AK
HO_Response
HO_Response MOB_BSHO-RSP
MOB_HO-IND Recommend
BS list
Target BS
HO_Request(MS, BS list) AK2
AK3
Anchor Authenticator Neighbor BS1 Neighbor BS2
Figure 2-14 AK Triggered by MOB_MSHO-REQ
2) 第二種情形為 MS 決定 target BS 之後才發出 MOB_HO-IND 訊息，對於第 一種情形在獲得 AK 失敗後還有機會再次求得 AK。此時 serving BS 傳送 HO Confirm 訊息給 target BS，當 target BS 接收到確認訊息後，首先回傳 HO Ack 給 serving BS，通知 serving BS 已經收到訊息了。target BS 接下來跟前面的情形一樣 執行 AK Assignment，可選擇性的透過 Context Request 向 anchor authenticator 要求 原先舊的 AK 後，再透過 AK_Request 要求一把新的 AK2。
MSMS
MOB_HO
MOB_HO--IND IND ((MS,TargetMS,TargetBS)BS)
HO_Complete HO_Complete
AK_Transfer
AK_Transfer(AK2)(AK2) AK2 GenerationAK2 Generation
RNG
RNG--REQ (HMAC/CMAC)REQ (HMAC/CMAC)
RNG RNG--RSPRSP
Context Request
Context Request