Castle on a Cloud

CAPWAP (Control and Provisioning of Wireless Access Points) 是一份由 Cisco 提出的協定, 主要用意在於提供佈建由 WiFi Controller 控管下的 WiFi 網路間的通訊, 考慮到 CAPWAP 實在有點龐雜, 這篇文章只會提及一些概念以及延伸的閱讀文件. 首先, 第一個概念是 CAPWAP 不是一份通訊協定, CAPWAP 的概念是透過多份 RFC 文件所完成, 其中最重要的是: RFC 5415 : Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification RFC 5416 : Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 其他還有一系列的相關文件圍繞 CAPWAP 的概念,  可以參考這一篇文章:  http://what-when-how.com/deploying-and-troubleshooting-cisco-wireless-lan-controllers/overview-of-capwap-cisco-wireless-lan-controllers/

在 802.11ax 中定義了一個新的功能, BSS coloring, 簡單來說, 此功能允許 802.11 網路中的 WiFi AP (BSS, Basic Service Set), 除了原本的 BSS ID 作為識別之外, 還可以選定一個 "顏色", 並允許在接收到不同 "顏色" 的封包時, 可以不必要重設傳送等候計數器, 而可以繼續傳輸. 來自:  https://www.zdnet.com/article/next-generation-802-11ax-wi-fi-dense-fast-delayed/

在 WiFi 網路中, 一個基本的識別方式就是 SSID (Service Set Identifier), 也就是我們口語中的 "WiFi 網路名稱", 然而, 此網路事實上是一個服務集合 (Service Set) 的概念, 而一個服務群集, 也可以對應到一個基本的無線網路, 包含: 一個 WiFi AP 以及多個 WiFi 使用者, 對於剛剛這種簡單的網路架構, 又稱為 BSS (Basic Service Set), 若是多個 BSS 都使用同一個 SSID, 則稱為 ESS (Extend Service Set), 如下圖所示: 來自: https://ppt.cc/fXIvex 對於 ESS 來說, 有兩個假設, 第一, 底下的 BSS 必須是相鄰 (有交疊範圍) 第二, 這些 BSS 有網路連線, (有線或是無線都可以) 這兩個假設是為了完成 ESS 的主要功能, 也就是換手 (handoff), 當裝置在同一個 ESS 下不同 BSS 範圍中移動時, 可不必重新連線就可以繼續傳輸. 這樣的流程事實上是由原本服務的 AP (BSS 1), 把使用者的資料轉傳到換手目標的 AP (BSS 2), 資料流程為: DS -> BSS 1 -> BSS 2 -> Sation, 也因此, 兩個 AP 之間必須連線, 同時切換時間也不能太久 (相鄰條件), 那麼在上述例子中, 如何知道 BSS 1 和 BSS 2 的差別呢? 在 WiFi 網路中, 為了完成這件事情, 所以就有了 ESSID 和 BSSID, ESSID 如上所述, 對應於 ESS 所使用的 SSID, 至於 BSSID (通常是 WiFi AP 的 MAC 位址) 來區分同個 SSID 下的網路. 反過來說, 同一個 WiFi AP 也可以擁有多個 SSID, 此功能稱為 VAP (Virtual AP), 此時, 一個 WiFi AP 會虛擬出多個 BSSID, 通常作法就是從原有的 MAC 位址往上加一, 作為多個不同的 BSSID. 這些 VAP 會對應到 WiFi AP 中的不同 VLAN 中, 因此, 我們可以給他們不同的網路設定, 例如: 流量, 安全性, 頻寬等,

若說, 802.11ax 是 802.11ac 的後繼技術, 802.11ay 就是 802.11ad 的演進版本, 考慮到 802.11ad 面臨的失敗, 802.11ay 在設計時, 改進了以下的效能: 傳輸範圍: 從 10m 到 100m 傳輸速率: 從 5Gbps 到超過 10Gbps 低延遲, 以及 4 MIMO Stream 的支援 低功率消耗 QCA64x8 (WiFi AP) 和 QCA64x1 (mobile) 這兩組晶片組就是 Qualcomm 提出的方案, https://www.qualcomm.com/news/releases/2018/10/16/qualcomm-dramatically-extends-wi-fi-experiences-5g-era-60ghz-80211ay 在其新聞稿中, 並沒有太多的技術內容, 比較值得注意的是 802.11ay 的use case, 在新聞稿中, Qualcomm 引入了幾家公司的評論: Asus Mobile: 特別著重在電競終端設備 (ROG電競手機) MikroTik: 代表 WiFi AP，尤其是企業端的產品 Facebook: Terragraph 計畫 這些不同公司的代表, 也顯示了 Qualcomm 對於 802.11ay 應用的想像, 包含了電競, 企業 WiFi 網路, 以及無線骨幹網路 (Terragraph), 其中, facebook 的 Terragraph 是最有趣, 也是唯一公開實際合作的, 我們介紹一下此計畫: https://terragraph.com/#terragraph

