---
title: 802.11 協議|第八週
tags: 無線與行動網路導論
---

# 回顧

原本 MACA 可以解決的 exposed node，到了 802.11 會變成聽到只要聽到 RTS 或 CTS 就要不可以傳，這在底下的傳輸細節會介紹到

以保持更不容易被打擾(collision)的傳輸環境

# 802.11

他是 IEEE 的一個標準；但是各家廠商的產品會有相容性問題，所以又有個 Wi-Fi alliance 負責制定相關規範，這是各個廠商去訂製的標準。

>這兩個組織都有網站

802.11 是一個歷史很悠久、很常見的協議，像是 NTU、台北市、你的手機筆電或你家，可以看到他。
>通常存在很久代表很成功

## 到底負責甚麼

802.11 主要是處裡 Physical 跟 MAC (linking) Layer 這兩層的範圍
再上層的就是直接用其他的協議，像是 TCP 跟 IP 這兩層。

### 物理層

會一直有隨著時代更新，畢竟用的頻段不一樣，技術也在進步，像現在普遍看到的 OFDM 和 OFDMA。
底下會有更詳細的說明

總之就是跟 Modulation、Coding 和 Bandwidth 等等的相關規定。
像是提供哪些 Unlicensed Band ，然後這些頻段會有多少的瓦數限制。
>上次提到的，忘記的名詞

### MAC 層

上面物理層會一直隨時代更新，但是 MAC 的核心概念卻保持不變，也就是**CSMA/CA**
當然會有一些擴充。

## 分支

其實 802.11 是 802 的其中一個分枝；802 有很多其他分支，像是 802.15 這個分支有名的是藍芽

### 有趣的命名的方式

abc 這些後綴名稱就是剛剛提到的擴充，但是 abc 代表的只是上市的時間，不代表開發的時間。
像 b 其實開發的比 a 早。

也不是所有字母都會用到，例如：

- 802.11l
- 因為手寫的話很難分到底是 1 還是 $l$。
- 802.11x
- 會被有些文章拿來當 802.11 的所有擴充的泛稱，所以也被避免掉
- 802.11ab
- 這也會被跳過，因為有些產品同時支援了 a 跟 b
- 所以印上去後，會不知道到底是支援了 a 跟 b，還是支援 ab 這個版本

順帶一提，802.11be 是目前(2023/04/10)正在訂定的標準，前面 WiFi 聯盟負責的。
老師說最近快定完了。

---

# MAC 核心

雖然 802.11 基本核心是分散式環境，大家是隨機存取的機制；但是有些情境下不是那麼的嚴格。

核心的三大要素

- CSMA/CA
- 聆聽後再 contention
- Random Backoff (RBO)
- 忙線則等待
- RTS 和 CTS
- 告知周圍的人

下面則會有更實際的說明

## 一些名詞


- BSS / Basic Service Set
- 由一個基地台和他所控制的手機，所構成的裝置集合
- 基地台在這裡被叫做 Coordination Function
- 也就是 AP
- 移動端(手機)在這裡被叫做 Stations
- 簡稱 STA
- BSA / Basic Service Area
- BSS 的範圍；或者說 AP 的控管範圍，也就是一個 Cell
- IBSS / Independent Basic Service Set
- 完全分散式的網路；相對於剛剛的 BSS，這個沒有中央的 AP
- 由於早期其實 AP 沒有普及，所以這種連線方式還比較常見
- 像有些早期的印表機，因為支援 IBSS 所以可以直接傳東西給他印


- ESS / Extended Service Set
- 將很多個 BSS 連在一起，連成一個大網路
- NTU 和 NTU peap 就是 ESS，是計中架了很多 AP 所連成的一個很大的網路
- 如上面的圖，台大比較像有重疊的那種
- 其實就是以前的多個蜂巢的結構
- ESSID
- 就是你連到的 ESS 的名字
- 然後你所在的 BSS 範圍也會顯示 BSSID
- BSSID 就是網卡的 MAC 地址

