Castle on a Cloud

在 2023 年的最後一天, 也就把這一系列文章做個總結吧, 近來幾個月, 因為工作的堆積與忙碌, 許多手邊待看的文章都是半完成品狀態, 尚未系統性的整理, 時間的缺少, 與缺乏整理, 多少也影響了撰寫的文章品質... 新的 2024 年, 雖說預期應該是越來越忙碌,  但還是希望可以分享更多有趣的無線通訊內容. 雖然, 在 blogger 文章中, 盡量不提演算法部分的內容, 不過對於通訊問題來說, 在進行問題討論前, 最重要的兩件事就是: 1) 定義模型: 描述觀察值與待測物之間的關係 2) 定義情境: 給定位提的討論設定, 提供公平比較的基準 在上一篇文章中, 我們說到網路節能的目標情境, 雖說不太完整, 但至少有些方向, 在這一篇文章中, 我們就來討論一下基地台的能源消耗模型. 首先, 為什麼是基地台? 如前所述, 無線接取網路佔 80% 能源消耗, 而基地台又是其中的要角, 所以, 當討論能源消耗模型時, 自然是從基地台下手. 至於此能源模型的定義, 則是由 3GPP TR 38.864 進行, 其文件名稱為:  “Study on network energy savings for NR (Release 18)” 來自: MTK 吳威德博士演說 在 3GPP 的能源消耗模型中, 按照慣例, 不會給每個參數明確數值, 但是, 我們可以看到, 有哪些因子會影響基地台的能源消耗: 其中, 我們先看功率項, 包含: 靜態 (static), 天線 (ante), 資源分配 (joint), 靜態功率可以想像是基地台開機就需要的作工, 包含: 冷卻, 電源供應, 等. 天線功率則包含每一組天線的射頻模組功耗, 包含, 放大器, 振盪器等, 最後, 資源分配相關功率則包含了使用的頻譜大小, 以及頻譜功率密度. (*PSD = Power Spectral/Spectrum Density) 此三個項次, 又可以對應於四種節能的方式: 空間: 漸少活躍的天線個數, 天線功率對應的 Sa 下降. 時間: 有一段時間不傳資料, 等校的 Sa 下降. (若是關機可以省下靜態功率) 傳輸功率: 減少天線的發送功率, 頻譜功率密度對應 Sp 下降. 頻寬: 減少使用的通訊頻寬, 頻譜大小對應的 Sf 下降. 透過上述能源使用模型, 由於 Sp 和 Sf 都...

在前述的文章中, 我們介紹了能源節省的各種面向, 然而, 針對一個工程問題, 我們首先要定義的是如何評量節能效率, 換句話說, 我們要定義在甚麼情境下進行節能效率的評估, 我們以兩份 ITU 文件作為參考: ITU-R M.2410-0, ITU-R M.2412-0 在第一份文件 (ITU-R M.2410-0), 名稱為: "Minimum requirements related to technical performance for IMT-2020 radio interface(s)", 定義了 IMT-2020 (5G NR) 中, 對於無線技術 (Radio Interface Technology, RIT) 所需要作出的評估, 其中, 關於能源效率的部分定義於 4.9 Energy efficiency, 以下是原文: Network energy efficiency is the capability of a RIT/SRIT to minimize the radio access network energy consumption in relation to the traffic capacity provided. Device energy efficiency is the capability of the RIT/SRIT to minimize the power consumed by the device modem in relation to the traffic characteristics. Energy efficiency of the network and the device can relate to the support for the following two aspects:     a) Efficient data transmission in a loaded case;     b) Low energy consumption when there is no data. Efficient data transmission in a loaded case is demonstrated by the average spec...

除了 3GPP 定義了網路節能的框架外, O-RAN 組織也定義了對應的節能功能, 稱為 Network Energy Saving (NES), 在 O-RAN 定義的架構下, NES 又可以分成以下的應用案例: Carrier and Cell Switch Off/On → 負載低時, 不影響 QoS 下, 關閉 Carrier 或是 Cell RF Channel Reconfiguration Off/On → Beamforming 下, 關閉部分 RF 陣列 Advanced Sleep Mode Selection → O-RU, O-DU, O-CU 的 Sleep Mode 選擇 O-Cloud Resource Energy Saving Mode → O-DU, O-CU 計算資源的能源節省 在 O-RAN 的 Use Case 中, 多數的功能都在 3GPP 的定義功能下, 但是相比 3GPP 的大基站節能框架, O-RAN Use Case 更著重在小基站的環境, 較不著重在底層無線傳輸的調整, 而著重在無線的設定調整, 因此, 在前兩個子項中, O-RAN 定義了不同層級的 ON/OFF 節能, 從 Cell, Carrier, RF array, 從大到小, 提供不同精細度的調整. 第三個子項, 則對應時間上的節能, 並實作於 3GPP 的框架中, O-RAN 扮演的角色像是不同基站的協調者, 同時滿足接取與解能的需求. 第四個子項, 則是目前看到 O-RAN 特有的項目, 透過 O-Cloud 與虛擬化技術, O-RAN 還可以調整 O-CU/O-DU 的計算資源, 提供計算資源上的節能成果. 針對 NES 的功能, O-RAN 也定義了對應的統計指標 (KPI), 包含: O-RU specific KPIs: Energy efficiency and power consumption  O-CU/O-DU hardware & software/ O-Cloud software & platform KPIs 在 O-RAN 所定義的 KPI 中明顯分成兩項:  RU 代表硬體的無線功率節省, O-CU/O-DU 代表的軟體耗能, 基於 KPI 的定義, O-RAN 也提供了資訊交換的流程...

