Castle on a Cloud

來自: 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

在上一篇文章中, 介紹了 BLE 5.0 的新功能, 其中, 其中有一項是 2Mbps 的物理層傳輸速率, 然而, 我們真實量測的網速為在 MAC 層的網路速度, 我們在計算 BLE 5.0 真實的 throughput 時, 必須考慮其 MAC 層的機制, 才能找出真實傳送時的速度. (事實上, 還要計入個層封包的 header 冗餘, 才能反映真實速度) 在 BLE 5.0 中, 影響 throughput 的 MAC 層因素包括下列四點: 每一個 Connection Interval 中的封包數量上限 封包間隔時間 (Inter Frame Space, IFS) 的長度 (150 ns) 用以回應 ARQ 的空封包 MAC 層的 header 冗餘 首先, 我們先看 MAC 層的冗餘, BLE 封包格式如下: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 在 BLE 4.2 之後, payload 長度為 244 bytes, 在使用 2M PHY 時, 對應的 PDU 長度為 266 (2+4+257+3) bytes, 換句話說, 傳送一個封包中, 資料佔 244/266 的比例. 接下來, 我們要回答在一個 Connection Interval 內可以傳幾個封包, 這個問題來自於兩個限制: 第一, Connection Interval 必須高於所有封包 + IFS 的總時長 第二, 來自硬體 (BLE 晶片) 以及作業系統的限制, 當需要設計一個高速應用時, 要特別注意此來自於裝置與作業系統的限制, 並根據需求選擇適合的 Connection Interval 長度. 在接下來的討論中, 我們先忽視第二點限制, 來考慮所有封包所產生的總時間長度, 在 BLE 中, 下一個回傳的封包為傳送的封包的 ACK, 考慮到一個單向的 BLE 應用 (只有 master -> slave 的資料回報), 此時回傳的封包為一個空封包 (沒有 payload), 因此, 一次資料交換的流程為: IFS + data packet + IFS + empty packet, 如下圖所示: h

本篇文章來源為:  https://www.novelbits.io/bluetooth-5-advertisements/ BLE 5.0 號稱有三大改良: 網速從 1Mbps 提升至 2Mbps 傳輸範圍提升 4 倍 廣播封包的 throughput 提升 8 倍 不過, 這些改良並不是同時完成, 和 BLE 4.2 相比, BLE 5.0 提供了兩種新的 PHY 層格式, 分別是對應高傳輸率的 2Mpbs (LE 2M), 以及透過錯誤更正碼保護對應高傳輸範圍的 PHY 層協議 (LE coded), 其中, 三種 PHY 層的協定如下圖所示: 來自:  https://www.novelbits.io/bluetooth-5-advertisements/ 在上表中, 我們可以看到, 當使用 LE coded 來延伸傳輸距離時, 傳輸速率並沒有提升, 反而是下降, 另一方面, 在廣播封包 (advertising) 部分, 和 BLE 4.2 相比, 新增了一種新的 Adverting, 稱為: Extended Advertisements, 和舊有的 Adverting (Legacy Advertisements) 相比, 新的規格可以使用所有的頻帶 (不只是 36, 37, 38), 也因此, 可以提供較寬頻的廣播通訊, 此功能應該是應對於 BLE Mesh 的技術, 考慮到 BLE Mesh 是以 Advertising 封包傳送, 其有效 throughput 並不高, BLE 5.0 可以針對此部分進行提升, 其基本想法也是在 {36, 37, 38} 上發送起始的封包, 並在 {0-36} 將剩餘封包傳輸, 因此, 此類的 Advertising 封包傳送機制, 就非常類似於舊有 BLE 中的一般封包傳送, 只不過, 現在傳送的對象是一整群的定閱使用者.

參考資料: https://www.cnblogs.com/iini/p/8977806.html http://leconiot.com/download/cc2640r2f/ble_stack_app/app_examples/exchange_mtu/exchange_mtu.html http://www.wowotech.net/bluetooth/le_encryption.html https://www.cnblogs.com/hzl6255/p/4127138.html http://www.wowotech.net/bluetooth/ble_connection.html https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 在藍牙通訊中, 我們可以先看一下整體的封包格式,  在這一篇文章中, 我們將先看到 PDU 這一層, 之後若有時間, 會繼續說明 L2CAP 和 ATT 的機制. 在 BLE 中, 基本的通訊單元稱為 PDU (Protocol Data Unit), 如下圖所示: 其中, Preamble 是用以辨別封包的開始, 大小為 8 個 bits, 分成兩種型態: 01010101, 10101010 Access Address, 則根據廣播封包或是通訊封包而不同, 廣播封包的位址固定為: 0x8E89BED6, 通訊封包則根據建立連線的對象而改變. CRC 則是用以保護 PDU 的資料傳輸. 在這篇文章中, 我們先專注在通訊封包的格式, 進入 PDU 封包後, 我們可以列出更詳細的資料格式: 其中, header 一共有 16 bits, 前 8 個 bits 的資訊為 LL header (Link Layer), 後 8 個 bits 為資料長度, 詳細說明如下: LLID (2): 指示接下來的封包為 L2CAP, 或是 LL control PDU NMSN (1), SN (1), MD (1): BLE 的 ARQ 和 Flow Control 機制 (之後會說明) RFU (3): 保留字元 (Reserved for Future U

