[WiFi] WIFI 7 공유기가 자신의 존재를 알리는 방법(2/2) - Beacon Frame의 MLE + Wireshark로 분석하기

프롤로그

이 글을 거의 일주일동안 썼는데, 생각보다 양이 적어서 놀랐다.

표준문서 하나하나씩 보면서 어디까지가 표준이고, 어디까지가 논문 내용이고, 어디까지가 지피티 할루시네이션인가 구분하느라 그랬나... 개념 잡는 게 조금 오래걸렸던 거 같다.

WiFi 7 에 대해서 이해하려면 다음 정보들을 알아야한다.

[Beacon / Probe Response]
 ├─ 기본 정보 (SSID, 채널)
 ├─ RNR
 │   └─ 다른 링크/AP 정보
 ├─ MLE
 │   └─ 멀티링크 구조
 └─ Multiple BSSID
     └─ 여러 AP 묶음

 

---

Multi-Link Operation(MLO) 구조 모델

MLO와 MLD에 대한 초반 개념은

2026.03.24 - [네트워크] - [WiFi] 최신 WIFI 7 (IEEE 802.11 be)에 새로 도입된 Multi-Link Operation(MLO)에 대해 알아보자

[WiFi] 최신 WIFI 7 (IEEE 802.11 be)에 새로 도입된 Multi-Link Operation(MLO)에 대해 알아보자

이전 글에 작성하여 발행하였다. 그래서 자세한 내용은 해당 글을 참고해주길 바란다.

 

MLO는 MLD 간에 하나 이상의 링크를 통해 통신할 수 있도록 하는 절차의 집합이다. 또한 이러한 통신을 하나 이상의 링크를 통해 관리하는 역할을 한다.

쉽게 말하면, 여러 링크를 통해 AP와 STA(둘 다 MLD) 간에 데이터를 송수신할 수 있는 기술로, EHT(초고속 처리량)을 위해 고안된 방식이다. 

이때 려어 링크를 통해서 데이터를 송수신이 가능하다라고 하는데, 그 링크들이 2.4GHz, 5GHz 대역대에 각각 위치할 수도 있고, 동일 대역의 서로 다른 채널에서 통신이 가능할 수도 있다.

MLO = 여러 링크를 동시에(or 선택적으로) 사용하는 통신 방식

 

기존 Wi-Fi에서 하나의 링크만을 연결하여 송수신하던 것을, 여러 링크 단위로 관리하는 것이다.

 

MLO는 두 MLD가 공통적으로 지원하는 주파수 대역이나 채널에서

• 탐색(discover)
• 동기화(synchronize)
• 인증/인증 해제((de)authenticate)
• 연결/재연결((re)associate)
• 연결 해제(disassociate)
• 링크 및 기타 자원 관리

을 수행할 수 있게 한다. 

 

MLD는 하나의 Upper MAC(U-MAC)과 여러 개의 Lower MAC(L-MAC)으로 구성된 구조를 가진다.

표준에서는 각 MLD가 하나의 MAC-SAP을 가지며, 상위 계층에서는 이를 하나의 MAC 인터페이스처럼 인식한다.(MAC-SAP(MAC Service Access Point)은 상위 계층이 MAC 계층의 서비스를 이용하기 위한 논리적 접점(인터페이스)을 의미한다.)

우리가 쓰는 윈도우나 안드로이드 같은 상위 계층 입장에서 보면, MLO는 MAC-SAP이라는 딱 하나의 입구만 가진다. 그래서 운영체제는 "아, 네트워크 인터페이스가 하나 있구나"라고만 생각할 수 있다

그러나 MLD 내부에는 여러 링크에 대응되는 STA들이 존재하며, 각 STA는 서로 독립적인 MAC 주소를 가진다.(STA는 일반적으로 말하는 사용자 단말기기(Station)를 의미하는 것이 아니라, MLD 내부에서 각 링크를 담당하는 MAC 엔티티를 의미하며, 해당 STA는 링크별 Lower MAC 기능을 수행한다)

예를 들어, 왼쪽 MLD에서는 MLD MAC 주소가 P이고, 각 링크에 대응되는 STA들의 MAC 주소가 각각 x, y, z로 존재한다. 오른쪽 MLD 역시 MLD MAC 주소가 Q이며, 각 링크의 STA들은 a, b, c라는 MAC 주소를 가진다.

각 링크는 x-a, y-b, z-c로 위와 같이 1:1로 연결된다.

즉, 동일한 MLD에 속한 링크들이라도 각각 서로 다른 MAC 주소를 가지며, 링크 단위로 독립적인 통신이 이루어진다.

단, 예외적으로 MLD MAC 주소(P)가 x, y, z 중 하나와 동일할 수도 있고, Q 역시 a, b, c 중 하나와 동일할 수도 있다. 하지만 이는 구현 선택 사항이며, 일반적으로는 서로 다른 MAC 주소를 사용한다.

 

 

MLD = 논리 장치 (MAC-SAP 1개)
STA = 링크 단위 MAC 엔티티
MAC 주소 = STA 단위로 부여

 

AP MLD의 구조를 나타낸 그림은 아래와 같다.

이 그림을 기준으로 구조를 한 번에 이해하려면, 데이터 흐름과 관리 흐름을 분리해서 보는 것이 가장 중요하다.

