Castle on a Cloud

在最新版本 (2021/7) 的 O-RAN SPEC 中, 在 MIMO Beamforming 的 Use Case 中加入了 E2 的使用情境, 和原本的 O1 介面的應用情境相比, E2 介面更即時, 因此, 最佳化的目標也從統計上的 Beam Allocation, (原文標題為: MIMO GoB (Grid of Beams) Beamforming optimization) 改為移動性的 MRO (Mobility Robustness Optimization) 問題 (原文標題為: MIMO Beam-based Mobility Robustness Optimization) 在 near-RT RIC 的 Use Case 中 (也就是上述的 E2 應用情境), 假設前述 GoB 的模型已經由 non-RT RIC 決定 (O1 應用情境), near-RT RIC 再藉由調整 MRO 的參數 (例如: Cell Individual Offset, CIO), 來保證使用者移動性的最佳化, 其流程如下: 和 O1 Use Case 類似, 在整體的交換流程中, 可以分成 4 個部分: [Step1-Data Collection] SMO 給定 GoB 的參數, 取得網路 (RAN) 中各節點的資訊 [Step2-AI/ML Flow] near-RT RIC 訓練 AI/ML 模型 [Step3-Configuration Update] near-RT RIC  透過 E2 界面對 E2 Node 進行 MRO 設定 [Step4-Performance Monitoring] near-RT RIC 持續量測網路效能, 適時驅動重新計算模型. 在整體流程上, 和原本 O1 情境中最大的差異在於起始條件, 考慮到 E2 情境中, GoB 的設定為必需的演算法輸入,  因此, 起始條件就包含 GoB 資訊給定 (GoB Beam Pattern Infomation is available), 同時, 當 GoB 資訊改變 (GoB Beam Pattern Change) 時, 就必須重新訓練 ML/AI 演算法, GoB 的資訊除了可以透過 SMO 計算得知 (透過 O1 告知 near-RT RIC), 也可以是存於 E2 N

在此 Masive MIMO 的 Use Case 中,  和之前 Traffic Steering 以及 Indoor Positioning 的範例不同, 負責運算的單元為 nRT-RIC (RT-RIC 也有一個範例, 但尚未有內容) 因此, 通訊的介面也由 E2 介面, 改成 O1 介面. 這樣修改的主要原因是 Massive MIMO 主要在 RU 上實作, 而 RU 和 O-RAN 之間的介面就只有 O1, 因此, 計算的位置就改到 nRT-RIC 中 SMO 進行, 資料的交換流程如下圖所示: 在整體的交換流程中, 可以進一步分成 5 個部分: [Begin]  電信營運商開始流程, 或是由事件觸發 [Step1-Data Collection] SMO 發起量測資料的流程, 取得網路 (RAN) 中各節點的資訊 [Step2-AI/ML Flow]  nRT-RIC 從 SMO 中取得量測資訊, 並訓練 AI/ML 模型 [Step3-Configuration Update] SMO 透過 O1 界面對 RU 進行設定, 包含以下資訊: 水平與垂直的波束寬度, 波束的水平與垂直角 每個波束所使用的最大能量 [Step4-Performance Monitoring] SMO 持續量測網路效能, 並適時驅動重新計算模型. 值得注意的是, 由於計算的單元為 nRT-RIC, 犧牲了運算的即時性. 因此, 在此處學習的 AI/ML 模型基於網路的長期效能最佳化, 而非針對即時的網路狀況. 對於 AI/ML 網路的訓練資料則包含了目前波束設定, 使用者的歷史分布, 基地台的波束參數 (水平/垂直方向角, 波束寬度等), 網路的效能 KPI, 等資訊.  透過 AI/ML 網路的學習, 限制網路中基地台使用的波束可用方向與能量, 即可減少相鄰基地台透過波束傳輸產生的干擾.

Massive MIMO 技術主要藉由多個傳送天線, 利用通道在空間中不同位置上的特性, 抑制使用者所收到的訊號干擾, 並提高接收端的訊號品質, 一般來說, Massive MIMO Beamforming 可分成兩類: 數位 (codebook-based): 透過預先量測的通道特性, 透過選擇不同 pre-coder 來達成使用者間訊號的干擾分離. 此技術較常用於 sub-6 GHz 的通訊規範. 類比 (phase shifter): 通常會合上述數位 Beamforming 一起實作, 成為混合 (hybrid) 架構, 在此架構下, 天線被分成數組, 每一組先藉由天線的相位調整 (phase shifter), 形成指向性, 組間再以數位方式提供不同使用者優化. 此技術可降低硬體取樣的成本, 通常用於 mmWave 的環境. 不論上述哪一種 Beamforming 技術, 對於 O-RAN 而言, 是從一個比較上層的角度看待, 最佳化的目標為 Beam 的選擇, 因此, 在此問題中, 可操作的變數包含: 天線場型的水平角(Azimuth), 垂直角 (Elevation), 以及變化的角度區間, 以及所使用的波束寬度 (beamwidth) 以及每一波束的傳送功率. 值得注意的是, 在 O-RAN 架構中,  Massive MIMO 的功能實作於 RU (Radio Unit), 如下圖所示: 來自:  https://www.techplayon.com/o-ran-fronthaul-spilt-option-7-2x/ 在圖中, 我們可以看到 Beam 的指向與控制, 都在 RU 中進行, 然而, RE (Resource Element) Mapping 和 Scheduling 都在 DU 中進行, 因此, 若是要根據排程結果, 提供使用者即時的 Beam Allocation, 則需要 RU 和 DU 之間的緊密合作.