在上一篇文章中, 我們介紹了網路節能的基本概念, 並從 Nokia 的角度出發, 說明了網路節能的好處與必要性, 接下來, 我們將基於聯發科吳威德博士在陽明交大的演講, 介紹從 3GPP 角度出發的網路節能功能探討. 在吳博士的演講中, 針對網路節能的必要性提出了兩個說明: 1) 5G NR 的通訊通率上升: 5G NR 中, 為了增加通訊容量, 大量使用多天線技術 (massive MIMO), 多天線技術, 尤其在 mmWave 的頻帶上, 可以有效增加通訊效能, 使得 5G 技術相對於 4G 更加耗電 (2 倍的通訊容量, 需要 8 倍天線個數), 根據 Ericsson 的調查, 從 2020 到 2030, 用於通訊能源的消耗將成長 61 倍.  2) 電費對於電信營運商的營運成本: 在現在電信營運商的營運成本中, 約略 20-40% 來自於電費, 以台灣三大營運商而言, 一年的電費約略是 20 億元, 在可見的未來, 由於綠能以及碳排稅的需求,  電費佔電信營運商的成本可能會將近 5 成, 甚至造成負擔. 考慮到上述的節能需求, 3GPP 從 R17 開始討論網路節能的功能, 在技術上的討論可以分成 3 個方向: 時間, 空間/功率, 頻率, 整體的進程可以以下圖表示: 來自: MTK 吳威德博士整理 針對每一項技術的細節, 我們會再找時間詳細介紹, 我們先從概念上了解 3GPP 在節能上的功能設計: 時間: 在基站加入類似手機休眠功能, 基地台也可以休眠, 根據 loading 決定工作時間 空間/功率: 透過功率和 beamforming 調整, 根據使用者位置與需求, 調整無線設置 頻率: 根據負載調整基地台的頻率使用,  類似反向的 Carrier Aggregation (CA) 在整體功能上, 由於 RF 是主要的能源消耗的部件, 因此, 直接的調整 RF 開關 (時間上多工), 或是 RF 功率調整 (空間上多工), 都比起頻率上多工來得更有節能效果, 整體的比較如下圖表: 來自: MTK 吳威德博士整理 以 3GPP 的角度來看,  主要的目標在於定義使用者 (UE) 和基站的共同協作機制, 因此, 特別著重的情境仍是大基站 (marco cell) 對使用者的節能功能,...

5G 網路尚未普及, 學界和業界已經開始討論 6G 的進展, 相較於 5G NR (New Radio) 的雄心壯志, 6G 的目標相對保守, 目前較確定技術變革的主軸大概有三項: NTN (Non-Terrestrial Networks) 網路: 包含低軌衛星, 無人機網路 ISAC (Integrated Sensing and Communications): 結合感知與通訊, 更動態的資源配置 Sustainable Networks: 對抗由於 mmWave 產生的高耗能與碳排放帶來的營運成本 其他, 還有一些尚待討論的項目, 像是: 更寬廣的頻寬 (Tara Hz), 智慧反射板 (RIS), 等. 當然, 也包含了 AI/ML 模型的引入, 用以支援這些新穎技術. 在上述的技術中, 最直接可用的就是 Sustainable Networks 帶來的節能, 不過, 我們首先要回答一個問題: 為什麼行動網路需要節能? 先撇開甚麼 "我們只有一個地球" 不談, 在 6G 這時刻強調節能的原因有兩個: mmWave 帶來的高能耗通訊成本, 大幅提升 RAN 端的能源使用 碳排稅對營運成本的疊加, 從固定成本變成累進成本 基於上述原因, 在 3GPP 討論 6G 的進程時,  營運商 (也是 3GPP 的主力) 自然對此議題投入大量興趣, 也很快的定調成 6G 的技術主軸之一. 那麼第二個問題是: 我們真的可以節能嗎? 可以節省多少能源? 在過去, 行動網路只考慮了手機 (裝置端) 的節能, 針對 RAN 端 (基地台, 射頻元件等) 的態度是反正有線不必考慮, 當節能需求被提出時, 第一個去實現的就是 Nokia/Ericsson 等業者, 而這些業者也針對節能提出一街解決方案, 我們以 Nokia 的為例,  根據 Nokia 的調查, 行動網路中多數的資源用於 RAN 端 (80%), 但是, 整體用於實際通訊的能源只有 15%. 圖片經作者修改, 原始來源: Nokia blog 當然, 這並不是說 85% 的能源都浪費了, 畢竟要知道使用者的通道, 要維持基本的通訊連線都需要資源消耗, 但是 85% 的巨大落差也表示了在網路節能上有巨幅的改進空間. 針對不同種類的能源消耗, 進行節能也需要不同解方, 比如說基地台的散熱能源...