우선 가장 위에 있는 MAC-SAP은 상위 계층과 MAC 계층을 연결하는 논리적 인터페이스이다. 운영체제나 IP 계층 입장에서는 이 지점 하나만 보이기 때문에, 실제로 내부에 여러 링크가 존재하더라도 하나의 네트워크 인터페이스처럼 인식된다. MLO의 핵심 특징인 “여러 링크를 쓰지만 하나처럼 보인다”는 특성이 바로 여기서 시작된다.

이전 글에 있던 저 Application 에서 U-MAC으로 들어가는 과정이 저 MAC-SAP으로 들어가는 것이다.

MAC-SAP 아래에는 두 가지 경로가 존재한다. 하나는 MLD Upper MAC Sublayer이고, 다른 하나는 Non-MLD Upper MAC Sublayer이다. MLD Upper MAC은 MLO를 사용할 때 동작하는 상위 MAC(U-MAC)으로, 여러 링크를 통합적으로 관리하는 역할을 한다. 예를 들어 어떤 링크를 사용할지 결정하거나, 트래픽을 여러 링크에 어떻게 분배할지 판단하는 기능이 여기에 포함된다. 반면 Non-MLD Upper MAC은 MLO를 사용하지 않는 경우, 즉 기존 Wi-Fi 방식으로 통신할 때 사용되는 경로이다. Wi-Fi 7 장치라 하더라도 상대가 MLO를 지원하지 않거나 단일 링크로 동작해야 하는 상황에서는 이 경로를 통해 통신이 이루어진다.

이 두 Upper MAC 아래에는 MLD Lower MAC Entity가 위치한다. 이 부분이 실제 무선 통신을 수행하는 핵심이다. 각 Lower MAC은 하나의 링크에 대응하며, 실제로 프레임을 전송하고 수신하는 역할을 맡는다. 구체적으로는 backoff 수행, TXOP 획득, 프레임 송수신, ACK 처리 같은 무선 MAC 동작이 모두 여기서 이루어진다. 그리고 각 Lower MAC 아래에는 PHY 계층이 존재하며, 여기서 실제 전파를 통해 신호가 송수신된다. 즉, 데이터는 결국 Upper MAC에서 내려와 Lower MAC을 거쳐 PHY를 통해 무선으로 나가게 된다.

여기서 표준 문서에 언급된 한 문장을 주목해 볼 필요가 있다.

"The MLD upper MAC sublayer distributes MSDUs to the affiliated STAs based on link availability and traffic-to-link mapping."

 

이 문구 때문에 마치 Upper MAC이 데이터를 아래로 일방적으로 밀어 넣는(Push) 것처럼 보일 수 있지만, 실제 동작은 조금 더 역동적이다. 여기서 말하는 'Link Availability(링크 가용성)'란, 하위의 각 Lower MAC이 독립적으로 백오프를 수행하다가 전송 기회를 잡았을 때를 의미한다. 즉, 하위 계층이 전송 준비가 완료되었다는 신호를 보내면 상위 계층이 그제야 패킷을 건네주는 '인출(Pull)' 방식에 가깝게 동작하며 최적의 링크를 찾아 데이터를 쏘게 된다.

이 구조를 실제 흐름으로 보면, 데이터는 상위 계층에서 MAC-SAP으로 들어온 뒤, 상황에 따라 MLD Upper MAC 또는 Non-MLD Upper MAC으로 전달된다. MLO를 사용하는 경우에는 MLD Upper MAC이 링크를 선택하고, 해당 링크의 Lower MAC으로 데이터가 전달된 뒤 PHY를 통해 전송한다. 반대로 MLO를 사용하지 않는 경우에는 Non-MLD Upper MAC을 거쳐 하나의 Lower MAC과 PHY를 통해 기존 Wi-Fi 방식으로 전송된다. 중요한 점은 이 전체 과정에서 MLME는 데이터 경로에 끼어들지 않고, 옆에서 MAC의 동작을 제어하는 역할만 수행한다는 것이다.

결과적으로 이 그림은 “하나의 인터페이스처럼 보이지만 내부에서는 여러 MAC이 동시에 동작하는 구조”를 보여준다. 그리고 이 구조 때문에 동일한 AP임에도 불구하고 서로 다른 링크에서 서로 다른 MAC 주소가 관찰되는 현상이 발생하게 된다.

이 구조를 이해하면, 실제 패킷을 캡처할 때 동일한 AP임에도 불구하고 서로 다른 MAC 주소가 보이는 이유를 명확하게 설명할 수 있다. 즉, Wi-Fi 7에서는 더 이상 “하나의 AP = 하나의 MAC 주소”라는 기존 개념이 성립하지 않으며, 링크 단위로 독립적인 MAC이 존재하는 구조로 확장되었다.

---

IE(Information Element)

IE(Information Element)는 802.11 관리 프레임의 Body에 포함되는 가변 길이 정보 필드이며, (Element ID, Length, Value) 구조로 구성되는 정보 요소이다.

IE는 802.11 관리 프레임에서 다양한 네트워크 정보를 전달하는 가변 구조의 핵심 데이터 단위이다.

이들 요소는 802.11 관리프레임 종류에 따라 달라지며, 종류마다 나타내는 순서(order)도 조금씩 다르다.

주로 비콘 프레임, 프로브 응답 프레임과 같은 관리프레임에서 나타난다.

• 관리 프레임(Beacon, Probe Response 등)에 포함됨
• 프레임 종류에 따라 IE 구성 및 순서가 달라짐
• 가변 길이 구조로 다양한 정보를 유연하게 전달

주요 요소로는 다음과 같다.