[摘錄自 簡均哲博士 於交大的演講] URLLC 為 3GPP 在 5G 標準中定義的一種型態, 全名為: Ultra-Reliable and Low Latency Communications, 分成兩項: Reliable (可靠性) 以及 Low Latency (低延遲), 主要應用的範圍可以是: AR/VR, 或是車聯網的應用, 在 3GPP R15 至 R16 的演進中, 可以總結於下圖: URLLC R15 和 R16 的技術演進 在這張圖中, 說明了 R15 和 R16 的技術差異, 其中, 相較於 R15 URLLC 的標準, 在 R16 中, 除了延遲的縮減從 10ms 到 1ms 之外, 特別著重在傳送效率以及高可靠性上, 增加其適合的應用場域. URLLC 使用以下的技術來達成低延遲與高可靠性: 更彈性的傳送架構: 引入 mini-slot 和不同優先權, 彈性配置傳送資源 預先的資源保留: 為突發的傳送需求, 提供預先的傳送資源配置 冗於的傳送機制: 同一筆資料來自於多個來源, 傳送多次, 來保證可靠性 透過上述技術, URLLC 可以用於以下的 Use Cases R15: AR/VR 的低延遲傳輸 R16: Factory automation, Transport Industry, Electrical Power Distribution 下圖列出三個應用案例的需求: 相較 R15 專注在一個 UE, 且在單純的 URLLC 下通訊, 在 R16 中, 更重視多個 UE 之間的資源分配, 或是在 URLLC 和 eMBB (Enhanced Mobile Broadband, eMBB) 共存的環境, 可以用於像是工廠自動化這種複雜的環境, 為了解上述問題, R16 希望可以把 URLLC 和 eMBB 分開, 並賦予優先權, 使 URLLC 的傳輸可以較快被服務. 同時, 也要增加 UE 的能力, 使 UE 有較好的能力 monitor 通道的 DCI, 可以較快取得傳輸的機會, 在增加冗餘保證可靠性的改善上, URLLC 有兩種做法: 第一, 可以用較低的 code rate 來傳送, 降低封包錯誤機率, 此方法有較高的通

在 BLE 通訊協定中, BLE 裝置透過 Advertising 告知周邊 BLE 裝置自己的存在, 其中, 考慮到 WiFi 的干擾, Advertising 封包在以下 3 個 bluetooth channel 上廣播: channel 37 (2402 MHz), channel 38 (2426 MHz), 和 channel 39 (2480 MHz), 我們可以利用下圖來了解其中干擾的關係: 來自:  https://www.infsoft.com/technology/sensors/bluetooth-low-energy-beacons 對於 connection 之後的資料傳輸, 則使用其他 bluetooth channel 進行通訊, 並藉由展頻通訊 (跳頻) 的方法, 對抗 WiFi 通訊產生的干擾, 透過不同的通訊目標, BLE 設計了 4 種不同的 advertising 的方式, 如下表所示: Advertising PDU Description Max Adv Data Len Max Scan Res Len Allow Connect ADV_IND Used to send connectable undirected advertisement 31 bytes 31 bytes Yes ADV_DIRECT_IND Used to send connectable directed advertisement N/A N/A Yes ADV_SCAN_IND Used to send scannable undirected advertisement 31 bytes 31 bytes No ADV_NONCONN_IND Used to send non-connectable undirected advertisement 31 bytes N/A No (來自:  Bluetooth Low Energy Scanning and Advertising ) Advertising Data (Adv Data) 代表在 advertising 封包中自帶的資訊, 在 BLE 中, 此資料的長度為 31 bytes. 更多的資訊可以透過 Scan

在一般 BLE 裝置中, 不同的連線階段也扮演不同角色, 一般來說, 可以分成這四種 GAP Roles: GAP Role Description BROADCASTER A device that only sends advertising events. OBSERVER A device that only receives advertising events. PERIPHERAL A device that accepts the establishment of an LE physical link using the connection establishment procedure. CENTRAL A device that supports the Central role initiates the establishment of a physical connection. (來自: Bluetooth Low Energy Scanning and Advertising ) 其中, Broadcaster 和 Observer 為一對, 進行 adverting 通訊, Peripheral 和 Central 為一對, 進行資料傳輸, 為了表示此 4 種 GAP 腳色, BLE 可以表示為以下狀態機 (State Machine) 的轉換: 來自:  https://iot.electronicsforu.com/expert-opinion/improving-battery-life-in-bluetooth-low-energy-connected-things-part-2/ 其中, 我們可以看到 Connection 和 Advertising 分屬不同的狀態, 以 one-hot state machine 的概念來說, 在一個時間內應只屬於一個狀態, 至於上述 4 個 GAP Role 則使用了狀態機不同的部分, 如下圖所示: 來自:  https://iot.electronicsforu.com/expert-opinion/improving-battery-life-in-bluetooth-low-energy-connected-thin