本文是 3GPP 標準會議現況與趨勢研討會, RAN2 Status of R15 EN-DC and NR SA 的摘要. 考慮到通訊的進展與投資, 通常不會一次完成, 以 Radio Access Network (RAN) 和 Core Network 來說, 通常 Core Network 的布建較慢, 也因此在 R15 中, 特別注重 EN-DC 的發展, 也就是使用舊有 LTE 的 Core Network 以及 5GNR 的基地台,

本文是 3GPP 標準會議現況與趨勢研討會, RAN2 Status of R15 EN-DC and NR SA 的摘要. 在 5GNR 中, user plane 最大的改變是加入一層 Service Data Adaptation Protocol (SDAP), 也因此, 3GPP 設計了許多機制來確保兩邊機制的共存, 為了瞭解 SDAP 的功能, 我們先來比較 LTE 和 5GNR 的差別, 下圖是 LTE 的 QoS 機制: 在 LTE 的架構下, bearer 為點對點關係, 換句話說, 每個 bearer 都只會對應於一個 QoS 標準,

本文是 3GPP 標準會議現況與趨勢研討會, 3GPP Self-evaluation Status for IMT-2020 Evaluation 的摘要. 考慮到 5G 的發展, IMT-2020, 也就是 ITU 為 5G 所成立的組織, 設定了一系列的時程, 包含系統的提出以及驗證, 如下圖所示: IMT-2020 process 所表示的是 IMT-2020 的時程, 目前所在是 step 3, 也就是提出 5G 標準的階段, 目前提出標準的組織 (Proponent) 只有 3GPP, 在此階段要做兩件事: 第一, 準備提出的文件, 第二, 提出各項參數的模擬結果 (效能評估) 這些結果也會在 step 4 由其他獨立組織模擬驗證 (例如: ITRI, MTK), 最終才送由 ITU 進行決定.

在 802.11ax 的通訊協定中, 一個最重要的變化, 就是引入了 OFDMA 的通訊標準, 如果我們回顧 802.11 的實體層通訊協定, 從第一個世代的 DSSS 為主的架構 (802.11b, 802.11g), 到第二個世代以 MIMO-OFDM 的架構 (802.11n, 802.11ac), 802.11ax 作為下一個世代的 WiFi 通訊 (或者, 按照新的命名方式為WiFi6), 引入 OFDMA 將改變一些 WiFi 的基本想法, 在說明 OFDMA 之前, 我們先說明 OFDM 和 OFDMA 的不同, OFDM (Orthogonal frequency-division multiplexing) 是一種調變技術, 簡單來說, 此調變技術將訊號放在不同的載波 (sub-carrier) 上傳送, 在過去的 WiFi 架構下, 採用 OFDM 只是改變了某一段時間的封包傳送方式, 但是, 在時間的分配上, 仍採取不同使用者競爭的方式, 此分散式競爭方式, 簡單來說, 就是使用者透過一個存取機率, 來爭搶傳送的資源, 並避免互相的干擾, 當取得通訊資源後, 使用者就可以在一定時間內進行資料傳輸. 來自:  http://www.ni.com/white-paper/53150/zht/ 但是, OFDMA (Orthogonal Frequency Division Multiple Access) 則打破了此規則, OFDMA 進一步將 OFDM 中的載波分配給使用者, 換言之, 多個使用者可以在同一個時間使用通訊資源,

在以往對於 WiFi 的印象中, 其傳輸模式為: 來自:  http://www.invocom.et.put.poznan.pl/~invocom/C/P1-4/p1-4_en/p1-4_7_6.htm 這樣的通訊架構下, 每次傳送從一對RTS-CTS開始, 同時, 只會傳送一個封包 (Data), 同時, 對於美一個封包都有其相對應的 ACK. 然而, 之前在玩 OpenWRT 時, 看到了一個奇怪的訊息 (Block ACK), 假如理解沒有錯, Block ACK 意味著一次傳輸多個封包, 並且在 ACK 時,  一次可以給多個封包 ACK 的資訊. 這樣一來, 在 802.11 的無線通道競爭機制下, 勢必有一些問題要釐清, 例如, 連續傳送的封包是否可以在同一個競爭的時段傳輸? 連續封包傳輸的數量上限是多少?

在上一篇文章中, 說明了在 Spark 中對 RDD 操作的限制, 然而, 比較不精確的地方在於, 在 Spark 中有另一種不同於 val 變數, 稱為 var, 可以供我們進行一般的運算. 舉例來說: scala> val foo = 1 foo: Int = 1 scala> var bar = 1 bar: Int = 1 scala> bar = 2 bar: Int = 2 scala> foo = 2 <console>:25: error: reassignment to val        foo = 2            ^ 可以看到, 宣告為 val 的參數 (foo) 無法改變, 但是, 作為 var 的參數 (bar) 可以被改變.