Element ID	이름	설명
0	SSID	ESS(확장 서비스 셋)의 이름
1	Supported Rates	지원 속도 (1, 2, 5.5, 11 Mbps 등)
2	FH Parameter Set	FHSS 관련 파라미터
3	DS Parameter Set	채널 정보 (현재 사용 채널)
4	CF Parameter Set	PCF(Contention-Free) 관련 설정
5	TIM	트래픽 존재 여부 (절전 STA용)
6	IBSS Parameter Set	Ad-hoc 네트워크 설정
7	Country	국가별 주파수/전력 규제 정보
8	Hopping Pattern Parameter	FHSS hopping 정보
9	Hopping Pattern Table	FHSS hopping 테이블
10	Request	정보 요청용
11~15	Reserved	사용 안 함
16	Challenge Text	인증 과정에서 사용
17	Power Constraint	송신 전력 제한 (802.11h)
45	HT Capabilities	802.11n 기능 지원 정보
48	RSN	보안 정보 (WPA2 등)
61	HT Operation	802.11n 동작 정보
127	Extended Capabilities	확장 기능 정보
191	VHT Capabilities	802.11ac 기능 지원 정보
192	VHT Operation	802.11ac 동작 정보
221	Vendor Specific	벤더 확장 (WPA 등)

 

---

Extension Informaion Element(Extension IE)

기존 802.11에서는 Informaeion Element(IE)의 종류를 Element ID(0~255)로 구분하였었다. 그런데 표준이 확장되면서 새로운 IE들이 계속 추가되면서 255 이내로 이 모든 것들을 수용하기는 어려워졌다. 당장 MLO에서도 STR일수도 있고, nSTR, MLMR, EMLSR등 다양하고, 그 외에 여러가지 정보가 필요할 수도 있는데, 이 모든 것들이 255내로 들어가기란 불가능. 

그래서 이를 해결하기위해서 Extension IE(확장 IE)를 도입하였다.

Element ID에 255값을 넣고 확장 IE임을 의미시킨 후에, 길이 다음에 Element ID Extension 으로 실제 IE 타입을 식별한다.

WIFI 7 에서 주요 IE목록은 다음과 같다.

Element Name	Element ID	Extension	설명	확장 가능	분할 가능
EHT Operation	255	106	EHT 동작 정보	Yes	No
Multi-Link (MLE)	255	107	MLO 핵심 정보	Yes	Yes
EHT Capabilities	255	108	EHT 기능 지원 정보	Yes	No
TID-to-Link Mapping	255	109	트래픽 ↔ 링크 매핑	Yes	Yes
Multi-Link Traffic Indication	255	110	링크별 트래픽 상태	Yes	Yes
QoS Characteristics	255	113	QoS 관련 정보	Yes	Yes
MLO Link Info	255	133	링크 세부 정보	Yes	No
AID Bitmap	255	134	STA 식별 비트맵	Yes	No
Bandwidth Indication	255	135	대역폭 정보	Yes	No
TWT Information Extension	255	141	절전 스케줄 정보	Yes	No

어떻게 쓰이는지는 바로 밑의 MLE을 보면서 구조를 자세히 알아보자.

 

Wi-Fi 7에서는 대부분의 새로운 기능이 Element ID 255 기반의 확장 IE로 정의되며, Extension 값으로 구분된다

---

Multi-Link Element(MLE)

Multi-Link Element는 Wi-Fi 7에서 도입된 대표적인 확장 IE로, MLD(Multi-Link Device)의 구조와 링크 정보를 전달하는 핵심 요소이다.

여기서 Element ID는 255값이 들어가고, Element ID Extension에는 107번이 들어가게 된다.

Element ID = 255
Element ID Extension = 107  (Multi-Link Element (MLE))

이라면 MLE라는 것을 알 수 있다.

 

하나씩 각 필드에 대해서 알아보도록 하자.

예전, 관리프레임/제어프레임/데이터프레임을 구분할 때 Type 필드 2바이트와 Subtype 4바이트로 어떤 프레임인지 구분했던 것 처럼,

[2026.03.18 - [네트워크] - [WiFi] IEEE 802.11 계층과 프레임에 대해 알아보자 (Wireshark로 뜯어보는 802.11 Frame의 모든 것)]

이 element의 variant(변형 종류)는 Multi-Link Control field의 Type subfield(Type 필드)에 의해 결정되며, 이에 따라 특정 field(필드) 또는 subfield(서브필드)가 존재하지 않을 수도 있다.

• variant : (MLE 종류)
• Type subfield : (MLE 타입 구분 필드)

---

Multi-Link Control

Multi-Link Control은 다음과 같다.

 

2바이트는 각각 3비트,1비트, 12비트로 이루어져있다.

 

 

Type

3비트이기 때문에 총 0~7까지 총 8가지를 표현할 수 있다.

이 값은 Multi-Link Element(MLE)의 종류(variant)를 구분하는 데 사용된다.

Type 값	의미
0	Basic
1	Probe Request
2	Reconfiguration
3	TDLS
4	Priority Access
5~7	Reserved

여기서 Type = 0은 일반적인 Basic MLE를 의미한다.
Beacon Frame이나 Probe Response Frame에서 주로 확인하게 되는 MLE가 바로 이 Basic 타입이다.

이 글에서는 Wireshark를 통해 Beacon Frame을 확인할 것이므로, 여기서 다루는 대상은 Type 0, 즉 Basic MLE에 해당한다

 

 

Reserved

Reserved 필드는 1비트이며, 현재는 사용되지 않는 예약 영역이다.

 

 

Presence Bitmap

Presence Bitmap 서브필드는 Common Info field 안에 어떤 subfield들이 존재하는지 표시하는 비트맵이다.

