經過前面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 (MS, Target BS)(MS, Target BS) Context Report
Context Report
AK_Request AK_Request(MS)(MS) HO Confirm
HO Confirm
AK2AK2
Authenticator Authenticator (Key Distributor) (Key Distributor) Target BS
Target BS (Key Receiver) (Key Receiver) Serving BS
Serving BS
HO HO AckAck
Figure 2-15 AK Triggered by MOB_HO-IND
3) 在前面兩種情形在獲得AK均失敗得情況下，[4]還提供第三種情形，為MS 移動到target BS後發送RNG-REG訊息時，target BS才開始去要求取得AK2 (Figure 2-16)。因MS發送的RNG-REQ帶有HMAC/CMAC，target BS必須要有能力能夠解 開，因此target BS必須立刻發送 ontext Request訊息給anchor authenticator，要求取 得MS之前與serving BS共用的AK Context，在這之後target BS還得需要向anchor authenticator取得介於MS與target BS之間新的AK Context。
C
MS
MS Serving BSServing BS
RNG-RNG-REQ (HMAC/CMAC)REQ (HMAC/CMAC)
AK_Transfer AK_Transfer(AK2)(AK2)
AK2 Generation AK2 Generation
RNG-RNG-RSPRSP
AK_Request AK_Request(MS)(MS)
AK2 AK2
Authenticator Authenticator (Key Distributor (Key Distributor)) Target BS
Target BS (Key Receiver) (Key Receiver)
Context Request
Context Request (MS, Target BS)(MS, Target BS) Context Report
Context Report
Figure 2-16 AK Triggered by RNG-REQ
分析以上的三種情形之所以能產生新的 AK，必須建立在 PMK 已經存在的前 提 下 才 能 成 立 ， 若 PMK 不 存 在 則 必 須 重 新 做 authentication (initiating re-authentication )。同樣的，當 MS 移動到另一個 NAP (mobility domain)底下的 target BS，則會因原先的 anchor authenticator 無法使用，亦得重新執行 re-authentication。
另外觀察的是，無論是上述哪一種情形，取得舊有或新的 AK 皆需要有 AK Assignment 訊息 (Context Request、Context Report、AK Request、AK Transfer)。尤其 是第一種情形，在尚未確定 target BS 時即要求所有可能的 candidate target BSs 各自 向 anchor authenticator 要求一把 AK，無疑是加重 backhaul 網路及 anchor authenticator 的負擔。因此本論文在下一節，提出新的方法來解決這些問題。
第 3 章
Distributed security mechanism
經由第二章描述 WiMAX 的架構下的整個認證授權程序，並分析 MS 在 handover 時的 AK 的產生過程及所需要花費的負載(loads)後，本章節提出本論文的 觀點並提供解決方法來減少 handover 中因 AK 產生的過程而導致延遲時間及增加 backhaul 端的網路負擔。
3.1 節中提出本論文的構想；3.2 節提出分析論點。