在過去的 LTE 系統中, 主要有兩種不同的 REF signal, 也就是: PSS (Primary Synchronization Sequence) 和 SSS (Secondary Synchronization Sequence), 這兩個訊號除了進行同步之外, 也幫助 UE 搜索並辨識基地台, 相關資料, 可以參考:  https://note-on-clouds.blogspot.com/2017/12/lte-sync-cellsearching.html 除了 PSS 和 SSS 之外, 還有一種在傳輸中重複出現的訊號, 用以進行下行的通道估測, 稱為: Cell-Specific Reference Signal (CRS) CRS 訊號會按照一固定模式在 frame 中重複出現, 如下圖所示: 來自: C. Hoymann, D. Larsson, H. Koorapaty and J. Cheng, "A Lean Carrier for LTE," in IEEE Communications Magazine, vol. 51, no. 2, pp. 74-80, February 2013. 這樣的架構, 理所當然地讓基地台必須持續傳送 CRS 訊號, 雖然可以提供下行通道的良好估測, 但也使基地台無法省下傳送能源, 事實上, 對於基地台而言, 省電的議題一直以來都不是優先考慮的項目, 畢竟, 對於大基地台 (marco eNB) 的應用情境, 基地台通常是接電, 全功率服務, 同時, 考慮到覆蓋範圍, 基地台的休眠機制, 也未曾列入考量範圍. 然而, 針對 5G NR 的應用情境, 大量的小基地台加入提供異質的接取, 此時, 繁雜的 CRS 訊號不只造成基地台無法休眠, 進而產生能源的浪費, 也造成了小基地台之間嚴重的相互干擾, 因此, 在 5G NR 的 lean carrier 的機制中, 取消了 CRS 訊號的傳輸, 取而代之的, 加入了 extended synchronization signal (eSS), 如下圖所示: 來自: C. Hoymann, D. Larsson, H. Koorapaty and J. Cheng, "

在 5G NR 中, Numerology 這個詞語對應於 Frame Structure, 這個詞語的中文意義有點難以翻譯, 直譯為: 數秘術, 在 Wiki 百科中的定義為: 數秘術, 是指物象化成數字的占卜, 如姓名學是用筆畫數. 這個字詞的來源許久, 可以追朔到希臘哲學, 當時, 數學, 宇宙學, 對世界的解釋, 是被連結在一起的, 考慮到數學的簡潔性, 許多哲學學派, 如畢達哥拉斯學派, 就將數字和宇宙的美感連結在一起, 並嘗試用數字來解釋觀察到的一切, 這樣的嘗試, 等於是將現實世界的觀察, 塞入一個理想模型中, 考慮到真實世界的不完美性, 以及一些錯誤假設的模型, 這樣的詮釋漸漸走入神祕主義, 也從科學術語, 過渡成占卜術的術語, 現在常見的搜尋結果, 就和生命靈數, 姓名筆畫等, 有較多的連結, 這也是一種術語的不可共量性, 好吧, 雖然這裡有許多故事可以說, 但我們還是回到 5G NR 的系統, 在 5G NR 中, 定義了 5 種不同的子載波 (sub-carrier) 間隔, 分別是: 15 KHz, 30 KHz, 60 KHz, 120 KHz 和 240 KHz. 相較於 4G LTE 網路只有一種間隔 (15 KHz), 5G NR 考慮到不同的頻帶特性 (sub-6 GHz, 28 GHz) 定義不同的間隔, 如下圖所示: 來自:  https://www.slideshare.net/3G4GLtd/beginners-5g-numerology 在上圖中, 我們可以看到, 對應於不同的頻帶有不同的子載波間隔, 最小的數值為 15 KHz, 之後為 2^n 的倍率成長, 15 KHz 的選用主要是和 4G LTE 向下相容, 同時, 考慮到 4G LTE 所使用的頻帶為 700 MHz, 等效可以拿到的頻寬資源較少, 使用 15 KHz 可以增加頻帶的利用效率, 對於較高頻的通訊而言, 較大的子載波間隔可以提供較短的時間延遲, 並減少 FFT 電路設計上的要求. 關於 4G LTE 的相關文章, 可以參考: https://note-on-clouds.blogspot.com/2015/12/lte-frame-time.html 雖然子載波間隔改變,

[改寫自 itcom 2019 陳儒雅博士的演講] 2020 年, 被描述為 5G 的元年, 隨著越來越多的裝置以及網路布建成形, 5G 網路的上線, 對於大眾來說, 似乎是近在眼前, 但對於學術界來說, 卻也是一個好時機來檢視電信研究的發展, 所謂的 5G 網路, 和我們之前討論/想像的 5G 網路有甚麼差別? 來自:  https://www.slideshare.net/DrDavidSoldani/soldani-the-pathto5gvtcspring2017final 根據 roadmap, 我們可以看到原本三位一體的 5G 網路: eMBB, URLLC, mMTC, 將專注在前兩項 (尤其是 eMBB, 也就是電信網路的部分), 主要仍是透過提高傳輸速度, 提供給使用者高速的上網體驗, 這部分也和我們目前看到的 5G 宣傳符合, 例如: 高傳輸率, eMBB ( 連結 ), 低延遲性 URLLC ( 連結 ) 至於 mMTC 則先交由 NB-IoT 來進行. 在技術項上, 則從三方面提出改進: 頻譜利用效率: Massive MIMO, channel coding, mini slot , lean carrier 其中, 前兩項是 phy 層直觀的改進, mini slot 對應於 low latency 的應用, lean carrier 修改了 MAC 層的機制,  取消 REF signal, 會產生比較有趣的改變 頻譜延伸: sub-6G, mmWave (28 GHz, 39 GHz) 針對 mmWave, 我們需要 beam sweeping , 增加頻寬從 20 MHz -> 100 MHz, 並加入省電的機制 ( bandwidth parts ) 以及針對變動的頻寬不同的調變技術 ( multiple numerologies ) 網路密集化: 小基地台與不同接取技術 (RAT) 的整合 4G / 5G 的共存, 小基地台的布建與基地台間的協作   其中, 值得注意的是, New Waveform 和 NOMA 不含於這次的標準中, 原因就是, 雖然在理論上有改善, 但實務上卻沒有顯著性, 作為學術界的一員, 雖然沒有參與 NOMA (Non-Orthogo