즉, Common Info에 포함될 수 있는 여러 정보들 중에서, 실제로 어떤 정보가 들어 있는지를 12비트로 미리 알려주는 역할을 한다.

여기서 중요한 점은, Presence Bitmap의 길이는 항상 12비트로 고정되어 있지만, 각 비트가 의미하는 내용은 MLE의 Type에 따라 달라진다는 것이다.

다시 말해, MLE는 최대 8가지 타입으로 나뉠 수 있고, 각 타입마다 Common Info에 들어가는 정보 구성이 다를 수 있다. 따라서 Presence Bitmap 역시 Type에 맞게 해석해야 한다.

이 글에서는 Beacon Frame에서 사용하는 Type 0 (Basic) 기준으로 설명할 것이며, 해당 Presence Bitmap의 각 비트가 어떤 의미를 가지는지는 아래에서 자세히 살펴보겠다.

 

---

Common Info

Common Info field는 모든 링크에 공통적으로 적용되는 정보를 담는 영역이다.
다만 Multi-Link Element는 Type에 따라 구조가 달라지므로, Common Info 내부에 포함되는 subfield의 구성 역시 Type에 따라 달라질 수 있다.

기본적으로는 모든 링크에 공통적인 정보들을 포함하지만, Basic Multi-Link element(Type = 0)에서는 다음과 같은 일부 필드가 포함될 수 있다:

• Link ID Info
• BSS Parameters Change Count

이 두 필드는 구조상 Common Info에 위치하지만, 성격상 모든 링크에 동일하게 적용되는 정보라기보다는 링크 식별 또는 상태 변화 추적과 관련된 예외적인 정보에 해당한다.

 

 

위에서 나온 Presence Bitmap은 Common Info field에 어떤 subfield들이 실제로 포함되는지를 나타내는 비트마스크이다. 즉,

• 비트 값이 1 : 해당 subfield가 Common Info에 포함됨
• 비트 값이 0 : 해당 subfield는 포함되지 않음

이때 중요한 점은, Presence Bitmap은 단순히 “포함 여부”만 결정하며,
각 비트가 어떤 subfield를 의미하는지는 Type에 따라 달라진다는 것이다.

 

Common Info field는 공통 정보를 담는 영역이며,
Presence Bitmap을 통해 실제 포함되는 subfield가 동적으로 결정된다.

 

Basic MLE(Type = 0) 기준으로 Presence Bitmap의 12비트가 각각 어떤 의미를 가지는지, 어떤 내용이 들어가는지는 밑에서 자세히 설명한다.

 

---

Link Info

Link Info field(링크 정보 필드)는 하나 이상의 링크에 특화된 정보(specific information)를 담으며, 선택적으로(optional) 존재한다. 즉, 링크마다 다른 정보들에 대한 내용들이 들어가는 건데, 존재하는 경우 하위 정보 블록이 들어가있다.

Link Info field 내부에는 여러 개의 subelement가 포함될 수 있으며, 각 subelement는 Subelement ID로 구분된다

Subelement ID	이름	설명	확장 가능
0	Per-STA Profile	각 링크(STA)의 상세 정보 (핵심)	Yes
1 ~ 220	Reserved	사용 안 함	-
221	Vendor Specific	벤더 정의 확장	Vendor defined
222 ~ 253	Reserved	사용 안 함	-
254	Fragment	큰 데이터를 나눠 담기 위한 조각	No
255	Reserved	사용 안 함	-

여기서 subelement ID가 0인 경우에 들어가는 정보는

• 링크별 MAC 주소
• 채널 정보
• capability
• 기타 링크별 설정

와 같다. 

Link Info는 여러 subelement로 구성되며, 실제 핵심 정보는 Per-STA Profile(ID=0)에 담긴다

---

Basic Multi-Link Element

자, 방금 위에서 MLE에 대해서 배웠고

이런 구조로 되어있는 것을 확인하였다. 이제 우리는 Multi-Link Control 에서 Type = 0일 때 Basic Multi-Link Element(Basic MLE)에 대해서 자세히 알아보자.

Basic MLE의 형식에 대해서 먼저 알아보자

Basic Multi-Link element는 MLD와 그에 속한 STA들에 대한 정보를 담으며, 이 정보는 ML Discovery(멀티 링크 탐색 과정)과 ML Setup(연결 설정)에서 광고(advertised)된다. 초기 개념에 대한 정보는 이전에 내가

2026.03.24 - [네트워크] - [WiFi] 최신 WIFI 7 (IEEE 802.11 be)에 새로 도입된 Multi-Link Operation(MLO)에 대해 알아보자

[WiFi] 최신 WIFI 7 (IEEE 802.11 be)에 새로 도입된 Multi-Link Operation(MLO)에 대해 알아보자

에서 언급을 했었다.

 

지금은 Basic Multi-Link element(Basic MLE)의

• Presence Bitmap subfield(프레즌스 비트맵) : 필드 존재 여부 표시 비트,
• Common Info field(공통 정보 필드)  : 공통 정보,
• Link Info field(링크 정보 필드) : 링크별 정보

각각 알아볼 것이다.

 

 

Presence Bitmap

Basic Multi-Link element에서의 Multi-Link Control field 내 Presence Bitmap subfield의 형식은 다음과 같다.

맨 뒤 5바이트는 현재는 사용되지 않는 예약 영역이다.

