Castle on a Cloud

在虛擬化技術中, 最一開始的技術從硬碟開始, 之後是 CPU 與記憶體的虛擬化, 最後則慢慢走向網路以及各種周邊裝置虛擬化, 其中, 在網路虛擬化的部分, 一開始以軟體方案 (OpenVSwitch) 為主, 此類方法依賴 Host Machine 上的程式進行資料的轉傳, 限制了 Virtual Machine 上的網路的效能. 為了增進其他裝置 (CPU, 記憶體, 硬碟) 的虛擬化程度, Intel 提出了 SR-IOV (Single Root I/O Virtualization) 的機制, 目標是透過對 PCIe 介面的虛擬化, 使一個裝置可以服務多個虛擬機, 其中, SR 代表只有一個 Host Machine, 也就是一般家用電腦狀況, 相對應的有所謂的 MR-IOV (Multi-Root I/O Virtualization), MR-IOV 適用於刀鋒伺服器 (Blade Server) 架構, 在此架構下, 多張刀鋒伺服器共享同一機櫃之 IO 支援 (如對外網路), 因此會出現多台 Host Machine (Multi-Root) 對單一 IO 裝置的存取需求. 考慮到 MR-IOV 可視為 SR-IOV 的延伸, 我們著重介紹 SR-IOV 的部分,  在 SR-IOV 中, 將原本提供 Physical Function (PF),  切割成多個 Virtual Function (VF), 而每個 VF 對應到不同的虛擬網卡, 其框架可以以下圖表示: 來自:  https://www.marvell.com/content/dam/marvell/en/public-collateral/ethernet-adaptersandcontrollers/marvell-ethernet-adapters-fastlinq-concurrent-nic-partitioning-sr-iov-technology-brief-2018-07.pdf 由上圖中可以發現, SR-IOV 需要裝置本身的支援 (PF和VF的功能提供), 以及虛擬層 (hypervisor) 的支援, 其中, PF 可以視為原本裝置的 driver 支援, 負責和 hpervisor 進行溝通, 當虛擬機生成後, 就直接透過 ...

在5G工業物聯網的應用中, 其中一項重要的應用就是低延遲網路, 低延遲網路可用於智慧工廠中, 特別是對於精密控制的工業機台, 在 3GPP 的架構中, 這些應用屬於工業 4.0 的範疇, 並將需要精密時間同步的工業物聯網服務稱為 Time Sensitive Communications (TSC), https://www.3gpp.org/news-events/2122-tsn_v_lan 其中, 用以支持精密同步的通訊協定為 802.1AS. 802.1AS 繼承自 IEEE 1588v2, 也稱為 PTP (Precision Time Protocol), PTP 的基本同步架構沿襲自 NTP (Network Time Protocol), 但考量了大型網路的複雜度, 對於網路中介裝置 (Bridge 或 Switch), 加入修正的機制, 以及對時鐘 (Grand Master, GM) 的選擇機制, 主要目標在於服務無法以 GPS 對時, 但需要比 NTP 更精確同步的場域, 其同步精確度的設計為 500 ns (七個網路節點, 時脈飄移小於 1PPM). 考慮到 802.1AS 是源自於 NTP 的設計, 我們在此篇文章中, 先介紹 NTP 的對時設計,  在 NTP 的基本想法中, 透過兩裝置封包交換, 計算兩者的通訊延遲, 並透過此延遲時間的估算 (下圖的 \delta), 用以同步兩個裝置的時間, 來自:  https://en.wikipedia.org/wiki/Network_Time_Protocol 在NTP中, 假設兩個裝置互相傳送封包 (上行/下行) 的延遲一致, 因此 \delta = ((t3-t2)+(t1-t0)) = 65 (ms) \delta 代表的是藍色部分的漂移時間 (propagation time), 其值除以二就代表著封包從 Server 到 Client 所需的單向漂移時間, 因此, Client 可以參考從 Server 送出的參考時間, 加上單向漂移時間, 用以作為本地校正的時間數值. 在 NTP 的架構下, 兩點之間的時間同步不成問題, 因為在同一個區網下, 同一網路媒介下, 上行和下行的時間差異不大, 但對於一個大型網路而言, 則會有以下兩個問題: 當有多個裝置想當...

在 上一篇文章 中, 介紹了企業專網, 以及其在 3GPP 中的角色以及兩種不同的應用情境. 接下來, 我們將從其佈建的方式, 詳細介紹其不同實作方案的差別, 本文主要的圖表和內容來自:  https://www.netmanias.com/en/post/blog/14500/5g-edge-kt-sk-telecom/7-deployment-scenarios-of-private-5g-networks 這篇文章詳細的敘述了7種不同的企業專網架構, 其中, 最為有趣的是 6 和 7 兩個韓國 SK 電信的實作案例. 本文專注於一般性架構 (前5種) 不會談到, 有興趣可以進入連結詳讀. 在之前介紹中, 我們說明了企業專網可以分成兩大類, 第一類是由場域主自行佈建, 維護從基地台至核網所有 5G 單元 (如下圖左), 按照實施者的不同, 在原文中拆成兩個方案討論. 第二類是由電信業者佈建, 此類專網會在一定程度上和電信業者的網路進行整合, 共享網路中的部分元件, 並使用網路分層 (network slicing) 的技術, 來達成場域主對安全性的需求 (如下圖右),  在此架構下, 我們將分成 3 種不同方案進行說明. 來自:  https://www.netmanias.com/en/post/blog/14500/5g-edge-kt-sk-telecom/7-deployment-scenarios-of-private-5g-networks 首先, 是方案一和方案二, 此兩方案在原文中的差異只有實施者是場域主或是電信商, 在網路架構上完全一致, 都是整套的獨立 5G 網路 (黑色部分),  並和電信商的 5G 網路 (藍色部分) 沒有任何實體上的重疊. 方案一, 二: 來自:  https://www.netmanias.com/en/post/blog/14500/5g-edge-kt-sk-telecom/7-deployment-scenarios-of-private-5g-networks   考慮到兩邊網路獨立, 在這兩個方案中, 企業專網必須有專屬頻譜 (圖中的 Local 5G freq.) 將墊高建置成本, 但另一方面, 由於企業專網的網路為實體上獨立, 因此, 有最高等級的...

