전력 절약: 잠자는 단말
휴대폰 화면을 끄고 한참 두어도 카카오톡 알림은 몇 초 안에 온다. 그런데 와이파이 칩은 그동안 대부분 꺼져 있다. 받을 게 있는지 모르는데 어떻게 깨어날 때를 알까? 와이파이 도어벨이나 온도 센서는 배터리 하나로 몇 달을 버틴다. 이 장에서는 단말이 자는 동안 AP가 데이터를 맡아 두는 약속과, 그 약속이 세대마다 어떻게 정교해졌는지를 본다.
- 절전 모드에서 AP가 프레임을 버퍼에 모아 두고, 비컨의 TIM으로 알리는 흐름을 안다.
- TIM 요소의 부분 가상 비트맵을 직접 인코딩해 본다.
- DTIM 주기가 배터리와 방송 프레임 지연을 어떻게 맞바꾸는지 계산한다.
- PS-Poll, U-APSD, TWT가 각각 어떤 기기에 맞는지 구별한다.
“나 잘게, 맡아 줘”
와이파이 칩이 받을 준비를 하고 깨어 있기만 해도(수신 대기) 수십~백수십 mA를 쓰지만, 깊이 자면 1 mA도 안 쓴다. 그래서 단말은 할 일이 없으면 잔다. 다만 AP와 약속을 한다.
- 단말이 보내는 프레임의 Frame Control에 Power Management 비트를 켜서 “이제부터 잔다”고 알린다(7장). 보낼 데이터가 없으면 몸통 없는 Null 프레임으로 알린다.
- AP는 그 단말에게 갈 프레임을 바로 보내지 않고 버퍼에 모아 둔다.
- AP는 매 비컨의 TIM(Traffic Indication Map) 요소에 “데이터가 쌓인 단말”의 AID(연결 번호, 9장) 비트를 켠다.
- 단말은 비컨 시간에 맞춰 잠깐 깨어 TIM만 보고, 자기 비트가 꺼져 있으면 다시 잔다. 켜져 있으면 PS-Poll을 보내거나 PM 비트를 끈 프레임을 보내 데이터를 받아 간다. AP는 더 남은 게 있으면 More Data 비트를 켠다.
방송·멀티캐스트 프레임(ARP, mDNS 등)은 누구 하나를 위한 것이 아니어서, AP는 이것들을 모아 두었다가 DTIM(Delivery TIM) 비컨 바로 뒤에 한꺼번에 내보낸다. DTIM은 비컨 N개마다 한 번이다(DTIM 주기). 절전 단말은 적어도 DTIM 비컨에는 깨어 있어야 방송을 놓치지 않는다.
집에 없을 때 온 택배는 경비실(AP)이 맡아 둔다. 경비실은 정해진 시간마다 게시판(비컨)에 “택배 있는 집 호수”(TIM)를 붙인다. 주민은 그 시간에만 잠깐 내려와 게시판을 보고, 자기 호수가 있으면 찾아간다. 전단지(방송) 같은 모두에게 가는 것은 정해진 날(DTIM)에 한꺼번에 돌린다.
TIM 비트맵 읽기
AID는 1~2007까지 있을 수 있으니 비트맵 전체는 251바이트다. 매 비컨에 다 싣기엔 아깝다. 그래서 앞뒤의 0바이트를 잘라낸 부분 가상 비트맵만 싣고, 잘라낸 앞부분의 길이를 비트맵 제어 바이트에 적는다. 비트맵 제어의 맨 아래 비트는 “DTIM 뒤에 방송 프레임이 나간다”는 표시다.
TIM 요소 인코더
ieee80211_beacon_add_tim_pvb()를 옮긴 것이다.TIM 인코딩: Linux net/mac80211/tx.c의 __ieee80211_beacon_add_tim(), ieee80211_beacon_add_tim_pvb()(“N1은 비트 1 ~ N1×8−1이 모두 0인 가장 큰 짝수”) · 최대 AID 2007, TIM 최대 251바이트: include/linux/ieee80211.h의 IEEE80211_MAX_AID, IEEE80211_MAX_TIM_LEN · 기본값 beacon_int=100, dtim_period=2: hostapd hostapd.conf
배터리 계산
평균 전류 = 잠잘 때 전류 + (깨어 있을 때 전류 − 잠잘 때 전류) × 깨어 있는 시간 비율. 깨어나는 횟수를 줄이는 것이 핵심이다. 단말은 매 비컨이 아니라 DTIM마다, 또는 “듣기 간격”(연결 요청에 적는 listen interval)마다만 깨어날 수 있다. 대신 그만큼 들어오는 데이터가 늦게 도착한다.
깨어나는 간격과 배터리
PS-Poll, U-APSD, TWT
| 방식 | 세대 | 데이터를 받는 법 | 잘 맞는 기기 |
|---|---|---|---|
| PS-Poll | 802.11 원본 | TIM을 보고 PS-Poll 제어 프레임을 보내면 AP가 프레임 하나를 보낸다. More Data가 켜져 있으면 다시 PS-Poll | 옛 기기. 프레임마다 왕복이 필요해 느리다 |
| “깨어남” 알리기 | 오늘날 대부분 | PM 비트를 끈 Null 프레임으로 “깼다”고 알리고 쌓인 것을 한꺼번에 받은 뒤, PM 비트를 켜 다시 잔다 | 휴대폰·노트북. 드라이버가 트래픽을 보고 자동으로 오간다 |
| U-APSD (WMM 절전) | 802.11e | 단말이 보내는 프레임(예: 음성 패킷)이 “방아쇠”가 되어 AP가 쌓인 프레임을 바로 돌려준다 | VoIP 통화 중인 휴대폰. 20 ms마다 보내고 받으며 그 사이 잔다 |
| TWT (Target Wake Time) | Wi-Fi 6 | AP와 단말이 “몇 시 몇 분부터 얼마 동안, 몇 초마다 깨어 있겠다”는 일정을 협상한다. 그 사이엔 비컨도 안 들어도 된다 | 배터리 IoT 센서, 그리고 AP가 여러 단말의 깨는 시각을 흩어 경쟁을 줄일 때 |
PS-Poll 하위 종류 IEEE80211_STYPE_PSPOLL, PM·More Data 비트: Linux include/linux/ieee80211.h · U-APSD: hostapd uapsd_advertisement_enabled, WMM 매개변수(6장) · TWT 지원 비트 WLAN_EXT_CAPA10_TWT_REQUESTER_SUPPORT/_RESPONDER_SUPPORT, hostapd he_twt_responder
절전에는 함정이 있다. 단말이 자는 사이 AP가 맡아 둔 프레임은 늦게 도착하므로, 화면이 꺼진 휴대폰에 핑을 보내면 수백 ms가 걸리기도 한다. 게임처럼 지연이 중요한 앱이 실행 중이면 운영체제가 절전을 잠시 끄기도 한다. 또 DTIM 주기를 너무 크게 잡으면 방송에 기대는 기능(ARP, 기기 찾기)이 늦어져 “같은 와이파이인데 기기가 안 보인다”는 문제가 생길 수 있다.
공유기의 DTIM 주기를 1에서 10으로 바꿨다(비컨 간격 102.4 ms). 화면 꺼진 휴대폰이 AirPlay·크롬캐스트 같은 기기 찾기(멀티캐스트)에 응답하는 데 걸리는 시간은?
멀티캐스트는 DTIM 비컨 뒤에만 나간다.
핵심 정리
- 단말은 PM 비트로 잠든다고 알리고, AP는 그동안의 프레임을 버퍼에 모은다.
- 비컨의 TIM이 데이터가 쌓인 AID를 알린다. 앞뒤 0바이트를 자른 부분 가상 비트맵 + 비트맵 제어(오프셋, 방송 표시).
- 방송·멀티캐스트는 DTIM 비컨 뒤에 나간다. DTIM 주기가 크면 배터리는 아끼고 지연은 커진다.
- 평균 전류는 깨어 있는 비율이 정한다. 깨는 횟수를 줄이면 수명이 거의 비례해 는다.
- PS-Poll(옛 방식), Null 프레임 깨어남(일반), U-APSD(통화), TWT(Wi-Fi 6, IoT·일정 협상).
확인 퀴즈
단말이 “이제 잔다”고 AP에 알리는 방법은?
TIM에서 AID 17의 비트가 켜져 있다면?
비컨 간격 100 TU, DTIM 주기 3이면 방송 프레임은 최대 약 얼마나 기다릴 수 있나?
Wi-Fi 6의 TWT가 특히 유리한 기기는?