비트	필드 이름	의미	해석
B0	Link ID Info Present	Link ID Info 존재 여부	"이 MLE가 어떤 링크 기준인지"
B1	BSS Parameters Change Count Present	BSS 변경 카운트 존재 여부	"AP 상태 바뀌었는지"
B2	Medium Synchronization Delay Information Present	동기화 지연 정보 존재 여부	멀티링크 동기화 관련
B3	EML Capabilities Present	EML 기능 정보 존재 여부	Wi-Fi 7 핵심 기능 중 하나인 EMLSR 관련 기능 정보
B4	MLD Capabilities And Operations Present	MLD 기능 및 동작 정보 존재 여부	"이 AP가 MLO를 어떻게 지원하는지" MLD 전체 Capability
B5	AP MLD ID Present	AP MLD ID 존재 여부	MLD 자체 식별 ID AP MLD 식별자
B6	Extended MLD Capabilities And Operations Present	확장 MLD 기능 존재 여부	추가 기능 확장
B7~B11	Reserved	예약

 

비트 = 1  : 해당 필드가 Common Info에 포함됨
비트 = 0 :  해당 필드는 없음

를 의미한다. 즉,

1. Type 확인 (여기서는 0 = Basic)
2. Presence Bitmap 읽음
3. 1인 비트만 Common Info에서 파싱

이다.

 

세부 내용들로는 아래와 같다.

 

Link ID Info

Link ID Info Present 서브필드는
Common Info field에 Link ID Info 서브필드가 포함되어 있으면 1로 설정되고,
그렇지 않으면 0으로 설정된다.

 

BSS Parameters Change Count

BSS Parameters Change Count Present 서브필드는 Common Info field에 해당 서브필드가 포함되어 있으면 1로 설정되고,
그렇지 않으면 0으로 설정된다.

non-AP STA에서는 항상 0
AP에서는 대부분 1이지만, 특정 프레임(Authentication, FT Action)에서는 0로 설정된다.

 

Medium Synchronization Delay

Medium Synchronization Delay Information Present 서브필드는 해당 정보가 Common Info field에 포함되어 있으면 1, 아니면 0으로 설정된다.

또한 non-AP STA에서 전송되는 Basic MLE에서는 항상 0으로 설정된다.

 

EML Capabilities

EML Capabilities Present 서브필드는 해당 정보가 포함되어 있으면 1, 아니면 0으로 설정된다.

단, NSTR mobile AP MLD에 속한 AP는 이 값을 0으로 설정한다.

 

 

MLD Capabilities And Operations

MLD Capabilities And Operations Present 서브필드는 해당 정보가 포함되어 있으면 1, 아니면 0으로 설정된다. 이 필드는 다음 프레임에 포함될 때 1로 설정된다:

• Beacon
• Probe Response
• (Re)Association Request
• (Re)Association Response
• Link Reconfiguration Response

그 외의 프레임에서는 0으로 설정된다.

 

AP MLD ID

AP MLD ID Present 서브필드는 Common Info field에 AP MLD ID가 포함되어 있으면 1, 아니면 0으로 설정된다.

다음 경우에는 0으로 설정된다:

• non-AP STA가 전송한 경우
• Beacon frame
• (Re)Association Response frame
• Authentication frame
• multi-link probe response가 아닌 Probe Response

Beacon에서는 AP MLD ID를 따로 안 넣는다.

존재할 수 있지만, Beacon에서는 의도적으로 안 넣음

 

Extended MLD Capabilities

Extended MLD Capabilities And Operations Present 서브필드는 해당 정보가 포함되어 있으면 1, 아니면 0으로 설정된다.

다음 조건을 만족할 때 1로 설정된다:

• Beacon
• Probe Response
• (Re)Association Request
• (Re)Association Response
• Link Reconfiguration Response

그리고 해당 필드 내부에 최소 하나 이상의 subfield 값이 0이 아닌 경우

그 외의 경우에는 0으로 설정된다.

---

Common Info

이제 type =0 의 Common Info에 대해서 보자.

 

 

 

Common Info Length

Common Info Length subfield는 Common Info field 전체 길이(옥텟 수)를 나타내며, 이 길이에는 Common Info Length 필드 자신(1바이트)도 포함된다.

Length = 자기 자신 포함

 

 

MLD MAC Address 

MLD MAC Address subfield는 Basic Multi-Link element가 설명하는 MLD의 MAC 주소를 나타낸다.

이 MLE의 “대표 MAC 주소”

MLD MAC 주소는 Multi-Link Device 전체를 식별하는 주소이며, 해당 주소는 MLO 구조에서 상위 MAC 계층(U-MAC)을 통해 관리되고 사용된다.

 

 

Link ID Info

Link ID Info field의 Link ID subfield는 해당 필드를 포함하고 있는 element에서 설명되는 링크의 식별자를 나타낸다.

"이 MLE가 어느 링크 기준으로 작성됐는지"

Link ID Info field의 Link ID subfield는 Basic Multi-Link element가 설명하는 AP MLD에 속한 AP의 링크 식별자(link identifier)를 나타내며, 다음 조건 중 하나를 만족한다:

• 지금 Beacon을 보내는 AP(Basic Multi-Link element를 전송한 AP)
• 비콘 안 보내는 숨겨진 AP도 포함 가능(Basic Multi-Link element를 포함하는 Multiple BSSID element에서 nontransmitted BSSID에 해당하는 AP)

 

Basic Multi-Link element가 non-AP STA에 의해 전송되는 경우, Common Info field의 Link ID Info subfield는 존재하지 않는다.

즉, STA는 Link ID 안 보냄

 

 

BSS Parameters Change Count