在之前文章中, 我們仔細地討論了 Indication 所需要做的修改, 在這篇文章中, 我們轉而討論另一種 E2 協定: Control, Control 在 O-RAN 的定義中, 用以乘載 RIC 對 E2 Node 的控制信令, 不同於 Indication 在 O-RAN SC 中有完整的定義, Control 的開源實作的進度較慢, 這可能主要來自兩個原因: Indication 可以回傳的資訊數量與格式相對明確, 可以定義並以模擬器實作 Control 所需承載的資訊需要硬體支援, 並和 Use Case 相關 而針對第二點, 也正是 FlexRIC 的優點, 在擁有 Open Air Interface 的硬體平台支援下,  FlexRIC 可以更容易實作 Control 的功能, 並結合硬體進行展示. Control 和 Indication 相同, 可以視為一個獨立定義的 Service Model, 需要預先定義其資料格式, 考慮到 O-RAN SC 並未有詳細定義實作, 我們通常以 plain-text 的方式定義 Control 的資料格式,  下圖為 FlexRIC 所實作的 Control 流程: 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric 在上圖中, 我們可以看到 Control 和 Indication 都需要 E2 和 E42 註冊流程, 這兩步驟建立起 E2 Node 以及 xApp 之間的通訊連線, 而對於 Control 和 Indication 兩者設計差異, 主要在於 Indication 是定期驅動, 所以需要設定驅動的週期, 相對的 Control 是依據 RIC 上的事件驅動, 送出 Control Request, 在 E2 Node 執行完後送回 Control Acknowledge, 這樣的設計邏輯在於 E2 Node 的回報應是頻繁且規律的, RIC 上的 xApp 透過這些收集的資料以及 AI/ML 的運算, 只有在必要的時候, 才透過 Control 更改 E2 Node 上的參數設定, 畢竟任何針對網路的修改都需要硬體反應時間,  同時, 太頻繁的修改也將導致網路的不穩定性, 要審慎進行.

在之前的說明中, 我們大致介紹了一個 Service Model (SM) 的建立, 以及所對應要進行的修改流程, 包含: SM 定義, RIC 以及 xApp 部分, 在這篇文章中, 我們會介紹一下其對應的流程以及背後參數設定原因, 首先, 我們先回顧一下在 O-RAN 架構中的 Indication 資料結構,  如下圖所示: 來自: Polese, Michele, et al. "Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges." IEEE Communications Surveys & Tutorials (2023). 在 O-RAN 的框架下, 其 Indication (其他型態也是) 傳送的資料結構分成兩層: E2 AP (Application Protocal): 可以視為信封, 標記了識別資訊與註冊流程 E2 SM (Service Model): 可以視為信紙, 收送雙方定義的資料結構 在 FlexRIC 中, 可以找到 xApp 的範例程式如下: https://gitlab.eurecom.fr/mosaic5g/flexric/-/blob/master/examples/xApp/c/monitor/xapp_kpm_moni.c 我們接下來會大略介紹一下程式碼, 並對應於 FlexRIC 的流程圖: 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create%20a%20xApp 以下是 xApp 接收 Indication 的程式 (稱為 monitor), 我們取最簡單的 xapp_kpm_moni.c 作為範例, 並以藍字為註解: examples/xApp/c/monitor/xapp_kpm_moni.c #include "../../../../src/xApp/e42_xapp_api.h" // FlexRIC 的 API #include "../../../../src/util/alg_ds/alg/defer.h" #include ...