在 5G 的時代, 其中一個主要的應用就是物聯網, 透過拓展 5G 的應用情境, 5G 服務的使用者不再只是人, 而包含了各式各樣不同需求的裝置,  像是: V2X 中的車輛與路旁裝置, mMTC 中的感測裝置,  這些多樣的裝置與應用, 使得 5G 不只是單一種電信商 (Operator) 網路, 而是一種異質的網路組合, 用以服務不同的應用情境. 考慮到此特性, 5G 網路就產生了企業專網的延伸, 其基本想法就是透過專屬的頻寬 (專網), 提供給場域營運商 (企業), 使得場域營運商可以按照其需求, 佈建一個符合自己應用情境的服務. 在台灣, 企業專網的頻帶為 4.8~4.9 GHz 的頻段. 目前已有多家企業 (如: 鴻海, 台積電) 表示興趣, 電信商也提出各自的解決方案, 然而, 不可否認的是, 目前企業專網尚未擁有成功的布建案例, 企業專網可以帶來甚麼優點? 比起 4G 的解決方案, 5G 的架構有甚麼幫助? 各國企業專網頻帶 (Source: Nokia) 在 3GPP R15 和 R16 的規範中, 定義了企業專網的架構 (稱為 Non-Public Network, NPN) 請參考: https://www.3gpp.org/news-events/2122-tsn_v_lan 在 3GPP 的分類中, NPN 可以大致分成兩類: SNPN (Stand-alone Non-Public Network): 在此架構下, 核網與頻帶都為營運上所擁有. 此架構等於是場域主自行營運一個小型的 5G 網路, 無須電信商的介入. PNI-NPN (Public Network Integrated NPN): 此架構下, 一些功能由電信商核網支援. 在此架構下又可以按照不同程度的功能切分, 形成不同的架構. 大致來說, SNPN 需要較高的建置成本, 較低的營運成本, PNI-NPN 則相反, 在安全性上, SNPN 掌握所有資料, PNI-NPN 則依賴電信商的支援, 下圖為 3G4G blog 提供的簡易比較 (MNO 為 Mobile Network Operator 縮寫): https://blog.3g4g.co.uk/2020/03/5g-private-and-non-public-network-npn.html 若我...

在上一篇文章中, 我們介紹了 RADIUS 認證協定, RADIUS 是基於 UDP 的方式建立連線, 不但無法保證資料傳輸的完整性, 也無法保證資料的安全性. 使用 UDP 的主要原因應該是在舊有有線網路的設計架構下, 將控制訊息以 UDP 傳輸, 使用者資料以 TCP 傳輸的想法, 此想法基於控制訊息短, 且具有定期重送的保護機制而形成, 使用 UDP 傳輸可以避免封包多餘的重傳, 以及訊息交換, 節省使用頻寬, 特別適用於早年頻寬有限的網路架構. 然而, 隨著網路的發展, 安全性和穩定性受到更多注意, 特別是針對無線網路, 由於在空氣中的封包可以側聽, 因此, 安全性受到更多考量. 為了增進 WiFi 網路的安全性, EAP (Extensible Authentication Protocol) 首先被提出, EAP 被定義於 RFC3748 , 為一個點對點的認證框架, 由於 EAP 的角色是框架, 而非協定, 因此有各家廠商的不同實現, 不同 EAP 的協定比較可以參考 Intel 的這篇文章: https://www.intel.com.tw/content/www/tw/zh/support/articles/000006999/network-and-i-o/wireless.html 802.1X 基於 EAP 的架構, 提出一種在區域網路 (Local Area Network, LAN) 的實作方式, 或者也可以稱為 EAPOL (EAP Over LAN), 提供 EAP 架構進行裝置與伺服器之間的資料交換, EAPOL 為一個點對點的通訊協議, 不依賴 IP 層, 可用 MAC 直接溝通, 在 EAPOL (或是 802.1X) 加入後, 整體的架構如下圖: 來自:  https://www.semanticscholar.org/paper/Extensible-Authentication-Protocol-(-EAP-)-Security-Sotillo/417b0aa1fd8d7ddb8616a018de1fbc9de039a40e 在上圖中, 可以看出來 802.1X, EAP 和 RADIUS 之間的分工, 一方面, EAP 架構下通訊的兩點為終端裝置和 RADIUS 伺服器, 補足了 RADIUS 只定義 NAS (...