- WDS
- 有時候買一些 AP 的時候包裝會寫他支援 WDS
- 就是 AP 之間可以透過無線連線，最終只要有一個透過 ADSL 電話線連到外面就好
- 不像上一張 ESS 是每個 AP 都有連接線出去
- AP 之間連線的時候，會分上下游
- Mesh BSS
- 最新最貴的 AP 連線方式
- 就是上面 WDS 的終極版；一樣只有一個連有線，其他就是都可以互聯
- 這個是比較後來才有的，較後面的 WiFi 才有支援，像 WiFi 6

:::info
大抄不會檢查幾面，主要是為了讓你不要死背；期中考是問答題
:::

## 另一種圖示


---

# Protocol Stack

## Layered Protocol


各層標頭檔 header 組成了每次傳輸的內容

## 802.11 的 Protocol Stack


上面圖中可以看到，總共可以分成四層：

- LLC:
- 這是所有 802 都共有的部分，屬於 L2
- 他是 L2 對 L3 的介面
- 可以確保兩層之間有穩定的資料傳輸
- MAC:
- 這就是 802.11 在管的 L2 部分
- 所有的 802.11 都有這層
- PHY
- 這就是 802.11 在管的 L1 部分
- 不像 MAC 是所有都共有的，物理層彼此間是不相容的
- 而一層物理層可以看到有細分成兩小層
- PLCP / physical layer convergence procedure
- 是 PMD 跟 MAC 之間的介面，處理物理層的格式
- 也就是說扮演著跟 LLC 很像的角色
- PMD / physical medium dependence
- 物理層的技術層，有著各種物理技術 PHY technologies
- 規範不同的調節 modulation 跟編碼 coding 方式

:::info
但是現在網卡大多支援很多種版本的物理層，所以才會用起來像是相容；但其實只是在做模式切換而已
:::

### 以前的 Protocol Stack (WiFi 3 以前)


1997 年的網卡，最常見的就是左邊的三個底層：FHSS、DSSS、Infrared。
>通常會買到中間那個
>只支援 20MHz 的頻寬

到了相對於 1997 「稍微」現代後，演進成右邊三個；左邊的 DSSS 演進成右邊的 DSSS，所以如果裝置是右邊的 DSSS，則他也會同時支援左邊舊的 DSSS，也就是版本上下相容。

:::info
這個是同個技術不同版本的上下相容；在旁邊的 OFDM 也是一樣，有一個演進版本。
可以看到演進版本可能會改變使用頻段，或是速度提升，也因此才會一種技術有很多種速度，就是對該版本的速度更新了很多次。
:::

FHSS 老師說還算常見，但是遠紅外線的就很少見了，而且就沒有演進的版本，可以看到後來演進出來的是 OFDM，以及 OFDM 的演進版本。
>老師說 OFDM 其實理論蠻早的，原因是以前處理硬體部分比較慢，到了現代才出來。

### 現在的 Protocol Stack (WiFi 4 以後)


這就是現代常見的版本。

可以看出隨著技術的進步，頻寬越來越大；而且 SINR 的改善了也使得 QAM 數變越來越大。
>QAM 請詳見之前的筆記
>簡單來說越大，能傳輸的 bit 越大，但是如果 BER 很大就不宜使用過大的 QAM 數

同時也向下相容以前的版本；老師說其實就是根據舊有的晶片開發出新的晶片。
WiFi 6,6E 還有新增 unlicensed band 6Gz。

## 不同物理層有不同的調製編碼方案 MCS