BSS Parameters Change Count subfield는 부호 없는 정수(unsigned integer)를 가지며, 초기값은 0이다.

중요한 변경이 발생했을 떄(중요 네트워크 상태[critical update]) +1이 된다.

기준 AP 또는 숨겨진 AP 상태 변화 반영

 

여기서 중요한 점은

Link ID Info와 BSS Parameters Change Count subfield는 AP가 전송한 Management frame에 포함된 Basic MLE에서는 Authentication frame을 제외하고 항상 존재한다.

 

 

Medium Synchronization Delay

AP가 전송한 프레임에 포함된 Basic MLE에서 Medium Synchronization Delay Information subfield이다. 이전 글들에서 이건 뭐하는 친구인지는

2026.04.19 - [네트워크] - [WiFi] 802.11be의 EMLSR 모드에 대해서 알아보자 - 동작과정/표준/관련연구/MATLAB 실습

[WiFi] 802.11be의 EMLSR 모드에 대해서 알아보자 - 동작과정/표준/관련연구/MATLAB 실습

에서 EMLSR 동작과정 중간에 적혀있다.

• MediumSyncDelay : (링크 동기화 지연 타이머)
• Duration : (지속 시간)

"링크 전환/동기화 동안 기다리는 시간"이다

0바이트 or 2바이트[0바이트면 쓰이지 않음] 이고, 쓰일때 이바이트는 아래 구조로 이용한다

Medium Synchronization Duration subfield는 MediumSyncDelay 타이머의 지속 시간(duration)을 나타내며, 단위는 32 µs이다.

Medium Synchronization Maximum Number Of TXOPs subfield는 STA가 MediumSyncDelay 타이머가 동작하는 동안 시도할 수 있는 최대 TXOP 개수(dot11MSDTXOPMax)를 나타내며, 이 값은 실제 값보다 1을 뺀 값으로 표현된다.

 

단, 값이 15일 경우에는
MediumSyncDelay가 0이 아닐 동안 제한 없이 TXOP 시도 가능을 의미한다.

여기서 더 자세한 내용은 생략한다.

 

 

EML Capabilities subfiled format

항상 있는 필드가 아니라 조건부 필드

EML Capabilities subfield는 EMLSR operation과 EMLMR operation을 위한 capability(기능 지원 정보)를 광고하기 위한 여러 subfield들을 포함한다.

필드	의미
EMLSR Support	단일 라디오 MLO 지원 여부
Padding Delay	초기 프레임 padding 시간
Transition Delay	링크 전환 지연
EMLMR Support	멀티 라디오 MLO 지원 여부
Transition Timeout	전환 제한 시간
Reserved	예약

EMLSR Support subfield는

Basic MLE에 의해 설명되는 MLD가 EMLSR operation을 지원하는지를 나타낸다.

지원하면 1, 아니면 0으로 설정된다.

EMLMR Support 랑 EMLSR Support 둘 다 1일 수는 없다.

EMLMR Support	EMLSR Support	의미
1	0	EMLMR(멀티 라디오) 사용
0	1	EMLSR(싱글 라디오) 사용
0	0	둘 다 미지원
1	1	허용 안 함

여기서 패딩딜레이 설정값은

EMLMR/EMLSR Padding Delay subfield value	EMLMR/EMLSR padding delay
0	0 µs
1	32 µs
2	64 µs
3	128 µs
4	256 µs
5–7	Reserved

다음만 허용이 된다.

transition delay 설정값은

EMLSR/EMLMR Transition Delay subfield value	EMLSR/EMLMR transition delay
0	0 µs
1	16 µs
2	32 µs
3	64 µs
4	128 µs
5	256 µs
6–7	Reserved

Transition Timeout subfield 값은

이렇게 허용이 된다.

 

그 외 추가적인 건 더 있지만, 일단은 여기까지만 알아보자

---

Multi-link Operation의 Beacon

Wi-Fi 7의 Multi-Link Operation(MLO)에서는 하나의 AP가 단순히 자신의 정보만 광고하는 것이 아니라, 같은 MLD(Multi-Link Device)에 속한 다른 AP(= 다른 링크)들의 정보까지 함께 광고하는 구조를 가진다.

기존 Wi-Fi에서는 하나의 AP가 하나의 BSSID와 하나의 채널만을 대표했다면, MLO 환경에서는 하나의 AP가 여러 링크를 대표하는 “정보 허브” 역할을 수행하게 된다.

AP가 AP MLD에 속해 있고, nontransmitted BSSID가 아닌 경우, 해당 AP가 전송하는 Beacon 및 Probe Response에는 다음 정보가 포함된다.

• 같은 AP MLD에 속한 다른 AP들의 정보
• Reduced Neighbor Report element
• TBTT Information field (길이 16 이상)

즉, 하나의 Beacon 안에 다른 링크(AP)들의 존재와 동작 정보가 함께 포함된다.

이는 단순히 “주변 AP 정보”가 아니라, 같은 장치(MLD)에 속한 다른 링크들을 설명하는 정보라는 점이 중요하다.

 

일부 AP는 직접 Beacon을 전송하지 않을 수 있다. 이를 nontransmitted BSSID라고 한다.

이 경우 구조는 다음과 같이 바뀐다:

• AP1: 실제 Beacon을 보내지 않음
• AP2: Beacon을 보내는 AP
• AP2가 AP1의 정보를 대신 광고

즉, “모든 AP가 직접 Beacon을 보내는 것이 아니라, 일부 AP가 대표로 여러 AP의 정보를 함께 광고한다”

