Castle on a Cloud

[註: 本篇文章原載於台大 MOOC 網站, 由於網站已無法連結, 故在此重新發文備份] 在上一篇文章中，我們介紹了Google Classroom。Google Classroom結合了Google文件、Gmail和Google網路硬碟所提出的教育資源平台，然而熟知Google的朋友們都知道，Google的武器絕對不止於電子郵件、雲端儲存以及文件編輯，事實上，Google也不滿足於提供Google Classroom這種較為靜態的教學模式，而是想藉由MOOC的浪潮，看看開放教育能做些甚麼。 於是， Google 在 2012 年基於所開設的課程： Power Searching with Google ，發展一個開放的 MOOCs 課程設計工具： Course Builder ，在 2013 年 9 月宣佈與 edX 合作，希望打造 MOOC.org 平台，擴展開放的 MOOC 資源從原本高等教育導向的課程，轉向社會大眾中的每一個人，就像 YouTube 一樣，每一個人都可以自由地在 MOOC.org 上開課分享自己的知識。 按照規劃， MOOC.org 原本應該在 2014 年上半年提出，卻因種種原因延遲，因此，在這一篇文章中，我們將把重點放在 Google course builder 上，看看 Google 怎麼結合旗下的資源，提供 MOOC 課程開發的環境。 Google course builder 是一個以 Google APP Engine(GAE) 為基礎的開發環境。 GAE 是一套公眾雲端運算 (public Cloud) 的服務，不同於 Amazon 以虛擬機這種基礎計算資源作為公眾雲端的切入點 (Infrastructure as a Service ， IaaS) ， GAE 提供一種雲端計算平台服務 (Platform as a Service ， PaaS) ，在 GAE 的平台上，你只需要調動樣板以及資源的需求，就可以建立一個動態網站，至於，在後台的伺服器與流量管理，就由 Google 來提供，減少使用者所需的技術門檻。 就算有 GAE 的幫忙，使用 Google course builder 的樣板仍需要一些技術背景，包括 HTML 以及 Java Script ，若...

[註: 本篇文章原載於台大 MOOC 網站, 由於網站已無法連結, 故在此重新發文備份] 早上7點，被Android智慧手機的鬧鐘吵醒，看時間時順手同步一下Gmail的信箱，沒有新的郵件，決定再賴床一下。到了公司，Google行事曆提醒下午1:30有一個會議要舉行，趕緊把Google Drive上的文件寄出。午休時，打開Chrome瀏覽器Google美食，一邊聽著YouTube的音樂，一邊用Google talk和朋友聊天，討論下班要去哪裡聚餐。下了班在捷運上，玩著Google play上下載的小遊戲打發時間。出了捷運站後，利用Google map的路徑規劃，找尋目標餐廳的地點，趕到聚餐地點和朋友見面。回到家中，設定Android智慧手機的鬧鐘和明天的行事曆，結束這一天。 是的，你的生活已經被Google所佔據，不論是手機、瀏覽器、搜索引擎與電子郵件，所有你在網際網路上的存取與活動，都是透過Google的大門，走入寬廣的網際網路之中，然而，Google並未心滿意足，他們仍然努力的滲透進一個又一個的生活領域，包括教育。 Google Classroom是Google for Education專案在2014年8月所提出的教育平台。Google Classroom的標語是：「More teaching, Less tech-ing」，也就是說，希望藉由科技的輔助，減少老師花費在課程雜務的時間 (例如：收作業、改作業、發布班級公告)，而有更多時間準備課程內容，增進教學品質。Google Classroom結合了Gmail的電子郵件聯絡、Google doc的線上文件編輯以及Google Drive的網路雲端硬碟，提供老師和學生們一個便利的教育資源平台(Course Ware)。 在Google Classroom中又分成了三個分頁：Stream(訊息串)、Student(學生)和About(關於)。Stream是目前課程進度，包括作業與公告，Student是學生管理的頁面，About則是課程的內容介紹以及教材。 Google Classroom有兩種方式可以加入課程，一種是學生以課程代碼的方式加入課程，比較特別的是，此課程代碼只有開課的老師知道，不提供以搜尋的方式查詢課程，另一種則是由老師把學生加入，然而，卻要求老師事前擁有...