在通訊系統中, 量測訊號 (RSRP, RSRQ, SINR) 主要的用途就是用來進行換手, 此功能從 2G 系統就被實作, 並隨著更多通訊技術的發展而增加, 在 TS 3GPP TS 38.331 中定義了 5G 網路中, 以下和換手與量測報告的相關驅動事件: Event A1 (Serving becomes better than threshold) Event A2 (Serving becomes worse than threshold) Event A3 (Neighbor becomes offset better than SpCell) Event A4 (Neighbor becomes better than threshold) Event A5 (SpCell becomes worse than threshold1 and neighbor becomes better than threshold2) Event A6 (Neighbour becomes offset better than SCell) Event B1 (Inter RAT neighbour becomes better than threshold) Event B2 (SpCell becomes worse than threshold1 and inter RAT neighbor becomes better than threshold2) 其中, A 系列的事件對應於相同的 RAT (例如: 4G, 5G, etc), B 系列的事件, 則對應於 RAT 之間 (inter-RAT) 的換手,  在各事件的描述中, 以下為一些簡寫的說明: special cell (SpCell): 主要的服務基地台 secondary cell (SCell): 次要的服務基地台, 提供 CA (Carrier Aggregation) 功能 在各項驅動事件中, threshold 為針對事件的一致性定義, 針對每一事件, 我們都可以定義其對應的數值, offset 則是針對每一個基地台定義, 其數值可以為正或為負, 各項數值的物理意義與定義範圍顯示如下表: 在所有的事件中, 我們可以依照其驅動條件分成兩類: 絕對數值事件: A1, A2, A4, A5,

對於定位而言, 量測資訊是必要的資訊, 不論是 UE 發起的量測, 或是, NRPPa 中由基地台進行的量測皆是, 在 LTE/ NR 的系統中, Measurement Report 一詞專指 UE 進行的量測, 在舊有的系統中, Measurement Report 主要作用是換手的決定, 透過鄰近基地台的訊號量測, Measurement Report 可以決定換手的事件 (Event), 這部份我們有機會再說明. 考慮到 Measurement Report 和換手 (建立連線) 的密切關係, Measurement Report 的設定在 RRC (Radio Resource Control) 層定義, 針對已建立連線 (RRC_CONNECTED) 的 UE, 可以進行量測的設置, 因此, 對於閒置 (idle) 的 UE, 必須先建立 RRC 連線才能設置, Mesaurement Report 的參數設置在 RRCConnectionReconfiguration 中設置, (並沒有在初始 RRC 連線時設置, 因為當時 UE 並非 RRC_CONNECTED, RRCConnectionSetupComplete 之後狀態才變成 RRC_CONNECTED), 其建立連線的流程如下圖所示: 因此, Mesaurement Report 的設置是在 UE 成功 attach 之後, 此時, Measurement Report 的設置 (measConfig) 就包在 RRCConnectionReconfiguration 中, 透過 serving eNB 傳給 UE, 其封包格式如下圖所示: 在圖中, 我們可以看到 measConfig 依附於 RRCConnectionReconfiguration, 在這個設置的範例中, measConfig 第一個子項目為: MeasObject, MeasObject 定義了 UE 要進行量測的目標,  在這邊的設置會隨著不同的網路特性改變: 同頻帶, 不同頻帶, 同系統, 不同系統, 必要的時候還要設置 Measurement Gap, 使 UE 暫離通訊服務進行量測, 透過告知 UE 這些量測的參數, UE 就可以依序填回量測的結果, 進行 Measurement Report 的回報. 在第二個

在研讀完 5G 的定位流程後, 我們來進一步看定位時所需要的量測資訊, 在這篇文章中, 我們先專注在 NRPPa 的量測資訊, 考慮到 NRPPa 是由 gNB 進行量測, 其攜帶的資訊較為簡單, 在整體定位流程中, 交換的資訊如下: 在 NRPPa 中, 所定義的交換資訊可以分成 2 類:  控制/輔助資訊: 提供定位的發起, 輔助資訊 (例: gNB 的設置) 和定位流程相關: E-CID (訊號強度), OTDOA (下行), UL-TDOA (上行) 為了取得量測的資訊, 除了要決定那些基地台進行量測, 這部分通常由一個 ANR (Automatic Neighbour Relation) 功能決定, 還需要決定量測的時機, 以及要量測的資訊, 關於量測的時機, 可以分成按需求進行量測, 或是週期量測, 其定義如下表: 在表格中, 我們可以看到不同的參數區間, 其中, 週期回報的時間區間可以從 120ms 到一小時, gNB 越常進行量測, 就可以得到越精確的定位結果, 也可以針對使用者進行追蹤等演算法改進, 但同時犧牲的就是 gNB 能來傳送資料的時間, 因此, 此數值應在定位需求與網路效能間取得平衡. 在回報的資訊部分, 則是按照 TRP 回報, TRP 為 TRansmission Points 的縮寫, 可以想像是小基地台指向性天線 (sector antenna), 如果一個基地台有多個天線, 則可以透過 TRP ID 和 Cell ID 區分, TRP 回報的資訊內容, 包括: AoA (角度), RSRP (訊號強度), RTOA, Rx-Tx Diff (時間差), 顯示於下表:

在 上一篇文章 中, 我們介紹了在 5G 下的標準定位流程, 其中, 包含了取用使用者量測資訊的 LPP 以及取用基地台資訊的 NRPPa, 在這篇文章中, 我們將著重在系統端定位的流程, 也就是透過 NRPPa 定位的資料交換流程. 在 3GPP 定義的定位框架中, 透過基地台量測定位資訊是最晚被完成的部分, 也因此, 在 5G NR 中並沒有複用 LTE 的對應框架 (LPPa), 而定義了新的定位協定 (NRPPa), 透過基地台進行定位的困難有兩個: 量測的目標: 不同於下行的量測, 可以讓 UE 量測基地台的廣播訊息, 上行的通道量測需要 UE 廣播訊號讓基地台進行量測 那些小基地台進行量測: 在 LPP 架構下, 給予 UE 一量測列表, UE 量測後填入, 考慮到 UE 有定期量測需求, 排定 UE 對周遭基地台量測較容易, 列表也可以較寬鬆, 然而, 當基地台進行量測, 則會影響該基地台所有的使用者, 占用大量系統效能  考慮到這兩點限制, 上行定位框架的實現, 就花了比較多時間討論, 然而, 上行定位架構可以提供系統主動定位的機會, 適合小基地台同頻布建下, 即時裝置定位/追蹤的應用情境, 我們以 UL-TDOA 為範例, 其定位流程圖如下: 以下為各流程的說明: 先確定 Serving gNB 的設定 透過 LPP 確定 UE 的能力 向 Serving gNB 發出資訊需求 Serving gNB 設定 UE 的 SRS (Sounding Reference Signal) 將 SRS 設定回覆 LMF LMF 發起定位資訊量測 啟動 UE 開始進行 SRS 傳送 回覆 LMF 設定結果 指定 Neighbor gNB 進行量測 量測目標 UE 的 SRS 訊號  將量測結果回報至 LMF LMF 進行定位後結束定位流程  其中, SRS 訊號即是 UE 廣播發出, 用以進行定位量測的訊號, 此訊號有不同的 pattern, 使得同時可以對多個 UE 進行上行定位, 在設定 UE 的 SRS 訊號後, 須把此設定通知進行量測的小基地台, 為了減少資源的使用, LMF 只會通知部分的(鄰近)小基地台進行量測, 為了決定誰是鄰近小基地台, 這裡就需要 ANR (Automatic Neighbour Relation) 涉入, 來確保只有鄰近的小

