發表文章

目前顯示的是 十一月, 2019的文章

[BLE] 藍牙的通訊封包格式與 ARQ 機制

圖片
參考資料:
https://www.cnblogs.com/iini/p/8977806.htmlhttp://leconiot.com/download/cc2640r2f/ble_stack_app/app_examples/exchange_mtu/exchange_mtu.htmlhttp://www.wowotech.net/bluetooth/le_encryption.htmlhttps://www.cnblogs.com/hzl6255/p/4127138.htmlhttp://www.wowotech.net/bluetooth/ble_connection.htmlhttps://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 PDUNMSN (1), SN (1), MD (1): BLE 的 ARQ 和 Flow Control 機制 (之後會說明)RFU (3): 保留字元 (Reserved for Future Use)Data Length (8): 表示資料長度 (0-255)* 雖然資料長度最長為 255, 但要扣掉 MIC 4…

[5GNR] 3GPP URLLC 的進展

圖片
[摘錄自 簡均哲博士 於交大的演講]

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 來傳送, 降低封包錯誤機率,
此方法有較高的通道使用效率, 但是延遲較長
第二, 對於較短的資訊, 則用重複的方式來確保可靠性,
此方法有時造成傳送資源的浪…