真的開始用 Spark 之後, 才發現和原本的程式概念差很多, 其中, 最重要的一點, 就是 Spark 是從資料 (RDD) 出發, 而不是從時序運算出發... 一般來說, 當我們寫程式時, 就是按照時序將要做的事情一行一行完成, 舉例來說, 我們簡單寫一個 parser: void get_tokens(char *line, char **tokens, size_t number_of_tokens) {     static const char *delimiter = ",";     for (size_t i = 0; i < number_of_tokens; ++i) {         tokens[i] = strtok(line, delimiter);         line = NULL;     } } 簡單來說, 就是把一個字串拿進來, 按照 "," 切開, 之後再按照其長度放到一個叫做 tokens 的陣列中, 看起來十分簡單易懂, 此時的資料就像是一堆記憶體碎片般, 我們可以任意地宣告, 處理, 搬移.

在過去, 我一共寫了4篇關於 OpenWRT 架構的文章, 當時, 因為只是記錄下工作的內容, 就沒有太講究介紹的架構, 以下大概是其內容: [OpenWRT] OpenWRT 的設定 (1): 時區和同步 [OpenWRT] OpenWRT 的設定 (2): 工作排程 [OpenWRT] OpenWRT 的設定 (3): 架構 [OpenWRT] OpenWRT 的設定 (4): 網路設定 為了讓大家可以比較快了解 OpenWRT 是甚麼, 因此, 在這裡寫一篇介紹文章, 介紹一下 OpenWRT 的歷史與應用情境. Linksys WRT-54G (圖片來自Wiki) OpenWRT 是一個 Linux (busybox) 為基礎的作業系統, 在 WiFi 一開始發展時, 基本的架構就是一個微處理器, 搭配 WiFi 的處理晶片, 此時, WiFi AP 還是嵌入式系統 (如: VxWorks) 的RTOS架構進行運算, 直到 2003 年 Linksys 推出了 WRT-54G 這台 WiFi AP (802.11g), 考慮到成本, 以 Linux 作為其作業系統, 由於 Linux 開源散佈的特性, 該作業系統也被要求開源發布, 也就成為 OpenWRT 的前身, 在 OpenWRT 推出後, 震撼了消費型的 WiFi AP 市場, 許多開源的工程師發現, 這套作業系統可以用便宜的硬體, 完成舉多高階AP的功能, 也因此, OpenWRT 也就成為開發 WiFi AP 開放平台的主流.

說到 WiFi 定位, 大家直覺想到的是用於室內環境中, 事實上, WiFi 訊號對於室外的定位也有幫助, 舉例來說, Google Map 上的定位除了 GPS 之外, 也包含 WiFi 訊號的輔助.   https://support.google.com/maps/answer/1725632 "Google 會利用無線存取點的公開 Wi-Fi 資料，以及 GPS、基地台資料與感應器資料，來改善定位服務。我們只會使用公開的 Wi-Fi 資訊來推測裝置的約略位置。" 至於 WiFi 訊號如何幫助定位呢? 我們可以用下圖來表示. (其實寫這篇網誌是因為花時間畫了一張圖, 雖然, 其中沒有甚麼技術, 也和研究沒有相關, 就寫成網誌分享...) (素材來自網路)

在 Qualcomm 提出 X50 的通訊模組後, MTK 也提出了相對應的參考設計, 考慮到 MTK 沒有完整的文件說明其設計, 在此文章中, 統整一下網路上蒐集的資訊. 並著重在其 mmWave 的設計與機制. 來自:  https://udn.com/news/story/7098/3356105 在 MTK 的參考設計中, 可以很明顯地看到一組 2X4 的天線, 事實上, 在手機的正面, 有一組相同的天線, 用以對抗手握的干擾. 另一方面, 在手機的側面有散熱孔, 採風扇散熱設計, MTK 表示在正式的設計中, 會藉由功耗控制來改善散熱問題, 不過這也側面反映了 mmWave 極為耗電, 這也是普及的挑戰.

首先, 我們先回歸 WiFi 的初始, 或者, 我們用 WLAN 這個名字更能了解 WiFi 的初始設計, Wireless LAN (Local Area Network), 無線地區網路, 換句話說, 就是一個無線的路由器 (router), 在同一個 WiFi AP 下的裝置, 就像接在一個交換器 (Switch) 下, 共用相同的子網域 (LAN), 根據這樣架構設計的 WiFi AP 就是 fat AP (autonomous AP), 此處的 fat 用以形容此類 WiFi AP 擁有許多功能, 例如: DHCP, NAT, 功率與頻帶設定等, 一般我們在賣場買到的家用 WiFi AP 都屬於此類, 只要接上電, 接上網路, 設定好對外連線後就可以使用, 來自:  https://www.solwise.co.uk/downloads/files/fit-vs-fat.pdf

802.11ax 被視為 802.11ac 的後續規範, 同時, 也會是 WiFi 的未來主流版本, 在所有的特色中, 除了增加 QAM 的調變, 增加頻帶, 增加MIMO, 這些用以增加傳送速度的功能外, 有兩個有趣的功能: Spatial Reuse 和 LBT (Listen before talk) 在這篇文章中, 主要討論 Spatial Reuse 的部分, 資料來自:  https://mentor.ieee.org/802.11/dcn/15/11-15-0811-00-00ax-topics-for-consideration-for-spatial-reuse.pptx 來自: http://maxwifi.org/2018/03/07/802-11ax-max-wifi-full-picture/ 在802.11ax中, Spatial Reuse又可以分成三個方向: OBSS-Interference based Frequency Reuse Sector Based Transmission (802.11ah) Beamforming and Spatial Sharing (802.11ad)