對於使用公眾 WiFi 的使用者, 連上網路之後第一件事應該就是被導到一個登入的網頁, 輸入帳密之後, 才能開始進行一般的上網瀏覽, 而此處的登入與認證程序, 通常使用 RADIUS 作為認證機制. RADIUS 全稱為: Remote Authentication Dial-In User Service, 初始定義於 RFC 2865:  https://tools.ietf.org/html/rfc2865 是一個基於 UDP 協定的通訊架構 (因此應用層要自行處理連線保證), 負責處理客戶端 (稱為NAP, Network Access Server) 的認證需求, 如下圖所示: 來自:  https://en.wikipedia.org/wiki/RADIUS 在上述的應用情境中, NAS 扮演的定義為: Initial Entry Point to a Network, 換句話說, 扮演類似 router 的角色, 做為對外網路的代理, RADIUS Server (Proxy) 的功能則是對應一分散式網路框架, 當 NAS 分屬不同地區的區域網路 router 時, 可以透過 proxy 的代理, 將各地區域網路的認證導向統一的 RADIUS Server. 事實上, 在一開始敘述的應用環境中, 使用者裝置一共認證兩次: 第一次, 連上 WiFi 網路, RADIUS 會先給予此 MAC 位址准入權限, 並將通訊導向設定的網頁伺服器, 第二次, 透過網頁伺服器送出使用者名稱與密碼 (或其他認證手段), 此時使用者才真正擁有上網的權限, 如下圖所示: 來自:  https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Wi-Fi-Cloud/manage_wirelessmanager/configuration/wifi_access/radius_mac_auth.html RADIUS 伺服器的功能不止於此, 還可以包含使用者登入後的計費, 登入時間控管等, 甚至也可以和 VLAN 結合, 動態賦予流量不同的安全設定. 同時, 為了進一步增強 RADIUS 的安全性, RADIUS 也加入了和 EAP (Extensibl...

在 LTE 的核網中, 資料透過 PDN (Package Data Network) gateway 連結外部網路, 在過往我的理解中, 資料只要出了 PDN GW, 就是和網際網路 (Internet) 相連, 因此, 不論是封包的轉傳, 或是應用的提供, 應該都要回歸 IP 層的設定. 然而, 事實上, 在 PDN GW 和 Internet 之間, 3GPP 還定義一個通訊界面, 稱為 SGi, 在此介面上, 或者說是在這中間的網路 (SGi LAN), 可以建立不同的應用,  用以提供各式加值服務, 以下是對 SGi 介面的定義: Interface between the PDN-GW and a packet data network. It may be an operator external public or private packet data network or an intra operator packet data network, e.g. for provision of IMS services 在定義中的 IMS (IP Multimedia Subsystem) services, 為電信商所提供的多媒體服務, 像是: VoLTE, 影像電話等, 和一般網際網路的應用不同, IMS 服務可以存取核網資訊 (例如: HSS 資料庫), 並透過其在核心網路出口的優勢, 提供較佳反應時間與頻寬. 另一方面, SGi LAN 也可以用以實作防火牆, DPI (Deep Packet Inspection), 等安全控制功能, 並可透過服務疊加的方式 (service chaining), 提供不同服務組合, 如下圖所示: 來自:  https://blog.advantech.com/tech-blogs/ntg/2017/11/sgi-lan-service-chaining/ 我們可以看到可以利用 SGi LAN 實現的服務可以分成兩類: 電信商的應用服務: 對於此類服務, 一開始的 IP 位址就必須為電信商服務的 IP, 當服務進入 SGi LAN 之後, 可藉由 NAT 實現負載平衡, 並利用資料中心內的資源, 提供服務 網路安全管理: 此類應用可以利用防火牆的設定, 提供 黑名單/白名單 的功能, 也...

在上一篇文章中, 我們介紹了 SBA 的架構,  然而, 考慮到 SBA 架構中, 出現不少 5G 專有的元件, 因此, 我們參考了 TS 23.502 4.3.6.3 中的一個和 routing 相關範例  (An example for interactions between AF and NEF), 說明如何在 SBA 架構下進行資料的交換. 此範例中,  AF (Application Function) 提供控管 User Plane 資料流的功能  (Application Function influence on traffic routing), AF 透過 SBA 架構, 對 SMF (Session Management Function) 下達指令, 更改在 Core Network 中的資料轉傳路徑, 完成 SDN (Software-Define Network) 的功能,  至於, NEF (Network Exposure Function) 則扮演不安全網路的代理角色, 整體流程如下所示: 來自: https://www.tech-invite.com/3m23/toc/tinv-3gpp-23-502_t.html#e-4-3-6 此範例中,  訊息主要在 SMF 和 AF 之間交換, 又分成兩種情況: AF 在安全的網域內 (例如: 在 Core Network 之中), 以及 AF 在不安全的網域 (例如: Core Network 外部的應用程式), 可以用以下 4 個步驟解說: 因應預先 AF 設定的條件, 或是, session anchor 的建立, SMF 會向 AF 發出通知 (notification) 若 AF 非信任節點, 此通知以及回覆透過 NEF 送出 (2a, 2b, 2d, 2e, 4a, 4b, 4d, 4e) 若 AF 為信任節點, 此通知以及回覆可以直接在 SMF 和 AF 之間交換 (2c, 2f, 4c, 4f) SMF 根據 AF 的回覆, 修改 UPF (User Plane Function) 的 routing 規則 在此範例中, 我們可以了解 AF 以及 NEF 的功能與設計, 同時, 透過 SDN 概念的引入, 5G...

