프롤로그
이전에,
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)에 대해 알아보자
프롤로그우리가 와이파이를 쓸 때 가장 중요하게 생각하는 요소는 무엇일까?나는 일단 빠른 속도, 끊기지 않는 것이 가장 중요하다고 생각한다. 4GB 프로그램 다운받는데 18시간 걸린다거나(실제
taesan-smj.tistory.com
WIFI 7의 핵심기능인 Multi-Link Operation(MLO)에 대해서 알아보았다.
더 낮은 지연, 더 높은 안정성, 그리고 더 많은 동시 연결을 처리할 수 있는 새로운 방식이 요구되는 세상에 맞춰서, 기존에 하나의 링크만 선택하여 통신하던 Single Link에서 여러 링크를 동시에 사용하는 MLO를 사용한다는 것이다.
여기에, 기존 2.4GHz 5GHz 말고 6GHz까지 넓은 대역폭을 사용하여 해당 요구들을 충족한다.
MLO 동작하기 위한 방법으로 기존 글에서는 STR모드와 nSTR모드에 대해서 설명했었다
| 기존 방식 | STR(Simultaneous Transmission and REception) | nSTR(Simultaneous Transmission and REception) |
| - 한 채널 고정 - 간섭 생기면 성능 저하 |
- 여러 링크를 동시에 송수신 - 가장 최고 성능 - 그러나 전력, 비용, 복잡도 문제 |
- 여러 링크에서 동시에 송신과 수신을 수행하지 않음 - 내부 간섭, 링크 간 간섭 감소 - 구현 복잡 |
이론적으로 MLO를 사용한다면, 여러 링크를 동시에 사용하기 때문에 througput(처리량)이 증가할 것이고, 특정 채널이 혼잡하면 다른 링크로 우회하여 빠르게 처리랄 할 수 있을 것이다.
하지만, 현실에서는 Multi Radio를 사용하기에는 RF 체인 제한, 전력 소모 문제, 하드웨어 구현의 복잡성, 비용 증가 등의 이유로 아직까지는 제약이 존재할 수 밖에 없다. 그래서 대부분의 단말은 Single Radio를 사용할 수 밖에 없다.
이 Single Radio를 사용하지만, MLO 환경에서 여러 링크를 사용하기 위해서 나온 모드가 바로 EMLSR(Enhanced Multi-Link Single Radio) 모드이다. 하나의 Radio를 사용하면서, 여러 링크를 전환하며 MLO 효과를 흉내내는 방식이다.
이번 글에서는 이 EMLSR이란 무엇이고 어떻게 동작하는지에 대해서 알아보고, MATLAB의 실제 시뮬레이션으로 동작 방식을 확인해보고, 최근 연구들에 대해서도 알아보자.
MLO Modes
RF체인에 대해 알고있으면 MLSR, MLMR에 대해서 이해하기 편해진다.
RF는 Radio Frequency의 약자이다.
RF 체인(RF Chain)이란, 무선 통신에서 디지털 데이터와 무선 신호를 변환하기 위해 필요한 하드웨어 처리 경로 전체를 의미하며, 물리적인 회로 한 줄이다.
| RF 체인 수 | 의미 |
| 1개 | 한 번에 하나의 신호만 처리 |
| 2개 이상 | 여러 신호/스트림 동시 처리 가능 |
쉽게 얘기하면, RF 체인은 몇 개의 신호를 동시에 처리할 수 있는지, 즉, 하드웨어 처리 능력을 의미한다.
즉, MLSR은 Multi Link를 Single Radio, 여러 개의 링크를 하나의 Radio를 이용하여 처리한다라는 의미이고
MLMR은 Multi Link를 Multi Radio로 처리한다라는 의미이다. 그러니까 이를 통해서 MLO모드를 정리하면

TXOP(Transmission Opportunity)
EMLSR을 이해하려면 TXOP 개념이 반드시 필요하다.
TXOP란, IEEE 802.1에서 한 번 채널 접근에 성공한 노드가 일정 시간동안 데이터를 전송할 수 있는 점유 시간을 의미한다.
기본 CSMA/CA를 통해서 채널에 접근을 성공했을 때 , 하나의 패킷을 보낼 수 있는데,
매 패킷을 보낼때마다 이렇게 되면 오버헤드가 증가하고, 처리량이 감소한다.
그러니까, 이거를 해결하기 위해 한 번 채널에 접근할 권한을 얻었으면, 특정 시간동안에는 해당 채널은 점유한 애가 계속 쓰도록 하는 것이다.
프레임 사이에 SIFS(Shor Interframe Spece)를 사용하여 계속 점유를 하고, 다른 노드는 이 시간 동안 끼어들 수 없다.
장점
- contention 횟수 감소 → throughput 증가
- burst transmission 가능 → 지연 감소
단점
- 한 노드가 오래 점유 → 공정성 저하
- 다른 노드 starvation 가능
EMLSR
위에서 언급했던 대로, EMLSR은 여러 링크를 하나의 Radio로 보내는 모드이다.
EMLSR 장치는 기존 STR장치나 nSTR장비 보다는 감소된 하드웨어 요구사항을 가진다.
표준에서 정의한 바로는
- MLD가 지원 여부를 advertise
- 특정 링크 집합을 선택
- 해당 링크에서만 동작
- TXOP 단위로 동작
- transition delay / padding delay 사용
이렇게 동작하는 것이라고 적혀있다. EMLSR 지원여부는 Capability로 표시되고,..그렇다.
한 번에 하나의 링크에서만 동작하며 TXOP 단위로 행동한다, 해당 링크에서만 데이터를 AP와 STA이 서로 주고받을 수 있다. 이를 통하여 전력 소모를 낮춘다.
해당 동작을 하는 동안 세부적인 내용인 vendor사 마음대로이며, 어떤 게 효율적인지는 연구가 필요한 상황이다.
정리를 하자면,
EMLSR은 하나의 Radio로 여러 링크를 활용하는 기술이 아니라, “여러 링크를 사용할 수 있는 환경에서, 단일 Radio가 반드시 지켜야 하는 동작 규칙”을 정의한 표준 모드이다. 따라서 표준은 링크 선택이나 스케줄링 알고리즘을 정의하지 않고, 클라이언트가 TXOP 동안 어떤 링크에서 어떻게 동작해야 하는지에 대한 제약만을 규정한다.
main PHY와 aux PHY
이건 EMLSR 이해에서 핵심이다.
main PHY / aux PHY는 표준용어는 아니고, 논문에서 쓰는 개념 모델이다. IEEE 802.11be 표준에는 두 용어를 직접 정의는 하지 않았으나, 정의된 동작 제약을 수행하기 위해, 그리고 설명하기 위해 나온 구현 관점의 추상화이다.
EMLSR에서 존재하는 제약은, 한 번에 하나의 링크에서만 송수신이 가능하다. 하지만, 여러 링크의 상태는 계속해서 알아야한다. 하나는 써야하고, 하나는 계속 상태를 알아야하기 떄문에 이러한 개념이 발생하게 되었다.
main PHY는 실제 데이터를 송수신하는 담당하는 PHY이다. 반대로, aux PHY는 다른 링크를 감시(듣기) 하거나 보조 역할을 하는 PHY이다.
Main PHY
- 실제 데이터 송수신
- TXOP 수행
- AP와 frame exchange
한 번에 하나의 링크에만 붙으며, TXOP동안에는 해당 링크에서 벗어날 수 없다.
Aux PHY
- 다른 링크 감시
- 채널 상태 확인 (CCA)
- ICF(Trigger frame) 수신 준비
데이터 송수신 안 할 수도 있고, 구현에 따라서 TX 가능/불가능이 정해진다.
이렇게 나누는 이유는 Main PHY가 한 링크에서 TXOP 수행 중일 때, 다른 좋은 링크가 생겨도, 있는지 알 수 없게되면 잡을 수 없다. 해당 링크를 Aux PHY가 대신 감시하거나 해서 처리량을 높인다.
EMLSR 동작 과정
downlink
AP가 STA한테 데이터를 먼저 보내주는 downlink 일때 먼저 보자.

AP는 특정 링크에서 데이터를 전송하려고 할 때, 가장 먼저 Initial Control Frame(ICF) 으로 해당 링크에서 자신이 데이터를 보낼 것임을 미리 예고한다. 즉, ICF는 “지금 이 링크에서 TXOP을 시작하겠다” 는 신호이다.
링크가 2개 이상 연결되어 있을 때, main PHY가 다른 링크에서 이미 동작 중이라면 AP가 바로 데이터를 보내더라도 STA는 해당 링크에서 이를 제대로 송수신할 수 없다. 서로 데이터를 주고받기 위해서는 main PHY가 해당 링크로 이동해야 하기 때문이다. 그래서 AP가 먼저 ICF를 보내 미리 알려주는 것이다.
ICF 이후에는 바로 데이터가 전송되지 않는다.
사람이 뒤에서 말을 걸 때, 갑자기 바로 용건을 말하기보다는 먼저 가볍게 불러서 상대가 돌아보게 한 뒤 이야기를 시작하는 것과 비슷하다. ICF도 마찬가지로, main PHY가 해당 링크로 이동해 올 때까지 기다려 주는 역할을 한다.
즉, ICF 뒤에는 main PHY가 해당 링크로 이동할 수 있도록 Padding Delay 만큼의 시간이 주어진다.
위 그림처럼, Link 1에는 aux PHY가 있고 Link 2에는 main PHY가 있다고 하자. 이때 AP가 Link 1로 ICF를 전송하여 “이 링크로 데이터를 보내겠다”는 사실을 알린다. 그러면 STA는 이를 인지하고, main PHY가 해당 링크에서 송수신을 수행할 수 있도록 Padding Delay 동안 Link 1로 이동한다.
그렇게 main PHY가 Link 1로 이동을 완료하면, 그 이후부터 해당 링크에서 실제 프레임 교환이 이루어진다. 일반적으로 CTS → DATA → BA 순으로 전송이 진행되며, 이 과정 전체가 하나의 TXOP 안에서 수행된다.
이때 BA는 Block ACK 로, 여러 데이터 프레임에 대해 ACK를 하나씩 보내는 대신 마지막에 묶어서 한 번에 응답하는 방식이다. 즉, TXOP 시간을 더 효율적으로 사용하기 위한 메커니즘이라고 보면 된다.
이렇게 데이터를 Link 1에서 전송하고 있는 동안에는, AP는 다른 링크(Link 2)로 해당 STA에게 데이터를 보낼 수 없다.
즉, TXOP이 진행되는 동안에는 해당 링크에서만 프레임 교환이 이루어진다.
DL TXOP가 종료되면, Main PHY는 특정 링크에 계속 고정되어 있는 것이 아니라, 다시 EMLSR 링크들을 감시하는 Listening 상태로 복귀해야 한다. 이때 Link 1과 Link 2 모두에서 데이터가 오는지를 확인할 수 있는 상태가 되어야 한다.
이렇게 TXOP 이후, 다시 모든 링크를 감시할 수 있는 상태로 돌아가기까지 걸리는 시간을 Transition Delay라고 한다. 이 시간이 지난 후에는 STA는 다시 ICF를 기다리는 상태가 된다.
uplink
이제는, STA이 먼저 데이터를 보내는 상황인 Uplink상황을 확인해보자.

데이터를 보내기 위해, 각 링크에서 각각 backoff를 진행하여(링크별 CSMA/CA) 채널 접근을 시도한다. 그 중에서 먼저 채널 접근 권한을 획득한 링크가 나오면, main PHY가 해당 링크로 이동한다.
Main PHY의 이동이 완료되면, STA는 RTS를 보내고 CTS(옵션이기는 하다)를 받는다. 이후 실제 데이터를 전송하고, AP로부터 BA를 수신한다.
uplink에서도 마찬가지로, TXOP 동안에는 해당 링크에서만 통신이 이루어지며, 다른 링크는 사용되지 않는다.
TXOP가 종료되면, main PHY는 특정 링크에 계속 고정되어 있는 것이 아니라, 다시 EMLSR 링크들을 감시하는 Listening 상태로 복귀해야 한다. 이때 Link 1과 Link 2 모두에서 데이터가 오는지를 확인할 수 있는 상태가 되어야 한다.
이렇게 TXOP 이후, 다시 모든 링크를 감시할 수 있는 상태로 돌아가기까지 걸리는 시간을 Transition Delay라고 한다.
Detail 동작와 제약
앞에서 Downlink와 Uplink의 기본 동작을 살펴보았는데, 실제 EMLSR 동작에서는 몇 가지 중요한 제약과 예외 상황이 존재한다. 이 부분을 이해해야 EMLSR의 전체 흐름을 정확하게 파악할 수 있다.
EMLSR은 단순히 링크를 전환하는 기술이 아니라, TXOP 동안의 단일 링크 고정, Transition Delay, CCA 기반 경쟁, 그리고 MediumSyncDelay와 같은 제약 조건을 포함하는 복합적인 동작 구조를 가진다.
1. TXOP 동안의 제약
EMLSR에서는 TXOP이 시작되면 해당 링크에서만 통신이 이루어진다.
즉, TXOP이 진행되는 동안에는 다른 링크로 전환하거나, 다른 링크에서 데이터를 송수신할 수 없다.
또한 이 시간 동안에는 AP 역시 해당 STA에게 다른 링크로 데이터를 보낼 수 없다.
이는 Single Radio 구조이기 때문에 발생하는 필수적인 제약이다.
2. CCA (Clear Channel Assessment)
각 링크에서는 독립적으로 CCA가 수행된다.
CCA는 현재 채널이 사용 중인지 아닌지를 판단하는 과정으로,
Uplink에서는 STA가 TXOP을 획득하기 위해 반드시 수행해야 한다.
EMLSR에서는 여러 링크가 존재하기 때문에:
- 각 링크가 각각 CCA를 수행하고
- 각 링크별로 backoff가 독립적으로 진행된다
즉, “어느 링크가 먼저 TXOP을 가져오느냐”가 성능에 직접적인 영향을 준다
3. TXOP 이후 복귀 동작 (Transition Delay)
TXOP이 종료되면, STA는 특정 링크에 계속 머무는 것이 아니라 다시 모든 링크를 감시할 수 있는 상태로 돌아가야 한다.
이때 필요한 시간이 바로 Transition Delay이다.
Transition Delay는 TXOP 이후, 다시 listening 상태로 복귀하기까지 걸리는 시간이다.
이 시간이 지나야 STA는 다시 ICF를 수신하거나, uplink 전송을 위한 경쟁에 참여할 수 있다.
4. Medium Synchronization 문제
EMLSR에서는 하나의 링크에서 TXOP을 수행하는 동안, 다른 링크의 상태를 제대로 파악하지 못하는 상황이 발생할 수 있다.
예를 들어:
- Main PHY가 Link 1에서 TXOP 수행 중
- Link 2에서는 채널 상태 변화 발생
이때 Link 2의 PHY는 CCA를 정상적으로 수행하지 못할 수 있다.
이 상태가 일정 시간 이상 지속되면 Medium Sync Loss (채널 동기 손실)가 발생한다
5. MediumSyncDelay
표준에서는 이러한 상황을 처리하기 위해 MediumSyncDelay라는 개념을 정의한다.
- 일정 시간(약 72μs) 이상 채널 상태를 제대로 파악하지 못하면
- MediumSyncDelay 타이머가 시작된다
그리고 이 타이머가 동작하는 동안에는 STA는 일반적인 방식이 아닌, RTS 기반으로 TXOP을 시작해야 한다
즉, 채널 상태를 완전히 신뢰할 수 없기 때문에 보다 보수적인 접근 방식으로 동작하는 것이다
TXOP 동안 다른 링크의 채널 상태를 제대로 파악하지 못한 경우, 해당 링크의 상태를 신뢰할 수 없기 때문에 RTS를 통해 채널을 안전하게 확보한 뒤 전송을 수행한다
uplink에서 RTS/CTS는 옵션이라고 했으나, 이는 채널 상태를 정상적으로 파악할 수 있는 경우에 해당한다.
반면, MediumSyncDelay 상태에서는 채널 상태를 신뢰할 수 없기 때문에,RTS/CTS 기반의 전송 절차를 반드시 거쳐야 한다고 볼 수 있다.
6. Switch Delay
uplink와 downlink을 표현한 그림과 설명 과정에서 switch delay라는 단어가 등장한다. 그러나 이 용어는 표준에서 직접 정의된 용어는 아니다.
EMLSR에서는 main PHY가 한 링크에서 다른 링크로 이동해야 하는데, 이 과정에서 일정한 시간이 소요될 수 있다. 이러한 PHY 전환 과정에서 발생하는 시간 지연을 여러 논문에서는 switch delay라고 표현한다.
이 switch delay는 하드웨어 성능과 구현에 따라 달라질 수 있으며, PHY의 구조나 RF 체인의 성능에 크게 영향을 받는다. 즉, 표준이 아닌 구현에 종속적인 지연 요소라고 볼 수 있다.
지금까지 처리량에 영향을 미칠 수 있는 delay는 총 세가지가 나왔다.
- Padding Delay
- Transition Delay
- Switch Delay
이 중 Padding Delay와 Transition Delay는 표준에서 정의된 파라미터이며,
Switch Delay는 실제 구현 과정에서 발생하는 물리적인 지연을 설명하기 위한 개념이다.
이 세 가지 요소를 어떻게 조절하느냐에 따라 처리량과 지연 성능이 크게 달라질 수 있으며, 이를 최적화하기 위한 연구는 계속 진행되고 있다.
EMLSR 관련 연구1 - Aux PHY의 능력
Understanding the New Enhanced Multi-Link Single Radio Feature of IEEE 802.11be WLANs 논문에서 나온 바로는 EMLSR 성능이 단순히 “멀티 링크를 쓴다”가 아니라, Aux PHY의 능력에 크게 의존한다는 것을 보여준다.
특히, 다음 세 가지 요소에 따라 처리량과 지연이 달라진다.
- aux PHY의 링크 변경 가능 여부
- aux PHY의 데이터 전송 가능 여부
- aux PHY가 main PHY에서 데이터 송수신할 때 sleep 모드 여부
에 따라 처리량과 지연의 변화를 확인한다.
1. aux PHY의 링크 변경 가능 여부
aux PHY가 링크 변경이 가능한 경우, 처리량에 어떤 영향을 미치는지 확인해보자.

기존에 aux PHY가 링크를 변경하지 않는 경우, aux PHY는 자신이 속한 링크에 그대로 존재하지만, main PHY가 다른 링크에서 TXOP을 수행하는 동안에는 실질적으로 해당 링크에서의 동작이 제한된다. 특히, main PHY가 다른 링크로 이동한 동안에는 해당 링크를 적극적으로 활용하지 못하는 상태가 된다.
main PHY가 link1
그 결과, 다른 링크에서는 채널 상태를 충분히 활용하지 못하게 되고, 다음 TXOP를 획득하기 위해서는 main PHY가 다시 해당 링크로 이동한 뒤, transition delay 이후에야 경쟁(backoff)에 참여할 수 있다.
즉, aux PHY가 링크를 변경하지 않는 경우, 각 링크는 TXOP 종류 이우에야 다시 경쟁에 참여하게 된다.
그 결과, 다른 링크에서는 채널 상태를 충분히 활용하지 못하게 되고, 다음 TXOP를 획득하기 위해서는 main PHY가 다시 해당 링크로 이동한 뒤, transition delay 이후에야 경쟁(backoff)에 참여할 수 있다.
즉, aux PHY가 링크를 변경하지 않는 경우, 각 링크는 TXOP 종료 이후에야 다시 경쟁에 참여하게 된다.
나중에 다시 한 번 언급될 내용이지만, main PHY 또는 aux PHY가 해당 링크를 떠나게 되면, 해당 링크에서 진행 중이던 backoff는 유지되지 않고 초기화될 수 있다.
그로 인해, main PHY가 다른 링크로 이동한 이후에는 해당 링크에서 다시 처음부터 경쟁을 수행해야 하는 상황이 발생한다.
반면에, aux PHY가 링크를 변경할 수 있는 경우에는 동작 방식이 달라진다.
aux PHY는 다른 링크로 이동하여 독립적으로 경쟁에 참여하고 backoff를 수행할 수 있다.
그 결과,
- Link 1에서는 main PHY가 TXOP 수행
- Link 2에서는 aux PHY가 미리 backoff 진행
- Transition Delay가 0이 될 수 있음 --> 이동된 채널에서 듣기 상태를 그대로 수행하면 되기 떄문
이 상태에서 Link1의 TXOP가 종료되면, aux PHY가 이미 채널 접근에 유리한 상태를 확보하고 있기 때문에, main PHY가 해당 링크로 이동하자마자 빠르게 TXOP를 시작할 수 있다.
즉,aux PHY가 링크를 변경할 수 있는 경우에는 TXOP 사이의 공백 시간이 줄어들고, 더 빠르게 다음 TXOP을 획득할 수 있기 때문에 처리량이 증가한다.
2. aux PHY의 전송 가능 여부
aux PHY가 스위치가 불가능하여 main PHY와 같은 링크에 존재하는 경우는, 앞에서 설명한 것처럼 실질적으로 다른 링크를 활용할 수 없기 때문에 여기서는 제외하고 넘어간다.
이제, aux PHY가 이미 다른 링크로 switching 된 상태에서, RTS와 같은 간단한 제어 프레임 정도는 전송할 수 있는 경우의 처리량을 살펴보자.

기존 Link 1에서 ICF 이후, 해당 링크에서 TXOP이 시작되면 main PHY가 이동하여 CTS를 응답하고 이후 데이터 송수신이 이루어진다.
이 과정에서 중요한 점은, 다른 링크(Link 2)에서는 aux PHY가 독립적으로 동작할 수 있다는 것이다.
- Link 1에서는 main PHY가 DATA → BA까지 TXOP 수행
- 동시에 Link 2에서는 aux PHY가 backoff를 수행
여기서 차이가 발생한다. aux PHY가 TX 기능이 가능한 경우, aux PHY는 단순히 backoff만 수행하는 것이 아니라, RTS를 전송하여 채널 접근 절차를 미리 진행할 수 있다.
그 결과, aux PHY가 Link2에서 이미 TXOP 직전 상태까지 만들어놓았다. 이 상태에서 Link 1의 TXOP이 종료되면, main PHY는 Link 2 로 이동하자마자 바로 DATA 전송을 시작할 수 있다.
반면, aux PHY가 TX 기능이 없는 경우에는 backoff까지만 가능하고, RTS는 main PHY가 해당 링크로 이동한 이후에 수행해야 한다. 따라서 TXOP 이후에 RTS/CTS 절차가 추가로 수행되면서 전체 지연이 증가하게 된다.
즉, RTS/CTS 과정이 TXOP 이후로 밀리게 되어 추가적인 지연이 발생한다.
결과적으로, aux PHY가 TX 기능을 가지는 경우에는 다음 TXOP을 더 빠르게 시작할 수 있어 처리량이 증가하게 된다.
3. aux PHY의 sleep 여부
여기는 딱히 그림 같은 것은 없다. 간단하게 설명하자면, aux PHY가 Link 1에서 Link 2로 넘어갔을 때, 해당 링크에서 동작하지 않고 sleep 상태로 들어가 버린다면 실질적으로 존재하지 않는 것과 마찬가지이다. 그 결과, 해당 링크에서 CCA나 backoff를 수행할 수 없게 되어 처리량이 낮아질 수 있다.
따라서, aux PHY가 sleep 모드로 들어가지 않고 계속 활성 상태를 유지하는 것이 더 높은 처리량을 얻는 데 유리하다.
위 세 가지 방식(링크 변경 가능 여부, TX 가능 여부, sleep 여부)을 종합해보면, downlink에서는 큰 차이가 발생하지 않지만, uplink에서는 aux PHY의 동작 방식에 따라 처리량에서 큰 차이가 발생한다.
EMLSR 관련 연구2 - 채널 변경 빈도
MLO에서 채널을 변경함으로써 처리량을 높일 수 있다. 그러나 단순히 채널을 변경한다고 해서, 혹은 자주 변경한다고 해서 무조건 처리량이 증가하는 것은 아니다. 채널을 변경할 때마다 switch delay가 발생하기 때문에, 채널 상태가 아주 좋은 깨끗한 상태라면 채널을 변경하여 사용하는 것이 오히려 더 처리량을 떨어뜨릴 수 있다.
그런데도 왜 채널을 변경하는 것이 처리량 증가로 이어질까?
핵심은 채널 상태(간섭 상태)에 있다.
무선 환경에서는 각 채널마다 간섭 수준이 다르고, 이 간섭은 시간에 따라 계속 변한다. 어떤 시점에서는 Link 1이 좋은 채널일 수 있지만, 시간이 지나면 Link 2가 더 좋은 채널이 될 수도 있다.
즉, 하나의 채널만 계속 사용하는 경우, 해당 채널에 간섭이 발생하면 처리량이 급격하게 감소하게 된다.
반면, eMLSR에서는 채널을 전환할 수 있기 때문에, 더 좋은 채널로 이동하여 데이터를 전송할 수 있다. 이로 인해 전체적인 처리량을 높일 수 있다.
하지만, 여기서 중요한 문제는 바로 채널 변경 빈도이다.
채널을 너무 자주 변경하면 오히려 성능이 나빠질 수 있다.
Dynamic Channel Switching and Transition Frequency Scheme for 802.11be eMLSR-Enabled Devices 논문에서는,
- 채널을 변경할 때마다 switching delay 발생
- 이 delay는 데이터 전송이 아닌 “공백 시간”
- 따라서 전환이 너무 잦으면 오버헤드 증가
를 이유로 들면서, 채널에는 이득(간섭 회피)와 비용(delay)이 동시에 존재한다고 말한다.
논문에서는 이를 Transition Frequency (채널 변경 빈도)라는 개념으로 정의하고, 다음과 같은 결과를 보인다
- 채널 변경 빈도가 증가하면 → 처리량 증가 경향
- 하지만 switching delay가 클 경우 → 증가 효과 제한
처리량은 switching delay보다 transition frequency에 더 크게 영향을 받는다
이러한 결과를 바탕으로, 논문에서는 단순히 채널을 변경하는 것이 아니라, 각 채널에서의 throughput을 측정하고 이를 신경망 모델에 입력하여, 환경에 따라 채널 변경 빈도를 동적으로 조절하는 적응형 채널 전환 방식을 제안한다.
MATLAB을 이용한 EMLSR 구조 실습
802.11be System-Level Simulation Using EMLSR Multilink Operation - MATLAB & Simulink
Simulate an IEEE 802.11be EMLSR MLO between an AP MLD and two STA MLDs.
kr.mathworks.com
이 예제 코드랑 거의 비슷하게 실험을 진행할 건데, 이전 글인
2026.04.16 - [네트워크] - [WiFi] WLAN Toolbox 분석하여 802.11be MLO의 EMLSR 동작과정 이해하기
[WiFi] WLAN Toolbox 분석하여 802.11be MLO의 EMLSR 동작과정 이해하기
프롤로그802.11be를 시스템 레벨 수준에서 시뮬레이션을 진행하여 내가 원하는 실험을 하거나 결과를 뽑아내내기 위해서는 지금까지 본 바로는 2가지 방법이 존재하는 것 같다.1. MATLAB의 WLAN Toolbox
taesan-smj.tistory.com
여기서 코드 까본 거 대로 일부분은 좀 수정해서 진행을 하겠다.
우선 제일먼저
openExample("wlan/BeSystemLevelSimulationUsingEMLSRMultiLinkOperationExample")
로 코드들 먼저 다운받자.
그러면

이런 파일들이 생길거다. 저 같은 폴더에다가
emlsr_test.m이라는 파일을 만들어 둔 다음에 해당 파일 처음에
%% clear
clc;
clear;
이걸로 초기화한다.
%% 초기 실험 환경 설정
rng(1,"combRecursive");
enablePacketVisualization = true;
enableNodePerformancePlot = true;
랜덤 시드 1을 설정해주고, 그래프 출력을 보여주는 기능들을 true 설정으로 킨다.
%% 실험 변수 설정
simulationTime = 1; %시뮬레이션 총 시간
MODE = "EMLSR"; % mode - emlsr/str
STAs = 2; % 단말기 개수
% MLD Config
paddingDelay = 3.2e-05;
transitionDelay = 3.2e-05;
bandAndChannelValues = [2.4 1; 5 36];
내가 임의대로 작성한 것인데, 예제코드에 나와있던 부분은 simulationTime, bandAndChannelValues 만큼은 확장적으로 적어두었다.
시뮬레이션 타임은 얼마만큼의 시간을 시뮬레이션 돌릴 것인지, bandAndChannelValues는 밴드 대역폭과 채널의 값을 입력하는 곳이다.
% Channel
% 수신 전력 = PathLoss + ShadowFading / ShadowFading ~ N(0, σ²) / 평균 0 dB 기준 +-5 dB 정도 랜덤 변화
shadowFading = 0; %같은 거리라도 신호 세기가 랜덤으로 변하는 정도
channelPathLoss = "free-space"; %free-space(LOS), residential(벽/가정), enterprise(사무실/벽 많음)
% PathLossModelFcn = @, 직접 공식 작성 가능
그리고 채널 정보들을 이렇게와 같이 설정하였다.
초기 환경변수 설정이 되었으니, 이제 WLAN시나리오대로 예제코드 따라가면서 작성해보자
%% WLAN 시나리오
% 시뮬레이터 생성 및 초기화
numLinks = size(bandAndChannelValues,1);
networkSimulator = wirelessNetworkSimulator.init;
wirelessNetworkSimulator을 초기화해준다.
%% Node 설정
%WlanLinkConfig(링크의 PHY/MAC[주파수/채널] 설정) + 송수신안테나 등
for linkIdx = 1:numLinks
apLinkCfg(linkIdx) = wlanLinkConfig( ...
BandAndChannel=bandAndChannelValues(linkIdx,:), ...
NumTransmitAntennas=numLinks, ...
NumSpaceTimeStreams=numLinks, ...
MCS=3 ...
);
staLinkCfg(linkIdx) = wlanLinkConfig( ...
BandAndChannel=bandAndChannelValues(linkIdx,:), ...
NumTransmitAntennas=1, ...
NumSpaceTimeStreams=1, ...
MCS=3 ...
); %#ok<*SAGROW>
end
노드를 설정해주기 위하여 apLink와 staLink를 각각 설정해준다. 위 코드 중에
NumTransmitAntennas=numLinks, ...
NumSpaceTimeStreams=numLinks, ...
이 부분은 일단 STA에 맞출려고 설정한 건데, 예제코드에서는 2로 적혀있던 값이다.
%TID Mapping
% Link 1 -> TID 0~3
% totalTIDs = 0:7;
% apLinkCfg(1).MappedTIDs = [0 1 2 3];
% staLinkCfg(1).MappedTIDs = [0 1 2 3];
% % %
% % % Link 2 -> TID 4~7
% apLinkCfg(2).MappedTIDs = [4 5 6 7];
% staLinkCfg(2).MappedTIDs = [4 5 6 7];
여긴 링크 TID값을 매핑해주는 곳이다. 실제 코드에서는 TID 0~7번 모두를 전체 링크에서 보낼 수 있게 설정되어있는데, 해당 부분을 수정하고 싶다면 이런식으로 수정을 진행하면 된다.
링크 설정이 전부 완료되었으니, 해당 부분들을 디바이스에 등록하자
% AP MLD 설정
apMLDCfg = wlanMultilinkDeviceConfig( ...
Mode="AP", ...
LinkConfig=apLinkCfg);
% STA의 EMLSR 모드 활성화
for i = 1:STAs
staMLDCfg(i) = wlanMultilinkDeviceConfig( ...
Mode="STA", ...
LinkConfig=staLinkCfg, ...
EnhancedMultilinkMode=MODE, ...
EnhancedMultilinkPaddingDelay=paddingDelay, ...
EnhancedMultilinkTransitionDelay=transitionDelay ...
);
end
for문으로 나는 sta을 등록하여 초기 변수에서 STAs 변수만 바꿔서 설정하게 만들었다. 원래 예제 코드에서는
apMLDCfg = wlanMultilinkDeviceConfig(Mode="AP",LinkConfig=apLinkCfg);
staMLDCfg = wlanMultilinkDeviceConfig(Mode="STA",LinkConfig=staLinkCfg,EnhancedMultilinkMode="EMLSR", ...
EnhancedMultilinkPaddingDelay=3.2e-05,EnhancedMultilinkTransitionDelay=3.2e-05);
이렇게 설정되어있다. (예제 코드가 더 맞는 거 같기도 하고...)
아 여기서 PaddingDelay값과 TransitionDelay값을 하드코딩 되어있는데, 나는 맨 처음 초기 변수 설정에 빼두었다.
그 다음 노드 생성을 하자
%% 노드 생성
% AP 생성
apMLD = wlanNode( ...
Position=[0 0 0], ...
Name="AP", ...
DeviceConfig=apMLDCfg ...
);
% STA 생성
for i = 1:STAs
staMLD(i) = wlanNode( ...
Position = [0*(i+1) 10*(numLinks-i) 0], ...
Name = "STA" + i, ...
DeviceConfig = staMLDCfg(i));
end
nodes = [apMLD staMLD];
%에러 체크
hCheckWLANNodesConfiguration(nodes)
% AP와 STA 연결(노드 연결)
associateStations(apMLD,staMLD,FullBufferTraffic="on");
역시 STA는 for문으로 내가 원하는 위치 position에 생성되도록 코드를 수정하였다. 원본은
apMLD = wlanNode(Position=[0 0 0],Name="AP",DeviceConfig=apMLDCfg);
staMLD = wlanNode(Position=[10 0 0; 0 10 0],Name=["STA1","STA2"],DeviceConfig=staMLDCfg);
nodes = [apMLD staMLD];
이렇게 되어있다.
이제 노드가 생성이 되었으니, 전체 시뮬레이터에 채널을 등록한다
%% 채널 설정
channel = hSLSTGaxMultiFrequencySystemChannel( ...
nodes, ...
ShadowFadingStandardDeviation = shadowFading, ...
PathLossModel = channelPathLoss ...
);
addChannelModel(networkSimulator,channel.ChannelFcn);
addNodes(networkSimulator,nodes);
등록이 모두 완료되었으니, 바로 이제 시뮬레이션을 돌려본다.
%% 트래픽 생성
%% 간섭
%% 시각화
if enablePacketVisualization
packetVisObj = helperPlotPacketTransitions(nodes, simulationTime, FrequencyPlotFlag=false);
end
perfViewerObj = helperPerformanceViewer(nodes,simulationTime);
if enableNodePerformancePlot
plotNetworkStats(perfViewerObj)
end
run(networkSimulator,simulationTime)
stats = statistics(staMLD(1));
disp(stats.MAC);
을 작성하고 재생버튼을 누르면

이렇게 코드가 동작을 하면서 EMLSR동작과정을 확인할 수 있다.

최종 수행된 모습이다.
맨 마지막
stats = statistics(staMLD(1));
disp(stats.MAC);
이 줄로 인하여 전체 처리량이나 패킷 주고받은 것들을 확인할 수 있다.

나머지 예제코드에 있던 것들은 해볼 사람들은 예제코드들 보면서 내용 이해하길 바란다.
에필로그
생각보다 작성하는 데 오래걸렸으나, 이번 글을 작성하기 위해서 논문 3편정도 읽고, 매트랩 코드도 다 까보고, 실습도 진행하면서 글을 정리하면서 작성하다 보니까 만족스럽게 글을 작성한 것 같다.
지금 임시 저장칸에 EMLSR, 접속 과정 등등 세부적인 것들 정리중인데 만족스럽게까지 정리할때까지 언제쯤...올릴지는 아직 미지수
이번 글도 약 3일...
시간없으면 또 지난 3주간처럼 방치될지도 모르겠다..
참고자료
https://kr.mathworks.com/help/wlan/ug/overview-of-wifi-7-or-ieee-802-11-be.html
Overview of Wi-Fi 7 (IEEE 802.11be) - MATLAB & Simulink
Learn the concepts of IEEE 802.11be or Wi-Fi 7 standard.
kr.mathworks.com