在過往的 BLE 應用中, 其網路架構為點對點通訊, 換句話說,  藍牙連線的兩端, 為 master - client 的架構, 對於這樣的通訊連線, 兩個裝置在進行連線的開始, 會先藉由在特定頻帶上的廣播訊息 (advertising), 取得連線的需求, 先交換雙方跳頻序列 (hopping sequence), 為之後展頻通訊進行準備. 考慮到 BLE 的架構, 連線兩端分享共同的 hopping sequence, 在此通訊框架上, 難以擴展成廣播, 或是一對多通訊的模式, 在舊有的 BLE 星狀網路 (star network) 中, 雖然支援一對多的網路架構, 但對 master 節點來說負擔頗重, 對於多個 client 連線時, 也會導致資源分配下降, 在 2017 年, BLE 也提出了 Mesh 的架構, 其主要的想法在於: 透過廣播訊息和 relay 方法, 將傳輸資料從原始節點擴散出去, 如下圖所示: https://wiki.makerdiary.com/nrf52832-mdk/mesh/ 考慮到 BLE 的特性, 我們可以看到所有的節點必須分享相同的 hopping sequence, 同時, 節點 (Ndoe) 透過廣播 (ADV bearer) 將資訊傳出, 接著, 這些資訊再透過 Relay 節點 (Relay Node) 把資訊向外轉傳, 轉傳的數量, 則透過 TTL (time-to-life) 來限制轉傳的次數, 此流程稱為 message flooding. 此方法可以方便的建立一個 BLE 區域網路, 特別適用於智慧家庭等應用環境, 而無須特別針對裝置連線設定, 然而, 另一方面, 則會犧牲了傳送的 throughput, 對於大量的資訊流量而言, 也將因為相同的 hopping sequence, 而產生如 WiFi 般封包碰撞的問題, 而減損的展頻通訊抗干擾的能力, 比較適合 IoT 網路中, 小資訊的資訊 (如: 溫度, 狀態等) 回報.

回顧行動網路 (telecom) 和電腦網路 (datacom) 之爭, 其中一個爭論要點, 就是分散式架構與中央式架構, 結果, 在邁向 5G 的今日, 我們可以看到兩者的融合發展, 一方面, 3GPP 陣營思考在小基地台架構下, 賦予基地台更多權力, 甚至讓資料可以不透過核心網路, 就在裝置間進行交換, 另一方面, WiFi 陣營, 在 802.11ax 的版本中, 也引入了更多 scheduling-based 的機制, 而非透過競爭解決, 以目前的趨勢觀看, 5G 的共識應該會是小基地台架構, 分散式的小基地台接取 (減少網路產生的延遲), 以及小基地台內的中央調控式資源分配 (增加頻譜利用率), 最後, 留下的問題仍然是: 要如何處理小基地台間的干擾, 對此, 雙方都有一些看法, 但最終有效方案仍未明... 好吧, 閒聊到此為止, 回到主題, 對於 downlink 的 MU-MIMO, 在之前 WiFi 的協定中已經定義完成, 主要透過 AP 將不同使用者的封包, 放在同一個 OFDM 區間中, 分時傳送不同使用者的資訊, 如下圖 (左) 所示, 原始圖片來自:  https://www.slideshare.net/CiscoCanada/cisco-connect-winnipeg-2018-optimizing-your-clients-wifi-experience-v4-public 圖右是 802.11ax 加入的新機制, 也就是 OFDMA 機制, 簡單來說, OFDMA 允許 AP 對資源做更詳細的切分 (對時間和頻率), 而不只是分時傳送資料給使用者, 增加頻譜的利用效率, 考慮到 downlink 的特性, 封包統一由 AP 配置後發出, 此部分的修改, 的確可以有效的減少使用者競爭, 但是對於 uplink 而言, 事情就沒有這麼簡單, 考慮到在舊有的 WiFi 網路中, 使用者各自競爭通道資源, 其中並沒有機制能讓 WiFi 使用者 "共同的" 在同一時間中分享通道資源, 為了解決此困難, 在 802.11ax 中定義了 uplink MU-MIMO 的機制, 如下圖所示: 來自:  https://www.ni.com/zh-tw