이 구조는 MLO에서 오버헤드 감소 + 관리 효율성을 위한 설계이다.

 

조건에 따라 하나의 Beacon에는 다른 MLD에 속한 AP 정보까지 포함될 수 있다.

예를 들어:

• 서로 다른 AP MLD가 같은 위치(co-located)에 존재하고
• 같은 BSSID 그룹에 속하며
• 아직 다른 AP에 의해 광고되지 않은 경우

 해당 AP들도 Beacon에 포함되어야 한다. 즉, 하나의 Beacon 안에 여러 MLD의 정보가 동시에 들어갈 수 있다.

 

Reduced Neighbor Report에 MLD 관련 정보가 포함되는 경우, 다음 필드들이 함께 설정된다.

• AP MLD ID
• Link ID
• BSS Parameters Change Count

이 필드들은 이전에 살펴본 MLE 구조와 동일하게
각 링크의 식별 및 상태 정보를 전달하는 역할을 한다.

 

 

같은 AP MLD에 속한 AP들은 Beacon 타이밍(TBTT)을 강하게 동기화해야 한다.

• AP 간 TBTT offset ≤ 254 TU
• 255 값은 사용 금지

이는 MLO에서 여러 링크를 동시에 활용하기 위해 시간 동기화가 필수적이기 때문이다.

 

즉 정리를 하면

• 하나의 AP는 자신뿐 아니라 다른 링크(AP) 정보까지 Beacon에 포함한다
• Beacon은 단일 AP 정보가 아니라 MLD 전체 구조를 광고하는 역할을 한다
• 일부 AP는 직접 Beacon을 보내지 않고 다른 AP가 대신 광고한다
• 경우에 따라 여러 MLD 정보가 하나의 Beacon에 포함될 수 있다
• 모든 AP는 **정확한 시간 동기화(TBTT)**를 유지해야 한다

 

Wi-Fi 7의 Beacon은 더 이상 “하나의 AP 정보”가 아니라, MLD 전체 링크 구조를 설명하는 통합 정보 프레임이다.

---

WireShark 실습

AP로는 ipTime의 802.11be가 지원이 되는 Be19000을 준비하였다.

모니터 모드가 되는 무선 랜카드 2개를 준비하였다.

그리고 와이파이7 802.11be가 되는 무선랜카드 하나 준비하여 윈도우 11에 장착하였다.

두 무선랜카드 모두 ipTime A3000U 장비를 사용하였고, 둘 다 Realtex RTL88x2bu 드라이버를 사용하였다.

지피티나 다른 블로그들 찾으면, 모니터모드를 쓰기 위한 설치 및 설정 방법은 잘 나올테니 이 글에서는 따로 다루지 않겠다. 
[언젠가 시간이 되면 한 번 적어보겠다]

그리고 둘 다 모니터 모드를 설정해준다.

sudo ip link set wlan0 name mon0
sudo ifconfig mon0 down
sleep 1
sudo iwconfig mon0 mode monitor
sudo ifconfig mon0 up


sudo ip link set wlan1 name mon1
sudo ifconfig mon1 down
sleep 1
sudo iwconfig mon1 mode monitor
sudo ifconfig mon1 up

을 이용하여, 기존에 

iwconfig 했을 때 wlan0, wlan1이 있던 상황을

mon0, mon1로 Monitor Mode로 설정하였다.

mon0은 2.4GHz 대역을 관찰하게 할 거고, mon1 은 5GHz 대역을 관찰하게 할 것이다.

http://192.168.0.1/ 에 들어가서, MLO 설정에 2.4GHz, 5GHz만 설정을 한 다음에, 이제 모니터모드로 MLO 동작과정에서 나오는 프레임들을 잡아보자.

칼리리눅스 터미널 창을 2개를 띄워놓고 각각

sudo airodump-ng mon0 -c1-13

sudo airodump-ng mon1 -c36-153

를 입력한다.

그리고, 보면, 이제 여러 AP들을 찾을 수 있을 것인데, 내가 찾고자 했던 ICIS_MultiLink가 2.4GHz대역과 5GHz 대역 모두에서 존재하는 것을 확인할 수 있다.

단, 2.4GHz대역에서 있는 맥주소는 62:38:6C:22:20:9F이고, 5GHz에서 잡히는 맥 주소는 6A:38:6C:22:20:98로, 공유기 설정에서 생성한 MAC는 5GHz와 동일한 것을 발견할 수 있다.

 

위에서

"MLD MAC 주소(P)가 x, y, z 중 하나와 동일할 수도 있고, Q 역시 a, b, c 중 하나와 동일할 수도 있다. 하지만 이는 구현 선택 사항이며, 일반적으로는 서로 다른 MAC 주소를 사용한다"

라고 언급했듯이,

L-MAC의 MAC주소는 각각 다르지만, U-MAC의 맥주소 6A:38:6C:22:20:98와  5GHz 대역의 맥주소가 6A:38:6C:22:20:98로 동일한 것을 확인하였다.

 

 

이제 윈도우11에서 802.11be6500 Archer TBE400UH 랜카드를 장착하여 와이파이 설정을 확인해보자.

802.11be가 사용된 것을 확인하였다.

지금다시 봤을때는 Wi-Fi 7으로 뜨고 있긴 하다.

 

 

아무튼간에, 

mon0은 2.4GHz대를 모니터링하고, mon1은 5GHz대를 모니터링한 후에 각각 필터를

wlan.ssid=="ICIS_MultiLink"

로 해당 와이파이에 어떤 통신이 이루어지고 있는지 확인해보자.