最近看到報導, Qualcomm 的 5GNR 毫米波通訊晶片和天線已經上市, https://chinese.engadget.com/2018/07/23/qualcomm-5g-mmwave-antenna-rf-module/ 一方面, 這是一個通訊應用的突破, 在 3GPP 和 Qualcomm 的強力推動下, 毫米波通訊似乎看到曙光, 另一方面, 也讓人懷疑這項技術能走多遠, 會不會像之前的 Relay 或 CoMP, 成為一個只在標準中的技術? 5G NR 的其中一個特點, 就是對多樣型態的無線技術支援, 當我們要提升傳輸頻寬, 其中一個可能性就是使用毫米波通訊. 然而, 毫米波通訊在通訊界提出已久, 但是實際的應用一直無法實現, 因此, Qualcomm 在他們的介紹文宣中, 宣稱毫米波通訊會是他們既CDMA以來, 下一個重要突破. (Note: 本文的圖片皆來自於以下連結) https://www.qualcomm.com/invention/5g/5g-nr/mmwave https://www.qualcomm.com/media/documents/files/making-5g-mmwave-a-commercial-reality-in-your-smartphone.pdf 在5G NR中, 定義的毫米波通訊的頻帶在 24GHz 以上, 包括: 24.25-27.5 GHz, 27.5-29.5 GHz 的頻帶, 比起傳統學界所定義的 60GHz, 頻帶較低, 氧衰減也較不明顯, 但也不會是ISM頻寬, 因此, 不會和 802.11ad 衝突.

(2018.07.16_3GPP標準會議現況與趨勢研討會 - 工研院 蔡華龍 博士) 以市場面來說, V2X 可以分成兩大陣營, 美國立法以 DSRC 為車載網路的規範, 中國考慮到 DSRC 專利佈局, 則以 Cellular V2X 為主, 以通訊協定發展來說, Cellular V2X 從 D2D 出發, 同時考慮到 V2X 有專屬的 side-link 頻帶 (5.9 GHz), 打破 Cellular V2X 最大限制 (只可用上行的頻帶), 因此, 相較 D2D 以 public safety 的有限應用情境, V2X 擁有更大的商用可能性. 目前已有 Cellular V2X 的晶片組 (9150), 主要是支援 side-link 的通訊, V2I 的通訊著墨較少, 然而, 目前公開資訊較少, 無法取得該晶片的詳細資訊,

(2018.07.16_3GPP標準會議現況與趨勢研討會 - 台北大學 魏存毅 教授) V2X: vehicle-to-everything 車載網路 一開始, 是為了提供類似於 DSRC (Dedicated Short Range Communications) 服務, DSRC 為 IEEE 陣營所定義, 用意在提供車間網路服務 (V2V), 通訊方法為 ad-hoc 網路, 並用 CSMA/CA 方式進行通訊, 然而, 考慮到通訊的延遲, DSRC 提出了 RSU (Road-Side Unit), 用以輔助車間通訊, 不幸的是, 由於 RSU 的布建難以普及, DSRC 以及之後版本的 802.11P, 推出後一直以來沒有應用實現, 也成為 Cellular V2X的機會, (基地台可以作為RSU) 而 Cellular V2X 網路, 可分成兩個階段: LTE V2X: R14, R15 (和 DSRC 相容) NR V2X: R16 and beyond 按照定義可以分成三種不同網路型態, D2D (PC5): 車間網路 (V2V), 車對行人 (V2P), RSU (DSRC) D2I (Uu): 和基地台, 或是 LTE 下的 RSU 溝通

當室內 WiFi 訊號強度不夠時, 我們第一個想法就是加裝 WiFi AP, 或是 WiFi 中繼器, 然而, 加裝的 WiFi AP 間, 若是沒有實作換手協定 (802.11r) 則無法自動換手, 必須自行切換WiFi AP, 對於 WiFi 中繼器而言, 則有使用者和中繼器相互干擾的問題, https://www.pbtech.co.nz/news/1103/What-is-a-Wireless-Mesh-Network 目前的 WiFi Mesh 技術, 主要基於兩個協定: 802.11x Band Steering 802.11k Radio Resource Management Band Steering 用以平衡 802.11ac 下, 5GHz 和 2.4GHz 的資料負載, 而 Radio Resource Management 則用來管理不同 WiFi AP 間的無線資源, 為了可以平衡 WiFi AP 間的負載, 802.11k 也支援換手服務,  可以將用戶自動歸屬於信號較強的 WiFi AP,