想看更多的話可以直接去[維基百科](https://zh.wikipedia.org/wiki/IEEE_802.11#cite_note-DMG_SC-22)

Coding rate 就是真正拿來傳輸資料的 bit 的比例；其他的 bit 就是用於其他用途而非傳輸資料。

Modulation 的細節要去修通訊原理；要根據 SINR 選擇最適合的 Modulation ，不是越快越好，也一樣請參考之前的筆記，有畫一張圖。

Gaurd interval / GI 是你傳資料之間要隔多久，當然是越小越好。

---

# PHY 層

- 首發早期的 PHY 層
- 2.4GHz 的 FHSS 速度 1,2Mbps
- 2.4GHz 的 DSSS 速度 1,2,5.5 和 11Mbps
- 被廣泛使用在上述的範圍
- DFIR 剛剛的遠紅外線，沒有被廣泛使用
- 現代，融合了高速的 WLAN/Emerging High Speed WLAN
- 5GHz OFDM 就是 802.11a
- 2.4GHz OFDM 就是 802.11g

一樣記得，不同的物理層是不相容的，需要製成「集成晶片 integrated wireless NICs
」才可以進行上面切換的動作

現在的底層就是 **OFDM / Orthogonal Frequency Division Multiplexing** 為主

## 頻段圖


現代聰明的 ap會自動幫你選最適合的頻段；通常會選擇紅色的分佈方式，這樣才可以最大利用頻段。

## DSSS 的 PLCP 跟 PDU

這裡以 DSSS 作為範例介紹 Packets header，標頭檔的部分；說明了物理層的格式。
不同物理層內容只會稍微不太一樣。

### long preamble


1. SYNC / synchronization
一堆重複交錯的 101010 訊號，用來對齊用；long preamble 格式的會有 128 bit，這也是名稱 long 的由來

2. SFD 開始訊號
這串訊號用來告訴接收者，在這段訊號之後，真正的資訊「就要來了」。
如果這裡解碼錯誤，導致後面的資訊遺失，那就是必須重傳的情況了。

:::info
也就是說，SYNC 用來「對齊」，SFD 用來傳達「真正的資訊要來了」。
這樣可以避免掉訊號遺失，雜訊等等。
:::

3. 資料部分
1. Signal
傳輸的速率，就是上面的 MCS 表對應的各種速度。
這個很重要，因為會影響解碼方式，也因此通常傳前面這幾個標頭的速率**通常會是固定且慢的**
像圖中就是**全都固定使用最慢的 1 Mbps**
>但是資料部分 DLPDU 的速度是依照 Signal 所講的速度傳輸的
>而上面連資料都使用最保守的 1 Mbps
2. Length (microseconds)
告訴資料會傳多久；是用上面的傳輸速率算出時間的
3. FCS Frame check sequence
檢查用；CRC Code
4. Service 保留用

### short preamble


大致跟 long 一樣，但是有些許不同

1. SYNC / synchronization
可以發現 short 只有 56 bit，這也是名稱 short 的由來
2. 傳輸速率
剛剛有說到，標頭這些重要資訊，通常會用最慢且固定的速率傳輸
但是在 short preamble 中，就是不固定也沒有最慢
1. 可以看到負責對位還有告知訊息開始的 SYNC 跟 SFD 仍保持一樣
畢竟這兩個最重要，沒收好訊息就爛掉了
2. 後面的資料則是以 2 Mbps 傳，稍微加快一些傳輸速度
代表對環境的狀態很放心。
3. DLPDU 的傳輸速率就是根據不同的 Signal 有不同速率

:::success
怎麼知道是長還是短？老師說他判斷應該是可以用 SYNC 和 SFD 來判斷
:::

---

# MAC layer

>分為必要跟選用的選項，所以通常為了節省成本，選用的就沒有。

- Traffic services
- Asynchronous Data Service (mandatory)
- 基於"Best-effort"原則交換數據封包
- 支援 broadcast and multicast
- Time-Bounded Service (optional)
- 使用 PCF 來實作
- Access methods
- DCF CSMA/CA (mandatory)
- 藉由隨機「等待 back-off」來避免碰撞
- 最小化連續封包 packets 間的距離
- 使用 ACK 封包來確認接收
- DCF w/ RTS/CTS (optional)
- Distributed Foundation Wireless MAC
- MAC 無線的分散式基礎
- 用來避免 Hidden node 問題
- PCF (optional)
- AP 會根據一個 list 去 poll terminals，或者說使用端

# Transmission Priorities -- IFS / inter frame spaces

IFS 是個一小段的時間，可以用來確定事情的優先度。

分為三種

- SIFS / Short Inter Frame Spacing
- 代表最高的優先度，用於 ACK、CTS、Polling response 等等
- PIFS / PCF IFS
- 代表中間的優先度，用於有時限的 PCF 服務 time-bounded service using PCF
- DIFS / Distributed Coordination Function IFS
- 代表最低的優先度，用於資料服務的同步

:::info
上面提到的 PCF 跟 DCF，是在前面的圖(下圖)有出現的東西；大略定義在上方
:::


為甚麼這三種 IFS 可以區分優先度？因為他們的時間長度不一樣：

$$
SIFS<PIFS<DIFS
$$

下圖也可以看出


不同的傳輸內容，會有不同的優先度，也就有了不同的等待時間；越高優先度的等待時間最短。

# CSMA / CA

802.11 用來避免碰撞的核心。

- 如果 STA 要開始傳輸封包，他會先去聆聽頻段 CA，聆聽時根據 CCA / Clear Channel Assessment。而所謂的 CCA 是指：
- 如果 STA 聆聽了一段 IFS，都是是空的
- 那麼，ST 就會開始傳輸
- 那如果聽到的某個時間點有人開始傳輸
- 他會繼續聽，等傳輸結束
- 然後再聽一段 IFS 的時間
- **並且，還要聽隨機一段時間 RBO**
- 如果在 RBO 的時間，有某個 STA 的 RBO 冷卻好了
- 他就會開始傳
- 並且他的傳輸會讓其他 STA 的 RBO 停止計時
- 其他 STA 直到下一次又開始進行 RBO 得時候，會從上次的時間繼續冷卻
- 但是有些協議版本則是直接重新骰一個 RBO 時間

下面用例子來介紹 802.11 避免碰撞的方法。


圖中有五個裝置共用頻段。為了有更強的說明，「聆聽」會改用「監聽」。

1. 首先三號在一開始有個封包要傳，於是三號會先監聽一段 IFS，而這個 IFS 是 DIFS，可以參考上面提到的規定。

2. 監聽完完整的 DIFS 後，三號發現都是空的，並沒有人正在使用頻段，於是三號就安心地開始傳封包；而三號的傳輸會使得該頻段處於 busy 的狀態

3. 同時 1 號、2 號、5 號都各自在某個時間點想要開始傳封包，並在那個時間點開始監聽頻段，**但是他們都會監聽一段時間後，聽到 3 號正在傳**。

4. 因此他們便會持續監聽，等到 3 號傳完，然後各自先均監聽一段 DIFS 的時間，這部分很像 3 號一開始做的事；但是監聽完後，**會再監聽一段隨機的時間**，這三個人的隨機時間均不相同，為圖中紅色加綠色的長度。

5. 二號監聽的隨機時間比較短，他聽完後，發現是空的，就開始傳；而這會造成 1 號跟 5 號監聽到一半發現有人在傳，於是他們的 timer 就會暫停下來。途中 4 號加入了進來，但是如同第 3 點，他也會和 1、5 一起等待 2 號傳完。

6. 等二號傳完後，他們三個再次進行第 4 點的動作，但是此時有點不一樣：4 號的確是隨機骰出一段時間，但是 1 跟 5 號他們有上次暫停計時的時間，所以他們會繼續計時剩餘的時間。

7. 此時尷尬的事情發生了，4 號隨機骰到的時間，剛好跟 5 號繼續的剩餘時間一樣長，而這就導致了碰撞。

8. 碰撞後就會造成傳輸失敗，所以他們三個又再次回到第 4 點，而這次換 4 號跟 5 號隨機抽時間，1 號則是繼續他剩餘的時間；並且最後換 1 號開始傳。

:::warning
有另一種是不會暫停計時，而是一律重新再給一個新的計時器，很像是排隊又要重排。
:::
:::info
監聽這個詞比較貼切，持續檢查頻段的這個動作，下面的其他 IFS 也都是監聽
:::

---

## 加入 ACK

上面只有提到「傳輸資料」而已，但是通常為了確認有傳成功，所以其實還會傳輸 ACK 封包。


接收方會在接收完資料後，監聽 SIFS 時間後，傳輸 ACK 封包。

這裡就可以看出不同時長的 IFS 是如何達成優先排序了；由於照前面的規則來說，其他想要傳的 ST，要等待的是 DIFS，這個時間比 SIFS 長，所以 ACK 封包一定會比他們先傳輸出去。

## 加入 RTS CTS

還記得為了避免 Hidden Node 而採用的 RTS CTS 方法嗎，如果把這兩種封包也加入討論的話：


可以發現跟上面 ACK 是一樣的原則，但是稍微不同的地方是，傳輸方監聽完 DIFS 後一開始傳的不是資料，而是 RTS，並且之後的間距都是 SIFS，原理如同上面 ACK 所述。

:::info
雖然上面的 RTS 前面等的是 DIFS，但那是因為他是「第一個開始傳輸的」才會有這個情況。
如果今天情況是，傳輸方在上一次監聽的時候，聽到有人在傳，也就是說上面的圖片開頭處會是某人傳完後的情況；那麼他除了會監聽 DIFS 這段時間之外，還要多監聽一段 RBO
:::

### NAV / Network allocation vector

如果其他人有監聽到 RTS 或 CTS，就會知道要從 RTS 或 CTS 訊號結束的時候開始，開始等，等到最近的一個 ACK 結束，而記住等待時間的方法就是設一個 NAV。
這樣這段時間他就可以先休息一下。

前面講的 CCA 其實有一步是檢查 NAV，如果有 NAV 話，就直到等到那個時間再真的去聽就好，沒有的話就是直接去聽。

要怎麼知道 NAV 要設置等多久？還記得上週 RTS 提到的會告訴傳多久嗎？
就是記錄從 RTS 結束到 ACK 會傳多久，CTS也有；然後裡面就有兩者雙方的地址。
後面會詳細介紹。

### 老師的優先順序概念分享

老師說他的統整下來，他歸納出
- 「連續動作之間」都是用 SIFS
- DIFS 很像是「新回合的開頭」

例如，傳輸資料後，必須要傳輸 ACK 以確認接收狀態，這就兩個就是個連續的動作。
RTS、CTS 也是，這些都是「傳輸資料」這個大動作中的「個別小動作」，彼此間是連續的；也因此等待時間才使用 SIFS。

直到傳了 ACK 代表傳輸結束，代表要開始新的一輪，所以就使用 DIFS。

## Contention window CW


每次隨機骰時間的上界，上界會隨著失敗次數變大。
這樣一來人少的時候就會有等短一點的效果，人越多就會更容易提高上界，也就容易等更久。

- 在 802.11 $CW=2^{n}-1$
- n 是失敗的次數
- 有絕對的下界跟上界，如圖中的 min 跟 max，值並不會超過這個範圍

而如果連續發生了很多次失敗，則很有可能是人太多了

## Random backoff / RBO 機制

$$
Backoff\ \ time=random()×Slot\_Time
$$

- $Slot\_Time$ 是基礎的時長，要以這個時長乘上隨機骰到的數字 $random()$
- 是 PHY 層的參數之一
- $random()$
- 會從 [0,CW]之間以均勻分布隨機取樣一個數字出來
- 這個 CW 有個絕對的上下界，如同上面所提
- 每個802.11標準的上下界會不一樣，也是 PHY 層的參數

總之是為了達到 slotted 的效果。

:::success
這是一種 (truncated) binary exponential backoff
:::

這時可以注意到 RBO 的用意：
為什麼上一次聆聽如果不是 busy 或者沒有傳失敗，下一次就不用 RBO？因為 RBO 是為了將你跟其他人分開。
舉例來說，A 是聽到 B 在傳輸，等 B 傳輸完後的情形，而 C 則是一開始聽的時候 B 就已經結束傳輸了；此時 C 就是上面舉例的那些情形。

## PIFS 跟 EIFS

這兩個時間，PIFS 上面有提到，EIFS 則是更長的 IFS

$$
SIFS<PIFS<DIFS<EIFS
$$

---

# 流程圖


要把流程圖跟38頁的圖對照在一起

1. 如果要傳資料，先檢查有沒有 busy

2. 如果是空閒的，先監聽 DIFS，然後再檢查，如果還是空閒的就可以傳了

3. 如果有在其他人傳，也就代表當前是 busy 而的，同下面：

4. 如果是 busy 的，等他傳完後，就會先監聽 DIFS 而然後還要再監聽一段 RBO ，在這之後都沒有人傳，才可以開始傳

然後流程圖也可以轉到狀態圖，但是比剛剛流程圖包含更複雜的細項，也就是包含了收 這件事，原本只有傳

# 狀態圖


檢查周遭有沒有人是看能量大小
但是也有可能是其他人要傳給我，所以也會去檢查 preamble 如果真的有人要穿資料，就會開始接，如果讀到地址是別人的，就會等他傳完

那個狀態圖的 RBO 應該同時包含了 DIFS

總之描述一個協議的方法不只一種

:::info
老師說只需要在大家 contention 的時候，注意要 slotted 就好
:::

---

# MAC frame structure

換講 MAC 的標頭，下面是大致的架構，但不一定每個都會有。


## Frame control / FC

FC 裡面的內容不是全部都會有，但就是有給很多內容可以讓你說明。

重要的是 Type 跟 subtype，這兩個可以知道這則訊號「是哪種訊息」；
可能是 RTS CTS ACK data 等等和其他特定功能的訊號。


上面只是一部份

# RTS 標頭


- FCS / frame check sequence
- 前面 PHY 標頭也有這個東西
- 是個 32-bit CRC
- Duration (Microsecond)
- 代表了「時間長度」
- 可以回想 PHY 的 Signal
- $$T=data\_time+CTS\_time+ACK_time+SIFS×3$$
- 為甚麼會有 3 個 SIFS，可以回顧上面的圖
- RA
- RTS 封包的接受者的位置
- 也就是要接收 data 的裝置的位置
- TA
- RTS 封包的傳輸者的位置
- 也就是想要傳 data 的裝置的位置

# CTS 標頭


- FCS / frame check sequence
- 前面 PHY 標頭也有這個東西
- 是個 32-bit CRC
- Duration (Microsecond)
- 代表了「時間長度」
- 可以回想 PHY 的 Signal
- $$T=data\_time+ACK\_time+SIFS×2$$
- 為甚麼會有 2 個 SIFS，可以回顧上面的圖
- RA
- CTS 封包的接受者的位置
- 也就是要傳輸 data 的裝置的位置

可以發現並沒有 TA

# ACK 標頭


- FCS / frame check sequence
- 前面 PHY 標頭也有這個東西
- 是個 32-bit CRC
- Duration (Microsecond)
- 跟 Data 的 Fragmentation 有關
- 所以長度會跟後面還有多少要傳的封包數量有關
- 對應的 SIFS 也是
- RA
- ACK 封包的接受者的位置
- 也就是要傳輸 data 的裝置的位置

ACK 的 duration 請見下面的 Fragmentation 會比較清楚。
由於資料並不是都一次傳完，而是會拆成很多小區塊一個一個傳送，而每傳送一個小區塊就需要一個 ACK，也因此才會有 Duration 這項資訊要傳。

# Data Fragmentation


敘述如上。要記得 FC 裡面有個 more fragments，這像參數要設成 1，直到最後一個 ACK，這項參數才可以設為 0。

可以發現 RTS CTS 的 NAV 結束點不是最後一個 ack，而是稍微近一點的。
會這樣設計的緣故是，可能後面的資料傳一傳遇到意外，就傳不成功，那麼如果其他人還傻傻等到最後一個 ACK 結束，會很沒有效率。

而遇到意外的部分，是因為 CSMA/CA 仍舊無法保證可以完全避免碰撞，有可能像是你走來走去，從一個環境好走進環境差，就會讓傳輸中途斷掉。