在完成 Service Model 的定義之後, 我們需要透過程式對所定義的 Service Model 進行操作, 考慮到 FlexRIC 的實作架構, 我們在修改 xApp 和 E2 Agent 的程式前, 要先修改 FlexRIC 相關的程式, 以提供 xApp 和 E2 Agent 串接的支援, 在此實作中, 我們以 Indication 作為開發的應用, 此應用中, xApp 負責送出訂閱 Indication 的需求, E2 Agent 則將數值填入 Indication Message 中, 並定期發送. 在 FlexRIC 官方網站中, 提供教學的連結如下: https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create%20a%20xApp https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Files%20need%20to%20be%20modified%20for%20developing%20xApp%20C%20binding 在 FlexRIC 中, 整體的資料交換流程如下: 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create%20a%20xApp 在上述的流程中, 我們可以歸類於以下 5 個步驟: E2 Agent 透過 E2 Setup 向 FlexRIC 註冊 (ID, 以及所支援的服務) xApp 向 FlexRIC 進行註冊 (為自定義的 E42 介面) xApp 向 E2 Agent 註冊 Indication 服務 (Subscription Request) E2 Agent 根據訂閱的資訊以及時間間隔, 進行資料回報 xApp 收到資料將數值存入 SQLite (不是標準的 O-RAN 流程, 在此先略去) xApp 向 E2 Agent 刪除 Indication 服務 (Subscription Delete Request) 在 FlexRIC 對應的 c-code 程式中, 為了加入一個新的 Service Model, 我們也要進行相對應的修改, 包含三個部分: xApp, RIC, 和 E2 Agent, 對應的資料夾位置為:...

在定義好 Service Model 的 Indication 之後, 我們接著去修改 Encode/Decode 的相關程式, 位置的路徑一樣是位於: ~/flexric/src/sm/new_sm 在此路徑下, 有兩個資料夾: dec, enc, 分別對應於 decode 和 encode 的功能 其中, 我們也可以看到, 在 encode/decode 中也對應了三種格式: ASN.1, fb (flatBuffer) 以及 plain, 對應於在 SM 建立的格式, 考慮到我們使用 plain 作為此次的範例, 相關的檔案就包括: enc/new_enc_plain.h, enc/new_enc_plain.c, dec/new_dec_plain.h, dec/new_dec_plain.c, 其中, header 檔 (.h) 只定義了程式,不須修改, 和 SM 相關修改的範例如下: enc/new_enc_plain.c: // 根據定義的 SM 資料格式長度宣告記憶體大小 // 並把 SM 中的資料直接 memcpy 至傳送的資料格式中 byte_array_t new_enc_ind_msg_plain(new_ind_msg_t const* ind_msg) {   assert(ind_msg != NULL);   byte_array_t ba = {0};   size_t const sz = sizeof(ind_msg->len) +                    sizeof(new_ng_u_tunnel_stats_t)*ind_msg->len +                    sizeof(ind_msg->tstamp); // 長度為 SM 定義的格式加上 timestamp 長度 //  printf("Size of the byte array = %lu\n", sz);   ba.buf = malloc(sz);  ...

在 FlexRIC 的架構中,  其 Service Model (SM) 包裝成 library 供 xApp 和 E2 Agent 使用, 因此, 在使用 SM 進行資料交換前, 必須先定義 SM, 並將定義好的 SM 封裝, 使得 xApp 和 E2 Agent 皆可使用. 詳細的說明, 可以參考官網建立 SM 的教學文件: https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create-a-service-model 來自:  https://gitlab.eurecom.fr/mosaic5g/flexric/-/wikis/Create-a-service-model 為了要建立 SM, 首先我們要建立相對應的檔案系統, 方法為執行: cd flexric/src/sm && python3 gen_sm.py 執行後輸入 SM 名稱 (default 為 new), 產生 new_sm 的資料夾與對應程式, 其資料結構如下圖所示:   產生完新的 SM 之後, 我們就要修改 CMakeLists, 將新的 SM 加入編譯路徑, 一共有兩層 CMakeLists.txt 需要修改: ~/flexric/src/sm/CMakeLists.txt ## 在此文件中, 加入新的 SM 路徑: add_subdirectory(kpm_sm_v2.02) .... add_subdirectory(new_sm) #在文件尾端加入產生的資料夾名稱 ~/flexric/CMakeLists.txt ####### ## Service Models ####### # KPM service Model encoding definitions set(SM_ENCODING_KPM "ASN" CACHE STRING "The KPM SM encoding to use") set_property(CACHE SM_ENCODING_KPM PROPERTY STRINGS "PLAIN" "ASN" "FLATBUFFERS") message(STATUS "Selected...

這一篇文章主要是介紹如何在 VM 中建立一個 FlexRIC 的測試環境, 主要依據 FlexRIC 的官方教程: https://gitlab.eurecom.fr/mosaic5g/flexric#1-installation 在 FlexRIC 的官方網站中, 有許多有用的資源, 可以參考. 和 O-RAN SC 的網站相比, 指引較為明確. 在以下的操作中, 我們使用 VirtualBox 7.1 的版本, Linux 的基底採用 ubuntu 20.04 的版本進行. * VirtualBox 6.X 版本對 ubuntu 20.04 有機率遇到顯示的問題 * 由於對 gcc 的版本需求, 需要 ubuntu 20.04 以上的版本 以下是 FlexRIC 的相依套件的版本需求: CMake: 3.15, Python: 3.8 SWIG (提供 python, Java 操作介面): 4.0 [A] 我們就先從 CMake 開始, 參考此份安裝文件: https://apt.kitware.com/ 1) 安裝認證套件與 wget sudo apt-get update sudo apt-get install ca-certificates gpg wget 2) 取得密鑰 wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | gpg --dearmor - | sudo tee /usr/share/keyrings/kitware-archive-keyring.gpg >/dev/null 3) 將 CMake 套件來源放入安裝庫 echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.gpg] https://apt.kitware.com/ubuntu/ focal main' | sudo tee /etc/apt/sources.list.d/kitware.list >/dev/null echo 'deb [signed-by=/usr/share/keyrings/kitware-archive-keyring.g...