在 上一篇文章 中, 我們介紹了 5G 架構下定位相關的協定, 以及其實現的架構, 若我們考慮 LMF-based 的定位框架, 可以按照資料收取的角色, 進一步分成兩類: UE-asssisted, LMF-based: 由 UE 進行量測, 資料回傳透過 LPP NG-RAN Node assisted: 由 gNB 進行量測, 資料回傳透過 NRPPa 我們接下來將分別對此兩個架構進行介紹. 首先, 我們從定位需求的發起方說起, 在 5G NR 的架構中, 有三個定位發起者: UE, AMF, GMLC (外部需求), 所有的定位需求, 將送到 AMF (LTE 中的 MME) 發動定位的量測需求, 針對以 UE 為基礎的量測流程, 覆用了原本 LTE 的 LPP (LTE Position Protocal) 定位協定, 對於以 gNB 為基礎的定位量測, 則定義了 NRPPa (NR Position Protocal annex) 協定, 這樣的設定有其歷史因素, 畢竟 LPPa (NRPPa) 的前身, 在 LTE 框架定義時, 一直未被完整實作, 另一方面, 考慮 5G NR 中新增了許多不同的無線介面, 為此擴增定位量測資訊也算是合理, 在進行量測後, AMF 將量測的回報回傳至 LMF, 進行定位計算, 其流程如下圖: 以下為整體定位流程的解說: 發起方: UE, AMF, GMLC (圖中 5GC LCS Entities) AMF 通知 LMF 進行定位, LMF 發起量測需求 確認 UE 量測能力 提供 PRS 訊號的 Pattern (同頻時 RPS 會分開) UE 進行 OTDOA/RSRP 等定位相關量測 gNB/UE 進行 下行/上行 訊號量測 上行訊號量測: NRPPa 下行訊號量測: LPP LMF 回報定位結果 回報結果給 AMF, GMLC (圖中 5GC LCS Entities) 對於 LPP 的定位資料量測, 和之前關於 Measurement Report 的設定類似 (參考 此文 ), 大致可以分成同頻 (小基地台環境) 或異頻 (通常是大基地台) 設定, Serving gNB 必須先給 UE 量測的列表, 以及排定量測時間 (異頻量測無法進行通訊), UE 進行量測後, 依據列表的順序, 回填量測資訊並回報給

在之前的文章中, 我們介紹了 5G NR 的新功能, 可以參考以下的介紹: LTE筆記: 5G 定位的應用與演進 ~1 LTE筆記: 5G 定位的應用與演進 ~2 LTE筆記: 5G 定位的應用與演進 ~3 在接下來這一系列文章中, 我們將敘述定位框架與流程, 並探討在 5G NR 中可以取得的定位量測資料. 在 5G NR 中, 定位可以分成三種: UE-based: UE 進行量測, UE 進行定位 UE-assisted: UE 進行量測, 核網 (LMF) 進行定位 RAN-assisted: RAN 進行量測, 核網 (LMF) 進行定位 不同的定位框架, 會對應到不同的量測資訊與定位方法, 如下表所示: 3GPP TS 38.305 -  Stage 2 functional specification of User Equipment (UE) positioning in NG-RAN 其中, 資料平面 (User Plane) 的定位則是和 4G 一樣使用 SUPL (Secure User Plane Location), 在控制平面 (Control Plane) 我們將著重於 UE-assisted 與 RAN-assisted 兩個架構, 並針對此兩個架構說明其中流程. 在 5G NR 架構下, UE-assisted 和 4G 一樣透過 LPP 進行, RAN-assisted 則透過新定義的 NRPPa (取代 LPPa) 進行, 在此架構下, 定位需求可以是由 UE 或是外部使用者 (透過 GMLC) 發起, 這些定位需求將透過 AMF (也就是 4G 中的 MME) 送達 LMF, 並由 LMF 進行後續整體定位流程的主導, 以及定位結果計算.

定位服務 (Locating Service, LCS) 已經定義於 3GPP 的標準 (以 5G NR 為例), 其中, 又可細分為兩種: 基於使用者量測資訊進行定位 (UE-assisted, 透過 LPP), 基於基地台與其他接取裝置進行的量測進行定位 (RAN-assisted, 透過 NRPPa), 定位的計算引擎稱為 LMF (Location Management Function), 定位需求可以由, UE, AMF, 或是外部使用者 (透過 GMLC 提出) 發動, 並交付給 AMF 向 LMF 提出, 如下圖所示: 根據 O-RAN 的精神, 並不會重複定義 3GPP 中的功能, 因此, 在此應用例中, O-RAN 著重於兩個特殊應用: 室內, 以及即時性. 首先, 針對室內應用,  在室內的環境中, 可由少數基地台服務一個樓平面的通訊需求, 因此, 可以假設這些基地台受控於同一個 near-RT RIC, 也避免了在大範圍空間中, 區域切割以及跨 near-RT RIC 通訊的問題, 在此網路拓譜下, near-RT RIC 可以取得所有基地台對使用者的量測, 並基於此量測資訊進行定位服務的提供. 事實上, 相同的資料流程, 也可以在 LMF 上提供定位的計算, 為了和標準 LMF 提供的定位服務做出差別, O-RAN 的應用例中強調了在 near-RT RIC 上的即時性 (低於1秒的延遲), 考慮到 LMF 位於核網, 資料傳遞經過層層延遲, 同時必須服務整體網路的定位需求, 響應時間易受計算需求變化影響, 相對的, 在 near-RT RIC 的架構下, 可將計算放置於 Edge 減少延遲, 也可以根據目標場域的需求預先配置計算資源, 確保響應時間. 考慮到此份應用例仍在非常粗略的階段, O-RAN 尚未定義出資料交換的流程, 以及適用於定位的量測資料來源, 以目前所列的資訊猜測, 資料應該可以分成兩部分: UE-assisted: UE 相關的資料, 可能暫存於 gNB 中, 或是作為 UE 狀態暫存. RAN-assisted: gNB 針對 UE 發出的 SRS (Sounding Reference Signal) 量測資訊, 不論何者資訊, 都仍必須透過 LMF 發起, 並和 UE 與 gNB 溝通. 因此, 比較合理的可能性是