在 4G Core Network 中, 不同的單元之間, 透過不同的介面溝通, 此架構又稱為點對點 (Point-to-Point, P2P) 架構, 其優點在於可以針對每一個介面, 設計最佳的通訊協定, 然而, 這樣的架構也造成網路的僵化, 難以擴展新功能. 考量至此, 3GPP 在定義 5G Core Network 時, 引入了 Service-Oriented 的想法, 命名為: Service-Based Architeture (SBA),  定義於 TS 23.501, 並以 RESTful API 作為溝通的介面, JSON 作為溝通的格式, 在 SBA 架構下, 5G Core Network 拆解成許多獨立的功能模組, 如下圖所示: 在上圖中, 我們可以看到 SBA 架構下, 可以分成兩部分, 其中, 和 RAN 直接相關的部分 (UPF, AMF, SMF), 仍舊維持 P2P 的架構, 但是, 對 AMF 以及 SMF 的管理單元, 都在同一個匯流排上, 以 RESTful API 的方式串聯, 而在匯流排上的功能單元, UDM, AUSF, PCF 是屬於標準的 Control Plane 功能, 其中, 和 4G Core Network 的功能對應可以表示於下圖: 其中, 由於 Control Plane 和 User Plane 分離的緣故, SGW-U, PGW-U 分別代表了 Serving Gateway (SGW) 和 PDN Gateway (PGW) 的 User Plane, 相對的, SGW-C 和 PGW-C 則代表了 Control Plane 的功能, AMF 用以管理 UE 的 Access 和 Mobility, 而 SMF 管理 UE 的 Session,  此兩個功能元件, 直接和 UPF (User Plane Function, 主要就是資料的路由) 以及 RAN (Radio Access Network, 主要就是基地台) 溝通, 並直接給予指令, 因此, AMF 和 SMF 仍是走標準的 P2P 介面. 其他在匯流排上的 SBA 單元, 則可以視為提供 AMF 和 SMF 的計算單元, 若以 SDN 作為框架, AMF 和 SMF 角色類似於 OpenFlow, 而其他元件則...

在通訊系統的演進中, 我們通常著重於 RAN (Radio Access Network) 的進展, 畢竟, RAN 的進步 (如: 傳送速率, 新的裝置, 等) 都比較和使用者相關, 但是, 相對於 RAN, 核心網路 (core network) 的改變也非常巨大, 從 3G 到 4G, 基本上完成了從 circuit switch 到 packet switch 的轉換, 讓行動網路, 不只有語音通訊的功能, 也引領手機裝置, 從功能手機演進為智慧型裝置, 接著, 從 4G 到 5G 網路, 面對多樣的終端裝置 (智慧手錶, 物聯網裝置, 等) 5G 核心網路引入兩個重要概念: 網路功能虛擬化 (Network Function Virtualization, NFV) 與雲端. 在本文中, 會著重在架構和功能的比較, 5G core network 的特色之後有機會再說明. 來自:  https://medium.com/@sarpkoksal/core-network-evolution-3g-vs-4g-vs-5g-7738267503c7 在 3G 的 core network 中, packet-switch 和 circuit-switch 是分開的, 其中, 負責 packet-switch 的是 GPRS (General Packet Radio Service), 藉由分時多工的方式, 分享通訊資源. 其中, SGSN 負責管理 UE 的 session, 移動性, 計費的功能, 可以想像是 control plane, GGSN 則負責將 IP-based 的在通訊系統傳送, 可以想像是 user plane. 來自:  https://medium.com/@sarpkoksal/core-network-evolution-3g-vs-4g-vs-5g-7738267503c7 到了 4G 網路, 就正式把 circuit-switch 從 core network 中移除, 相對於 3G 把所有功能都放在 SGSN 內, 4G core network 針對功能做了較佳的切分, 其中, MME 負責 session 和 mobility 的管理, HSS 為使用者認證資料庫, S-GW 將來自 internet 的...

在 BLE 5.1 中加入了對角度估測的支援, 此功能可以廣泛利用於室內定位的範疇, 提供公尺以下之定位精確度, 此定位功能利用多天線之技術, 估計目標裝置相對之角度, 又可以分成以下兩種估計之架構: AoA (Angle of Arrival) 和 AoD (Angle of Departure). 來自:  https://www.rohde-schwarz.com/ae/solutions/test-and-measurement/wireless-communication/ wireless-connectivity/bluetooth/bluetooth-direction-finding/bluetooth-direction-finding_251246.html 在 AoA 的架構下, 移動裝置需要單一天線, 並發送一特殊訊號 (DF-enabled packet), 固定裝置 (BLE Gateway, BLE GW) 擁有多根天線, 進行角度之估測, 在 DoA 的架構下, 移動裝置依然透過單一天線傳輸, 但是此時, 特殊的 DF-enabled packet 由 BLE GW 發出, 角度之估測則在移動裝置進行, 在 BLE 5.1 的架構下, 裝置必須發送一特殊訊號,  也就是上述的 DF-enabled packet, 其中 DF 為 Direction Finding  的縮寫, 此訊號的特色為包含一串 Constant Tone Extension (CTE) 訊號, 用以提供固定的波型 (waveform) 和頻率 (frequency) 的訊號, 以供接收端進行 IQ 的分解 (顯示收到訊號的的強度和相位改變), 進行之後之角度估測. https://www.bluetooth.com/wp-content/uploads/2019/05/BTAsia/1145-NORDIC-Bluetooth-Asia-2019Bluetooth-5.1-Direction-Finding-Theory-and-Practice-v0.pdf 在角度估測部分, 以 AoA 為例, 移動裝置發出 DF-enabled packet, 而 BLE GW 依序從不同天線接收,  因此, 每根天...

