Castle on a Cloud

在 WiFi 的系統中, 我們通常想到得知 SSID 的方式, 都是 WiFi AP 透過 Beacon 封包進行廣播. 然而, 由於 Beacon 的傳送間隔不確定, 且需在同頻上進行接收, 對使用者而言, 若需要快速知道附近所有的 WiFi AP 列表, 就可以用 Probe 的方式進行主動掃描. 對於 Probe Request 封包而言, 其包含的資訊和 Beacon 類似, 主要有以下資訊: [header] 目標的 BSSID (若為廣播探索則填入 FF:FF:FF:FF:FF:FF) 裝置目前使用的通道 支援的通訊速度, 對 HT PHY 的支援 來自: https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics 當 WiFi AP 收到 Probe Request 後, 會檢查其支持的速率,  若相符則會回覆 Probe Response, 其格式基本上和 Probe Request 一致, 只是在 SSID 欄位中會帶有 WiFi AP 對應的 SSID 的資訊. 來自:  http://csie.nqu.edu.tw/smallko/sdn/mininet-wifi_lab1.htm 由上述內容可知, Probe Request/ Response 基本上是一種反向的 Beacon, 不但目標一致: 讓 WiFi Client 得知 WiFi AP 的資訊, 連傳送的封包格式都類似, 唯一差別的地方應是發送的時機, 不同於 Beacon 為等時發送 (通常是 1 秒 10 次), Probe Request 為使用者發起, 例如, 在手機上進行 Scan WiFi, 因此, 其傳送的間隔不定, 根據 Cisco Meraki 的統計, 對於手機裝置約為下表: 來自:  https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics 針對未連線的使用者, 裝置會頻繁 (每分鐘 10-15 次) 的發送 Probe Request, 隨時準備更新要連線的目標, 進入休眠則保持約每分鐘探索一次的頻率, 節省電力. 但是對於已連線 (associated) 的使

在 E2 Node 進行設定 , RIC 訂閱 RAN function 之後, RIC 和 E2 Node 之間的訊息交換就算完成, 兩者之後的互動, 就按照 RAN function 和其中的 Action 定義, 在所有的互動中, Indication 是最早被實作出來的項目. 事實上, Indication 並不是一種 E2 Application Protocol (E2 AP) 定義的功能, 在 E2 AP 中, 四種功能型態 分別為: REPORT, INSERT, CONTROL, POLICY. Indication 的資料通常被包含在 REPORT, INSERT 兩個功能項內, 其中的的差別在於, REPORT 為比較單純的資料回報, INSERT 則牽涉到 E2 Node 的控制 (回報後, 等待新的控制訊息下達). [註] 目前 xApp-bouncer 的實作就接近 INSERT 的方式, 換句話說, 就是 xApp 收到一個 Indication 後就送一個 CONTROL 給 E2 Node. 然而, xApp-bouncer 的實作並非標準的 INSERT 實作,  其 subscription 的 RAN function 仍為 REPORT,  CONTROL 也未按 E2 AP 格式, 而是以字串方式傳送. 回到這次的主題, 我們討論的應是 Indication-REPORT 的範例, 如第一張圖所示, Indication 所帶的資訊可以分成三類: 識別資訊: RIC Request ID IE, RAN Function ID IE, RIC Action ID IE 資訊內容: RIC Indication Type IE, RIC Indication Header IE, RIC Indication Message IE  其他資訊: RIC Indication SN IE, RIC Call Process ID IE 其中, 識別資訊是用以傳達目標的 xApp 與之後的資料處理, 資訊內容和其他資訊則是 xApp 向 E2 Node 所訂閱的資訊. 比較需要注意的是: RIC Indication Header IE, RIC Indication Message IE 這兩項資訊, 其表示方式皆為 16