在 O-RAN 的架構下, 目前主流有兩個開發的平台: OSC (O-RAN Software Community): O-RAN 官方的開源軟體, 基於 K8S 進行實作, 持續更新不同版本:  https://wiki.o-ran-sc.org/ SD-RAN: ONF 軟體開發, Intel 提供支援硬體支援 (FlexRAN), 也是基於 K8S 進行開發: https://docs.sd-ran.org/master/index.html 此平台相較於 OSC, 更著重於 xApp 的開發, 尤其是和 SON 的功能整合 今天要介紹的 FlexRIC 相較之下就較為小眾, 背後發展的組織為 EURECOM, 也是 Open Air Interface (OAI) 的開發者, 因此, FlexRIC 平台最佳的硬體支援也就是 OAI 的 5G 基地台. EURECOM 的生態系 ( https://openairinterface.org/mosaic5g/ ) 如果這只是一個小眾的實作, 為什麼我們要特介紹呢? 事實上, FlexRIC 平台在作為實驗平台上有下列兩個優點: 硬體支援性: 相較 Intel FlexRAN 的平台, OAI 的環境較好搭建與取得, 這也是在缺乏商用 Small Cell 的情況下, 可能最簡單的實作方式 架構的簡易性: 相較 OSC 和 SD-RAN 以 K8S 的 RIC 實作, FlexRIC 使用平行的 c 程式進行 RIC 實作, 較容易 trace code 與修改. 以下是 FlexRIC 的架構圖 (我們之後還會看到許多次): FlexRIC 的架構 (來自: https://openairinterface.org/wp-content/uploads/2022/07/2022-07-13-EURECOM-FLEXRIC-SLIDES.pdf ) 在 FlexRIC 的架構中, 和 OSC 與 SD-RAN 不同, 是將兩者以 library 的方式分享, 而沒有透過 K8S 的機制, 將不同的 xApp 與管理單元隔離開來, 這樣的架構的好處, 是可以透過一個預先定義的 SDK, 簡化布建的複雜度, 但是相對的, 當今天服務模型改變, 整個 SDK 也需要重新定義與修改, 極端一點的說法, 就是當一...

在介紹此 Use Case 之前, 我們可能要先說明一下甚麼是 Network Slicing, Network Slicing 的概念, 是將網路分成許多虛擬的通路, 而每一條通路, 都有其分配下去的資源 (頻寬, 傳送優先權等), 因此, 對於有 QoS 需求的使用者, 就可以藉由非屬不同虛擬通路, 達成使用者的通訊分級, 並確保安全性與通訊品質. 這樣的概念, 在電腦網路中十分盛行, 尤其針對有線網路部分, 我們可以藉由 VLAN (Virtual Local Area Network) 的設置, 串起在不同國家的辦公室, 也可以賦予不同 VLAN 優先權進行傳輸. 假如我們想要把類似的概念套用在行動網路上, 我們就必須套用於行動網路中的兩個主要的部份:  Core Network (核心網路), Radio Access Network (無線接取網路). 原圖來自: https://teppeilog.com/whatisnwslicing_e/ 首先, 對於 Core Network 的 Sciling, 由於是有線網路的設置, 所以在現有的系統架構中, 就已有許多實作討論, 以 5G NR 網路來說, 通常會有 eMBB, URLLC, mMTC 這三種網路, 加上一個控制網路, 前三者是不同 QoS 的分群, 第4種是用來傳送網路的控制信令. 然而, 在實際的網路中, 無線通訊資源的分配實際上是在 RAN 中分配, (* 使用者實際透過 RAN 分配的 resource block 進行通訊) 因此, 若我們要真的進行針對使用者的通訊進行保證, 還必須針對 RAN 進行相對應的設置, 就稱為: RAN Slicing. 為了實作此功能, RAN 也必須向 Core Network 確認 Slice 的設置, 並據此進行 RAN slice 的設計.   在 O-RAN 的系統中, Core Network Slice 的資訊儲存於 SMO 中, 這些資訊以 SLA (Service Level Agreement) 的方式表示. 除了 Core Network Slice  的資訊之外, 為了對 RAN 網路進行配置最佳化, O-RAN 還收集了一些其他資訊, 主要包含下列兩項: 網路的效能參數 Performance M...