在 前一篇文章 中, 我們說到 container 技術可以減低虛擬機的 overhead, 因此, 下一個問題就是, container 是怎麼做到的? 其技術特徵和虛擬機的技術差異為何? 事實上, container 的概念主要來自於 linux 的多工與分離, 就像是我們高中程式課在工作站寫 c code 的經驗, 不同使用者, 以不同帳戶同時登入同一台主機, 每個使用者有自己的空間 (namespaces), 分隔獨立的程式 (PID), 並共享工作站的資源 (CPU, 記憶體, 以及硬碟等), 這樣的概念就是最基本的 container 的由來. 不過, 上述的行為只解釋了對於檔案系統與程式的隔離, 接著, 在工作站環境中, 另一個問題就是, 假如有一個使用者寫了一個無止盡的 while loop, 將拖慢所有人的速度, 為了避免此狀況發生, cgroup 在 2006 年被提出, 用以限制, 控制與分離一個行程群組的資源 (例如: CPU, 記憶體, 磁碟輸入輸出等), 可以參考:  https://access.redhat.com/documentation/zh-tw/red_hat_enterprise_linux/6/html/resource_management_guide/ch01 https://delftswa.github.io/chapters/docker/ 在上圖中, 我們介紹了 namespaces 和 cgroup 的功能, 剩下來相關的套件, SELinux, capabilities, AppArmor, 和安全性相關, Netlink 和 Netfilter 則和網路虛擬化相關, 在下一篇文章 (2) 中, 我們預計先研讀網路虛擬化的部分, 安全性則先跳過, 之後 (3) 再往上介紹 libvrit, LXC, systemd-nspawn 三個模組, 最後 (4) 則是比較 docker 和 linux container (如: LXC) 的不同. 預計先透過這一系列四篇文章介紹 docker 的基礎, 並在之後繼續介紹 kubernetes 的技術 [Update]  Docker使用的Linux核心模組功能包括下列各項： ...

在之前, 當我們說到雲端, 想到的是一套虛擬機管理系統 (如: OpenStack), 提供不定使用者按照需求的計算資源 (以虛擬機的數量和規格計算), 隨著雲端的發展, 網路虛擬化加入 (基於 OpenVSwitch 或是 SDN 技術), 因此, 網路資源的使用與計費也加入雲端運算的列表中, 並開始有基於流量的 scaling 技術成熟, 使得 "按需求計算 (On demand)" 變成 "動態調整計算 (Auto-scaling)." 一般而言, 雲端運算仍圍繞著虛擬化的概念打造, 尤其是虛擬機, 透過虛擬化技術, OpenStack 可以將硬體資源切割成多個獨立的單元, 保證各運算單元之間的獨立性, 以及所可以取用的計算與網路資源, 提供遠端使用者一致的介面進行操作, 然而, 虛擬機也成了雲端運算的瓶頸, 考慮到所帶來的 overhead, 當計算需並非隨時間改變時 (通常一說是工作週期 > 0.3~0.5), 自己建構伺服器就變得更為有效的選擇. 對此, 雲端運算有兩種回應方式, 例如 OpenStack 使用的 KVM 技術就走向半虛擬化 (共享 Linux kernel), 或是更極端的, MaaS (Metal as a Service) 直接租借實體機, 這些不同的變化, 一方面讓雲端有更多樣的選擇, 另一方面也反映出雲端運算所受到的限制. 來自:  https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ 在所有的虛擬化技術中, Container 是一個有趣且有潛力的方法, 其中, 最為大家熟知的 Container 技術大概是 docker, 然而, Container 事實上並不是一個新的技術, 也不一個為了虛擬化所研發的方法, 其技術比較像是一組設定, 將一群執行續困在一個沙盒中, 藉由限制其對系統資源的存取以及網路虛擬化, 來模擬一個虛擬的計算空間, 稱為 Container. 和傳統的虛擬化技術不同, Container 並沒有虛擬完整的 IO 介面, 比較起來, 更近似於一群程式, 因此, 無法直接復用 OpenStack 等既有系統, 但是, ...

在 5G NR 中, 加入了 28 GHz mmWave 的通道, 由於其通道衰減快, 天線小的特性, 使得許多基本的通訊方法要重新設計, 其中, 最重要的即是波束指向 (beam sweep) 技術, 波束 (beam) 所指的是利用天線陣列將電磁波往特定方向集中, 在之前的文章中, 我們已有些許介紹, 例如: LTE筆記: 波束成型 (beamforming) 和天線陣列 LTE筆記: beamforming 和 precoding (1) LTE筆記: beamforming 和 precoding (2) 同時, 也針對 5G NR 中的應用有一些介紹: LTE筆記: 5G NR mmWave (Qualcomm X50) LTE筆記: 5G NR mmWave (MTK M70) LTE筆記: 3D beam-forming in 3GPP 不誇張的說, mmWave 以及其所帶來的 beam sweeping, 應當是 5G 通訊中最為重要的技術突破, 也是其 New Radio 的由來, 在 5G NR 中, beam sweeping 分成三個階段: Initial gNB Beam Acquisition gNB Beam Refinement UE Beam Refinement 5G New Radio (NR) : Physical Layer Overview and Performance 簡單來說, 一開始 gNB (5G 基地台) 先針對不同波束進行 SSB 廣播, 使用者 (UE) 就可以從 SSB 中知道自己是被哪一個方向的波束服務, 5G New Radio (NR) : Physical Layer Overview and Performance 然而, 考慮到如果方向切得過細, 將使 gNB 花許多時間廣播 SSB 訊息, 因此, 在初始時, 波束不會太細, 直到 Beam Refinement 時, 才透過 CSI-RS 的資訊交換, 確定更細的波束, 到此為止, 是 gNB 的波束選定, 在確定 gNB 波束後, UE 也可以透過切換不同波束, 取得 ACK, 來決定使用者端的波束選定. 事實上, 類似的波束搜尋技...

