Коди фонтану та LT-коди: Ерадикація з помилками

Чому важливе ратлі кодування

Класичні коди erasure, такі як Reed-Solomon, фіксують коефіцієнт заздалегідь, кодуючи k джерельних блоків у n загальних блоків і гарантуючи відновлення, якщо прибуло будь-яких k з n. Це добре працює, коли втратна швидкість відома заздалегідь, але стає неефективним або недостатнім, коли поведінка каналу непередбачувана, як це часто буває в broadcast та multicast налаштуваннях, де різні приймачі відчувають дуже різні втрати одночасно. Наприклад, супутникове мовлення файлу до мільйонів set-top box не може адаптувати фіксований коефіцієнт до індивідуальної якості прийому кожного глядача. Коди fountain вирішують цю проблему повністю, не фіксуючи коефіцієнта: відправник просто продовжує генерувати та передавати нові краплини безперервно, і кожен приймач, незалежно від того, скільки пакетів він втратив індивідуально, припиняє слухати, коли накопичилося достатньо краплинок для декодування. Це робить коди fountain природним вибором для broadcast та multicast розповсюдження, peer-to-peer обміну файлами, де різні peers утримують різні підмножини закодованих даних, і deep space комунікації, де повторні запити надзвичайно повільні.

Надійна розподілена хвильова структура та ступінь крапель

Серце LT коду – це ймовірність розподілу, яка використовується для вибору кількості джерельних блоків, що називається ступенем, яку кожна крапля XORє разом. Наївний підхід міг би завжди об’єднувати фіксовану кількість блоків, але це невдало: занадто мало і декодування зупиняється, оскільки нічого не перекриває достатньо для ланцюгового реактивного зв’язку, занадто багато і кожна крапля стає непрозорим комбінацією, яку неможливо вирішити, поки майже все інше вже невідомо. Ключова ідея Ла́убея полягала в надійному розподілі хвиль, який навмисно створював контрольований мікс ступенів: багато крапель з ступенем одиниці, що забезпечує миттєво розв’язні блоки для запуску ланцюгової реакції декодування; поширення невеликих ступенів, щоб нові джерела блоків отримували покриття та інтегрувалися; і іноді крапля торкається великої частки файлу, що допомагає забезпечити, що кожен джерельний блок охоплюється принаймні одним блоком з високою ймовірністю. Цей ретельно налаштований мікс дозволяє декодуванню успішно працювати з невеликим постійним коефіцієнтом над збільшенням теоретильної мінімальної кількості крапель, необхідних, а не вимагати значно більше крапель, ніж джерельних блоків.

Декодування LT коду: розв’язання головоломки XOR

Декодування LT коду по суті полягає у просуванні впевненості через біпартітну графіку, яка з’єднує краплі з джерельними блоками, які вони об’єднали. Детектор підтримує пул отриманих крапель і повторювано шукає будь-яку краплю з ступенем видимості одного, тобто посилається лише на один джерельний блок, який ще не було відновлено; оскільки крапля зі ступенем видимості одного є буквально неосідженою копією цього блоку, вона може бути прочитана безпосередньо. Цей нещодавно відремонтований блок потім XOR-ється з усіма іншими краплями, які посилалися на нього, що може перетворити деякі з цих крапель на нові краплини зі ступенем видимості одного, запускаючи ланцюгову реакцію відновлень. Цей процес, відомий як «очищення» або «віра просування», триває до тих пір, поки весь джерельний файл не буде відновлено, або детектор застигає, оскільки серед невирішених крапель немає жодної краплини зі ступенем видимості одного, тобто потрібно більше крапель із потоку. Елегантність цього підходу полягає в його швидкості: кожне XOR-операція дешева, а загальна складність декодування масштабується приблизно лінійно з розміром файлу для добре налаштованого розподілу ступенів видимості, на відміну від важкого поліноміального арифметики, що використовується в алгебраїчних кодах видалення помилок, таких як Reed-Solomon.

Перевищення, ймовірність виходу з ладу та практичне налаштування

Жоден фонтанний код не декодує з нульовим перевищенням у реальності; зазвичай потрібно кілька додаткових крапель поза точним джерелом блоків k для гарантії того, що процес «розсипання» не зупиниться, і це перевищення є ключовим дизайном.

Для LT-кодів із міцним розподілом солютонів очікуване перевищення зростає пропорційно квадратному кореню від k та логістичному фактору, що означає, що більші файли фактично стають відносно більш ефективними, потребуючи менше відсотка додаткових крапель, ніж маленькі файли.

Якщо декодер застрягає з невеликою кількістю відновлених джерельних блоків, залишшається невелика система рівнянь XOR, які часто можна вирішити за допомогою деякої кількості гаусового відсіювання як резервного варіанту, обмінюючи трохи більших обчислень для гарантії завершення навіть коли віральне поширення само по собі застрягає.

Від LT кодів до Raptor кодів та реальних впроваджень

LT коди стали проривом, але їхня середньостатистична складність декодування, хоча й лінійна, все ще вимагає значної кількості крапель і достатнього облік мережі граф, що спонукало пізніші розробки до подальшого вдосконалення. Raptor коди, розроблені Аміном Шоклолахі, використовують фіксований швидкісний зовнішній код, зазвичай простий код з низькою щільністю парності, який накладається на внутрішній LT код із навмисно ослабленим розподілом ступенів. Ця комбінація досягає справді лінійної по часу кодування та декодування з постійними, дуже малими надбаннями, незалежними від розміру файлу – властивість, яку самостійно не можуть забезпечити LT коди. Raptor коди та їхня стандартизована версія RaptorQ вже використовуються в реальних протоколах, зокрема у послугах 3GPP мультистрімного трансляції та розповсюдження, стандартах DVB-H мобільного телебачення та специфікаціях IETF для надійної доставки файлів через мережі з втратами. Походження від початкової ідеї Luby про фонтани, через LT коди до Raptor кодів ілюструє типову схему в теорії кодування: елегантна ймовірнісна конструкція поступово узасиблюється за допомогою алгебраїчної основи, поки вона не стає достатньо ефективною для масового застосування.

Frequently asked questions

Спробуйте наживо

Усе, що вище, працює прямо у вашому браузері — відкрийте Fountain Codes and LT Codes: Rateless Erasure Coding і змінюйте параметри під час роботи. Нічого не встановлюється, нічого не завантажується на сервер, уся модель живе в одній вкладці.