在 2022 年 11 月,  O-RAN 組織加入的一個新的介面稱為 Y1 interface, 此介面提供 Near-RT RIC 不只是可以透過 E2 介面和 RAN 中的元件溝通, 更可以繞過 Non-RT RIC 和 SMO 提供一個直接對外的方式, Y1 interface 和 RIC 和其他元件間的關係如下圖: 來自: O-RAN.WG1.OAD-R003-v08.00 (O-RAN Architecture Description) 在上圖中, 我們可以看到 Y1 interface 直接和 Y1 consumer 對接, 至於 Y1 consumer 可直接讀取 Near-RT RIC 的分析結果, 存取有以下兩種限制: Y1 consumers could be Application Functions (AFs) when they are in an O-RAN trusted domain.  The RAN analytics information could be provided to AFs in a secure manner via an exposure function. 在這邊給予一些解釋, 第一點限制了 Y1 consumers 必須在 O-RAN 的信賴網路內, 這邊的信賴網路通常就是 O-RAN 的內部網段 (或是預先設定過的內網), 若要提供第三方應用, 則必須透過曝光功能 (exposure function) 的方式進行, 這邊的曝光功能類似於 3GPP 定義的網路曝光功能 (Network Exposure Function, NEF), 基本想法即是保護 Y1 介面不會直接被外部網路存取, 而必須透過一信賴的元件轉傳, 透過這樣的機制, 可以確保遭受攻擊時, 不至於癱瘓整體的 Y1 服務. 在加入 Y1 interface 之後, Near-RT RIC 的架構可以表示如下圖: 來自: O-RAN.WG3.RICARCH-R003-v04.00 (Near-RT RIC Architecture) 在這份文件中, 我們可以更清楚的看到 Y1 interface 的實作方式, 基本上實作的邏輯會類似於 E2 和 A1 interface, 也就是: 透過 termin...