考慮到實作上的困難, 3GPP 最終並沒有制定底層的功能切分, 此部分的功能切分, 就變成一個開放議題, 而回到各設備廠商的實作, 其中, 值得一提的是 O-RAN 此組織在 C-RAN 協定上的努力. 首先, 先談談 O-RAN 這一個組織, O-RAN 全名為 ORAN Alliance, 組成包括全世界重要的電信商以及設備商, 其目標是提供開放架構的電信網路,  將原有的特製化設備, 使用標準的軟硬體取代,  並透過開放的系統與定義完善的接口, 讓更多硬體商加入設備提供, 完成電信網路的白牌化. 先撇開最終成敗不談*, O-RAN 的目標的確是一有趣的想法. 有興趣的同學, 可以查看:  https://www.o-ran.org/ 其中, 關於 C-RAN 的討論在於 WG6: The Cloudification and Orchestration Workgroup, 在此工作項的說明中, 就強調了要引入商用硬體, 加入 C-RAN 的競爭, 在該份文件的撰寫時, 也的確花了很大的篇幅討論商用軟硬體的腳色, 不過, 商用硬體的腳色並不是本文的重點, 因此先存而不論,  回到功能的切分, 在 O-RAN 的討論中, 決定了底層切分的方式為 Option 7-2, 並且透過一個名為 Open fronthual 的介面通訊, 因此, 在 O-RAN 的架構下, C-RAN 的架構變成了: CU-DU-RU (Radio Uint), 其中, RU 為天線的單元, 透過 fronthaul 傳送至 DU. 此時, 就將引出了延遲的問題,  對此, O-RAN 的想法是根據不同的應用的延遲需求來佈建 DU, 如下圖所示: 來自: Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN (v2.0) 在上圖中, 我們可以看到 DU 基本上是安放於 edge 上, 考慮到其負擔了部分 PHY 層的功能, 必須在低延遲下, 和 RU 進行溝通, 其中, 延遲的限制約為 0.1 ms, 也限制了 fronthual 網路的範圍小於 20 km. 至於 CU 的位置則隨應用而改變,  對於 URLLC ...

在 上一篇文章 中,  提到了 3GPP 組織於 TR 38.801 中決定了 higher layer 的分層設定, 對於 lower layer 的分層設定則留待之後討論, 所衍伸的討論文件為: TR 38.816 Study on CU-DU lower layer split for NR 在 TR 38.816 中討論了以下四個不同的選擇: Inter-PHY split: Option 7-1, Option 7-2, Option 7-3 MAC-PHY: Option 6, 其中, 不同的選項表示如下圖: 來自: TR 38.816  Study on CU-DU lower layer split for NR 在圖中, 我們可以看到 Option 7-1 的斷點在 FFT/IFFT 的部分, FFT/IFFT 通常都是由專屬電路負責, 因此, 移入 CU 並沒有太大的意義, Option 7-2 則把和使用者即時通到資訊相關的 pre-coding 部分也放在 DU, 這樣的架構可以減少 DU 向 CU 回傳的資訊量, 最後則是 Option 7-3 的架構, 只把 coding 的部分移入 CU. 在 TR 38.816 的討論中, 由於以下兩個原因, 最後並沒有做出選用的結論, 第一, 在系統實作上, 許多基地台有其特有的功能 (如: beamforming), 這部分的功能並不在 3GPP 的規範之中, 可實作於實體層的不同部分, 如果強硬規定其切分方式, 可能會影響各廠商的實作. 第二, 在原有的 Radio Access Network 規範中, 對於上行 (uplink) 接收部分, 並沒有詳細的功能切分(functionality)定義,  同時, 對於未來不同的通訊需求 (IoT, ultra-low latency), 也可能改變實體層所需的功能, 這也造成了此處切分的困難, 不論如何, 雖然 TR 38.816 無法取得一致的同意,  但是這份文件也指出了切分時的重要依據, 也就是 fronthual 所需的頻寬, 並討論了幾種不同切分下的應用情境, 作為廠商實作之參考. 