보면 2.4GHz대에서는 채널 1번에서 비콘 프레임이 잡히고 있고

5GHz(오른쪽)에서는 채널 36번에서 비콘프레임이 잡히고 있는데, 5GHz대에서 계속 실시간으로 잡히고, 2.4GHz대에서는 어쩌다 1~2개씩 잡히고 있는 상황이다.

2.4GHz대는 62:38:6c:22:20:9f BSSID값을 가지고, 5GHz대에는 6a:38:6c:22:20:98로 잡힌다.

표로 정리해보면

 

현재까지 확인할 수 있는 정보는

	AP	STA
MLD MAC	6a:38:6c:22:20:98	AC:A7:F1:3EA5:0F
2.4GHz MAC	62:38:6c:22:20:9f
5GHz MAc	6a:38:6c:22:20:98

이다.

 

 

MLE부터 먼저 찾아볼까?

이렇게 있고, 일단 비트 부터 보자.

파란색 칠해진 부분 2칸 앞에 FF가 보인다. 255로 extended element id라는 것을 의미하고, 그 다음에 10은 Ext Tag Length를 의미한다.

그 다음 나오는 6b(107)로 Multi link임을 알려준다.

여기 앞에 3개 알았으니, 그 다음 Multi-Link Control을 봐보자.

Type이 00으로 Basic Multi link element이다.

그 밑에 쭉쭉 위에서 설명했던 내용이 있다. Presence Bitmap도 쭉 12바이트가 보이고, 1 켜져있는 게 해당 값들이 있는거구나 알 수 있다.

Common Info칸을 가보자.

2.4GHz에서 보이는 MLD MAc Address와 5GHz 에서 보이는 MLD MAC Address가 둘 다 6a:38:6c:22:20:98 인것을 확인할 수 있다.

즉, 멀티링크로써 이 둘은 같은 AP에서 왔음을 확인할 수 있다.

여기서, Link ID를 보면 2.4GHz는 0x01, 5GHz는 0x00번으로 번호가 매겨진 것을 확인할 수 있다.

 

그 외에, EMLSR Support : True로 되어있어서, EMLSR을 사용하는 것을 확인할 수 있다.

EMLSR이 뭔지 모르겠다면

2026.04.19 - [네트워크] - [WiFi] 802.11be의 EMLSR 모드에 대해서 알아보자 - 동작과정/표준/관련연구/MATLAB 실습

[WiFi] 802.11be의 EMLSR 모드에 대해서 알아보자 - 동작과정/표준/관련연구/MATLAB 실습

여기서 확인하고 오자.

EMLSR의 대표적인 성능 문제인 EMLSR Padding Delay, EMLSR Transition Delay 값 모두 0으로 설정되어있다.

 

 

고작 이만큼 뜯어볼라고 이 2편을 쓴거다.

그래서 여기서는 아쉬우니 1편에서 나온 RNR까지 같이 까보자.

2026.04.24 - [네트워크] - [WiFi] WIFI 7 공유기가 자신의 존재를 알리는 방법(1/2) - Beacon Frame의 RNR

[WiFi] WIFI 7 공유기가 자신의 존재를 알리는 방법(1/2) - Beacon Frame의 RNR

여기에서 나온 내용대로 와이어샤크로 마저 확인해보자.

찾았다.

보면 Neightbor AP Information 이 2개가 있음으로써, 각각 2개의 링크를 알려준다.

 Neighbor AP TBTT Offset: 249

• 약 249 TU 후에 비콘 옴
• 1 TU ≈ 1024 μs
• 약 255ms 뒤에 비콘 도착

“지금 바로 스캔하지 말고, 이 타이밍 맞춰서 들어가라”

BSSID: b2386c222098

• 해당 AP의 MAC 주소
  → 정확한 AP 식별자

 Short SSID: 0xfa051702

• SSID 압축 버전
  → 빠른 비교용

BSS Parameters: 0x5c

• AP 상태 플래그 집합
• 포함될 수 있는 것:
  • co-located AP 여부
  • same SSID 여부
  • 기타 capability

“이 AP의 성격”을 나타냄

 

여기서 채널을 보자.

• Operating class: 134
• Channel Number: 53

이 AP는 5GHz 대역의 채널 53에 존재함라고 알려준다.

어 근데, 난 분명 36번 채널을 스캔하는데 저게 나온다.

 

다른 걸 보면

1번에 있는 2.4GHz대에 있는 것을 확인했느넫 53번에 하나가 더 숨어있는 셈이다.

 

BSSID : b2:38:6c:22:20:98인데

6GHz에 같은 공유기에서 있는 다른 와이파이를 알려준다.

MLO을 쓰는 건 아니니 그냥 넘기면 된다.

이렇게 RNR까지 다 까보았다.

 

AP Channel Report

처음에 이거 발견했을 때 be에서는 못봤는데 갑자기 나타나서 다른 애들 알려주길래 저게 RNR인줄알았다. 근데 아니었다.

Radio Measurement (802.11k) 관련 규격에서 사용한다.

이쪽에 가서 채널을 스캔하라! 라고

얘는 명령을 내려주는 친구다.

11k이다 보니까 옛날부터 있던 애를 여기서 쓰고 있다.

 

 

 

에필로그

이전 글과 이번 글 둘을 합쳐서 거의 2주 가까이 썼다. 그래서 이것저것 겹치다보니까 결국엔 이렇게 되었는데..

똥글이 되어버린 거 같다. 근데 시간투자만큼은 제일 많이 한 글들이다.