在 之前的文章 中, 我們介紹了 O-RAN 中室內定位的 use case, 在當時, 該 use case 仍定義在 WG1 的文件中,  只載明了動機與目的, 並沒有提出進一步的資料交換流程, 我們簡潔的整理如下: 目的: 改善原有 LMF 的定位框架, 提供低延遲定位響應 方法: 將定位計算放置於 xApp 中, 減少資料傳遞所需時間 在此框架下, 仍遺留下一些未解的問題, 像是: 定位需求由誰發起或轉達 (原有 LMF 架構中, 定義了 LMF 接收定位需求的機制), Near-RT RIC (xApp) 與 Non-RT RIC (rApp) 之間的分工, 等... 為了回答這些問題, 在 WG2 的更新文件中, 定義了兩個應用情境: Scenario 1: Only Near-RT RIC 在此應用情境中, 我們可以看到, 定位的計算是由 Near-RT RIC 負責, 量測的資料則主要由 E2 介面從 RAN 中取得, 至於定位的需求與回應, 則是由外部的應用 (也可以是核往) 所驅動, 在這邊值得注意的是, O-RAN 新定義了 Y1 介面, 提供一個 Near-RT RIC 和外界的溝通方式, 而不必透過 Non-RT RIC 轉介. Scenario 2: Only Near-RT RIC 在此應用情境中, 我們可以看到 Non-RT RIC 在其中的角色, 主要是透過 O1 介面收集資料, 並進行定位模型/演算法的訓練, 在與 Non-RT RIC 協作的情況下, xApp 也要支持模型的選擇與更新, 可能是考慮到定位的即時性, 定位的請求與更新, 仍是透過 Y1 直接和 xApp 溝通, 不過定位完的資訊也會存回 Non-RT RIC, 供其他應用取用.

 以下的圖片與部分說明來自 3GPP 標準會議現況與趨勢研討會 (4/11), 講題為: ETSI 可重構智慧表面群組報告初探 (A brief summary of ETSI Group Report) 報告者為: 陽明交大電信所 黃昱智 副教授. 對於一個通訊系統的研究中, 最重要的是要有一個共通的比較基礎, 讓大家可以進行演算法開發, 有一個標準可以進行演算法開發的比較以及討論的基礎, 對於 RIS 來說也是, 因此, ETSI 也討論了相對應的通道模擬基礎. 在理論上, 我們可以把通道模型表示如下: 相較於原有的通道模型, 通常是只討論基地台到使用者的通道, 在此通道的基礎下, 我們討論兩種通道模式: LOS (直視路徑), NLOS (非直視路徑), 相較於傳統的通道模型, 當 RIS 加入網路之後, 多增加了一條路徑, 也就是 RIS -> UE 的通道, 此通道就和 RIS 所設定的 config 相關, 在 RIS 設定中, 為了彰顯 RIS 的效應, 我們通常假設 RIS -> UE 的通道為直視路徑, 同時, BS -> RIS 也用有直視路徑, 透過此兩個直視路徑, 對抗 BS-> UE 的非直視遮蔽. 為了討論 RIS 的通道模擬, 我們先看一下傳統的通道模型, 在 3GPP 的架構下就針對 LOS 和 NLOS 的通道, 針對不同環境進行建模: 對於通道建模而言, 通常是基於實際場域的量測資料, 建立隨著路徑的衰減參數, 以及在該環境下的訊號變異量, 此兩個數值, 在物理意義上, 代表了訊號強度隨著距離的衰減, 以及無線訊號在該環境中, 由於多路徑與遮蔽效應, 造成的通道變異. 考慮到 3GPP 的通道模型在通訊領域中已取得廣泛的成功, ETSI 在 RIS 的通道建模上就想要直接複用 3GPP 的通道建模量測, 但是額外加上兩個項次, 表示 RIS 對於通道的影響, 如下所示: 在其通道模型中, 加入了一項用以表示透過 RIS 產生的衰減, 另一項, 則是表示透過 RIS 反射路徑的通道加乘, 基於上述的通道模型, ETSI 也做出了一些量測, 並提供初步的參數如上表. 考慮到 ETSI 對於 RIS 的通道建模仍在初期的階段, 不論是上述的修正參數項, 以及後續的參數估計與量測, 都仍未定. 事實上, R...

 以下的圖片與部分說明來自 3GPP 標準會議現況與趨勢研討會 (4/11), 講題為: ETSI 可重構智慧表面群組報告初探 (A brief summary of ETSI Group Report) 報告者為: 陽明交大電信所 黃昱智 副教授. 在 ETSI 分類中, 也把 RIS 的通道估測模型分成兩類: 第一類是將無線通道拆成三段: BS-UE, BS-RIS, RIS-UE, 如下圖所示: 在此模型中, 通常 BS-UE 的通常視為不存在, 以發揮 RIS 的效應. 這個通道模型是學術界喜歡的通道模型, 因為可以直觀的看出 RIS 相位變化對於接收端訊號的影響, 同時複用原本的 MIMO 通道模型, 延續之前通訊問題的討論框架, 在 RIS 的應用中, 主要也就是透過調整上圖中 RIS 的相位 (\Phi) 來最佳化系統, 使得系統有較佳的傳輸效能. 第二種通道估測的方法則將通道 (BS-RIS, RIS-UE) 視為一個整體, 並透過使用者的反饋的訊號強度 (RSSI, RSRP) 或是通道量測 (CSI) 進行估測. 考慮到在真實通訊系統中, RIS 通常作為一被動元件, 無法進行通道量測, 也因此, 上述將通道分離為 BS-RIS 與 RIS-UE 的方法, 較缺乏實作的可行性,  針對這種通道整體估測的方式, 對應於不同的 RIS 設定, 操作方法又可分三類: Element-wise RIS: RIS 每一個元件分開調整相位 Sub-suface-based RIS: 將 RIS 區分成多個子區塊 (sub-surface) 分開調整  Configuration-wise RIS: 根據設想的 beam pattern, 設計對應的元件相位 其原理與說明, 如下圖所示: 上述三種不同的 RIS 操作方式, 分別對應於不同的應用情境, 第一種可以產生最多元的通道變化, 但對應的訓練與回授資料較大, 第二種則對應於超大型的 RIS, 可以切割為多個子平面服務不同使用者, 第三種則對應於小型的 RIS, 有較簡單的操作方式, 可能作為 RIS 初始的應用案例.

以下的圖片與部分說明來自 3GPP 標準會議現況與趨勢研討會 (4/11), 講題為: ETSI 可重構智慧表面群組報告初探 (A brief summary of ETSI Group Report) 報告者為: 陽明交大電信所 黃昱智 副教授. 在目前 RIS 的發展中, 由於還在前期的探索階段, 3GPP 尚未進行標準的推進, 目前主要題討論發展的組織為 ETSI, 全名為: European Telecommunications Standards Institute, 雖然一開始是歐洲的電信標準組織, 不過近年已轉型為全球化標準組織, 對於 RIS 的標準化, 主要在兩份文件 (未完成, 未公開) 的文件: ETSI GR RSI 0002 (Jan. 2022) ETSI GR RSI 0003 (Spet. 2022) 而目前 ETSI 對 RIS 的規劃為: 先進行先期的研究, 之後提到 3GPP 標準討論. 最終標準化的制定的主要賽場, 應仍是 3GPP 的標準會議. 在 ETSI 的規劃中, RIS 的控制可以分成 4 個種類: Network-controlled RIS: 由 Network 收集 measurement 收集/處理, 以及 RIS 的設定 Network-assisted RIS: 由 RIS 進行 measurement 收集/處理, 由 Network 進行 RIS 的設定 Standalone RIS: 由 RIS 收集 measurement 收集/處理, 以及 RIS 的設定 UE-controlled RIS: 由被授權的 UE 收集 measurement 收集/處理, 以及 RIS 的設定 可以整理如下表格: 其中, 我們先來看第 1, 2 種, 和 Network 相關的控制種類, 此處的 Network 不是網路, 而應該是指遠端的控制器 (雲端, 核心網路, 等), 相對的, RIS 也有一個 RIS Controller, 也負擔部分控制功能. 其對應的系統架構圖如下: (由於是截圖, 解析度較差, 請見諒) 在此框架下, Network-controlled RIS 的應用情境中, RIS 的控制全部由遠方 (網路) 的單元進行控制,  RIS Controller 基本上就只是根...

