# 無線通訊與網路 Wireless Communications and Networks ## Physical Layer - **Frequency allocation**:頻段會被分配給不同用途,像是手機、雷達、無線電之類的 - **ISM**:Industrial, Scientific, Medicine,各國挪出某一段頻段主要開放給工業,科學和醫學機構使用。使用這些頻段無需許可證或費用,只需要遵守一定的發射功率(一般低於1W),並且不要對其它頻段造成干擾即可 - 如何描述波: ![image](https://hackmd.io/_uploads/HkTUG7kixe.png =60%x) ### Modulation and keying - **Modulation**:調變。如何把訊號轉成能在通道中傳遞的形式,可以指類比或數位訊號 - **keying**:可看作是Modulation的數位特例,如何把在通道中表示、傳遞0、1訊號 - **ASK**:Amplitude Shift Keying,用振幅變化表示 - **FSK**:Frequency Shift Keying,用頻率變化表示 - **PSK**:Phase Shift Keying,用相位變化表示 ![image](https://hackmd.io/_uploads/BJXV4mkilg.png =60%x) 圖中每單位只能表示0或1,但還有 **++Q++PSK** 之類的,PSK表示是PSK,Q表示每單位能表示4種訊號,也就是2個bit;8PSK則是能表示3bit - **Demodulation**:接收方要解調變 - **Carrier Synchronization**:送/收方使用的頻率要一致,但可能因為相對速度(衛星)、溫度、設備老化之類的走鐘 - **Bit Synchronization**:訊號單位的起始點要對齊 - **Frame Synchronization**:從什麼時候開始/結束是一個 packet(封包) 要對齊 ### 干擾 - Source of distortion - **Attenuation**:衰減,因為距離 - **Reflection/Refraction**:反/折射 - **Diffraction**:繞射 - **Scattering**:粗糙表面的散射 - **Doppler fading**:都卜勒效應 #### Attenuation - *Friis* **free-space equation** 用來描述遠場通訊因距離導致的訊號強度衰退 - $P_{tx}$:送出來的強度 - $G_t、G_r$:因送/收方天線形狀之類的帶來的天線增益 - $\lambda$:波長,波長愈短愈不容易繞射愈容易被吸收愈容易衰減,向遇到雨滴之類的 - $L$:是啥 ![image](https://hackmd.io/_uploads/Hk0gXEJoel.png) ![image](https://hackmd.io/_uploads/S1sWL4Joex.png) #### Distortion:Non-line-of-sight path - **LOS**:Line of sight,兩點之間的直線路徑 但無線通訊會有不是直線的傳輸路徑,雖然可以克服直線方向被遮擋的問題,但也要解決其他問題,比如說不同路徑長表示抵達收方的時間不一樣,會有延遲 ![image](https://hackmd.io/_uploads/H16uI4Joxl.png =60%x) ![image](https://hackmd.io/_uploads/rkX0v4Jsge.png =70%x) - **path-loss exponent $\gamma$** 因為剛剛 free-space equation 沒考慮牆壁之類的遮擋物,所以多引入一個 $\gamma>2$,讓訊號強度距離不只以距離平方衰減 另外單位要轉成 dB 就是取log乘10(樵夫很誠實) ![image](https://hackmd.io/_uploads/S1L4dVyoge.png =60%x) - 牆壁之類的障礙物很難用數學描述,所以直接用一個變異數$\sigma$的高斯隨機變數 $X_\sigma$ 表示 (那跟 $\gamma$ 差在哪? $\gamma$ 是控制距離對信號的影響程度,表示的是更均勻的環境品質,可能水氣雜質之類的) ![image](https://hackmd.io/_uploads/HyW0cEkoge.png =60%x) #### Noise and Interference 剛剛都是原訊號的 distortion 而已,現在來說別人造成的干擾 - **Noise**:收方電子設備內部的訊號干擾,比如說熱躁訊很難去除 - **Interference**:別人的訊號 - Co-channel interference:別人跟你用同樣頻段,那就直接撞爛 - Adjacent-channel interference:別人頻段在你附近,雖然沒有直接重疊,但收方的 filter (嘿 帶通濾波器) 太爛沒辦法只把目標頻段獨立濾出來 小整理,收到的訊號可能會 - distorted by channel - disturbed by noise and interference 那會對各bit造成什麼影響呢? #### Symbols and bit errors - **SINR**:**S**ignal to **i**nterference and **n**oise **r**atio,訊雜比,就是 $\frac{收到的信號強度}{外部干擾強度}$,有時候不考慮外部因素 **I** 就會是 **SNR** 是判斷信號還能不能用的評斷標準,通訊設備會有辦法量測這個值(how??)來決定當前 channel 能不能用,太糟可能換其他種 Modulation,或是放棄通訊 ![image](https://hackmd.io/_uploads/SkOL04Joll.png =50%x) - **BER**:bit error rate,幾個bit中會壞1個bit,5G或其他G會要求這個值要低於某個限制,10^7^ 之類的 而 SINR 可以用來算 BER - $0.5e$:常數 - $E_b$:每個收到的bit的能量 - $N_0$:noise power ![image](https://hackmd.io/_uploads/H18OxS1jxx.png =40%x) (右上角指數其實就是每個bit版的SINR,但為什麼要除阿?不是本來就是 ratio 了嗎?除了的意思是SINR分母的噪聲不管甚麼時間多長都是一樣的值嗎?不是功率嗎?沒錯,分母 $N_0$ 是平均每 Hz 頻寬的噪聲功率,不管時間多長都一樣,而且看起來 SNR 分子的功率單位是 per Symbol) 太爛就要換一種調變方式 ![image](https://hackmd.io/_uploads/rkMRzHyslg.png =65%x) #### Channel models 描述 channel - **AWGN**:Additive White Gaussian Noise model $r(t) = s(t) + n(t)$:收=送+躁,就醬,他們都是有時間t的函數 - **Rayleigh fading**:適用於沒有 line-of-sight path 但很多 indirect path 的情形 - **Rice fading**:一個主要的 LoS 跟其他許多 indirect path 後兩者參數都很多,至於實際要代多少值進去,需要到該環境實際測量 ![image](https://hackmd.io/_uploads/SJ7-Dryjxx.png =55%x) - **BSC**:binary symmetric channel,不考慮實際物理了,直接當作每個 bit 都有機率壞掉(bit間彼此獨立)的究極簡化模型 ![image](https://hackmd.io/_uploads/BkVXIBJoxe.png =60%x) - Typical Wireless Sensor Network:大家都用小功率近近的通訊,省電又不容易干擾到別人 - channel 很爛的話,改善通訊品質: - **頻道編碼** (Forward Error Correction, FEC) 在傳送端加入冗餘資料,讓接收端即使收到部分錯誤的資料,也能自行檢測並修正錯誤 - **自動重傳請求** (Automatic Repeat-reQuest, ARQ) 接收端檢測到錯誤時,會要求傳送端重新傳送資料。 #### Choice of Modulation 根據需要的 - data rate - symbol rate - BER - ... 去選擇要用哪種調變 C/N 跟 SNR 差不多,總之愈高表示這個channel愈好,可以用更高效的調變方式 FEC 是冗餘之類的,總之只有這比例的 bits 有用 ![image](https://hackmd.io/_uploads/HJoYPH1oeg.png) #### Energy Issue 雖然也可以用很強的訊號強度來把噪聲蓋過去來提升SNR,但要射出 1mW 的訊號通常需要 30~100mW 的能量 ## Link Layer - **Error Control**:make sure that the sent bits arrive and no other - **Framing**:group bit sequence into packets/frames - **Link Management**:discovery and manage links to neighbors ### Error Control - **要點** - **Error-free**:deliver exactly the sent bits/packets - **In-sequence**:deliver them in the original order - **Duplicate-free**:at most once - **Loss-free**:at least once - **Cause** - fading, interference, loss of bit synchronization, … - **Approaches**: - Backward error control, **ARQ**:送了再說 - Forward error control, **FEC**:先處理再送 #### Backward error control 送了再說 ##### Basic procedure - **Duplicate-free/in-sequence**:Put header information around the payload - **Error-free**:Compute a checksum and add it to the packet. (e.g. CRC) - **Loss-free**:Provide feedback from receiver to sender (ACKs) ##### Automatic Repeat-request, ARG 出錯就重送 - **Alternating bit protocol, ABP** 給 message 加一個 bit,照順序輪流標0/1,收端收到以後回傳 ACK0 或 ACK1,送端確認收到ACK0/1,才繼續送下一個1/0。缺點是送端每 packet 都要等 ACK,慢,所以後兩個方法是ACK累積起來再一次送 - **Go-back N** 一次送 N 個 packet,收端只會回傳1個ACK,for the last correct in-order frame,比如說送端送了1234567,收端收到123 567,那收端只會送 ACK3,並把567都捨棄,送端知道後,從4開始繼續送 N 個 packet - **Selective Repeat** 送端送123456,收端收12 4 6,收端會把收到的都記著(所以會需要 buffer),並要送端重送3 5 什麼時候重送? - **Probing protocol**:如果丟包了就進入 Probing mode,觀察丟包情形,如果現在 channel 很爛就先暫停不送 #### Forward error control, FEC 不用重送,直接加點神奇 bits,讓收端自己糾錯還原正確訊息 常用以下兩種,這邊就不講實際機制 - Reed-Solomon codes (RS) - Bose-Chaudhuri-Hocquenghem codes (BCH) ![image](https://hackmd.io/_uploads/HJMlEv-hxl.png =90%x) - **Inter-leaver**:干擾通常是持續一段時間,FEC如果是連續N個bit都爛掉很難還原,所以把順序打亂編碼,還原後,干擾會四散不連續,比較容易還原 - **Code rate**:原本有 k 個symbol,FEC 編碼成 n 個 symbol,則 code rate 為 $\frac{k}{n}$,亦即編碼有幾%是有用的資訊 考慮 symbol 為 0、1 的情況,則 n、k 須滿足 $2^{n-k} \ge \sum_{i=0}^{t} \binom{n}{i}$ 才能應付最多 t bit 出錯的情形 #### ARQ v.s FEC ARQ 只有重送會有 overhead;FEC 一直都有 overhead ![image](https://hackmd.io/_uploads/B1N-OP-nxx.png =60%x) ### Framing BER 固定的話: - **Small packets**:++low packet error rate++, high packetization overhead - **Large packets**:++high packet error rate++, low overhead 左圖:訊號好的話,大封包有效率;但訊號差的話,大封包容易壞,要一直重送 右圖:大封包有效率但容易壞 h(overhead, payload size, BER) ![image](https://hackmd.io/_uploads/SyYhKv-3le.png) ![image](https://hackmd.io/_uploads/r1RKiw-3gx.png) ### Link management Goal: decide to which neighbors that are more or less reachable $\Rightarrow$ Establish a neighborhood table for each node 等損耗線不會是一個圓,而且是非對稱的 $\Rightarrow$ 送過去很好,不代表送過來會很好,重點是收方環境 ![image](https://hackmd.io/_uploads/rkA1avZ2gl.png =50%x) 但我們資工不用那麼難,當作兩個圓分成三區就好:超讚、有點糟、超爛 ![image](https://hackmd.io/_uploads/B1x_pD-2xg.png =50%x) 通訊範圍指的可以是 - 小圈圈:以內必收的到 - 大圈圈:以外不可能收的到 要講清楚 判斷 Link quality ![image](https://hackmd.io/_uploads/r1MDxOZhxg.png =60%x) ## MAC Layer Medium Acess Control,主要處理 CA (Collision Avoidance) 可參考 [計算機網路 (J.F. Kurose)](https://hackmd.io/-7cQaBF4Ro2tO9Mai2lEug#channel-partitioning) ### Collision Avoidance 1. **Reservation based**:預先分配媒介使用權,但需要中央控制器 `e.g.` TDMA、FDMA、CDMA 2. **Contention based**:動態根據通道狀況去搶使用權 `e.g.` (Slotted)ALOHA、CSMA、MACA 3. **Hybrid** `e.g.` DAMA #### Reservation based ##### TDMA Time division multiple access 每個節點在分配到的 time slot 傳送,來避免彼此間互相碰撞 ![image](https://hackmd.io/_uploads/ryN58etTxl.png =50%x) ##### FDMA Frequency division multiple access 每個節點在不同的 frequency 做傳送以免互相干擾。Guard Band是保留的頻帶,目的是為了減少不同頻帶之間的干擾。 ![image](https://hackmd.io/_uploads/HypuUgY6gx.png =50%x) ##### Hybrid 在時間、頻率上都切分 e.g. 5G Resource Block ![image](https://hackmd.io/_uploads/BkwUSw53xl.png =50%x) ##### CDMA Code Division Multiple Access 切成不同份的正交編碼,使訊號不會碰撞,把同個 time slot、frequency band 進一步切分 ##### MIMO Multiple Input Multiple Output 多根天線同時發射、多根天線接收 舉例來說,我們人有左右兩隻耳朵,所以就算左前方、右前方都有人在講話,我們還是可以分辨出兩種聲音 也就是說,發送陣列可以同時發送不同訊號,只要發送陣列與接收陣列間,不同路徑的差異性(振幅變化、相位差)夠大,我們就可以在接收端根據這些 CSI (Channel State Information 通道特徵資料)分離出不同發射天線的訊號。 能夠在不增加頻寬的條件下,利用 Spatial multiplexing,相比 SISO 系統線性地提升資訊傳輸速率。 ![image](https://hackmd.io/_uploads/ryjoslFplx.png) #### Contention based 沒有中央控制器,各人去搶頻道使用權 ##### pure ALOHA 最早的 random access protocol,想送就送,有錯再說 traffic load 高的時候容易碰撞 ##### Slotted ALOHA 一樣是想送就送但把頻道在時間上分段(slot),只能在 slot 的開始處進行傳送。每次傳送的數據必須 $\le$ slot,改善了隨時隨地都有可能封包的缺點,減少衝突。 (J.F. Kurose 有提到[隨機重送](https://hackmd.io/-7cQaBF4Ro2tO9Mai2lEug#Slotted-ALOHA)的機制,這邊張貴雲沒說) ![image](https://hackmd.io/_uploads/HycpXILIJg.png =80%x) ![image](https://hackmd.io/_uploads/BycCd8Ypee.png =90%x) ##### CSMA Carrier Sense Multiple Access 會先聽通道上有沒有別人在傳 - 1-persistent CSMA - idle:傳 - busy:繼續聽下去 - p-persistent CSMA - idle:有機率 $p$ 直接傳,機率 $1-p$ 繼續等 - busy:繼續聽下去 - Non-persistent CSMA - idle:傳 - busy:停下來等一段時間(長短是隨機分布),時間到再聽一下 #### Hybrid ##### DAMA Demand Assigned Multiple Access 輪流用 ++Contention-based++ (slotted ALOHA)、++Reservation-based++ (TDMA、FDMA、CDMA 都可能使用) (賤民用搶的、VIP有為他們保留的資源) ![image](https://hackmd.io/_uploads/Hyjes8tTxe.png) ### IEEE 802.11 MAC Wi-Fi 的 Protocol,大概吧 #### 簡介 ![image](https://hackmd.io/_uploads/SJNr3UFall.png) | 名稱 | 全名 | 功能 | 類比 | | ---------- | ------------------- | ---------------------- | ------------ | | **802.11** | IEEE 無線網路標準 | 定義 Wi-Fi 的 PHY 與 MAC 層 | Wi-Fi protocol | | **STA** | Station | 終端使用者設備 | 筆電、手機 | | **AP** | Access Point | 提供無線連線與管理 | 無線基地台 | | **BSS** | Basic Service Set | 單一無線網路範圍(AP + STAs) | 一個 Wi-Fi 小區域 | | **ESS** | Extended Service Set | 多個 BSS 組成的大網路 | 校園 Wi-Fi | | **DS** | Distribution System | 連接多個 BSS 的骨幹 | 有線主幹網路 | 802.11 分兩種模式: - **infrastructure mode** 一個網路是屬於有AP管理的情況,所以每個節點都是將資料傳送給AP再由AP分配到個節點去。AP與node間都是1 hop - **Ad-hoc mode** 節點與節點之間的傳送是沒有AP管理的。都是節點傳節點。屬於 multi hop 的環境 #### Frame Structure 反正就醬 ![image](https://hackmd.io/_uploads/ry9zRUFpee.png) #### 傳遞模式 802.11 將時間分為週期性 Superframe,每個 Superframe 由兩個部分組成: - **Superframe**:整體時間架構 - **PCF**:Point Coordination Function 集中式,靠 AP 做 Polling - **DCF**:Distributed Coordination Function 分散式,每個 STA 自行競爭(CSMA/CA + Backoff) ![image](https://hackmd.io/_uploads/SkNgV19plg.png) - **Beacon**:由 AP 發送,是整個 Superframe 的開頭,用來「公告」時間、通道狀態、與控制資訊。 - **NAV**:Network Allocation Vector 在 802.11 中,每個 Frame Header 都會帶有一個 Duration Field(持續時間欄位),用來告訴其他 STA:「我接下來要占用媒介多久」,其他 STA 收到這個欄位後,就會把自己的 NAV 設為這個時間,並在這時間內保持靜默。 - **CF-End**:Contention-Free End Frame AP 會發送一個 CF-END frame 告訴所有 STA 恢復自由競爭(DCF 模式) ##### PCF 1. AP 傳資料給特定 STA(DL) 2. STA 回傳 ACK 確認收到 3. AP 跟 STA 說你可以講話了(Polling) 4. STA 傳資料(UL) 5. AP 確認收到(ACK) 6. AP 選下一個 STA 重複 1. ~ 5. ![image](https://hackmd.io/_uploads/HyhwHfc6le.png) 但這樣傳資料、等確認收到、傳資料,太慢了,所以引入 **Piggyback** 機制,把 Polling 和 ACK 直接跟要傳的資料一起送 ![image](https://hackmd.io/_uploads/B1R8vf5peg.png) ##### DCF 當聽到 CF_END 代表 DCF 週期開始,STA 彼此競爭傳送 想傳送資料的 STA 會先等待一段 **DIFS** 時間,再隨機等一段時間(**Random Backoff**,減少碰撞機率) ![image](https://hackmd.io/_uploads/SJAKOz5Tgl.png) 需要等 **DIFS** 是因為,CSMA 是先講先贏,所以透過區分不同等待時間,可以實現 Priority,讓 Beacon(等 PIFS)有比較高的優先權,不會被一般封包(等 DIFS)卡住 SIFS(10μs) > PIFS(30μs) > DIFS(50μs) > EIFS(>50μs) ![image](https://hackmd.io/_uploads/r1pOYfcaeg.png =80%x) CSMA 就是先聽再送,而 CA(Collision Avoidance)主要可以由兩種機制達成: - **Random backoff**:等一段時間,就是上面剛說的方法 - **RTS/CTS**:Sender 發送 RTS 之後必須在限定時間內收到來至目的端的 CTS 訊號 ##### CSMA/CA with Random backoff 有個 Random backoff counter,隨機決定要等多久,期間有別人在傳送就先暫停計時,idle 再繼續,計時歸零就發送,如果發送後發生碰撞,就重新骰骰子決定要等多久 ![image](https://hackmd.io/_uploads/HkMVL75Tlx.png =80%x) ##### CSMA/CA with RTS/CTS 在802.11中為了解決 Hidden terminal problem,使用了 **RTS/CTS** 的機制。 - **RTS**(Request to Send):Sender 用來告訴鄰居們我要送了的封包,此時 Sender 的鄰居會進入禁止傳送的 NAV 狀態 - **CTS**(Clear to Send):收端會發送 CTS 警告他周圍的點,我現在要聽了,你們安靜,此時周圍的點也會進入 NA V狀態,不影響送端與收端的傳輸。 上述方法可以解決 Hidden terminal problem 造成的 Collision,但會導致 Exposed terminal problem,造成 Waste bandwidth - **Hidden terminal problem** → Collision A正在傳送資料給B,C想傳送資料給D節點,但是C節點不知道有人正在傳送資料給B節點,此時傳送資料給D節點,造成B節點收資料時產生碰撞。 ![image](https://hackmd.io/_uploads/rkpwbmc6ex.png) - **Exposed terminal problem** → Waste bandwidth B傳送資料給A,此時C想傳送資料給D。但是C發現B正在傳送資料,所以C就停止傳送資料給D。但事實上C傳送資料給D是不影響AB傳輸的。 ![image](https://hackmd.io/_uploads/S1ZYbXcTel.png) ##### MACA Multiple Access with Collision Avoidance MACA的特色是要傳之前不用再去聽網路有沒有人在傳送,而是用RTS/CTS來決定是否可以傳送。 收到RTS的區域是可以傳送的,因為碰撞是發生在收端,但收到RTS的人不一定有辦法傳到收端。 收到CTS的區域代表是不能傳送資料給其他節點的。因為收到CTS代表他在 Receiver 的傳輸半徑內,如果此時送資料將會打斷Receiver的資料傳送。 收到RTS與CTS的代表他不能接收資料也不能傳送資料。 (唉呦,總之就是,要發言要先舉手,老師看到以後會叫課堂上的其他人先閉嘴,阿走廊上課堂外的人就算看到教室裡有人要舉手發言也沒差,可以繼續講話,反正他們不會吵到老師,只有聽到老師說要閉嘴的要閉嘴) #### 802.11 的省電模式 在無線網路中,行動裝置(如筆電、手機)通常使用電池供電。因此 IEEE 802.11 設計了 Power Save Mode(省電模式),讓 STA 可以在空閒時進入睡眠,降低耗電量。 - **infrastructure mode** STA 告訴 AP 我要進入省電狀態 AP 收到別人給這個 STA 的資料會先幫它存在 buffer - **Ad-hoc mode** STA 告訴其他 STAs 我要進入省電狀態 別的 STA 收到別人給這個 STA 的資料會先幫它存在 buffer ##### infrastructure 的省電模式 1. STA 進入省電模式 - 通知 AP:「我進入省電狀態」 - AP 暫存該 STA 的資料(Buffer) - AP 建立 TIM(Traffic Indication Map)表,紀錄哪個 NODE 是否有資料要做傳送 2. Beacon Frame 通知 - AP 定期發送 Beacon frame(例如每 100ms) - Beacon 中包含 TIM,告訴哪些 STA 有封包等待。 3. STA 定期醒來接收 Beacon 檢查 TIM、DTIM,看自己需不需要接收資料 - TIM - in PCF:waiting AP transmit data - in DCF:送 PS-Poll 給 AP 跟 AP 要資料 - DTIM - AP sends out the buffered broadcast/multicast packets 5. AP 傳送暫存的資料 6. 傳送完資料後,STA 可再度進入睡眠 - **TIM 類型** - **TIM** - **DTIM**(Delivery TIM) TIM 的特例,用來通知「有廣播(Broadcast)或多播(Multicast)」資料要送 AP 在每 N 個 Beacon 發送一次 DTIM Beacon。 所有進入省電模式的 STA 都會在這個時刻「一起醒來」,接收廣播或多播資料。 - **ATIM**(Ad hoc TIM) ##### ad-hoc mode 的省電模式 一個Beacon interval是一個醒睡週期,分成以下步驟 1. **TBTT Window**:Target Beacon Transmission Time,STAs 競爭傳送 Beacon - 在每個 Beacon Interval 開始時,所有節點會競爭(DCF: CSMA/CA)發送 Beacon frame。 - 第一個成功送出 Beacon 的節點就「定義」了該週期的時序。 - 其他節點接收到 Beacon 後同步時間。 - (Beacon 主要用來同步時間,不負責告訴誰有資料,因為沒有 TIM) 2. **ATIM Window**:Announcement Traffic Indication Message,喚醒通知階段 - Beacon 傳送後,所有節點都會保持清醒一小段時間,稱為 ATIM Window。 - 在這段期間內,若某節點有資料要傳給別人,會送出 ATIM frame。 - 收到 ATIM 的節點(接收方)會回覆 ACK,並標記「我下個階段要保持清醒,準備收資料」。 3. **Data Transmission** 階段(資料傳輸階段) - ATIM Window 結束後,進入本 Beacon 週期剩餘的時間。 - 所有在 ATIM Window 被「叫醒」的節點,保持清醒並進行資料傳輸。 - 沒有被喚醒(沒被 ATIM 指定)的節點,可以進入睡眠模式直到下一個 Beacon (下圖打錯,應該是 TBIT,不是 TBTT) ![image](https://hackmd.io/_uploads/SyvHF4cpgg.png) ### IEEE 802.15.4 MAC 低速率、低功耗、低成本,Wi-Fi 家族(IEEE 802)中專門為 IoT 裝置、感測網路、智慧家庭...設計的協定基礎。只定義最底層的 PHY、MAC 兩層 分成兩種裝置 - **FFD**(Full function device):全功能裝置 - 可連多個 FFD、RFD - 可成為網路協調者(PAN Coordinator) - **RFD**(Reduced function device):簡化功能裝置 - 只能連一個 FFD 通訊 - 不能成為網路協調者 通訊於同一實體層頻道中的一個++個人操作空間++(Personal Operating Space, POS)內的兩個或是兩個以上的裝置會構成一個++無線個人區域網路++(Wireless Personal Area Network, WPAN),但是一個網路中必須包含至少一個 FFD 以作為個人區域網路之協調者。 #### Topology IEEE 802.15.4 提出了三種拓樸架構 - **Star Topology** ![image](https://hackmd.io/_uploads/B18HzO56ll.png =30%x) - **Peer-to-Peer / Mesh Topology** ![image](https://hackmd.io/_uploads/rkSESOc6gl.png =40%x) - **Cluster Tree Topology** ![image](https://hackmd.io/_uploads/H1OYBOcpgl.png =50%x) #### Frame structure 802.15.4 的 Frame structure ![image](https://hackmd.io/_uploads/HJS6r_q6lx.png) #### Data Transfer Model - **Non Beacon-enable networks** - No beacon frame - ++unslotted CSMA/CA++ channel access mechanism - **Beacon-enable networks** - With beacon frame - ++Slotted CSMA/CA++ channel access mechanism (802.15.4 有 slot 的概念,802.11 沒有) ##### Beacon-enable (Slotted CDMA/CA) 由 PAN Coordinator(Personal Area Network Coordinator)定期發送 Beacon frame,同步整個網路。 當裝置們收到 **網路協調者** 所發出的 Beacon 後,他們會將 backoff slot 對齊 Beacon發出的時間,然後反正就是 random backoff Beacon-enable mode 中有 Superframe 結構,由 PAN Coordinator 發送的 beacon frame 決定時間長短之類的 一個 Superframe 主要分為兩個區塊: - **Active portion**:切成 16 個相同大小的 time slot,分為兩個區間 沒要傳資料的裝置可以進入省電模式 - **CAP**(Contention-Access Period) - 要傳資料的裝置用 Slotted CSMA/CA 來搶 - **CFP**(Contention-Free Period) - 協調者可以把這區間保留給有需求的裝置,分派 **GTS**(Guarantee Time Slot,可由數個 time slot 組成)給他們 - 一個協調者最多可以分派 7 個 GTS * 一個裝置若已經被分配倒固定時槽,也依然可以在競爭區間中活動。 - **Inactive portion**:協調者跟沒要傳資料的裝置在這時候睡覺 ![image](https://hackmd.io/_uploads/S1Kzc_5pee.png =80%x) 如果 Coordinator 有資料要送給裝置的話,會在 beacon 裡頭夾帶訊息告知該裝置(有點像TIM?) 當裝置收到 Beacon 後,會看協調者有沒有要傳訊息給自己,有的話在 CAP 搶著送 request 給 coordinator,coordinator 收到再傳資料給他 ![image](https://hackmd.io/_uploads/rkkFntc6ex.png =80%x) ##### Non beacon-enable (Unslotted CDMA/CA) 在非 Beacon-enable的網路中,裝置必須要定期的詢問協調者有沒有資料要給他 裝置先以 Unslotted CSMA/CA 競爭媒介權,接著裝置發送一個 Data Request frame 給網路協調者來詢問協調者有無暫存資料。 當協調者有資料要送給裝置,也使用 Unslotted CSMA/CA 競爭媒介權,等競爭到媒介使用權之後,再傳送資料給裝置。 (FP:有沒有暫存資料) ![image](https://hackmd.io/_uploads/ByL70t96gg.png =80%x) ##### IFS(Interframe Space) 收方需要時間處理封包,所以送端連續一直送封包,封包間要等一段時間,不能不間斷連續傳送,這段「兩個 MAC frame 傳送之間必須間隔的最小時間」就叫 **IFS**(Interframe Space) - 如果上一個發送的封包不需要 ACK,那 IFS 的計時從封包送完開始 - 如果需要 ACK,那 IFS 的計時從收到收端傳來的 ACK 結束後才開始 IFS 可以分長短兩種: - **SIFS**(Short Interframe Space):傳完小封包用的 - **LIFS**(Long Interframe Space):傳完大封包用的 ##### Reliable transmission 送端送 frame 給收端以後,開啟一個計時器,等待 *macAckWaitDuration* 時間,如果沒收到 ACK 就重送 frame,這步驟可以重複 *aMaxFrameRetries* 次,超過視為傳送失敗 ![image](https://hackmd.io/_uploads/HJMWk99plg.png) #### 802.15.4 適用於感測網路的特性 在感測網路的環境中,該如何節省裝置的電量消耗是一個當重要的問題,在 IEEE 802.15.4 標準中亦定義了省電的機制。 其中最重要的概念是降低裝置的工作週期 (Duty cycle),使得每個裝置都能夠盡量的減少運作的時間,並進入休眠模式, 由於 IEEE 802.15.4 標準電池最佳化網路參數的作法 (Beacon 間隔、工作週期可降低、固定的時槽等),所以電池的壽命能夠大幅提昇至數月或數年, 而進入休眠模式中則會有延遲訊息的問題,對於整體網路的效能會帶來極大的影響,因此是否進入休眠模式以及進入休眠模式時間的長短主要就取決於使用者所需的應用及環境而定。 - 浪費電的原因 - **Collision**:碰撞造成封包傳送失敗 - **Overhearing**:接收到太多別人的封包 - **Control-packet overhead**:為了控制拓樸系統的封包代價 - **Overemitting**:發射功率超出實際所需 - ==**Idle listening**==:沒人要傳給他,但他一直在聽,這是++主要的問題++ ### 802.11b v.s. 802.15.4 綜觀來說, IEEE 802.15.4 標準成功增進了可靠度、降低了電量的消耗,達到了建立網路的代價低、用便利的特性 IEEE 802.11 標準達到了速度的要求,以及使用上的彈性 ![image](https://hackmd.io/_uploads/rkVZf59axe.png) ### WSN(Wireless sensor network) 重點是,是 sensor 要用的,要省電,不能用 RTS/CTS,太耗電 - MAC protocols for WSN:可以分成兩類 - **Asynchronous**:網路中的 sensor node 藉由和鄰居交換醒睡時間而決定醒睡週期 `e.g.` S-MAC、B-MAC、Wise MAC ...etc - **Synchronous**:網路中的 sensor 需要透過外部的精確時間同步,或是有需要達到整個網路 global 同步的情況 `e.g.` TRAMA、DMAC ...etc #### S-MAC 為了省電,S-MAC中的 sensor node,依照定義好的cycle時段,規律的進行醒睡狀態切換 - **Listen period**:聽取無線頻道上是否有節點對自己發出傳輸資料的 request,有資料需要傳輸的節點也會在此時段中對 receiver 發出傳輸需求(CSMA/CA with RTS/CTS) - **Sleep period**:剛剛說要傳、需要收資料的醒著,其他進入休眠模式以節省電量消耗 ![image](https://hackmd.io/_uploads/rJEgaqq6xx.png =80%x) 這麼一來就需要 node 就需要跟鄰居的醒睡週期同步才能正確傳/收資料 所以 S-MAC 使用 **virtual cluster** 的方式決定 local 的醒睡 schedule 一個新加入網路的sensor node a 將會先聽取網路一段時間,如果一段時間內沒有收到其他node傳來的schedule資訊時, a 將會自己決定醒睡 schedule,並且把自己的schedule廣播出去給周圍的鄰居 如果 a 在等待時間結束前,收到來自鄰居的醒睡 schedule,a將會依照收到封包的醒睡 schedule 運作 (總之就是晚來的要配合別人。TX/RX = transmit/receive = 送端/收端) ![image](https://hackmd.io/_uploads/r18sA55aeg.png =90%x) 如果一個sensor接收到兩個來自不同node的醒睡週期時,該sensor將要在兩個不同週期的listen period中醒來,因此在cluster交界處的node,需要同時在兩個 cluster 的 listen period 中醒來,會有比較高的 idle listening 和 overhearing 問題。 ![image](https://hackmd.io/_uploads/B19625qpgl.png =60%x) ##### DFI(data forwarding interruption problem) 在多跳傳輸(multi hop)中,考慮 A $\rightarrow$ B $\rightarrow$ C A 要傳給 B,此時 C 發現沒人要傳給自己,就跑去睡覺。當 B 收到封包,發現自己要再傳給 C,但 C 在睡,所以要等他下一次才能傳,造成傳輸delay ##### Adaptive Listening 為了解決 DFI,S-MAC 使用 Adaptive Listening 當 A 傳給 B 的時候,C overhears 到 RTS/CTS,知道他的鄰居要傳輸資料,雖然知道不是傳給自己的,但因為自己有可能是 B 的下一跳,所以在 A B 傳輸完後,C 會保持清醒一小段時間(一小段而已,所以開銷不會增加太多),這樣 B 要傳給他的話就可以馬上處理,不然如果 C 沒聽到有 node 要送給自己就跑去睡的話,B 還要等 C 醒來 ##### Message Passing 傳輸長封包時,一旦出現幾個bits錯誤就必須浪費許多時間重傳整個封包, 但是分割成數個短封包時,又會出現 RTS 和 CTS 的 control overhead (Re-transmit message problem) message passing 的目標就是減少錯誤封包重傳時的 overhead 在 S-MAC的 message passing 中,每個大封包雖然被切割成小段落,但是這些獨立的小封包將會被「一次」傳輸出去, 也就是說,只使用一次RTS和CTS就連續傳輸數個小封包 接著 receiver 透過類似 Store and Forward 的概念(這啥?),即時檢查接收到的封包,並且在最後的ACK中,要求sender重傳錯誤的封包 receiver 周圍的鄰居聽到 receiver 送出重傳需求的ACK時,將會多等待一段時間,等 sender re-transmit 資料後再開始進行傳輸,藉此減少 re-transmit 時造成的 contention latency,增加網路的效能。 ![image](https://hackmd.io/_uploads/B1BP42qagg.png =90%x) ##### 優缺點 雖然 S-MAC 提供 sleep mode,可減少平時 ++idle listening++ 的問題,但欠缺依照通訊量,彈性調整醒睡時間比例的機制 - **Advantage** - ++Idle listening++ is reduced by sleep schedules - time synchronization overhead may be prevented by sleep schedule announcements - **Disadvantage** - Sleep and listen periods are predefined and constant - Adaptive listening incurs overhearing or idle listening #### B-MAC B-mac 的 sensor 自行決定醒睡時間,所以 sender 有資料要傳輸時,receiver 可能還在休眠狀態,因此sender會連續的發出一長段的preamble,以確保可以通知到receiver (※Preamble is not a packet but a physical layer RF pulse) sender決定要傳送資料後,會先使用 Clear channel assignment(**CCA** 技術可以聽取頻道上的 noise,並且從雜亂的載波中,分辨頻道是否可以傳輸資料)聽取一下頻道中是否有人正在傳送資料,若判斷頻道是空的,sender 將會連續送出一長段時間的 preamble 通知 receiver 而每個 sensor 都會週期的醒來一小段很短的時間,看有沒有人要送資料給他,若收到來自 sender 的 preamble,receiver 進入等待狀態,醒來的間隔必須++短於 preamble++ 等 sender 的 preamble ++結束++後,receiver 和 sender才開始進入資料的收送狀態 ![image](https://hackmd.io/_uploads/rJ4DYn9pee.png) ##### 優缺 B-MAC 的機制可以達成 Low power listening (**LPL**),minimize listen cost 但因為 preamble 的長度要夠長,才能保證能夠通知 receiver,會造成相當大的 transmission delay,在網路通訊量增大後,會造成效能急速下降 - **Advantage** - Doesn’t need any synchronization - Doesn’t need RTS/CTS(但是不採用 CTS 的情況可能產生 hidden terminal 問題) - Clean and simple interface - **Disadvantage** - Long Transmission delay - Bad performance when heavy traffic load #### D-MAC Data-gathering MAC 上面幾個都是 Asynchronous 的 MAC protocols,DMAC 是 **Synchronous** 的 雖然 S-MAC 採用 Adaptive Listening 來改善 DFI problem,但效果依然有限。 如下圖 source 要向右傳到 sink,但只有下一跳的 node(通訊範圍內。綠點) 會 overhear 到並醒著,再下一跳(紅點)依然還是在睡 ![image](https://hackmd.io/_uploads/rytA5vsTxg.png =70%x) D-MAC 採用樹狀拓樸,在啟動階段建立並維護一棵 **data gathering tree** 收集 sensor node 的資料到 sink 每個 node 傳輸資料至 sink 的 path 將會依照此樹狀結構的 routing 路徑傳輸 有了每個節點的 Level 後,D-MAC 就能排定 Staggered Wakeup Schedule,反正就是++各層會輪流醒來傳給下一層++,直到傳到 sink 然後用的是 slotted ALOHA,slot的安排要決定於網路的樹狀結構 ![image](https://hackmd.io/_uploads/H184ddopex.png) ##### 優缺 DMAC的最大缺點就是彈性太差,當網路拓樸改變後,每個node必須重建醒睡時間 - **Advantage** - DMAC achieves very good latency compared to other sleep/listen period assignment methods - **Disadvantage** - Collision avoidance methods are not utilized, if number of nodes that have the same schedule try to send to the same node, collisions will occur. #### Comparison of WSN MAC protocols ![image](https://hackmd.io/_uploads/ry26Y_o6xx.png) (np-CSMA : non-persistent CSMA) ## LORA ### Intoduction **LoRa**(Long Range):適合**低速率**、**低功耗**、**長距離**(10km) 的 IoT 無線技術,是現代物聯網(IoT)中非常重要的,主要用在「感測器資料回傳」、「遠距設備監控」,是一種低功耗廣域網路技術(LPWAN, Low Power Wide Area Network) **NBIoT**:一個 4G 有用的 protocol,低功耗、長距離,商業上使用 Low power Long Range(2、30 km) #### LORA 網路架構 LoRaWAN 是 LoRa 的上層協定,採 **星狀拓樸**(Star-of-Stars): - End Devices 感測器或裝置,發送資料(如溫度、濕度、GPS)。 - Gateways 收到 LoRa 訊號後,透過 Ethernet / 4G 傳給 Network Server。 ![image](https://hackmd.io/_uploads/By-PoyFCel.png =90%x) LORA 規範至少要有 16 個 channel,大家每次要傳輸的時候都**隨機**跳到其中一個頻道,避免碰撞,又不需要中央控制器排誰用甚麼 channel ![image](https://hackmd.io/_uploads/HyVpjytAee.png =70%x) #### Data Rates data rate 要在 Communication Range 跟 Message Duration(Communication Delay,一個封包從開始傳送到完全送完所花的時間)權衡 高頻雖然 data rate 高,傳資料快,但容易被干擾,沒法傳太遠 LoRa data rates range from 0.3 kbps to 50 kbps,因為是 IoT 用的,資料不會太大,不需要太高的 data rate #### ADR(adaptive data rate) 為了省電,通道狀況糟的時候(SINR 的 IN 大),把 data rate 調低以維持正常通訊,而不用多耗電調高 S,是 each end-device 的調整 #### Classes of LoRaWAN end-device 有三種類別 - **Class A**:最省電,裝置只有在要上傳資料給 gateway 時會起床。所有裝置都必須支援 - ++Uplink++:end-device 主動發送上行資料給 gateway(ALOHA-type) - ++Downlink++:送完 uplink,end-device 開啟兩個短暫的窗口(RX1、RX2)聽 gateway 的 downlink - **Class B**:在 class A 的基礎之上,加上會 **週期性** 的醒來打開額外的接收窗口(Beacon-synchronized slots,由 gateway 廣播的 beacon 同步時間),需要同步時間,設備成本高 - **Class C**:裝置幾乎隨時開啟接收窗口,只有在自己上行傳輸時短暫關閉接收,注重避免因為睡覺而沒聽到別人消息 ![image](https://hackmd.io/_uploads/BJbLZyaplg.png =90%x) ### Physical Message Format - **Uplink Messages** ![image](https://hackmd.io/_uploads/SkFdXeFAgg.png) - **Downlink Messages** ![image](https://hackmd.io/_uploads/SJTqXeFClg.png =80%x) Preamble:長長的固定的訊號,讓接收端偵測到封包開始,幫助接收端完成頻率同步與 symbol 同步 ### Receive Windows 每次 end device 送一個 uplink,都會開短暫開兩次 receive windows 聽看看有沒有 downlink,第二次是調參數再試一次 雖然短暫,但 receive windows 的長度至少要長到能確實偵測到 preamble 在 Downlink process 結束前,end-device 都不能傳 uplink ![image](https://hackmd.io/_uploads/ryjhSgKAle.png =60%x) - **RX1** - frequency channel:跟 uplink 同頻道 - data rate:看地區規範,預設是跟 uplink 一樣 - 收到 preamble 的話,end-device 就維持醒著聽完,並取消打開 RX2 ![image](https://hackmd.io/_uploads/H1szdgYCxg.png =70%x) - **RX2** - frequency channel、data rate 都是固定的 - 因為 RX1 是依 uplink 參數動態決定的,但如果 uplink 資料壞掉就糟了,這樣就沒辦法 downlink,所以 RX2 是固定的,預設是看各地區的標準,但可以透過 MAC commands 修改,反正大家一樣就好 ![image](https://hackmd.io/_uploads/r1T8dxYRgg.png =70%x) 而如果 network (server) 有要傳 downlink 給 end-device 的話,總是會在 RX1、RX2 的開頭傳 ### MAC Message Format ![image](https://hackmd.io/_uploads/SyfcKZt0ee.png =70%x) **FPort**:用來表示 FRMPayload 的內容是甚麼,當為 0 的時候表示是傳 MAC commands **FOpts**:也可以拿來傳 MAC commands **FCnt**:Frame Counter,紀錄收送了幾個封包,收送端數字一對就知道丟了多少封包,就可以評估 channel 的好壞。也可以拿來當作加解密的金鑰,因為收送端數字都一樣(通訊好的情況),而且只有彼此知道這個數字 比較重要的是 **FCtrl**,負責控制 data data rate 之類的網路行為資訊,有興趣再查 有些欄位寫 RFU,表示 Reserve for future use #### ADR(adaptive data rate) FCtrl 裡有個 bit 是 ADR,表示要不要使用 ADR,end-device、network 都可以設置它,但 ADR 具體怎麼調是 Network server 決定,end-device 選擇要不要接受 - 會移動的 end-device 因為 channel 情況一直變,ADR 會跟不上,所以規定不能動態改變 data rate,所以這 bit 總是 0 - 靜態的就看情況決定要不要使用 ADR 但是 data rate 也不能亂調,調到無法通訊就糟了,所以照這演算法調 ![image](https://hackmd.io/_uploads/H1IsHft0ge.png) ### MAC Commands MAC commands can be contained by - FOpts field - FRMPayload(且 FPort 設 0) 總之有各種 command,像是 確認 channel 好不好、 end-device 在幾個 gateway 的通訊範圍內、 Network server 叫 end-device 調 TXPower(發送強度)、data rate、channel, end-device 回覆要不要接受這樣的調整(無法調才會說 no) 調整 duty cycle(限制多久能發一次資料) 調整 RX2 的 頻道、TXPower、data rate 之類的參數(其實也可以調 RX1 的,但通常不會調,因為 uplink 能上傳就表示這參數大概能用,RX1 就沿用) 問 end-device 電量 設置前 N 個為 default channel 設置 TX 之後多久要開 RX 跟 Network 對時 ... 基本上要調整都是 Network server 計算,end-device 回覆接不接受,而且通常都會答應,除非自己做不到 default channel 重要,因為各國之間頻段不一樣 ### End-Device Activation end-device 加入 LoRaWAN network 的時候要 activate Activation 有兩種方式 - **OTAA**(Over-The-Air Activation):動態生成 Session Key,安全性高 - **ABP**(Activation By Personalization):事先設定 Session Key,加入網路速度快,安全性低 #### OTAA Activation ##### Before Activation 之前,end-device 需要存有幾個資訊 - **JoinEUI**:Join Server 的 ID,global unique(Join Server 是負責管理裝置入網(activation)與生成加密金鑰的安全伺服器) - **DevEUI**:Device ID,製造時分配的唯一識別碼 - Device Root Keys:製造時分配的唯一識別碼 - **AppKey**:用於產生應用層加密金鑰(AppSKey,跟 data 有關) - **NwkKey**:用於產生網路層金鑰(FNwkSIntKey、SNwkSIntKey、NwkSEncKey,跟 LoRA 的設定有關) - **JSIntKey**:由 NwkKey 推導出的,用來確保 join 訊息沒被竄改 - **JSEncKey**:由 NwkKey 推導出的,用來加密 join 訊息 ##### After Activate 之後,end-device 會存有幾個資訊 - **DevAddr**:end-Device address,之前的 DevEUI 太長了佔封包,用短一點但不是 global unique 的 DevAddr 就好,由 Network Server 分配給裝置 由於 LoRaWAN 支援 Roaming(end-device 離開原本的網路(home network),移動到其他 LoRaWAN 網路(visited network)時,它的上行訊息可能會被當地的 Gateway 接收到),所以 Gateway 必須知道該把這個訊息送到哪個 Network Server 因此 DeVAddr 由兩部分組成 - ++AddrPrefix++:用來識別網路(Network Server ID) - ++NwkAddr++:用來識別 end-device - Network session key:只有裝置跟 server 知道 - **NwkSEncKey** - **SNwkSIntKey** - **FNwkSIntKey** - Application session key - **AppSKey** ##### 資料驗證 - MIC:message integrity code,用來確保資料沒被竄改 - **Data** - **Integrity** - **uplink**:end-device 用 ++FNwkSIntKey++ 跟 ++SNwkSIntKey++ 兩把 key 各計算一半,再組合成最終 MIC,分兩部分是因為在 roaming 環境下,負責轉發的 forwarding Network Server 只有 FNwkSIntKey(SNwkSIntKey 只有 end-device 跟 Serving Network Server 有,才安全) - **downlink** 時用 ++SNwkSIntKey++ 驗證 MIC - **encrypt / decrypt** - ++AppSKey++(payload field of application-specific data messages) - **MAC Commands** - **encrypt / decrypt** - ++NwkSEncKey++(uplink and downlink) ##### Join Procedure An end-device has to go through a new join procedure every time it has lost the session context information. 從 end-device 的角度來看,Join procedure(加入網路)就是讓 Network Server 分配 session keys(通訊金鑰)與 DevAddr(裝置位址),以便之後能安全地收發資料,分成兩步驟: 1. **Join-request**(or Rejoin-request) 由 end-device uplink Join Request 給 Network(無加密) 這封封包包含了它的身分與驗證資訊: - ++JoinEUI++:指定要加入的 Join Server - ++DevEUI++:裝置唯一識別碼(出廠時給定) - ++DevNonce++:計數器,每次發送 join request 的時候 +1,避免重複 Join、確保安全性 ![image](https://hackmd.io/_uploads/SygVQAKRex.png =60%x) 2. **Join-accept** 如果 Network server 接受這個 Join Requet,就會回覆 Join Accept Message(不接受就不傳東西) - ++JoinNonce++:計數器,每次發送 Join accept message 就 +1。end-device 用它來推導出 session keys. - ++Home_NetID++:裝置所屬網路識別碼,由 LoRa Alliance 官方分配,用來唯一區分全球不同的 LoRaWAN 網路 - ++DevAddr++:分配給裝置的臨時地址(之後 uplink/downlink 都用這個) - ++DLSettings++:下行連線參數(例如 RX1/RX2 offset) - ++RxDelay++:uplink 與 downlink 的延遲設定 - ++CFList++:可選欄位,提供額外頻率設定 ![image](https://hackmd.io/_uploads/HyZL4CKCll.png =95%x) ##### Rejoin-request message Rejoin-Request 用來讓 end-device 在運作期間「重新連線」或「更新金鑰/網路參數」而不必完全重新 Join。(無加密) 分成 3 種 - Type 0:完整重新加入,重設通訊參數、金鑰(session key、DevAddr...) - Type 1:同步連線狀態,重設通訊參數(ADR 之類的,不換 key),適用於 end-device 失去 server context 的時候 - Type 2:更新 session keys,但比 Type 0 輕量,提升安全性而不完全重新 Join ##### Key derivation diagram(V1.1) ![image](https://hackmd.io/_uploads/Bk1Id1qCgg.png) SF 一個 symbol 幾 bit #### ABP(Activation by Personalization) 所有必要的網路與應用金鑰、位址等資訊都「預先設定」在裝置裡,而不是透過 join 過程動態獲取 不需要 Join-request、Join-accept 的過程 ++DevAddr++ 和 session keys(++FNwkSIntKey++、++SNwkSIntKey++、++NwkSEncKey++、++AppSKey++)都直接存在 end-device 裡,不需要透過 Join Procedure 中的 ++DevEUI++、++JoinEUI++、++AppKey++、++NwkKey++ 來推導 啟動簡單、快速,不需要頻繁更新 session key,適合無法常連線的場景 但缺點是 - 安全性較差:金鑰是固定的 - 不支援 roaming:因為 DevAddr 是固定分配的 ### Physical Layer #### Channel frequencies 各地區頻段不一樣 ![image](https://hackmd.io/_uploads/BkhOTk9Cee.png =80%x) #### Default Channel 每個裝置都要有出廠即具備的預設頻道,用來傳 Join Request #### Spreading factor 看不懂,跟 symbol 有關,反正跟 bit rate 正相關,SF 愈高、資料傳輸愈快、通訊距離愈短 ![image](https://hackmd.io/_uploads/Bk_K7xq0xg.png =60%x) #### Optional Channel Frequency 除了 default channels 外,Network Server 可以透過 MAC Command(NewChannelReq)新增可選通道(optional channels) #### Maximum payload size 指在不同 Data Rate(Spreading Factor + Bandwidth)下,單一 LoRaWAN frame 可容納的最大應用層資料量,因為法規有 duty cycle 限制 Data rate 低的話傳輸慢,不能傳太大的資料,不然花太久時間 - ++dwell time++:the amount of time a device uses a particular channel - ++dwell time coufigurations++:No Limit (0) and 400ms (1) ![image](https://hackmd.io/_uploads/Bkx_mec0xl.png)