在之前的文章中, 介紹了在新 WiFi 協定中討論的空間重複利用方案, 而在這一篇文章中, 則是介紹在 802.11ax 實作的方案, 主要內容來自:  https://blog.aerohive.com/dueling-navs-in-802-11ax/ 在介紹 802.11ax 特殊的 NAV 機制之前, 我們先介紹標準 802.11 下的標準 NAV 機制 (RTS-CTS 機制), 原始的 RTS-CTS 機制 NAV  為 Network Allocation Vector 的簡寫, 當使用 RTS-CTS 傳出機制時,  在 RTS, CTS 封包中, 都會在 duration field 中填入 NAV 的長度, 當其他使用者收到 RTS/CTS 封包時, 會根據 NAV 的長度, 凍結 backoff window, 換句話說, 在宣告的 NAV 時間內, 都不會嘗試傳送封包 原本的 RTS-CTS 機制是為了解決 hidden node/explore node 問題, 然而, 考慮其實作的方式, 只可以解決 hidden node (潛在的干擾), 但是, 對於 explore node (潛在的傳送機會), 卻沒有幫助, 在此保守的設計下, 使用者當聽到附近基地台的訊號時, 也會停止嘗試傳送封包, 特別是在一般 WiFi 網路下, 由於 AP 使用的功率高於使用者不少, 容易發生由 AP 發送的 RTS 阻斷多數使用者傳輸機會的狀況, 對於密集佈建的 WiFi 網路而言, 將減低網路效率. 因此, 802.11ax 設計了一個新的 NAV 機制, 將 NAV 分成 Intra-NAV 以及 Basic NAV,  對應於鄰近網路的 NAV 以及所屬網路的 NAV, 如下圖所示: 來自:  https://blog.aerohive.com/dueling-navs-in-802-11ax/ 在 802.11ax 的機制下, 可以針對此兩種 NAV 設定不同的門檻, 換句話說, 對於 Intra-BSS NAV, 可以設置一較高的門檻, 只有其能量夠高 (隱含距離較近), 才設置 NAV 的保護, 而對於相同 AP 下的 NAV, 門檻較低

不太確定放在此類別是否正確, 不過, 之前 node.js 的程式碼都歸於此類別, 也就先暫時這樣分類吧... 主要參考的內容如下: http://larry850806.github.io/2016/06/16/nodejs-async/ https://www.tutorialspoint.com/nodejs/nodejs_callbacks_concept.htm node.js 為平行化 (非同步) 架構, 因此, 當我們執行一個 function 時, 會先放入 event loop 中, 並在背景繼續執行其他程式流程, 如下圖所示: https://blog.outsource.com/2018/09/26/understanding-the-event-loop-in-node-js-outsource/ 此平行化架構, 不同於 c / java 按程式一行一行執行的架構, node.js 可允許同時執行多項程式, 有利於利用多執行緒處理, 然而, 當一個程式需要另一個程式的結果時, 就需要 callback 來完成. 舉例來說: var fs = require('fs'); // fs.readFile(filename, callback(err, content)) fs.readFile('test.txt', function(err, content) {     var str = content.toString();     console.log(str.length);     console.log('finish'); }); console.log('not finish'); 此程式目的為讀一個檔案 (test.txt) 並顯示長度, 紅字部分為 callback 部分, 在這部分的程式將等到 readFile 執行完之後才會執行, 執行結果如下: $ node callback.js not finish 245 finish 我們可以看到先出現: not finish, 來自於最後一行的程式: console.log('not finish')

對於室內定位的應用而言, Bluetooth 由於其低功耗, 普及, 以及覆蓋範圍小等特性, 一直以來, 都是室內定位的熱門選擇, 在過去, Apple 就曾經以信號強度 (RSSI) 為依據, 推出室內定位用的 iBeacon 作為定位的解決方案, 其定位精度約為 1-5 公尺. 在新的 Bluetooth 協定中, 加入了 AoA/AoD 的支援, AoA (Angle of Arrive) 只需要接收端有多天線系統 (傳送端可為單天線), 可以分辨來自不同天線訊號的時間/相位差, 就可以計算出傳送端相對接收端的角度資訊, 類似的, AoD (Angle of Departure) 則要求傳送端有多天線系統, 就可以藉由 ACK 等資訊, 計算出接收端相對於傳送端的角度資訊, 來自:  http://dev.ti.com/tirex/content/simplelink_academy_cc2640r2sdk_2_30_02_00/ modules/blestack/ble_aoa/ble_aoa.html 在 Bluetooth 5.1 中, 距離資訊仍是來自於 RSSI 訊號強度, 而不是用 ToA (Time of Arrival) 來取得距離資訊, 這應該是因為希望和過往的 Bluetooth 裝置相容, (ToA 需要裝置間同步與硬體的支援, 無法相容於之前的裝置) 因此, 只希望修改 Bluetooth Gateway 的硬體與演算法, 來提供定位的結果. 在目前的架構下, AoA 資訊的取得, 的確能夠改善定位誤差, 特別是在直視路徑 (LoS, Light of Sight) 的環境中, 然而, 針對 Bluetooth 定位所遇到的其他問題, 例如: 過多的布建數量, 仍無法提出解答, 同時, 考慮 AoA/AoD 對於天線排列的要求, 如何提供一種均一, 容易開發, 且準確的 AoA/AoD 資訊, 將會是此標準能否廣泛應用的關鍵.

參考:  https://www.opencli.com/perl/python-install-mysqldb 和 Java, C 引入 library 的方法不同, 對 python 而言, 所使用的套件需要先安裝 (如這篇文章), 或是, 將 make 好後的檔案放入指定路徑 (如 libsvm 的方法), 在這篇文章中, 使用 pip 的方式, 安裝連接 mySQL 的套件, 因此, 第一個步驟, 就是安裝或是升級 pip: $ apt-get install python-pip $ pip install -U pip 如果在升級 pip 後, 出現以下錯誤: Traceback (most recent call last):   File "/usr/bin/pip", line 9, in <module>     from pip import main ImportError: cannot import name main 需要修改 /usr/bin/pip 中的變數為: from pip import __main__ if __name__ == '__main__':     sys.exit(__main__._main()) 接著, 安裝必要套件與 python 插件: $ apt-get install python-dev libmysqlclient-dev $ pip install MySQL-python 我們一樣寫一隻簡單的程式來操作 mySQL database, 參考自:  http://www.runoob.com/python/python-mysql.html import MySQLdb db = MySQLdb.connect("localhost", "USERNAME", "PASSWORD", "DB_NAME", charset='utf8' ) cursor = db.cursor() cursor.execute("SELECT VERSION()&q