在 上一篇文章 中, 我們介紹了 Traffic Steering 在 WG1 文件中的定義, 接著, 我們繼續看一下 WG2 中相關的 Use Case 定義, 相關文件名稱如下: O-RAN.WG2.Use-Case-Requirements-v02.01 為什麼我們要把 WG1 和 WG2 的文件分開來說呢? 在 O-RAN 的組織切分中, WG1 和 WG2 負責的功能如下: WG1: Use Cases and Overall Architecture Workgroup WG2: The Non-real-time RAN Intelligent Controller and A1 Interface Workgroup 相較 WG1 以應用情境和架構為主, WG2 著重在 Non-RT RIC 的功能, 因此, 我們預期在 WG2 的文件中, 我們可以看到更多的技術細節. 而在 WG2 的文件中, 一開始的確從相同的流程圖 (請參考 上一篇文章 ) 出發, 但是額外討論了兩個 non-RT RIC 的功能: EI (Enrichment Information) 和 A1 policy. 在 EI 的討論中, 原本 17 步驟的流程圖, 拓展成 28 步驟, 其中, 增加的步驟主要在原有步驟之後, 如下圖所示: 來自: O-RAN.WG2.Use-Case-Requirements-v03.00 在上圖, 我們可以看到 EI 參與的方式, 是由外部通知 non-RT RIC, 當有新的 EI 資訊進來後, non-RT RIC 就會開始生成資料, near-RT RIC 可以以詢問 (request) 或是訂閱 (subscription) 的方式, 取得 EI 的資訊, 輔助決策. 在 EI 的例子中, 用以輔助決策的資訊為: Radio Fingerprint, 在原本 mobility management 的架構下,  為了進行換手的判斷, UE 將會量測連線基地台 (serving eNB) 的訊號強度, 以及附近基地台的訊號強度, 當兩者強度落差到一定時, eNB 就會進行換手的程序. 然而, 考慮到量測時間的限制, 有時候 UE 無法量測到附近所有的基地台, 此時, 就可以藉由長時間的統計數據 (也就是 Radio Fingerprint

在 ORAN 的 SPEC 中, Use Case 的說明主要在以下三個文件: O-RAN.WG1.Use-Cases-Analysis-Report-v04.00 O-RAN.WG1.Use-Cases-Detailed-Specification-v04.00 O-RAN.WG2.Use-Case-Requirements-v02.01 其中, WG1-Use-Cases-Analysis-Report 範圍最廣, 定義可行的應用情境, WG1-Use-Cases-Detailed-Specification 定義需求與基本的資料流, WG2-Use-Case-Requirements 則進一步討論不同佈建下的實作, 更接近實際場景, 在應用案例的數量上, 因為 ORAN 採取的是並行的策略,  定義完成的應用情境, 也隨著要求細節的增加而逐漸減少, 我們先以三份文件中都出現的 Traffic Steering 為範例: 在 WG1 的討論中, 會將一個 Use Case 分成 4 項討論: Background and goal of the use case (應用情境的目標) Entities/resources involved in the use case (各單元的功用) Solutions (一個簡單的資料流, 各元件如何協力完成目標) Required data (E2 Node 需實作/提供的資訊) 針對以上四點, 我們從 WG1 文件中整理出以下說明: 對於 Traffic Steering 而言, 其目標考慮的不只是換手與移動性問題, 還考慮在不同無線介面 (NR, LTE, WiFi) 之間的切換, 並考慮了各節點在不同負載下, 如何透過預先資源配置, 確保通訊品質. 為了達成上述目標, 需要 Non-RT RIC, Near-RT RIC 以及 E2 Node 參與, 其中, Non-RT RIC 負責產生 policy 予 Near-RT RIC 執行, 而 E2 node 則負責資料收集, 以及換手功能的執行 Non-RT RIC 透過 O2 介面定期取得系統效能的參數, 並發起 Traffic Steering, 當發起 Traffic Steering 後, 會再次收集資料, 運算出適合的 policy, 並將 policy

和 non-RT RIC 不同, near-RT RIC 可說是完整由 ORAN 設計的元件, 在 near-RT 的架構設計上, 較 non-RT RIC 簡潔, 並引入虛擬化和資源共享, 其架構使用 container 為主的計算架構 (例如: kubernetes), 並提供一個共同的資料存取層, 將計算 (xAPP) 以及資料儲存分開, 並提供各項 xAPP 之間的資料存取管理, 安全性管理以及服務管理, 如下圖所示: 來自: O-RAN.WG3.RICARCH-v01.01   near-RT RIC 對外則有三個接口, 提供 O1, A1, E2 三個介面的串接. 其中, O1 主要是讓 xAPP 統合 E2 Node 資訊後,  向 non-RT RIC 提供錯誤 (faults and events information management, FM) 或是效能 (performance management, PM) 的資訊. A1 介面則以 RESTful API 的方式, 以 1-to-1 對應方式, 使 rAPP 提供 xAPP 支援, 最後, E2 介面則是負責將 xAPP 做成的指令傳達至對應的 E2 Node, 進行相對應的工作. 通常在 ORAN 的架構圖中, near-RT RIC 被歸類於 RAN 的部分, 而 non-RT RIC 被歸類於 SMO 模組的部分, 在實際的布建上, near-RT RIC 通常和 CU 部現在同樣的位置 (Cloud/Edge), 這是因為在 5G NR 架構下, CU 多半被視為軟體化的實作, RU 為硬體實作, 而 DU 則是軟體/硬體兩者兼有, 看實際布建的需求, 簡單的想法就是, 若需要越即時的計算結果, 則需要把 near-RT RIC 往前端布建, 然而代價就是, 較小的管轄範圍以及更頻繁的資料交換. 在這邊需要注意的是, ORAN 的架構的確不只包含 5G, 也可支援 LTE, 此處的表現在 E2 Node 定義包含了 CU/DU (5G NR 架構下), 也包含了 eNB (O-eNB) 請見 O1, A1 介面的 介紹 中的圖一, 但應避免在同一脈絡中, 混用 5G NR 和 LTE 兩邊不同的概念與名詞, 除非是在討論 NSA (Non-StandAlone) 或 SA (S

介紹完 ORAN 中的各項介面後, 我們接著介紹 ORAN 架構中兩個主要元件: non-RT RIC 和 near-RT RIC, non-RT RIC 全寫為: non-RealTime Radio Intelligent Controller, near-RT RIC 則是 non-RealTime Radio Intelligent Controler. 兩者的差別明顯的在於響應的時間, 並透過 A1 介面, 交換資料並分工. 在本文中, 將著重於 non-RT RIC 的介紹. non-RT RIC 負責秒以上等級響應時間的操作, 按照 ORAN 的想法, 其主要有三個功能: Enrichment Information Service: 透過 O1 取得系統的效能, 匯集外部資訊 ML Model Management Service: 更新於 near-RT RIC 上運行的 ML (Machine Learning) 模型 Policy Management Service: 透過 A1 管理 near-RT RIC 要執行的 policy  其詳細的功能圖可以以下圖表示: 來自: O-RAN.WG2.Non-RT-RIC-ARCH-TR-v01.00 在圖中, 我們可以按照顏色分成四塊: 紅色: 暨有 SMO 功能, 又稱為 FCAPS  (Fault, Configuration, Accounting, Performance, Security) 藍色: 暨有 non-RT RIC 功能 黃色: 連接外部資料 (Enrichment Information Service) 白色: rAPP 的架構 (透過 R1 介面, Open API for rAPP) 從圖中, 我們可以發現, non-RT RIC 並不是一個全新的發明, 而是在許多舊有架構 (SMO framework) 下,  重新組織的成果, 在 ORAN 的定義下, 主要是透過介面的標準化, 以及虛擬化的技術, 將 rAPP 引入 SMO 的框架下, 使第三方可以更輕易的開發 non-RT RIC 的功能, 同時也可以相容現有的程式框架, 避免重複開發. * SMO: Service Management and Orchestration 考慮到現有 SMO 的功能,

在 上一篇文章 中, 我們介紹了 A1 和 O1 介面, A1 和 O1 主要從 non-RT RIC 出發, 用以串接 O-RAN 架構中各裝置, 而 E2 介面*則由 near-RT RIC 出發連接 5G 網路中的裝置, 並稱為 E2 Node, 我們一樣從架構圖出發: 來自: O-RAN.WG1.O-RAN-Architecture-Description-v03.00 這張架構圖和之前的一致, 不過標出了 3 個 control loop 以及時間響應:  Non-RT RIC (>=1000 ms), Near-RT RIC (10~1000 ms), O-DU (<10 ms), 在這張圖中, 我們可以看出 E2 和 O1 介面在時間響應上的差異, 簡單來說, E2 負責較即時的資料交換, 並基於各 E2 Node 的控制訊息實作. 考慮到 O-RAN 的架構, 基本上所有實體 (CU, DU, eNB) 都可以作為 E2 Node, 在 E2 介面的定義上, 採取將 E2 Node 虛擬化的想法, 如下圖所示: 來自:  https://wiki.o-ran-sc.org/download/attachments/10715420/Near_RT_RIC_for_ONS.pdf 在圖中, 我們可以看到, 每一個 E2 Node, 不論扮演 CU, DU 或其他功能, 都透過 E2 Agent 和 Near-RT RIC 上的 xApp 進行資料交換, 不同的單元, 如 O-DU, O-CU, O-eNB, 與 Near-RT RIC 之間介面相連的關係如下圖:   來自: O-RAN.WG3.E2AP-v01.01 從上圖, 我們也可以看到 O-RAN 取名 E2 而非 E1的 原因, E1 介面為 3GPP 定義 CU-CP 和 CU-UP 之間的介面,  因此, O-RAN 從 E2 定義, 而非如 A1, O1 般, 從1開始編號.  在 E2 Node 一開始連上 Near-RT RIC 時, 透過 E2 Node Setup Procedure, 告知 Near-RT RIC 自己所支援的 Func (對應到 Near-RT RIC services), 宣告完所支援的功能後, Near-RT RIC 可透過 E2 介面來操作

在大略看過 O-RAN 的架構之後, 在這一篇文章中, 我們把重點放在各單元之間的介面, 來自: O-RAN.WG1.O-RAN-Architecture-Description-v03.00 在 O-RAN 架構下, 其自訂介面可以包括以下項目: O1: FCAPS (Fault, Configuration, Accounting, Performance, Security) 的控制介面 O2: 和 O-Cloud 溝通 A1: Non-RT RIC 和 Near-RT RIC 溝通 E2: Near-RT RIC 和 gNB/eNB (O-RAN 中稱為 E2 Node) 溝通 Open Fronthaul: RU (Radio Unit) 溝通   CUS: Control User Synchronization (連接至 DU)  M: Management (連接至 Non-RT RIC 或 DU) 多數的介面都是直接定義兩個單元之間的界接 (O2, Open Fronthaul), 比較值得關心的介面像是 E2 (因為 E2 Node 有各式功能) 以及 O1 與 A1 (兩者都連接 Near-RT RIC, 如何分工?) 我們先從 O1 和 A1 介面開始, 按照 SPEC 中的描述, O1 介面不直接與 Non-RT RIC 相連, 並負責 FCAPS 功能, A1 介面則是連接 Non-RT RIC 和 Near-RT RIC 提供 RAN 的設定最佳化, 在目前 O-RAN 框架下, A1 介面有以下三個功能: Policy Management Service: 提供 Near-RT RIC 的執行策略設定 ML Model Management Service: 更新 Near-RT RIC 的 ML 模型 Enrichment Information Service: 提供 Near-RT RIC 外部資訊 透過 A1 介面, 我們可以發現在 Near-RT RIC 和 Non-RT RIC 的分工上,  Near-RT RIC 負責即時的運算, Non-RT RIC 負責 ML 模型訓練以及參數選擇, 詳細的內容與分工, 我們之後會以實例進行說明, 至於 A1 和 O1 的分工, 我們可以用下圖來解釋: 來自: O-RAN.WG1.

ORAN (Open Radio Access Network) 是一個主要由電信營運商發起的組織, 其目標在於在 3GPP 的 5G NR 架構上, 提供一個開放性的管理架構, 提供 Radio Access Network (基地台, 無線接取點) 的協作管理, 智能化, 與虛擬化, 其官方網站為:  https://www.o-ran.org/ 在上述目標中, 我們可以釐清一些重點: ORAN 的發展是基於 3GPP 架構, 因此, ORAN 不會重複定義 3GPP 的功能, 而以補充 3GPP 框架, 或是提供協定外的裝置管理為主 ORAN 的組成為營運商為主, 和 3GPP(硬體廠商也佔有重要角色) 不一樣 , 發展重點也著重於開放硬體架構 或許, 會有人好奇:  假如 ORAN 不是一個通訊協定 (如 3GPP LTE/5GNR), 那麼其標準的意義與範圍為何? 事實上, 在通訊系統的實作中, 有許多功能的演進都不是由 3GPP 推動, 而是由各硬體/營運商實作, 例如 China Mobibe 的 Cloud-RAN 就是一個很好的例子, 通訊協定, 通常只定義了封包交換的格式與流程, 作為基本的相容性規範, 而留下了許多空間讓各家廠商實作並優化演算法與架構. 對於 ORAN 而言, 其目標也不是提供優化演算法的標準, 反而是在現有 3GPP 的框架下, 提供框架與資料接取流程, 站在電信營運商的角度, ORAN 可以解決兩個問題:  透過開放降低白牌裝置的進入障礙, 進而降低整體建置成本,  透過定義資料交換架構, 使得一集中式控管的 RAN 架構更容易實現, 有利於在 5G NR 眾多異質接取設備下, 提供良好的布建與管理. 下圖為 ORAN 的架構:   來自:  https://www.o-ran.org/ 在 ORAN 架構中, 依循 Cloud-Edge-eNB (RF) 的架構,  依據即時性的需求, 將 RAN Intelligent Controller (RIC) 架構分成 3 個部分: Non-RT RIC: 紫色方塊, 位於雲端平台, 響應時間 >1000 ms Near-RT RIC: 深藍色方塊, 位於 Edge 平台, 響應時間為 10~1000 ms O-DU (distributed unit), O-RU (r

本文內容主要來自: Hard, Andrew, et al. "Federated learning for mobile keyboard prediction." arXiv preprint arXiv:1811.03604 (2018). 連結參考:  https://arxiv.org/abs/1811.03604 在舊有的 deep learning 架構中, 我們通常將大量資料收集到一個伺服器, 並學習網路之參數, 這樣架構的假設是: 這些資料包含了所有使用者的行為, 因此, 在給定一個好的網路架構的前提下, 我們便可藉由該網路的參數學習, 來表現所有資料的特徵. 然而, 這樣的假設, 面臨到行為的動態, 以及資料增長的問題. 舉例來說, 在此研究中的題目, 是根據現有輸入, 對下一個輸入詞彙的預測. 此問題會隨著地域與時間的變化, 而有不同結果. 因此, 如何透過使用者的回饋, 動態更新模型, 就是一個困難的問題. 因此, Federated Learning 被提出用一個簡單的方法來解決此問題, 其中的想法與資料交換大致如下圖所示: 在一開始, 每一個裝置會先下載一個共通的模型 (w_t), 在此應用中, 下一個字元的預測藉由 LSTM 網路進行, 因此, w_t 代表的是 LSTM 中的參數, 透過預先收集的大量資料學習出來, 接著, 根據每個裝置上收集的資料 (個數為n_k), 裝置自行學習並更新 LSTM 網路, 此參數值 (w^k_{t+1}) 也會回傳至中央伺服器, 執行 Federated Learning 更新, 中央伺服器收到每個裝置的更新參數後, 根據資料的大小賦與權重 (n_k/N),  並更新整體網路的共通模型 (w_{t+1}). 在 Federated Learning 的架構下, 不但能夠利用裝置有限的計算資源, 提供一個分散式的網路學習架構, 動態對應越來越大的資料叢集, 另一方面, 考慮到回傳的資料為 LSTM 網路的參數, 而非使用者行為, 此方法可以減少對使用者隱私的侵害, 並減少中間網路的資料傳輸.

本文主要搬移自:  https://www.ericsson.com/en/blog/2020/12/5g-positioning--what-you-need-to-know 在 上一篇文章 中, 我們大略介紹了在 5G NR 中的定位應用, 其對應的技術進程, 以及在 5G NR 下增進定位精確度的機會. 在這一篇文章中, 我們將繼續說明在 3GPP R16 下的定位架構. 在 5G NR 中, 定義一個新的單元: Location Management Function (LMF), 用以作為定位的核心,  LMF 透過 Access and Mobility management Function (AMF) 收取感測資訊, 並透過 NLs 介面, 回報定位的結果, 如下圖所示: 來自:  https://www.ericsson.com/en/blog/2020/12/5g-positioning--what-you-need-to-know 在 5G NR 中, AMF 負責管理裝置的移動性與註冊, 對應於 4G 中 Control Plane 的功能, 並可以透過 NG-C 介面, 直接和基地台溝通, 取得相關的通道量測資訊, 如果想要知道 5G NR 架構下的細節, 可以參考: https://note-on-clouds.blogspot.com/2020/08/5G-Core-Network-SBA-1.html https://note-on-clouds.blogspot.com/2020/09/5G-Core-Network-SBA-2.html 另一方面, 資料的回傳是以 LPP (LTE Positioning Protocol) 和 LPPa (LPP Annex) 的格式, 主要是透過量測傳送訊號中特殊的 Resource block 來取得訊號強度, 對於 Downlink 來說, UE 觀測基地台的 PRS (Positioning Reference Signal) 訊號, 對於 Uplink 來說, 則是基地台觀測 UE 的 SRS (Sounding Reference Signal) 訊號, 考慮到有小基地台密集佈建的情況, 相鄰的小基地台將使用不同的 PRS 排列, 同時, SRS 訊號也會覆蓋所以頻寬, 以增加小基地

本文主要搬移自:  https://www.ericsson.com/en/blog/2020/12/5g-positioning--what-you-need-to-know 在通訊的進展中, 定位技術的發展一直是重要, 但是進度緩慢的一塊, 在室外的環境中, 我們通常可以用 GPS 取得 5 公尺左右的誤差, 但在室內或是城市的環境中, 卻一直缺乏一種良好的方式進行定位. 在過去 4G 的時代中, 考慮大基地台的配置, 著重於(室外)訊號的覆蓋,  對於定位資訊的要求, 只有在跨基地台移動 (換手) 時出現, 因此, 只需要室外環境數公尺的定位需求就可以滿足, 但是在 5G 的架構下, 由於 (1) 小基地台的布建, 增加換手頻率, (2) mmWave (26 GHz) 通訊帶來的波束指向問題, 需要使用者的位置資訊, (3) V2X 車聯網通訊的低延遲需求, 也引入車間相互定位的需求, (4) 企業專網與工業 4.0 的 IoT 環境, 引入對"物"的精確定位需求, 以上 5G 的新興應用層面, 推動定位技術在 5G 中的重要性, 從過去的加分角色, 變成 5G 網路中必須的技術. 來自:  https://www.ericsson.com/en/blog/2020/12/5g-positioning--what-you-need-to-know 考慮到定位的不同應用需求以及其技術限制, 在 Ericsson 這篇文章中, 將應用場域按照定位需求, 分三個等級:  1-10 cm (cemtimeter), 10~100 cm (Decimeter), >100 cm (meter), 並對應於: 室內工業物聯網, V2X 車載網路, 以及行動通訊 (Mobile broadband, MBB), 其中, MBB 的應用與技術和 4G 類似, 使用 DL-TDoA 的技術與訊號強度 (RSRP) 為主, DL-TDoA 技術透過使用者 (UE) 回報量測值, 並以三角定位方式求得位置, fingerprinting 則是利用收集得訊號強度進行比對並定位, 進入 Decimeter 等級主要是引入 GPS 的相關技術 (GPS-RTK, AGPS),  並搭配車上的感測器, 以及路邊的裝置 (road-side unit) 進行定位的

本文主要搬移自:  https://blog.3g4g.co.uk/2020/10/positioning-techniques-for-5g-nr-in.html 針對 3GPP R16 對於定位的更新, Qualcomm 總結如下: Release 16 supports multi-/single-cell and device-based positioning, defining a new positioning reference signal (PRS) used by various 5G positioning techniques such as roundtrip time (RTT), angle of arrival/departure (AoA/AoD), and time difference of arrival (TDOA). Roundtrip time (RTT) based positioning removes the requirement of tight network timing synchronization across nodes (as needed in legacy techniques such as TDOA) and offers additional flexibility in network deployment and maintenance. These techniques are designed to meet initial 5G requirements of 3 and 10 meters for indoor and outdoor use cases, respectively. In Release 17, precise indoor positioning functionality will bring sub-meter accuracy for industrial IoT use cases. 簡單來說, R16 定義了一個新的參考訊號 (PRS), 用以支持定位技術: RTT, AoA/AoD, TDOA, 並放寬了同步的要求. 在 R16 中, 針對定位的目標為: (室內) 3 公尺, (室外) 10 公尺 的定位精確度. 針對精密室內定位的需求 (公

在上一篇文章中, 我們介紹了 Servlet 架構下的編譯環境, 並以範例說明如何產生一個網頁回應. 然而, 對於 RESTful API 而言, 另一個主要的需求即是作為 API 介面, API 的全稱為: Application Programming Interface, 主要的用途就是提供一個介面, 讓不同應用程式透過網路溝通, 簡單來說, 像是一個服務的窗口, 並定義該窗口對應的功能與服務. 另一方面, JSON 則是一種資料封裝格式, 可以把資料以 key-value 的方式, 組成 JSON 物件, 進行傳送. 來自:  https://docs.aws.amazon.com/zh_tw/sdk-for-javascript/v2/developer-guide/working-with-json.html 為了利用 Servlet 提供 JSON 的解析與回應, 我們需要章中, 我們介紹了 Servlet 架構下的編譯環境, 並以範例說明如何產生一個網頁回應. 然而, 對於 RESTful API 而言, 另一個主要的需求即是作為 API 介面, API 的全稱為: Application Programming Interface, 主要的用途就是提供一個介面, 讓不同應用程式透過網路溝通, 簡單來說, 像是一個服務的窗口, 並定義該窗口對應的功能與服務. 另一方面, JSON 則是一種資料封裝格式, 可以把資料以 key-value 的方式, 組成 JSON 物件, 進行傳送. 為了利用 Servlet 提供 JSON 的解析與回應, 我們需要 import org.json.*; 做為參考的 library, 範例程式可以參考:  https://blog.csdn.net/CapMiachael/article/details/72930357 import java.io.BufferedReader;  import java.io.IOException;  import java.io.PrintWriter;  import javax.servlet.ServletException;  import javax.servlet.http.HttpServlet;  import javax.servlet.http.Http

在 上一篇文章 中, 我們建立了 Servlet 的編譯環境, 接著, 我們就從最簡單的 helloworld 開始, 介紹如何撰寫第一支 Servlet 程式. 以下是編譯環境中的路徑: 網頁根目錄: /var/lib/tomcat8/webapps/ROOT/ tomcat8 library 目錄: /usr/share/tomcat8/lib/ tomcat8 log 目錄: /var/lib/tomcat8/logs/ 首先, 我們要先定義 Servlet API 的入口, 此文件位於: /var/lib/tomcat8/webapps/ROOT/WEB-INF/web.xml 我們將內容填入如下: <web-app> <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>HelloWorld</servlet-class> </servlet> <servlet-mapping> <servlet-name>HelloWorld</servlet-name> <url-pattern>/HelloWorld</url-pattern> </servlet-mapping> </web-app> 在文件中, 定義了 API 的路徑 ( servlet-mapping ) 以及對應的 Servlet 程式 ( servlet ), 透過這兩個設定, 我們就建立了 Servlet 與 API Server 之間的呼叫關係, 接著, 我們進行 helloworld 的 Servlet 程式撰寫, 以下為範例: import java.io.*;  import javax.servlet.ServletException;  import javax.servlet.http.*;  public class HelloWorld extends HttpServlet  {       static final long serialVersionUID = 42L;    

在 之前的文章 中, 介紹了如何用 node.js 快速建立 API Server,  然而, 由於效率問題, node.js 並不是一個穩定的架構用以作為 API Server, 同時, JSON Server 本身實作的架構, 依賴對檔案的讀寫, 對於大量存取的 API 實作來說, 容易造成 IO 的消耗, 考慮到上述因素, 我們便開始研究其他 API Server 的實作方式, 在本篇介紹中, 便以 Java Servlet + tomcat8 作為實作的平台. 關於 Java Servlet 是 Java 語言中的一種特殊類別, 用 Java 編寫的伺服器端程式, 可以透過與使用者的互動, 動態產生網頁, 對於 API Server 來說, 主要的功能則是繼承自: javax.servlet.http.HttpServlet 另一方面, tomcat 則是一開源的 HTTP 伺服器, 支援 Servlet 與 JSP, 在我們的實作中, 我們使用 ubuntu 16.04 作為基礎的作業系統, 並使用 tomcat8 作為網頁伺服器 (參考: 此文 ). 安裝 tomcat8 的開發環境: sudo apt-get install tomcat8 sudo apt-get install tomcat8-docs tomcat8-examples tomcat8-admin tomcat8 的開啟/關閉/重啟: systemctl start tomcat8 systemctl stop tomcat8 systemctl restart tomcat8 安裝好 tomcat8 之後, 會使用預設的服務埠 (8080), 連入: http://127.0.0.1:8080 之後, 我們可以看到下方頁面: 其中, 紅框處為網頁目錄的位置,  此目錄也是我們之後開發 Servlet 程式的相對根目錄, 藍框處標明了套件安裝的路徑, 其中, 這兩個路徑我們之後都還會用到, /usr/share/tomcat8/lib/ 有用以 compile 的 library, /var/lib/tomcat8/logs/ 則保存紀錄檔, tomcat8-examples 則提供一些 Servlet 的範例程式, 可以參考. 我們在此整理一下開發環境的重要目錄: 網頁根目錄:

在 上一篇文章 中, 我們介紹了 802.1AS 如何選擇同步源, 並顯示在一個大型網路中, 如何標定每一個實體埠的角色. 在這篇文章中, 我們將由透過訊號源角色定義的網路拓譜出發,  研讀在此網路拓譜下, 802.1AS 如何提供更精密的同步, 我們先從下圖出發: 來自:  https://www.ieee802.org/1/files/public/docs2008/as-nfinn-fast-master-select-0408-v2.pdf 在圖中, 我們定義了不同埠的角色, 根據這些角色, 我們就可以得知同步訊號的流向, (簡單來說, Master是同步訊號流出, Slave是同步訊號流入) 在定義完每一個埠的不同角色後, 我們可以根據封包的流入/流出定義相對時間, 如下圖所示: 來自:  https://www.ieee802.org/1/files/public/docs2008/as-nfinn-fast-master-select-0408-v2.pdf 在上圖中, 我們可以看到對於時間同步產生延遲的三個因素, 第一, 封包的處理時間, 此時間為節點上處理所需要的時間, 和節點硬體相關, 第二, 封包的排隊延遲, 此時間和每個埠上的流量相關, 越多封包會有越高延遲, 第一個延遲在相同路徑的前提下, 可以透過 NTP 估測並抵銷, 第二個延遲則無法在 NTP 下進行處理. 在 802.1AS 中為了提供更精確地同步機制, 使用硬體計算延遲時間, 其方法為對每一個封包打印進入時間 (T_in) 以及送出時間 (T_egr), 透過其兩個時間差, 以及傳送到該節點的連結延遲 (T_link), 此延遲時間可以利用類似 NTP 的方式估測, 根據上述的量測量以及同步源的時間 (now), 更新送出去的時間 (now'), 此時間就會變成下一節點用以同步的時間. 在 802.1AS 中, 透過每一個節點更新更精確地同步時間 (now'), 對於每一個節點, 都可以參考上一個節點的時間 (now), 因此, 此同步問題就減化成兩節點間的同步問題, 當然, 此描述稍微簡化了 802.1AS 的機制,  事實上, 802.1AS 還會根據震盪器時脈誤差,  提供更精確的時間 (now') 估測.

在 上一篇文章 中, 我們介紹了 NTP 同步機制, 考慮到 NTP 機制的簡單且能以效率的完成同步, 此機制被實作於電腦網路中, 透過指派同步的時間伺服器,  Windows 和 Linux 就可以利用 NTP 相同機制處理同步系統時間, 此同步的系統時間, 除了顯示於使用者, 也用以防範網路攻擊. 然而, NTP 機制有兩個主要的缺點, 第一, 當有許多同步訊號源 (時間同步伺服器) 時, 要向哪一個對時? 第二, NTP 協定假設封包來回的時間對稱, 這個假設在區域網路中成立 (來回路徑一致, 延遲也會相同),  但在大型網路中, 封包來回的路徑可能不一, 也會造成不同程度的延遲. 在 802.1AS 中就針對這兩個限制進行一些調整, 這邊先提及一下, 802.1AS 的前身是 IEEE 1588, 也稱為 PTP (Precision Time Protocol), 所以當看到 IEEE 1588 和 PTP 時, 事實上, 就想像其類似於 802.1AS 的機制, 802.1AS 針對多個時間源的問題, 稱為: Grand Master selection, 在此機制下, 時間同步伺服器透過發出 Announce 訊號通知, 並有兩個行為: 第一, 在沒有聽到更好的 Announce 訊號時, 發出 Announce 訊號, 第二, 在收到更好訊號源發出的 Announce 訊號時, 作為被同步的裝置, 透過 Announce 訊號的傳播, 便可以選出網路中最好的同步訊號源, 並保有一定的強韌性, 如下圖所示: 圖片生成自:  https://www.ieee802.org/1/files/public/docs2008/as-kbstanton-8021AS-overview-for-dot11aa-1108.pdf 值得注意的是, 在 802.1AS 中, 所謂好的同步訊號源,  可以根據管理者的優先權設定, 以及時間訊號的來源 (例如: GPS) 進行比較, 會將自我認知的好壞, 轉換成一向量 (越小越好), 放在 Announce 訊息中, Announce 訊息中也會包含訊號源的 MAC 位址, 作為識別, 透過此選擇的機制, 網路中的個節點將產生一個樹狀結構 (如下圖),  此樹狀結構將影像後續的時間更正機制. 來自:  https://www