在 OpenWRT 的預設設定中, /etc/config/network 的設定可以分成兩部分, 第一部分是CPU那一端的設定檔, config 'interface' 'loopback'        option 'ifname'   'lo'        option 'proto'    'static'        option 'ipaddr'   '127.0.0.1'        option 'netmask'  '255.0.0.0' config 'interface' 'lan'         option 'ifname'   'eth0.1'         option 'type'     'bridge'         option 'proto'    'static'         option 'ipaddr'   '192.168.1.1'         option 'netmask'  '255.255.255.0' config 'interface' 'wan'         option 'ifname' 'eth0.2'         option 'proto' 'dhcp' 在此部分, 我們可以看到, 對於 CPU 那一端的網路設定而言, 除了 Linux 常見的 loopback 網路設定外, 還有兩張網卡, 分別對應於上一篇文章中圖片內的 eth0 和 eth1, 事實上, eth0.1 和 eth 0.2 對應於同一張物理網卡, 只是虛擬成兩張網卡使用.

對於 OpenWRT 系統來說, 最重要的功能就是提供網路通訊, 而對於 WiFi AP 而言, 網路一共分成兩個角色: 作為有線網路的路由器, 以及作為 WiFi 無線網路主控節點, 而對應於 OpenWRT 的設定檔而言, 則是對應於 network 和 wireless 兩個設定檔中. 為了理解這兩個檔案的設定, 我們要先理解硬體上的設定, 我們以 TP-Link 1043 為例, 其 CPU, 有線網路和無線網路的關聯性如下圖: 來自:  https://openwrt.org/fr/toh/tp-link/tl-wr1043nd

在 Linux 系統中, cron 是一種將工作排程的方式, 關於 cron 的敘述, 可以參考鳥哥的介紹: http://linux.vbird.org/linux_basic/0430cron.php 而在 OpenWRT 中也支援 cron 的功能, 要啟用 cron 的功能, 我們要先編輯 cron 的排程列表, 輸入 crontab -e, 就可以開始編輯 cron 的工作排程, 其格式如下: 來自:  http://einverne.github.io/post/2017/03/auto-reboot-openwrt.html 簡單來說, 就是定義 分; 時; 日; 月; 周期 以及要執行的工作, 舉例而言, 我們可以定義: */1 * * * * echo "hello" 這樣就會每一分鐘都顯示一次 "hello" 訊息, 我們可以在 logread 中看到: root@OpenWrt:~# logread Jun 21 07:17:01 OpenWrt cron.err crond[1211]: USER root pid 1495 cmd echo "hello"

在完成 OpenWRT 的移植之後, 接下來就要開始設定 OpenWRT 的設置, 畢竟, 都建立了一個以 Linux 為基底的 WiFi AP, 當然會希望它可以完成比既有 WiFi AP 更多的功能. 在 OpenWRT (以backfire為例) 中, 關於功能的設定, 都放在 /etc/config 資料夾之下 root@OpenWrt:/etc/config# ls dhcp      dropbear  firewall  fstab     mountd    network   openflow  system    wireless 其中, dropbear 是 OpenWRT 的 SSH server, fstab, mountd 負責檔案系統部分, dhcp, firewall 如其名稱所示, 負責 IP 位置請求以及防火牆, openflow 為 openflow 的相關設定, network 為有線網路的設定, wireless 為無線網路的設定, 這兩部分應該會找時間再記錄細節. system 為一些系統上的設定, 例如所在時區.

在之前的一系列討論中, 說明了 802.11ad 中 beam training 的流程, 然而, 考慮到其技術和傳統 WiFi 的差異, 還是有必要特別討論以下兩點: 在進行 beam training 時, 傳送端和接收端的天線場型 由於 beam training 同時佔有了 beacon 的區間, 因此我們要討論 beam training 如何取代原有的 association 流程 針對第一個問題, 我們可以參考這篇實作的論文: O. Jo et al., "Holistic design considerations for environmentally adaptive 60 GHz beamforming technology," in IEEE Communications Magazine, vol. 52, no. 11, pp. 30-38, Nov. 2014. 在圖中 (figure 2), 明確說明不同階段下, 傳送端和接收端使用的天線場型, 其中, SLS 也就是在一開始的 beacon 階段, 此時, 只學習傳送端的天現場型, 接收端都使用 quasi-omni 的天線場型, 而之後的 beam refinement 和 beam training 才會學習接收端的場型, (這兩部分之後會再找時間詳細介紹)

在開發許多 IoT 裝置或是 WiFi AP 時, 由於這些裝置缺乏完整的程式開發的環境, 我們會需要 toolchain /cross-compiler 來輔助我們進行程式的開發, 考慮到所有程式都會編譯成執行檔, 而此執行檔的建立, 又和所使用的系統平台相關, 因此, toolchain 的主要功能即在於提供一套編譯環境, 可以讓你編譯不同平台上可以執行的程式, http://slideplayer.com/slide/11189636/ 以 Raspberry Pi 為例, 可以參考這一篇文章: https://www.raspberrypi.com.tw/tag/toolchain/ 當然, toolchain 中有許多細節, 在此不詳細敘述, 只放上來這一次針對 OpenWRT backfire 製作 toolchain 的步驟, 由於backfire版本過舊, 也列出所需要的修改.