參考:  https://blog.csdn.net/letsseehow/article/details/10483729 首先, 利用 wget 下載 libsvm, 並解壓縮, 下載網址請參照 libsvm 的官網:  https://www.csie.ntu.edu.tw/~cjlin/libsvm/ 或是直接用此連結: libsvm連結 假設解壓縮完的資料夾路徑為: ~/libsvm-3.23 需要 make 兩次, 一次在 ~/libsvm-3.23, 另一次在 ~/libsvm-3.23/python/, 完成後, 應該可以找到: ~/libsvm-3.23/libsvm.so.2 把檔案移到 python2.7 的資料夾下, 指令如下: sudo cp ~/libsvm-3.23/python/*.py /usr/lib/python2.7/dist-packages/ sudo cp ~/libsvm-3.23/libsvm.so.2 /usr/lib/python2.7/ 接著, 我們來寫一個簡單的 SVM 測試程式: from svmutil import * from svm import * y, x = [1,-1], [{1:1, 2:-1}, {1:1,2:1}] prob  = svm_problem(y, x) param = svm_parameter('-t 0') model = svm_train(prob, param) yt = [1] xt = [{1:1, 2:-1}] p_label, p_acc, p_val = svm_predict(yt, xt, model) print(p_label) 其中, y 是 label, x 是分類輸入, 舉例來說: {1:1, 2:-1} 代表有兩個 feature, 第一個數值為 1, 第二個數值為 -1, svm_parameter 為 SVM 所用到的參數, 請參照 libsvm 的說明, yt, xt, 則是用來 testing 的資料, 執行結果如下: $ python svmtest.py * optimization finished, #iter = 1

工研院 陳仁賢 博士 @ 交通大學 3GPP標準會議現況與趨勢研討會 5G NR 的目標: 使用兩個不同的頻帶 (sub-6GHz, mmWave-28GHz) 在此兩個不同通道特性的頻帶上, 提供一致的通道接取 來自:  https://news.samsung.com/global/everything-about-5g-samsung-publishes-5g-nr-standards-whitepap 4G LTE 的通訊協定 (TDD 部分) TDD 有 7 種不同的配置 (靜態, 固定) 使用 CP 保護 data (CP 長度和 coverage 相關) sub-carrier spacing: 15 KHz  對於 5G NR mmWave 的新問題: 通訊距離過短, 需要 beam-training 的技術 => 需要大量的資訊回報, 較適合 TDD 的架構 Small cell => 覆蓋範圍變小 => 減少 CP 的需求 => 縮短 CP, 或是拉寬 sub-carrier spacing Small cell => 動態的 UL/ DL 的需求 => 使用者少, UL/ DL 的使用需求隨著時間改變 => 動態的 TDD 分配架構 => slot configuration 更寬的頻帶使用, 20MHz => 200 MHz => 寬頻帶來大量的 sub-carrier, 以及 FFT 的需求 => 推升電路複雜度, 並使裝置更耗電 => Bandwidth Part (BWP) => 只接收部分的頻寬 5G NR 的新框架: 動態的 sub-carrier spacing 以 15 KHz 作為一個單位 (numerologies = 0) 15 KHz * 2^n (n = 0, 1, 2, 4) 不同的設定對應到不同的 CP 長度 來自:  https://www.slideshare.net/3G4GLtd/5g-nr-key-features-and-enhancements 5G NR 的新框架: dynamic TDD 模式 3 types of OFDM symbol

在之前的 文章 中, 我們介紹了如何建立一個 json-server, 通常, 這樣的架構是為了作為 RESTful API 的介面, 在文章的安裝步驟中, 事實上, 有暗示此 JSON server 是以 NodeJs 的架構撰寫, 考慮到 NodeJS 對網頁端的支援, 也的確是一個合適的選擇. 傳送到 json-server 的資訊將被放到一個 .json 文件中暫存, 然而, 考慮到 json-server 並非設計作為資料庫使用, 當暫存資料過大時, 就會讓讀取/寫入失去效率, 因此, 我們需要寫一隻程式, 從 json-server 中取值, 處理, 再刪除數值, 架構如下圖所示: 資料處理的架構 當然, 更好一點的架構是直接用 NodeJs 來架設 REST API Server, 但考慮到平台的熟悉程度, 還是先用寫好的套裝程式來改, 應該比較穩定一些, 雖然犧牲不少效率... 在實作範例中, 我們使用 node-rest-client 作為開發套件, node-rest-client 建立在 NodeJs 之上, 可以參考: https://www.npmjs.com/package/node-rest-client 在其官網上, 有許多範例, 因此就不再多述如何安裝 node-rest-client, 以及每一個 REST 函數的呼叫, 在進入程式之前, 只提醒兩件事情: NodeJs 有原生的平行化架構, 因此, 當使用多個 client 時, 要注意每個 client 的執行並不會依照程式的順序. 相同的, 由於平行化架構, global variable 的存取順序可能和預期不同, 要自己想好順序, 並包在同一個 client 中. 因此, 本程式的目標流程有以下三個: 讀取 json 總數 => 取出最後一個 json 物件 => 刪除最後一個 json 物件 以下是所實作的程式: var Client = require('node-rest-client').Client; var client = new Client(); // get the number of json object // refer to the &