在 4G LTE 的時代, 每一次 LTE-A 的升級, 最佳宣傳總是 CA (Carrier Aggregation, 載波聚合) 的技術, 一方面是 CA 可以為使用者帶來更高頻的傳輸速度, 另一方面, CA 也考驗電信商的頻譜, 藉以宣稱自己是最佳的服務提供者, 然而, CA 所帶來的並非全是好事, 更寬廣的頻譜意味著更加耗電, 以及更複雜的電路設計, 同時, 寬頻的接取也只發生在少量使用者的情境下, 在真實的使用情境下, 則需要有一個有效的排程機制, 才能隨著使用者需求的改變, 動態調整傳輸使用的頻寬. 而此問題在 5G NR 中就變得更加的複雜, 一方面, 不同於 4G 的環境, 跨越了不同的頻帶, 以及物理特性, 在物理層的設計上也加入了對各頻帶的適應性設計, 例如, 在之前文中所說明的 Lean Carrier 以及 Multiple Numerology, 因此, 在所使用的頻寬上, 5G NR 也提出了 Bandwidth Parts, 也就是讓使用者隨著通訊的需求, 動態調整使用的頻寬, 如下圖所示: TR38.300 Fig 6.10 在圖中我們可以看到頻帶的調整可以分成兩類:  BWP1 -> BWP2: 在同一個中心頻率下, 更改使用的頻寬 BWP2 -> BWP3: 中心頻率改變 考慮到此兩類不同的操作, 3GPP 中也給予不同的切換時間限制, 在目前的標準定義 (38.211) 中, 主要針對 sub-6 GHz 進行標準的規範, 分成三種: intra-band (只改變頻寬): < 20 us intra-band (改變頻寬與中心頻): 50-200 us inter-band (改變頻寬與中心頻): < 900us 資料來自:  https://ziyubiti.github.io/2018/03/07/5gnrbwt/ 同時, 一個 BWP 對應於 UL 或是 DL 的傳輸, 一個使用者最多同時可以有 4 個 BWP 進行資料傳輸, 使用情境如下: 來自:  https://newsletter.mediatek.com/hubfs/mwc/down...

來自: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 我們一樣從 BLE 的封包封裝開始介紹 L2CAP 協定, 在之前的介紹中, 我們介紹了 LL (Link Layer) 層的通訊協定, 在 LL 層的 payload 中, 我們可以加入更上層的封包格式, 在 BLE 協定中, 其中一種上層協定稱為 L2CAP (Logical Link Control and Adaptation Protocol), L2CAP 中主要負責功能如下: 封包的分段 (Segmentation) 重組與拆解 重傳與資料流控制 (Flow Control) 封裝 (Encapsulation) 與排程 (Scheduling) QoS 機制的支援 相對於底層封包傳送以 PDU (Packet Data Unit) 為單位, L2CAP 上層應用可以以 SDU (Service Data Unit) 來傳送資料, 一個 SDU 的大小最大可以為 64 KB, L2CAP 協定會將一個 SDU 按照 PDU 的大小進行重新切分與重組, 並將一個 Service 虛擬成一個邏輯通道 (L2CAP Channel), 讓上層應用進行存取. 為了完成上述功能, L2CAP 由兩個部分組成: Channel Manager, Resource Manager, 如下圖所示:  Figure 1.1: L2CAP architectural blocks in "Logical Link Control and Adaptation Protocol Specification" 對於一個 L2CAP Channel 而言, 對應一個 Channel ID (CID), 一個 CID 對應於一個 P2P 的 BLE 連線, 基於一個 CID, L2CAP 提供 Flow Control 與重傳機制, 對於 L2CAP 底下的 PDU 而言, L2CAP 提供檢查 CRC 和重傳機制, 考慮到 LL 層本身的重傳機制, PDU 會在連線失敗之前不斷重傳, L2CAP 實際上的 Flow Control 機制為控制 PDU ...