對於雲端運算而言, 另一個問題是如何提供即時的資料處理, 在原本 hadoop 的架構下, 由於目標在處理大量的資料, 並不提供即時的資料運算, 然而, 隨著雲端運算的概念發展, 越來越多的應用需要及時結果, 因此, 也有許多平台 (如: Storm, Infosphere) 考慮了即時資料串流處理的方式, 簡單來說, 把輸入資料做為資料流, 把運算做為流節點, 提供透過各節點的處理, 可以把有用的資料留下, 作為放入儲存前的前處理, 對於此類流運算而言, 節點之間的同步成了最大的問題, 也常常是該運算架構中的瓶頸. 對於 Spark 來說, 流運算架構也基於前述的 RDD 資料結構, 而把所輸入的資料切為多個小型的 RDD, 並對每一個 RDD 進行運算, 如下圖所示: 來自:  https://spark.apache.org/docs/2.2.0/streaming-programming-guide.html

波束成型的技術, 並不只能用在60GHz, 只是在較高頻的頻帶上, 波束成型的技術能夠有較好的成果, 事實上, 在802.11ac Wave 2中, 已經實作了波束成型的技術, 並藉由4天線支援搭配MU-MIMO技術, 提供不同使用者之間, 不同天線場型的下行資料傳送, 如下圖所示: 來自:  https://blog.mojonetworks.com/mu-mimo-how-may-the-path-look-like-from-standardization-to-implementation/ 在圖中, 我們可以看到波束成型的技術的示意圖, 對於不同方向的使用者, 設計不同的波束, 最大化該方向的功率 (PEAK), 同時, 最小化對其他使用者的干擾 (NULL),

在802.11ad中, SLS (Sector Level Sweep)主要在BHI (Beacon Header Interval)中進行, 而BRP (Beam Refinement Process)則在 DTI (Data Transmission Interval)進行, 我們可以看下圖的對應關係: 來自: https://dl.acm.org/citation.cfm?doid=2915371.2915377 在DTI中, 又分成兩個部分: Contention-Based Access Periods (CBAPs)  Scheduled service Periods (SPs) 兩者的差異在於CBAP透過競爭取得, 而SP則是AP預先安排好的通道規劃使用,

在 上一篇文章 中, 我們介紹了802.11ad的beam training分類, 其中, SLS (Sector Level Sweep) 主要在 Beacon Header Interval 進行訓練, 其主要的MAC frame設計如下圖: 來自:  https://dl.acm.org/citation.cfm?doid=2915371.2915377 在Beacon Interval中, 分成兩個部分: Beacon Header Interval (BHI) 和 Data Transmission Interval (DTI), BHI用來決定天線的指向性, 而DTI則用以傳送資料, 兩者合起來的Beacon Interval則為802.11ad中的重複單元, 最大的時間長為1000 ms, 通常設定為100 ms, 用以確保延遲不會過長,

考慮到802.11ad運作在60 GHz的頻帶, 由於氧吸收和高基頻, 電磁波隨著距離衰減快速, 為了增加其訊號增益, 並考慮高基頻帶來的微小天線間距, 我們可以透過多天線技術, 來完成指向性天線設計, 背景知識可以參考以下文章: LTE筆記: 波束成型 (beamforming) 和天線陣列 LTE筆記: beamforming 和 precoding (1) LTE筆記: beamforming 和 precoding (2) 然而, beamforming的技術, 也會為通訊帶來不少問題, 考慮到原有的通訊都是基於全向性天線, 因此, 我們假設干擾也是全向性, 並設計了RTS-CTS技術, 同時, 我們也並沒有處理如何選擇天線指向的問題, 為了考慮這些問題, 802.11ad設計了兩種MAC層機制, 稱為: Sector Level Sweep (SLS) 和 Beam Refinement Process (BRP) 簡單來說, SLS是一種粗略的選擇機制, 應用於一開始的通訊建立, Rx 端使用較寬的波束 (Q-Omni) 接收, Tx輪流傳送指向性強波束, 進行學習, 而BRP則是精密的選擇, Tx和Rx都使用指向性強的波束, 如下圖所示: 來自:  https://www.researchgate.net/figure/Beamforming-training-in-80211ad_fig1_282861106

除了3GPP主導的LTE之外, WiFi通訊也是一種主流的通訊技術, 目前, 在市面上通行的WiFi協定為802.11ac, 其特色在於雙頻帶 (2.4GHz和5GHz), 8天線MIMO, OFDMA, 512QAM, 以及高傳輸速率支援 (866.7Mbps), 而表定的下一世代WiFi為802.11ax, 基本上繼承了802.11ac的所有技術特徵, 只是擁有更多天線, 並提升至1024 QAM的調變技術而已, 那麼, 標題提到的802.11ad技術又是甚麼呢? 和802.11ac和802.11ax不同, 802.11ad (WiGig) 專注於短距離高速傳輸或是戶外的應用環境, 因此, 其運作的頻帶為60GHz, 同時具有, 高傳輸量, 快速衰減, 以及指向性的特色, 以下為兩者的比較表格: 來自:  https://kknews.cc/tech/j82yke.html