為了建立一個簡單的網頁介面, 我們在 Linux (ubuntu 16.04) 上建立一個標準的網頁開發環境, 也就是所謂的 LAMP: Linux, Apache, MySQL, PHP 這部分滿簡單的, 可以參考:  https://jerrynest.io/ubuntu16-04-wordpress/ 只需要輸入以下指令: sudo apt-get update sudo apt-get upgrade sudo apt-get install lamp-server^ sudo apt-get install phpmyadmin 其中, phpmyadmin 為一個可以透過 php 讀取 mySQL 的介面, 完成安裝之後, 記得把 php 網頁專案放到 /var/www/html/ 底下, 確保外部的存取, 指令如下: cd /var/www ln -s /usr/share/phpmyadmin 完成後, 可以透過 http://yourip:port/phpmyadmin 來查看 mySQL 的設定, 進入網頁後, 帳號為 root, 密碼為安裝 mySQL 時輸入的密碼, 就可以利用圖形化介面操作 mySQL, 接下來, 要建立一個動態網頁的環境, 在動態網頁的架構下, 通常我們將網頁分成三部分: 框架 (html), 排版 (css), 計算 (php), WordPress 是一個基於 PHP 技術的網頁模板, 並提供大量的模板參考, 在參考的文章中, 使用 apt-get 的方式來安裝 WordPress, 但在實測環境中, 因為不是純粹的 localhost 環境, 並透過 NAT 進行 port-to-port 的對應, 因此無法直接套用生成的 config 檔. 因此, 我們參考 WordPress 的教學, 直接對環境進行設定. 教學來自:  https://codex.wordpress.org/Installing_WordPress 此教學分成 5 個部分, 下載 WordPress: wget https://wordpress.org/latest.tar.gz 設置資料庫 (帳戶和表格), 可以透過 phpMyAdmin 來設置 設置 wp-

[2D vs. 3D beamforming] 5G NR 中的 beamforming 的技術主要利用天線陣列, 以及控制每一個天線陣列的相位, 來達成波束指向, 因此, 當天線排成一列時, 方向在一個平面上切換, 為 2D beamforming, 當天線排成一個長方形時, 方向可以在一個錐狀空間切換, 為 3D beamforming, 我們可以將各式排放方式以下圖表示: 來自:  http://www.sharetechnote.com/html/5G/5G_MassiveMIMO_FD_MIMO.html 圖片引用的文章中, 有 beamforming 的技術細節, 有興趣的讀者可以閱讀, 以下內容, 主要摘要自:  http://4g5gworld.com/blog/3gpp-stands-fd-mimo-3-d-beam-forming 在 3GPP R13 的規範中, 將 beam forming 的技術推廣至 3D, 此技術可以支援 Active Antenna System (AAS) 技術, 在此技術中, 討論一個 2D 的天線陣列, 擁有 8 個以上的 TXRUs (transceiver units), 每一個 TXRU 擁有獨立的震幅 (amplitude ) 和相位 (phase) 控制, 來自:  http://4g5gworld.com/blog/3gpp-stands-fd-mimo-3-d-beam-forming 而在最近 3GPP 會議 (3GPP TSG RAN #65) 中, 就討論要如何驗證其效能, 該研究分成兩個階段: 在第一階段: 將探討不同數量 TXRU 的影響 (8, 16, 32, 64), 並探討同構與異構在不同情境下的效能, 與可行性研究. 每一個 TXRU 的大小, 間距, 頻率以及極化設定, 並決定如何為其建立虛擬化的模型 在 R12 MIMO 的架構下模擬其效能, 設定為: 8x1 的天線陣列 (水平擺放於基地台頂端), 並分別模擬 Macro (3D-UMa) 和 Urban Micro (3D-UMi) 兩種不同設定 在第二階段: 在Macro (3D-UMa) 和 Urban Micro (3D-UMi) 兩種不同