在 3GPP 中, C-RAN 的定義主要集中於 TR 38.801 這份文件,  Study on new radio access technology: Radio access architecture and interfaces,  如果有興趣的話, 可以在以下連結中下載: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3056 TR 38.801 不只包含了 C-RAN 的討論 (在 11.1 節), 還包含了許多 LTE 和 NR 共存架構, network slicing, control plane/ user plane 分離, 等議題, 畢竟其最終目標即是探討下一世代 (5G NR) 的 Radio Access Network (RAN) 架構, 不過, 我們今天就先著重在 C-RAN 部分, 或者, 以 3GPP 的術語來說, 是 CU (central unit) 和 DU (distributed unit) 的切分. 在 TR 38.801 中一共討論了 8 種選項 (Option), 如下圖所示: 最終, 在 TR 38.801 針對 CU-DU 分離的技術做了兩個決定: 第一, 針對高層 (upper layer) 的功能切分, 選擇使用 Option 2,  後續將針對此切分方式, 定義通訊界面 (F1 Interface in TS 38.470), 第二, 針對低層 (lower layer) 的功能切分, 在 TR 38.801 中未決定, 在之後 (TR 38.816) 之中繼續討論, 其中, 值得一提的就是針對 upper layer 的討論時, 最終有兩個選項放入最終表決, 分別是: Option 2 和 Option 3-1. Option 2 為 PDCP-RLC 的切分方式, 到慮到 5G NR 中支援多樣態的無線傳輸介面, 在 PDCP-RLC 之間進行切分, 可以將應用層資料 (來自 IP 層通訊),  透過不同介面傳送至裝置, 並且在裝置上重組這些無線封包. 同時, 在 Dual Connectivity (DC) 的架構...

在 LTE 網路中, 定義了兩種換手 (handover) 的方式, 第一種稱為 X2-based handover, 發生在兩個基地台間有 X2 介面, 可以直接將資訊過 X2 介面傳輸, 不用經過 MME (Mobility Management Entity), 此類的換手依賴基地台間的溝通, 不經過核心網路 (core network), 第二種稱為 S1-based handover, 資料將通過 S1 介面回到 MME 後, 從原本的服務基地台 (Serving eNB, S-eNB) 傳達給目標基地台 (Target eNB, T-eNB), 整體流程如下所示: 來自:  http://www.3glteinfo.com/intra-lte-handover-using-s1-interface/ 在 LTE 系統中, 換手的需求是由基地台 (eNB) 所發動, 而換手的依據則是由使用者 (UE) 對附近基地台的訊號強度進行量測, 當原本服務的基地台 (S-eNB) 發現有目標基地台 (T-eNB) 的訊號較佳, 則會向 MME 提出換手的需求 (S1-AP: Handover Reqd), MME 此時將對 T-eNB 提出申請 (S1-AP: Handover Req),  並在回覆 (S1-AP: Handover Req Ack) 後, 通知 S-eNB (S1-AP: Handover Cmd), 確定換手需求同意後, S-eNB 將會進一步去通知 UE (RRC Conn Reconfig Req), 去和 T-eNB 進行資料連線 (Non-Contention RACH Proc), 並通知 SGW (Serving Gateway) 將 UE 的資料重新導到 T-eNB. 對應於 X2-based handover, 其中多數概念類似, 唯一的差別, 只有在一開始原本透過 S1 介面以及 MME 與 T-eNB 確定的流程, 改成由 S-eNB 與 T-eNB 直接溝通, 如下圖所示: 來自:  http://www.3glteinfo.com/intra-lte-handover-using-x2-interface/

在 上一篇文章 中, 說明了 C-RAN 架構的優點, 然而, 在一開始的 C-RAN 架構下, 直接將 RRH 和 BBU 切開, 這樣的好處是可以透過 CPRI (Common Public Radio Interface) 介面切割功能, 因此, 不牽涉到既有通訊模組與硬體的變化, 可以快速布建, 然而, 考慮到 CPRI 所需的高頻寬與低延遲,  通常需要專屬光纖來實現, 也提升了 C-RAN 在實作上的困難. 考慮到這樣的原因, 許多研究者以及 3GPP 組織開始討論要如何切分 C-RAN 的功能, 若我們將 4G LTE 的通訊架構展開, 可以得到下圖: 來自:  http://www.techplayon.com/5g-nr-gnb-logical-architecture-functional-split-options/ 其中, Option 8 就是原本 RRH-BBU 的切分方法, 在上圖中, 比起原本的 PHY-MAC-RLC-PDCP 分層, 又將各層依據其功能, 細分成不同子層, 以下為詳細的定義: Low-PHY ( 7-2 ): FFT/IFFT, add/remove CP, resource mapping/de-mapping High-PHY ( 7-2 ): other PHY functions (例如: channel coding) Low-MAC: HARQ, Signal Measurement, Random Access Control (即時, 或與 PHY 相關) High-MAC: 使用者排程 (scheduling), JS/CS CoMP Low-RLC ( 3-1 ): 封包依據 MAC 層的長度, 重新切分 (segmentation) High-RLC ( 3-1 ): RLC 層的資料重傳 (ARQ) 以上內容參考自:  SAHA, Rony. (2018). Functional Split Options in C-RAN Architecture. 10.13140/RG.2.2.31060.04480. 若有多個不同的定義, 則將使用的版本列在括弧中. 考慮到新的功能切分, 原本 4G LTE 中的 BBU 和 RRH, 在討論 5G 的 C-RAN 架構時...