在使用MLlib的Linear Regression程式中, 我們大概可以簡單地分成以下三部分:  資料讀取  Regression模型的建立  顯示計算結果 在資料讀取部分, 對應於以下程式碼: // Load training data val training = spark.read.format( " libsvm " ) .load( " data/mllib/sample_linear_regression_data.txt " ) 其目標是從 檔案 中, 取得數值並創立一個RDD, 此檔案依循libsvm的格式 (也就是key-value pair), 詳細的資料格式可以參考林智仁老師的網頁 (libsvm) 介紹: https://www.csie.ntu.edu.tw/~cjlin/libsvmtools/datasets/

Spark 相較其他平台有一個好處就是對Machine Learning的支援, 相同的, 為了利用此支援性, 我們也找其中一個範例程式來編譯使用, 在這一系列文章中, 我們將以Linear Regression為範例, 其參考的網頁為: https://spark.apache.org/docs/2.2.0/ml-classification-regression.html#linear-regression 而整份參考的程式位址如下: https://github.com/apache/spark/blob/master/examples/src/main/scala/org/apache/spark/examples/ml/LinearRegressionWithElasticNetExample.scala 在閱讀程式以前, 我們先建立Spark MLlib的編譯環境, 大致上, 流程和之前 這一篇文章 一樣, 建立專案 => 複製程式碼 => build => 執行

在Spark中, 資料的基本架構為 RDD (Resilient Distributed Dataset), RDDs 可以使用 Hadoop InputFormats (例如 HDFS 文件) 創建, 也可以從其他的 RDDs 轉換. 我們可以簡單的從一個文字檔建立 RDD, 例如: scala> val textFile = sc.textFile("README.md") 基本上, 就是從文字檔中建立一個 RDD 物件, 此時, 該 RDD 物件已經轉換成 string array 的格式, 可以透過: scala> textFile.collect() 查看, RDD 仍保有HDFS的特性, 也就是 key-value 的格式, 在 textFile 這個 RDD 中, key 就是第幾行, value 則是每行的數值, 對於所有的 RDD, 我們都有兩種操作: action 和 transformation, RDD 的 actions 從 RDD 中返回值, transformations 可以轉換成一個新 RDD 並返回它的引用. 如下圖表示: https://stackoverflow.com/questions/39311616/transformation-process-in-apache-spark

在之前介紹 SparkPi 程式時, 我們看到兩個特殊的指令: map, reduce. 我們先列出 官方指南 中的介紹: map (func): Return a new distributed dataset formed by passing each element of the source through a function func. reduce (func): Aggregate the elements of the dataset using a function func (which takes two arguments and returns one). The function should be commutative and associative so that it can be computed correctly in parallel. 簡單來說, map 就是對數據進行運算, 得到一組轉換的結果, 在 SparkPi 中, 所做的對應是藉由 Monte Carlo 方式, 取得 0 或 1的數值, 而 reduce 則是聚集數據集中的所有元素, 定義為: 對兩個參數運算, 回報一個結果, 在 SparkPi 中, 把兩個數值相加, 回報相加結果. 特別的是, 在 Spark 中, map, reduce 分屬不同類別, map 是 transformations, 而 reduce 是 actions, 定義如下: transformations, which create a new dataset from an existing one actions, which return a value to the driver program after running a computation on the dataset.

寫了一些Spark的文章, 才發現自己還沒介紹過Spark, 於是, 就把之前自己整理的一些資料放上來, 當作Spark的介紹, 在介紹中, 我將著重在Stream和ML部分的比較, 這也是未來在研究Spark時會比較重視的部分, Apache Spark 是由UC Berkeley AMP 實驗室所開發的雲端運算框架, 用來構建大型的, 低延遲的資料分析系統. 比較起其他雲端運算架構, 像是IBM的InfoSphere, 或是Strom的流計算, Spark繼承了MapReduce中根據資料位置移動計算的精神 (moves compute processes to the data), 並在此架構上, 引進了記憶體層 (in-memory) 計算的概念, 提供使用者對於暫存資料的控管, 減低在迭代時所需要的資料存取時間. 來自:  https://ogirardot.wordpress.com/2015/05/29/rdds-are-the-new-bytecode-of-apache-spark/

Spark提供以下三種程式寫作方式: python, scala, 以及java 其中, scala是其原生支援的程式語言, 理論上來說, 應該有最簡潔的架構與語法, 於是, 我們就從scala出發, 來看看SparkPi是如何撰寫, 以下是SparkPi的程式, 來自: spark/examples/src/main/scala/org/apache/spark/examples/SparkPi.scala