此 db.json 文件中, 定義了三種不同的 JSON 資源: posts, comments, profile, 並定義每一種資源的內容, 以 posts 為例, 就是: id, title, author, 要去存取此 JSON 資源最簡單的方式, 就是透過 URL, 但也有一些方便的工具, 例如: postman, 可以讓我們快速開發, 以下為操作範例, 首先, 我們先測試 POST (開立一個新的 JSON 項目), 首先, 我們要先輸入 JSON Server 的位址與對應的 JSON 資源 (http://localhost:3000/posts) 接著, 到 Body 的部分填入數值, 選擇 x-www-form-urlencoded 的格式, 按照定義, 我們在 posts 資源中, 有 title, author 兩個項目, 填入對應數值, 接著, 回到 Params 的項目, 輸入 id 也就是主要的查詢鍵 (key), 在這裡 id 的數值會自動是 posts 中最低數值加一, 在下方的視窗中, 我們就可以看到產生出來的 JSON 格式, 按下送出後, 也可以看到來自 JSON Server 的回應: 201 Created 從此回應也可以用來確認是否程式有問題. 所輸入的資料也就會保存在 db.json 這個文字檔中, 我們可以在 JSON Server 上透過 vim 打開 db.json, 可以看到多出來的一個條目: "posts": [ { "id": 1, "title": "json-server", "author": "typicode" }, { "id": 2, "title": "newline", "author": "jxk" }, { "title": "xxx", &q

在建立一個簡易的 JSON Server 之後, 我們可以來簡單的測試一下其功能, 在開始之前, 我們先介紹一下 JSON 以及 RESTful API 的一些基本概念, RESTful (REpresentational State Transfer) API 的名稱雖然有點難以解釋, 不過可以簡單的想像這是一個建立在 HTTP 協定上的一種通訊規格, 其特色就是透過 URL (網址, IP 和 port 的組合) 對資源進行操作, 而所謂操作對應到 HTTP 協定中的: GET, POST, PUT, DELETE, GET 為查詢 JSON 資源, 只需要填入正確的 URL, 例如: http://localhost:3000/posts/1, 就是查詢 id 為 1 的 posts JSON 內容, POST 為發布一個新的 JSON 資源,  PUT 為更新一則 JSON 資源, 至於 DELETE 則是刪除某一則 JSON 資源, 這部分, 我們會在下一篇文章中利用 postman 來作操作範例, 在一般的網頁瀏覽中, HTTP 承載的內容格式為 HTML (以靜態網頁為例), 並透過瀏覽器將 HTML 的資源轉成圖文並茂的網頁內容, 但在 RESTful API 中, 承載的內容則為 JSON 或是 XML, 其共通之處在於透過 key-value 的形式儲存資料, 而其中, JSON 又因為其輕量簡便的特性, 而受到廣泛的使用. 在上一篇文章中, 我們以 json-server db.json 開啟一個 JSON Server, 其中 db.json 就隱含了 JSON 的格式, 我們可以將此文件打開, 內容如下: { "posts": [ { "id": 1, "title": "json-server", "author": "typicode" } ], "comments": [ { "id": 1, "body": &q

沒想到也會有要寫 JSON 的一天... 由於按照網路上的教程都無法好好在 Ubuntu 16.04 環境上, 建立 JSON Server, 因此記錄一下自己安裝的步驟: 以下是參考過的資料: https://andy6804tw.github.io/2018/02/01/json-server-intro/ https://oomusou.io/json-server/intro/ https://medium.com/codingthesmartway-com-blog/create-a-rest-api-with-json-server-36da8680136d https://blog.csdn.net/csqingchen/article/details/48495353 https://stackoverflow.com/questions/47767370/package-npm-has-no-installation-candidate 在教程中, 只要一行指令就可以完成 JSON Server 的安裝: npm install -g json-server 然而實際操作之後, 在 16.04 上安裝會出現以下兩個問題: 第一, 存取權限的限制, 這個部分使用 sudo 就可以解決: sudo npm install -g json-server 第二, nodejs 的版本過舊 (4.2.6), 因此, 使用以下兩個指令: sudo npm install n - g sudo n stable 這兩個指令 (作為版本管理) 來升級 nodejs 的套件, 升級後, 就可以適用上述指令安裝 JSON Server. 完成後, 輸入 json-server db.json 就可以從 localhost:3000 看到 JSON server 的介面,  如下圖所示:  這樣就可以確定完成了 JSON Server 的安裝, 接下來, 我們會進一步去研究怎麼進行簡單的操作, 包含: PUSH, GET, POST 的常見的 RESTful API 操作

對於 WiFi 系統而言, 省電的需求主要在用戶端, (因為 WiFi AP 通常是直接連上電源) 因此, 在省電模式的設計上, 也著重在下行的省電機制. 基本的機制和想法很簡單, 就是 WiFi AP 藉由 TIM (Traffic Indication Map), 告訴使用者, 是否需要在這一個 Beacon Period 中醒來接收資料, 由於 TIM 只會表示該使用者是否仍有資料需要下載, 因此, 還需要配合一個 DATA 的標示, 來表示該使用者的封包是否已經傳輸完成, 若是 DATA more = 0, 則使用者在接收完下一個封包後, 就可以回歸睡眠模式 (sleep), 直到下一次 Beacon 的時間, 來確認是否有下行的封包. 對於 multi-cast 和 broadcast 的封包也是一樣, WiFi AP 也會先暫存這些封包, 直到使用者醒來接收. 流程如下圖表示: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/Enterprise-Mobility-8-5-Design-Guide/Enterprise_Mobility_8-5_Deployment_Guide/ch5_QoS.html 當使用者在 sleep 模式時, 並不會進行 CSMA/CA 的通道存取, 同時, 使用者可以根據自己的電力需求, 每隔數個 Beacon Interval 起來聽 TIM 的訊息, 此間格又稱為 Listening Interval, 此數值較大有較佳的省電效果, 但是也會造成較嚴重的封包延遲. 當使用者收到 TIM 封包時, 有兩種模式開始接收下行封包, 第一種如上圖所示, 使用 polling 的方式向 WiFi AP 索取封包, 當有大兩使用者同時離開 sleep 模式時, 將會產生競爭, 假設 WiFi AP 暫存許多下行封包, 以方法的效率較低, 另一種方法則是告訴 WiFi AP 離開 sleep 模式, 此方法由於可以和其他傳輸機制結合, 如 Block ACK 等, 在有大量下行封包需要傳送時, 比較有效率. 詳細的資訊可以參考以下的延伸閱讀: (包括 frame 架構的解說) https: