Снижение размерности данных в Wi-Fi-сетях для ВКР: темы, метрики и защищаемая архитектура

В марте 2026 года CNews сообщил: третьекурсник МФТИ вместе с учёными ИППИ им. А. А. Харкевича предложил подход, обходящий «проклятие объёма данных» в Wi-Fi-сетях будущего. Речь о ситуации, знакомой каждому, кто разбирался с MIMO: чем больше антенн и поднесущих, тем больше служебной информации о состоянии канала приходится передавать обратно на точку доступа. Формально пропускная способность растёт — фактически часть её съедает сам механизм измерений канала.

Почему это важно для дипломника? Здесь сходятся три вещи, за которые на защите ставят высокий балл: актуальный стандарт (IEEE 802.11bn / 802.11bf), измеримая инженерная задача и понятный набор метрик. Тема сформулирована не «про Wi-Fi вообще», а про конкретное узкое место — значит, её можно смоделировать, посчитать и защитить. Дальше разберём, как превратить новостной повод в структуру ВКР.

Три темы ВКР, которые вырастают из этой новости

Тема 1. Сжатие канальной информации в Wi-Fi 7/8 на основе автоэнкодера

Актуальность. В статье описана именно эта логика: уменьшить объём данных о канале, не потеряв качество связи. Пока стандарт 802.11bn уточняется, готовых открытых решений мало — вы работаете на «белом пятне».

• Цель: разработать и оценить метод сжатия CSI с сохранением точности восстановления канала.
• Задачи: обзор методов (кодовая книга стандарта, compressed sensing, нейросетевые); построение модели канала; реализация энкодера-декодера; сравнение с базовым уровнем по NMSE и степени сжатия.
• Структура: Глава 1 — теория MIMO-OFDM и обзор литературы; Глава 2 — архитектура кодера и интеграция в цепочку channel sounding; Глава 3 — эксперименты, вычислительная стоимость, выводы.

Тема 2. Имитационная модель 802.11bn в ns-3: цена ограниченного фидбэка

Актуальность. Прямое продолжение новости: исследователи проверяли гипотезу на моделях, а вам нужна воспроизводимая среда. Готовых модулей под Wi-Fi 8 почти нет, поэтому даже аккуратная симуляция — это новизна.

• Цель: количественно оценить, как ограничение объёма служебных данных влияет на пропускную способность и задержку в плотном сценарии.
• Задачи: анализ требований 802.11bn; развёртывание ns-3 с модулем Wi-Fi; реализация сценария с несколькими точками доступа; введение искусственного ограничения на фидбэк; серия экспериментов и статистическая обработка.
• Структура: Глава 1 — стандарт и обзор смежных работ; Глава 2 — проектирование имитационного стенда и модели ограничения; Глава 3 — результаты, оценка по ISO/IEC 25010, экономика внедрения.

Тема 3. Снижение размерности телеметрии Wi-Fi-сети: OpenTelemetry и потоковая агрегация

Актуальность. «Проклятие объёма данных» живёт не только в эфире. Сеть из нескольких тысяч точек доступа генерирует поток метрик, который тоже надо как-то хранить и обрабатывать. Тема ближе к системной архитектуре, чем к радио.

• Цель: спроектировать пайплайн сбора и агрегации телеметрии с заданными требованиями к задержке и стоимости хранения.
• Задачи: классификация метрик; выбор методов агрегации (гистограммы, sketch-структуры); прототип на OpenTelemetry Collector; нагрузочное тестирование и расчёт экономии на хранении.
• Структура: Глава 1 — анализ источников данных; Глава 2 — архитектура пайплайна и схема развёртывания; Глава 3 — нагрузочные испытания, RTO/RPO для хранилища, выводы.

Аналитическая глава: как обосновать выбор, а не перечислить термины

Сравнение подходов к снижению размерности

Первая глава часто превращается в свалку определений. Так делать не нужно. Сделайте сравнительную таблицу — это сразу показывает комиссии инженерное мышление, а не пересказ википедии.

Обратите внимание на последний столбец. Именно в нём чаще всего «сыпятся» студенты: метод выбран нейросетевой, а данных для обучения нет. Заранее решите, откуда возьмёте канальные реализации, и напишите это прямо в тексте ВКР.

Обоснование инструментального стека

Статья работает как аргумент: задача лежит на стыке физического уровня и обработки данных, поэтому одним инструментом не закрыться. Ниже — рабочая матрица выбора, которую можно перенести в раздел «Обоснование средств разработки».

Документация и требования

Техническое задание оформляйте по ГОСТ 34.602-89, программную документацию — по группе ГОСТ 19. Это не формальность: на многих кафедрах за неверно оформленное ТЗ снижают балл автоматически, вне зависимости от качества кода и экспериментов.

Проектная часть: схемы, алгоритмы, интеграция

Здесь комиссия смотрит не на текст, а на схемы. Минимальный набор, который закрывает вопросы: контекстная диаграмма, схема компонентов (UML component), диаграмма последовательности для процедуры channel sounding и схема развёртывания, если речь об эксплуатации.

Логическая цепочка обработки выглядит примерно так: точка доступа отправляет преамбулу → клиент оценивает канал → значение CSI проходит через энкодер и квантователь → по обратному каналу уходит компактное представление → декодер восстанавливает матрицу → на её основе считаются веса предкодирования. Каждое звено — потенциальный узкий по задержке элемент, и об этом стоит сказать отдельно.

import torch
import torch.nn as nn

class CSIAutoencoder(nn.Module):
    """Сжатие CSI: N_поднесущих x N_антенн x 2 (Re/Im) -> латентный вектор."""
    def __init__(self, n_in=256, latent=32):
        super().__init__()
        self.enc = nn.Sequential(
            nn.Flatten(),
            nn.Linear(n_in, 128), nn.ReLU(),
            nn.Linear(128, latent),        # «узкое горло» задаёт степень сжатия
        )
        self.dec = nn.Sequential(
            nn.Linear(latent, 128), nn.ReLU(),
            nn.Linear(128, n_in), nn.Sigmoid(),
        )

    def forward(self, x):
        z = self.enc(x)
        return self.dec(z), z

Обратите внимание: в реальной системе квантование стоит между энкодером и декодером, и его нельзя игнорировать при обучении. Иначе получите красивые графики на защите и полную деградацию после дискретизации — классическая ошибка.

Тестирование и метрики: чем измерять результат

Технические метрики

• NMSE восстановления канала — насколько точно вы вернули матрицу.
• Overhead в процентах от полезной пропускной способности — главный количественный аргумент.
• Throughput и BLER — что получилось на выходе системы.
• Задержка инференса на стороне точки доступа — часто именно она убивает идею на практике.
• Потребление памяти и энергии — если речь о встраиваемой платформе.

Системные и эксплуатационные требования

Если ваша тема связана с телеметрией, добавьте RTO и RPO для хранилища метрик — это сразу придаёт работе инженерный вес. Качество атрибутов удобно раскладывать по ISO/IEC 25010: производительность, надёжность, сопровождаемость. Комиссия любит, когда модель качества не выдумана, а взята из стандарта.

Как оформлять результаты

Минимум три повторности эксперимента, доверительные интервалы, фиксированные seed'ы генератора случайных чисел. Фраза «в среднем получилось быстрее» без разброса значений — прямой приглашение к неудобным вопросам. И обязательно сравнение с baseline: без него ваша цифра ничего не значит.

Чему вы научитесь на такой работе

• Проектировать архитектуру, где вычислительная нагрузка распределена между клиентом и точкой доступа, а не свалена в одно место.
• Обосновывать выбор стека через ограничения задачи, а не через «так принято».
• Работать с имитационными средами и понимать границы их применимости.
• Считать метрики качества по стандарту, а не по интуиции.
• Оформлять ТЗ и программную документацию в соответствии с ГОСТ.

Что проверить перед сдачей

Частые вопросы

Источник: Третьекурсник помог ученым обойти «проклятие объема данных» в Wi-Fi сетях будущего (опубликовано 2026-03-24)