在 上一篇文章 中, 我們介紹了如何安裝單機版的Spark, 接下來, 為了要撰寫Spark程式, 我們要先建立Spark的編譯環境, 此時, 就要用到SBT這個套件, SBT (Simple Build Tool) 是Scala的編譯器, 有興趣可以參考:  https://www.scala-sbt.org/ 接下來, 我們就要重新創一個專案, 重新執行之前範例中的SparkPi, 我們主要參考以下連結: https://console.bluemix.net/docs/services/AnalyticsforApacheSpark/spark_app_example.html 因為有一些修改, 就把指令紀錄如下: 一開始, 先建立專案的資料夾, 把SparkPi移入, mkdir -p ~/spark-submit/project mkdir -p ~/spark-submit/src/main/scal cp /usr/lib/spark/examples/src/main/scala/org/apache/spark/examples/SparkPi.scala ~/spark-submit/src/main/scala/SparkPi.scala 接著, 設定SBT的環境: vim ~/spark-submit-example/build.sbt 貼上以下內容 (空行必須保留, Scala的版本號記得修改): name := "SparkPi" version := "1.0" scalaVersion := " 2.11.6 " libraryDependencies += "org.apache.spark" %% "spark-core" % "2.1.2" libraryDependencies += "org.apache.spark" %% "spark-sql" % "2.1.2" resolvers += "Akka Repository" at "http://repo.akka.io/

在很久以前, 曾經裝了一次 Spark 1.6 , 不過, 後來因為時間緣故, 就沒有繼續玩下去, 現在重新開始, Spark也到2.2版了, 於是就重新安裝並建立單機的測試環境開始, 希望能夠介紹一系列的Spark基礎. 主要的安裝過程參考這篇: 大數據運算系列：SPARK FOR UBUNTU LTS 16.04 安裝指引 想說這篇文章寫得很詳細就不重複列出過程了, 基本上指令複製貼上就可以完成, 有興趣安裝可以直接去引用連結, 或是去之前Spark 1.6的文章連結, 兩者只差在Spark 1.6版沒有安裝SBT, 不過, 在這篇引用文章中, 仍有一些錯誤 (或是混淆), 於是幫忙澄清一下:

在這篇文章中, 我們將依據此篇文章的說明, 解釋 beamforming 和 precoding 其中的差異: http://ma-mimo.ellintech.se/2017/10/03/what-is-the-difference-between-beamforming-and-precoding/ 在最寬廣的意義上, beamforming 和 precoding 是一致的, 兩者都在多天線的架構下, 以MIMO的通訊架構, 並基於接收端不同位置的通道資訊, 透過資料的預先處理, 提高接收端的SINR, 以及系統效能, 但若是我們進一步細分, 則可以把 beamforming在分成兩種: digital beamforming 和 analog beamforming, 如下圖所示: 來自:  http://ma-mimo.ellintech.se/2017/10/03/what-is-the-difference-between-beamforming-and-precoding/ 其中, 數位 beamforming 就是 上一篇文章 中說的 precoding 技術, 該技術為每一根天線的資料設計 precoder, 並分別在每一個天線上傳輸不同資料, 而類比 beamforming 則是一般指涉的 beamforming 技術, 此時, 每一根天線的資料都相同, 差異的只有資料間的相位差,

對於MIMO (Multi-input Multi-output) 系統來說, beamforming和precodeing都是重要的干擾抑制技術, 然而, 這兩個詞語, 卻也在一定程度上造成混淆和誤用, 在這一系列文章中, 我們將嘗試解釋其中差別, 在介紹beamforming和precodeing兩者差異之前, 我們先簡短介紹一下MIMO, MIMO簡短來說, 就是傳送端和接收端都有多根天線, 而不同的天線之間, 就有不同的通道, 如下圖所示: 來自: https://zh.wikipedia.org/wiki/MIMO

在5G的技術中, 其中一個新被引入的通訊技術就是波束成型 (beamforming), 波束成型技術可以大略的分成兩種: 第一種、藉由量測到的通道係數, 設計傳送參數 (precoder), 最佳化通道 第二種、透過多天線的相位偏移 (phase shifter), 決定電波傳遞強度模 在文章中, 會著重介紹第二種波束成型的架構, 在第二種波束成型的架構中, 所使用的是電磁波干射的物理特性, 簡單來說, 透過電磁波的建設性干涉與破壞性干涉, 我們就可以在某個方向上產生一個較強的訊號, 而在其他方向上減低此訊號的影響. 來自:  https://en.wikipedia.org/wiki/Phased_array 在上圖中, 我們可以發現這種波束成型架構的兩個需求: 1. 必須有多根天線服務同一筆傳輸訊號 2. 每個天線都必須要有一個相位調節器 (phase shifter)

在所有 IoT 應用中, 除了穿戴裝置和感測器外, 另一個常被討論的應用就是車載網路, 不同於上述兩種應用, 面臨藍牙, LoRa, OneM2M的競爭, 車載網路由於其反映延遲和安全性的需求, 主要仍在 3GPP 的架構下討論, 稱為 V2X (Vehicle-to-everything). Note: 還有 802.11P 的 DSRC, 不過, 不在此文討論... 事實上, 在目前的架構中, V2X又 可以大概分成4個部分: V2V (車對車), V2I (車對號誌), V2N (車對網路), 以及V2P (車對行人) 如下圖所示: 來自:  https://www.hksilicon.com/articles/1453396 目前主要推動國家為中國大陸和美國, 圖片連結 有詳細的沿革紀錄, 可以了解雙方推動 V2X 網路重點的不同.