在上一篇文章中,  我們談到 CSI-RS 在 beam management 中的作用, 主要是在 Beam Refinement 中提供通道係數的量測, 用以提供對 TX/RX 雙方更加合適的波束場型, 至於一開始的波束配置, 則由 SSB Burst 提供數個波束指向的 RSRP 資訊. 為了進一步了解其流程, 我們就介紹一下 SSB (Synchronization Signal). SSB 這個參考訊號在 4G LTE 時已出現, 主要包含兩個部分: PSS 與 SSS, 用以識別基地台的資訊. 有點像是 WiFi 的 Beacon, 廣播基地台的識別資訊, 讓使用者連入. 在我們之前的 文章 中, 也有介紹過, 就先不提 PSS 和 SSS 的部分. SSB 和 SSB Burst 在 5G 的系統中, 對 SSB 做了一些修改. 主要的原因是因為 5G NR 中對應了不同的頻寬,  同時, sub-6GHz (FR1) 以及 mmWave (FR2) 的不同物理特性, 也使得 SSB 的設計上和 LTE 有些許不同, 我們先專注在 SSB Burst 的部分. 在 5G NR 的 TDD 系統中, 關於 SSB Burst 的敘述一共分成 5 個情境, 並對應於不同的載波頻率適用, 從 Case A - Case E, 為從低頻至高頻, 其對應的 SSB 的時間, 也由高至低 (高頻可有較短時的 time slot 設定), 我們可以由下圖看出差異: 來自:  https://blog.csdn.net/u010658002/article/details/113067577 SSB Burst 的訊號依然跟隨原有 LTE 的機制,  在一個 sub-frame (5 ms) 內出現, 其預設的時間間隔為 20 ms, 因此, 若 UE 沒有抓到 SSB 的資訊, 則預設會聽 20 ms 的時間, 至於 SSB Burst 中對應的波束資訊, 則列於 SIB1 中, 讓 UE 在接收到 Cell 資訊時, 也就可以了解所對應的 SSB 波束資訊. 在上圖中, 我們也可以看到, 越多數量的 SSB, 也會造成系統越大的負擔 (真實資料傳輸越少), 因此, 在 5G NR 中也對不同載波的 SSB Burst 的數量,...

在 5G 的系統中, 由於 mmWave 的引入, Beam (波束) 的估測, 追蹤, 排程, 與管理, 就變成必要的技術, 然而, 不論是多麼新穎的技術, 背後都是建立於量測, 在 5G 的系統中, 就透過 CSI-RS 來提供不同波束的量測資訊. 在 3GPP 定義的波束掃描機制中, 約略可以分成三個階段: Initial Bean Acquisition: 透過 Synchronization Signal Blocks (SSB) 的參考訊號,  透過波束掃描 (Beam Sweeping) 的方式, 取得 RSRP 決定約略波束方向 Transmit-end Beam Refinement: 傳送端 (以下行而言是基地台), 傳送 non-zero-power CSI-RS (NZP-CSI-RS) 作為精細的通道估測, 若是上行則由 UE 傳送 Sounding Reference Signal (SRS) 進行估測. 在此階段, 接收的波束場型固定, 透過改變傳送的波束, 取得精細的波束資訊. Receive-end Beam Refinement: 和上個階段相反, 固定傳送波束, 更改接收波束. 相對的, 使用的 SRS 和 NZP-CSI-RS 也對調. 我們可以用下圖來解釋此三個階段 來自:  https://www.sharetechnote.com/html/5G/5G_Phy_BeamManagement.html 可以看到 CSI-RS 在波束選擇的問題中,  主要是在第二和第三階段加入, 用以提供更精確地波束資訊. 此時使用不同的波束, 代表的就是不同的無線通道響應, 考慮到我們希望可以得到精密的 CSI 資訊,  在 CSI-RS 的設計上, 我們可以分時使用不同的波束,  並在不同的 sub-carrier 上進行傳送, 使接收端可以進行通道估測. 來自:  https://www.mathworks.com/help/5g/ug/nr-downlink-transmit-end-beam-refinement-using-csi-rs.html 上圖示以第二階段, 並考慮下行的 Beam Refinement 作為範例, 可以看到, UE (接收端) 固定一接收波束場型...