Castle on a Cloud

參考資料: 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 來傳送, 降低封包錯誤機率, 此方法有較高的通