在原本的行動網路架構中,  所有的訊號處理都放在基地台 (base station, BTS) 上計算, 整體的系統方塊圖如下: http://dl.ifip.org/db/conf/ondm/ondm2017/1570337472.pdf 在這樣的架構下, 我們可以粗略地將所有系統方塊分成兩部分: BBU (Base Band Unit) 與 RRH (Remote Radio Head), 其中, BBU 處理基頻的訊號處理, RRH 則用以處理射頻相關訊號. 假設一個基地台有 3 個 sectors, 則需要 3 個 RRH, 但只需要一個 BBU, 經由 BBU 處理完之後的訊號, 則將由 S1/X1 介面, 通往 core network. 在這張功能方塊途中, 我們可以看到 RLC, PDCP 等單元, 如果不清楚可以參考:  https://note-on-clouds.blogspot.com/2017/03/lte-layer-2.html 在 4G LTE 中, C-RAN 的架構即是把 RRH 和 BBU 分離, 並使用光纖連接兩者進行資料傳輸, 簡單來說, 在 C-RAN 架構下, 類比訊號經過預先處理後,  得到數位訊號後, 透過光纖傳到一個 BBU pool, 進行基頻處理, 這樣的架構主要的好處主要是可以節省 BBU 的安裝需求, 考慮到 RRH 可以安裝於天線旁邊, 但是 BBU 仍需要散熱處理, 分散式 (架設於基地台旁的機房) 的 BBU 架構, 將導致大量的散熱需求, 並增加營運商架設基地台的成本. 當把 BBU 拉回中控進行運算後, 可以得到另一個額外好處: CoMP, 由於 BBU 在一起運算處理, 在進行訊號處理時 (例如: channel coding),  可以偕同多個基地台一起, 降低基地台對使用者的干擾, 尤其對於基地台的邊緣使用者, 能有更好的通訊品質.

在 LTE 的網路架構下, 由於其中控式設計, 相鄰的基地台之間會產生相互的干擾, 在過去大基地台 (macro cell) 的架構下, 可以藉由預先的網路規劃, 使得相鄰的基地台之間, 使用不同的頻帶,  因此, 在標準的蜂巢 (六角形) 佈建下, 也有所謂 reuse factor =7 的說法, 然而, 在 4G 甚至是未來 5G 的架構下,  小細胞基地台 (small cell) 將在網路中佔有更加重要的地位, 不同於 macro cell 的佈建, small cell 通常無法預先進行良好的規劃, 同時, 在密集佈建 (ultra-dense deployment) 的情境下,  small cell 之間的相互干擾, 就成了一個重要的問題. 因此, 在 3GPP 規劃中 (Release 8), 就提出了 Inter-cell Interference Coordination (ICIC) 的機制, 此機制基本上和之前分頻多工的網路規劃一致, 就是讓相鄰的 small cell 基地台使用不同的頻帶資源, 和舊有的分頻多工的網路規劃不同的地方有兩個: 第一, ICIC 分成內外兩圈的使用者 (UE), 只有在邊界上的使用者才分頻多工, 第二, 頻譜資源的溝通改成由 small cell 基地台透過 X2 介面進行, 換句話說, ICIC 的分配結果, 是透過基地台間溝通, 而非預先規劃. 透過 X2 介面, small cell 基地台會傳送 Uplink (UL) 受到影響的通道, 以及預計要分配給邊緣 UE 傳輸的通道給相鄰基地台, 相鄰的基地台將會在受影響的通道上降低功率, 並避開預計傳輸的通道, 來自:  https://www.netmanias.com/en/post/blog/6391/lte-lte-a/ interference-coordination-in-lte-lte-a-1-inter-cell-interference-coordination-icic 在 ICIC 之後, 3GPP 又提出了兩個 ICIC 的變形版本:  enhanced ICIC (ICIC), further enhanced ICIC (FeICIC). eICIC 在 3GPP Release...

[註: 本篇文章原載於台大 MOOC 網站, 由於網站已無法連結, 故在此重新發文備份] 相較於人文學科的學生，對於電機資訊領域的學生，除了一般的課堂授課之外，實驗課是大學生涯重要的課程。以電機系而言，在大學的課程設計中，通常會教導邏輯設計、電子實驗以及基本的程式設計。學生們將透過實驗把課堂所學的理論與公式，透過實體的電路或是程式實現出所設計的功能。 對於電機資訊領域的學生，實驗課是非常重要的訓練。一方面實驗課提供學術研究的工具，像是程式語言，作為模擬的撰寫以及理論的驗證工具，另一方面，在實驗課的進行中，學生將了解一個真實系統是如何運作的，舉例而言，在寫C語言程式時，我們需要宣告變數，並在使用完後刪除，對於作業系統而言，這就代表了記憶體的管理。同時，實驗課也訓練了系統設計(如何完成一個大型程式\電路)、錯誤更正(如何找出程式\電路中的錯誤)以及方法找尋(錯誤發生時該如何找資料修正)的能力。因此，當我們開始思考如何利用MOOC翻轉教育時，也該同時想想，如何利用MOOC翻轉實驗課！ 然而，不同於一般的教室授課，實驗課要求學生們利用實驗器材，實際地完成一個又一個功能，從一開始較簡單的功能開始，由助教教導除錯的方式，並驗證所完成的功能，到了課程的最後，則會結合所有學習過的功能，完成一個完整的專題。不同於紙本考試，實驗特通常以專題的完整度與功能驗證，作為評分的標準。這樣的特色，對於一個大規模、公開、線上的課程而言，也同時意味著無法提供實體器材、軟體授權，也無法由助教提供功能驗證的困難。 困難，但不代表不需要嘗試。在下述文章內容中，將介紹兩堂課程分別是courserea平台上由Rice大學開設的“Python交互編程入門”以及edx平台上由MIT所開設的“電子與電路”課程，並介紹網路上可以取用的公開資源，幫助對於電機資訊有興趣的讀者，能夠動手做實驗，透過實作，深入了解系統。 Python交互編程入門 “Python交互編程入門”由Joe Warren, Scott Rixner, John Greiner, Stephen Wong所開設，顧名思義，這門課程是介紹如何寫作一個Python語言的線上課程。Python是一種近年來興起的高階程式語言，所謂高階程式語言，對於一個資工背景的人而言，同時意味了兩件事情：容易上手、效率低落。由於Python語言的設計...

[註: 本篇文章原載於台大 MOOC 網站, 由於網站已無法連結, 故在此重新發文備份] 不同於國際上知名的 MOOC 平台， ewant( 育網 ) 平台是由兩岸五所交通大學 ( 包括上海交通大學、西安交通大學、西南交通大學、北京交通大學及國立交通大學 ) 於 2013 年共同發起，並由國立交通大學負責設計建構的開放教育平台。 面對 Coursera 和 edX 的競爭， ewant 把注意力放在廣大的華人市場，希望成為華語文的共通 MOOC 的平台。為了達成這樣的目標， ewant 和政治大學、中央大學、陽明大學等眾多台灣大專院校合作，同時也和中國大陸的交大系統、清華大學和哈爾濱工業大學合作，提供跨越兩岸的華語課程。 微學程 在課程設計上， eWant 也有微學程的系列課程，就如同 Coursera 的專業課程與 edX 的 XSeriel 一般，也是將一系列的課程包裝成學程的形式，提供學生選擇，目前一共規劃了包括青少年心理、工程力學、中國式管理、化學工程、統計方法、機械設計六個學程，主要由西南交通大學與國立交通大學開設。 實體考試與認證制度 不同於 Coursere 、 edX 與 Udacity 以理工和管理課程為主， ewant 在課程開設上有更多通識性科目，例如「孫子兵法與企業經營」這樣的通識性課程。而且在與哈爾濱工業大學及上海交通大學的合作之下，學生只要能通過考試，就可以承認其校內的通識學分。 此外，在證書的頒發上， ewant 平台也嘗試和非學術單位共同頒發，例如「 走讀臺灣茶 」這一門課程，就與臺灣茶協會合作提供認證證書。 由於 ewant 的發展目標是一個地域性的 MOOC 平台，因此和臺灣的空中大學合作將課程同步開放於 TaiwanLIFE 平台。一方面提供空中大學更豐富的師資與教學內容，一方面則由空中大學則支援 ewant 平台實體考試的空間。在這樣的合作關係之下， ewant 可以在臺灣 13 個空中大學實體教室利用傳統的證件與人工識別，提供一年 4 至 5 次的實體考試認證。 eWant 平台上多元且通識取向的開課方向以及和社會單位合作頒發證書的方式，有助於將 MOOC 的發展普及於一般社會大眾，而不只侷限於大學生族群。 然而在目前參加考試不收取...

[註: 本篇文章原載於台大 MOOC 網站, 由於網站已無法連結, 故在此重新發文備份] Udacity將重心從大學課程轉向技能培訓的專業領域。因此，不同於Coursera和edX以影片和同儕互評為主的教學模式，Udacity以專題導向(project-based)的方式設計課程，期望可以培養出學生的實作與專業能力。舉例而言，Udacity的第一堂課程：Intro to Computer Science，就要求學生完成一個搜索引擎，並利用此搜索引擎建構一個社群網路。希望學生從做中學，獲得帶得走的一技之長。 然而正因如此，他們的課程設計困難、師資稀少，Udacity一共只有18門課程，主要圍繞在資訊工程以及管理領域。不過，Udacity不像Coursera與edX與眾多知名大學合作，他們選擇和Google、NVidia、Facebook等公司合作開課，學生將因此有機會接觸真實企業案例，甚至有機會去這些公司工作。 在此前提之下，他們會提出那些承認學生能力的機制呢 ? Certificates MOOC之所以吸引眾人目光，其中一個原因是免費，然而Udacity卻決定 自2014/5/16起不再發放實質上不具價值的免費證書 ，大眾仍然可以免費學習，但是要取得證書就必須經過付費的身分認證。Udacity指出這是一個很困難的決策，但是如果要提升證書價值，這就是不得不做出的轉變。 不同於Coursera與edX依據每門課程的定價收費，Udacity是以月費計價—一個月199美元，收費期間他們會提供助教(Coach)與解題的服務，也就是確保學生有更佳學習體驗，協助其最終取得證書。 至於Udacity的身分認證方式也很不同。課程開始時，學生將和助教進行一次視訊介紹；完成課程時，助教則會再度確認你的身分資訊。這樣的認證方式簡單而有效，卻需要大量的人力投入。 Online Master of Science in Computer Science Udacity另一個創舉是和喬治亞理工學院(Georgia Tech)與AT&T合作，提供線上資訊工程碩士(Online Master of Science in Computer Science，OMS CS )的學位。 在Udacity上，該學位向所有學生...