 |
|
Пробило меня сегодня на ликбез. По модемам, протоколам модуляции, коррекции, компрессии, текущему
состоянию дел и перспективам развития... Куулер в свое время, помнится, "сисадминские байки"
любил рассказывать, где объяснял благодарным слушателям чем icmp отличается от tcp/ip
и тому подобные вещи, почему бы мне не заняться аналогичным делом - рассказать,
как именно шипит и жужжит та белая коробочка с лампочками, и почему оно так часто
теряет CARRIER.
Проблема передачи информации между компьютерами появилась вскоре после
появления собственно компьютеров. "Материальные носители" - магнитные ленты, дискетки -
великая вещь (и до сих пор - если мне нужно перенести три гига информации
из пункта А в удаленный на пять километров пункт Б - я скорее всего
воспользуюсь жестким диском, а не модемом или еще каким сетевым средством),
но сеть - тоже хорошо. И появились сети - локальные для начала, на расстоянии
вытянутого провода. Что было уже хорошо, но... хочется-то, конечно,
большего - отдать мелкий файлик приятелю Васе с другого конца города, а то и
получить что-то из другого города. Ну, а поскольку наиболее повсеместно протянутая
из тогдашних паутин проводов называлась "телефонная сеть", появились коробочки,
позволявшие передавать информацию по ней. Появились, развиваются (до сих пор,
как ни странно), и, несмотря на бурный рост разнообразных xDSL, умирать пока не
собираются.
Телефонный канал, как вы, наверно, догадываетесь, изначально для передачи цифры
предназначен не был, а предназначен был для передачи голоса, то есть - звука.
Если быть точным - то звука в полосе частот от (приблизительно) 300 до 3400 Гц (на цифровых - до 4000 Гц,
на тех, что собраны из контактов, релюх и кусков провода - как получится), что, конечно,
далеко от Hi-Fi звучания, но достаточную разборчивость речи обеспечивает.
Чтобы "засунуть" внутрь цифру - нужно превратить цифру в звук (промодулировать),
а на другом конце демодулировать - проанализировав дошедший туда звук понять,
что же там хотели сказать. Ну, раз модуляция - поговорим о модуляции.
"Шумоподобные" технологии распространения
не получили (и сложновато технически, и толку мало - спектр получается широковат), поэтому модуляция
осуществляется классическим образом: берется несущая (синусоида
определенной частоты), и изменяется (то есть, собственно, модулируется) по какому-нибудь параметру.
По амплитуде (амплитудная модуляция), частоте (частотная)
или фазе (фазовая). От этого и начнем плясать.
Пропуская совсем уж малоизвестные протоколы модуляции, начнем с v21. Модуляция "дискретно-частотная"
(FSK, frequency shift keying), то есть - каждый бит передается своей частотой. Поскольку
(вечная проблема) в телефонной розетке всего два провода (как результат - мы слышим в наушнике
сами себя, так называемое "ближнее эхо" или "местный эффект"),
чтобы отличить передачу удаленной стороны
от своей собственной - используется четыре частоты: две "туда" и две "обратно".
Скорость протокола v21 была 300 бит/с или 300 бод (baud). То есть, сдвиг частоты
происходил 300 раз в секунду, и за один "раз" передавался ровно один бит.
При "простых" видах модуляции, когда у сигнала просто переворачивается фаза или
меняется частота, скорость жестко ограничена только частотной полосой.
Действительно, даже если мы на своем конце попытаемся "перевернуть" фазу, скажем,
5000 раз в секунду - на другой конец придет "каша", полученная после обрезания полосы
сигнала. Реально, поскольку спектр при модуляции обязательно "размазывается" дополнительно,
да и "туда-обратно" разделять как-то надо - практический предел находится где-то
в районе 1000-2000 бод.
В следующем по хронологии виде модуляции - v22 - ситуация выглядела следующим образом.
На низшей (для v22) модуляционной скорости (а это целых 600 бит/с)
ничего принципиально не изменилось. Модуляция, правда, используется "дискретная
фазо-разностная" (DPSK, differential phase shift keying), то есть бит кодируется "переворотом"
фазы несущей на 180 градусов, в остальном все на месте - частотное разделение каналов,
один бит за один "элемент модуляции". На высшей же для v22 скорости - 1200 бит/с
- все становится куда веселей и лучше. Ну и, собственно, с v22 начали появляться те идеи,
развитие которых постепенно привело к скоростям вроде 33600. Итак.
Итак. Разделение каналов - частотное. Модуляция - DPSK. Но - и очень простое "но" - за один
"раз" передается теперь не один бит, а два бита. Поскольку фаза теперь может не только
"переворачиваться" на 180, но и "поворачиваться" на 90 и 270 градусов. То есть,
фаза нарезана не просто на "плюс" и "минус", а на четыре положения. Что и позволило передавать
данные в два раза быстрее - при бодовой скорости 600 бод иметь 1200 бит/с канальную, "битовую",
скорость.
Есть одно общее заблуждение, настолько распространенное, что почти ставшее "истиной".
Заблуждение состоит в том, что "бод" (baud) есть "наукообразный термин" для выражения "бит в секунду",
бит/с, и что если на модеме написано "33600" - то это "модем на 33600 бод". На самом деле это не так.
За, так сказать, "один акт модуляции" (сдвиг фазы/амплитуды/частоты/чего-там-еще) можно передать более
одного бита информации (достаточно "нарезать" эти сдвиги на мелкие дольки). Частота этих самых
"актов модуляции" однозначно ограничена частотной полосой канала (слишком частая модуляция
будет "размазана" за счет ограниченной полосы), скорость же передачи данных ограничена
не только полосой, но и соотношением сигнал/шум, определяющим, насколько мелко можно нарезать
единицу модуляции,не боясь, что разница потонет в шумах.
Скорость, с которой происходят скачки амплитуды/фазы называется "бодовой" скоростью, и не превышает 2400 бод.
Скорость же передачи данных (битовая, или "канальная" скорость)... ну, вы в курсе. :-) Поэтому
модем с надписью 33600 - это отнюдь не модем на "33600 бод", а вовсе даже модем на 2400 бод,
но - на 33600 бит в секунду.
Дальше - проще. Синусоида заданной частоты (несущая частота
известна и постоянна) характеризуется двумя параметрами - амплитудой и фазой.
Амплитуда может меняться от 0 до 1, фаза - от 0 до 2*Пи. Разделяем каждый интервал на сколько нужно
делений, а "акт модуляции" сводим к изменению фазы несущей на сколько-нужно и заданию амплитуды
какой-нужно. На том конце - детектируем, анализируя амплитуду и сдвиг фазы каждого дошедшего кусочка синусоиды.
Пример? Нарезаем фазу на четыре кусочка, амплитуду - на четыре уровня (итого 2+2=4 бита на бод),
и получаем v22bis. Бодовая скорость 600 бод, битовая - 2400 бит/с. И это только начало :-)
кстати, v22bis до сих пор актуальности не потерял. Скорость, конечно, мала для
"браузинга интернета" (впрочем... работал же я в интернете на 2400 несколько лет назад),
но достаточна для почты, а простота протокола определяет его неприхотливость -
там, где современный модем на v34bis не может завершить своё "бжумм-бжумм-шшшшш"
из-за шумов или искажений, v22bis зачастую живет без проблем.
Крастота, правда? Давайте теперь нарежем амплитуду на, э... 16 уровней, и фазу на 16 уровней
- получим сразу 4+4=8 бит за бод и 600*8=4800 бит/с скорость! А вот и опаньки.
При малых амплитудах шумы будут сильно мешать определению точной фазы отсчета,
и как следствие - нарезку по фазе придется уменьшить,
со всеми вытекающими. Поэтому... поэтому придется немного заняться теорией.
Наш кусочек синусоиды, как мы уже договорились, характеризуется амплитудой и фазой.
Удобным представлением для этого является комплексное число в виде A*exp(i*Ф),
где A - амплитуда, Ф - фаза, соответственно.
Шумы воздействуют не на амплитуду и фазу "по отдельности", а на это число целиком,
поэтому и нарезку делать надо не по "фазе и амплитуде", а по действительной и мнимой части
нашего комплексного числа. А если попроще... на листке бумаги рисуются оси координат,
вокруг центра рисуется окружность единичного радиуса (максимальное значение амплитуды).
Точка внутри окружности соответствует сигналу с амплитудой, равной расстоянию от начала координат,
фаза - углу между отрезком от точки до нуля и осью абсцисс. Впрочем, чего это я вам основы
комплексной арифметики рассказываю - сами должны знать :-)
А дальше - так. На плоскости рисуется сеточка (прямоугольная) из точек. Точки, выходящие за пределы
окружности отсекаются как "запрещенные", полученная совокупность точек нарекается
умным научным термином "сигнальное созвездие", и за, так сказать, один акт модуляции передается
одна из точек сигнального созвездия. Voila - мы имеем так называемую "квадратурную"
(QAM - quadrature-amplitude modulation) модуляцию, практически идеально использующую
шумовые характеристики звукового канала (наверно, оптимальней была бы структура не "квадратиков"
а "сот", впрочем - возможно, так уже и сделано, тут я уже не в курсе).
...на самом деле все чуть сложней - например, перед передачей битового потока
он прогоняется через специальный алгоритм, обеспечивающий "в среднем постоянный" уровень аналогового
сигнала на выходе (QAM-кодер может "запутаться" в точках, соответсвующих малой амплитуде,
удаленный же модем может распознать это как снижение уровня и подкрутить усиление. Куда при этом уползут
точки созвездия, и что получится в результате, оставляю в качестве упражнения читателю.
Следующий шаг - введение эхогашения. Если мы имеем полосу в 3кГц в среднем шириной,
и хотим передавать информацию в обе стороны - придется либо делить полосу на две половинки:
"туда" и "обратно", либо... либо пытаться устранить собственное эхо, то есть, попытаться
"вычесть" из входа приемника сигнал собственного передатчика, орущего ему же "в ухо".
Это осложняется тем, что идеальных линий (с чисто активным сопротивлением 600 Ом) не бывает,
как, впрочем, и идеальных модемов, и потому чисто аналоговые методы "вычитания"
помогают не сильно. В результате вычитание собственного сигнала делается в DSP, и "настройка
эхогашения" становится обязательным этапом установки соединения.
А теперь, вооруженные сокровенным знанием про QAM и эхогашение, примемся за
v32. Прислушавшись к процедуре "начального установления связи" можно услышать:
- прерывистый писк в начале. Модемы на v22* пищали непрерывно, писк этот остался
"для совместимости" (чтобы модем на v22* смог соединиться с более современным,
пусть даже на v22), но периодически происходит "переворот" фазы сигнала
(ухом слышится как "разрыв" в писке), как сигнал "я умею v32!".
- "пикхшшшшшшшшшш" первого модема: короткий "пип" как сигнал "я тебя слышу,
счас будем соединяться", затем второй модем молчит, первый выдает в линию
тестовую последовательность и подстраивает параметры эхогасителя до достижения
нужного уровня подавления собственного сигнала. Второй модем тем временем,
зная параметры тестового сигнала, оценивает качество линии.
- "пишшшшшшшшшшш" - первый модем настроился и замолк, шипит и настраивается второй - первый слушает.
Обычно это шипение несколько отличается по громкости и/или тональности - все-таки один шипит "здесь",
а другой - "оттуда", с того конца линии.
- "ШШхк...." - и тишина. Сигнальные цепи подстроены, модемы договорились о параметрах модуляции
(в соответствии с качеством линии), зашипели друг на друга (поэтому шипение стало громче)
и выключили динамик - началась работа по передаче данных.
Уфф. Протоколы коррекции и компрессии оставим на потом, а сейчас еще чуть-чуть о v32.
С достоинствами понятно - первый протокол с нормальной QAM (тем самым использующий
почти на пределе шумовые характеристики линии), первый протокол с эхогашением... по мелочи -
если в процессе соединения модем обнаруживает, что качество связи упало - идет запрос на снижение
скорости (fallback), при этом (понятно) надежность возрастает, хотя скорость и падает.
Недостатки... есть, конечно. Главных - два: одинаковая скорость в обе стороны (если
модем 1 слышит модем 2 "на двоечку", а модем 2 слышит модем 1 "идеально" - связь будет
"на двоечку", потому что... потому что так вот), и отсутствие штатного fallforward
(повышения скорости) - если по линии прошел шумок и скорость упала - обратно она уже не вырастет, разве что
через процедуру "повторной установки связи" - ретрейн (которого вполне может и не быть - зачем модемам ретрейниться на хорошей линии).
Как правильно перевести слово "ретрейн" (retrain) на наш, русский, язык я,
например, до сих пор толком не знаю.
"Перетренировка" не совсем подходит - кого там "тренируют"? Ближе всего (если не отрываться
от словаря и
не изобратать нового смысла старых слов) - "повторное обучение", что, впрочем, тоже не совсем точно.
По сути "ретрейн" (можно я его переведу так?) - повторная установка связи, очень похожая
на начальную установку связи (пип-пшшшшшшш-пШШШШШШШ) за
исключением того, что собственно протокол уже известен, и настраиваются только параметры протокола.
Производится ретрейн при "неустранимых сбоях"
в "гладкой" работе протокола модуляции. Такие "неустранимые сбои" как правило возникают в результате
резкого ухудшения качества (или изменения параметров) линии, как правило - всплесков шума, при
которых модемы "не слышат" друг друга и не могут штатным образом снизить скорость. "Неустранимость"
- понятие весьма субъективное и зависит от авторов прошивки к модему.
Процедура эта довольно неприятна, поскольку занимает значительное время (несколько секунд - а если линия
у вас трещит часто, а модем просит ретрейн на каждый треск, то заметную часть времени данные просто не передаются),
да и сам по себе чувствителен к шумам и трескам.
Соответственно, устойчивость и скорость работы модема на шумных линиях во многом зависит от его "политики"
по отношению к ретрейнам - тот, что просит ретрейн на каждый чих жить толком не будет. Например,
"сбой синхронизации TCM" (о TCM - позже) можно устранить ретрейном, а можно -
запросом renegotiation на скорость, равную текущей. Те, кто знает про этот трюк - на шумных линиях работают,
кто не в курсе - ретрейнится. Впрочем, я отвлекся. Вернемся к v32 :-)
Скорости v32 - 4800, 7200 и 9600 bit/s, довольно скоро появился протокол v32bis
(собственно, чистого v32 я ни разу и не видел - только v32bis да v32t), в котором
появились скорости 12000 и 14400 бит/с, затем, сначала как "фирменное расширение", а потом и как стандарт -
v32terbo, со скоростями 16800 и 19200, вплоть до так и оставшегося нестандартным 21600 (V32terbo Enсhanced) в модемах Russian Courier 21600 (переделка USR Sportser 14400 выпуска первой половины 90-х). . Как видно - шаг изменения скорости равен 2400 бит/с,
и эта традиция, в общем-то сохранилась. Новые скорости добавлялись простым и понятным
способом - увеличением количества точек в сигнальном созвездии.
Однако дальше опять случился затык. А может, просто инженерная мысль не сидела на месте
и мешала дальше тупо наращивать плотность точек. :-) В-общем, выяснилось,
что требования к шумам для больших скоростей получаются уж больно строгие,
и ошибки при передаче идут уж слишком часто для того, чтобы успешно исправляться
вышележащим протоколом коррекции-компрессии. Вот бы иметь возможность исправлять "на лету"
хотя бы полпроцента "битых" бит, примерно как на компакт-дисках... да и
недостатки v32* (которые частично пыталась исправить, например, приснопамятная USR,
придумав v32 with ASL (Adaptive Speed Leveling) - возможность
"несимметричной" передачи и динамического изменения скорости в обе стороны).
Результатом стал протокол v34 (и его расширение - v34bis). За который, по моему глубокому мнению,
создателям надо поставить памятник при жизни, предварительно оторвав у создателей
все выступающие части, чтобы неповадно было :-)
Итак, v34*. Непревзойденный до сих пор шедевр в области запихивания максимального
количества информации в минимальной толщины звуковой канал с искажениями, потерями
и шумами. По порядку:
- уже знакомая нам QAM.
- уже знакомое нам эхогашение.
- широкий выбор всего подряд с каждой стороны: в отличие от v32, где (даже с ASL)
частота несущей и бодовая скорость выбиралась совместно, здесь все параметры передачи
(то есть абсолютно все) определяются принимающей стороной, и могут
независимо изменяться. Почему принимающей - понятно: ей это шипение потом слушать :-)
- разнообразие (по сравнению с v32) несущих и бодовых скоростей (читай: полос спектра),
позволяющее выбрать "живую" рабочую полосу даже в клинических случаях "заваленных насмерть верхов"
или "гудения на низах".
- precoding, shaping, и тому подобная "предкоррекция" - внесение передающей стороной
"предыскажений", компенсирующих искажения канала передачи (неравномерность АЧХ, нелинейность).
- этап "замера" характеристик линии при установлении соединения.
- штатная процедура rate renegotiation (изменения скорости) при изменении характеристик линии
- на слух (при включенном динамике) слышится как короткое "попискивание" в процессе собственно связи.
- и главное - так называемая TCM, Trellis Coded Modulation.
На TCM я просто обязан остановиться подробнее. Как я уже говорил,
чем плотнее расположены точки в сигнальном созвездии (и чем больше бит мы передаем в боде),
тем выше требования к шумам и искажениям в линии. Практически это означает, что
повышая скорость передачи данных мы повышаем (причем довольно резко)
вероятность ошибки, сбоя при передаче. Пока количество сбоев исчисляется единицами бит на
несколько единиц-десятков килобайт - с такими сбоями справляются протоколы коррекции/компрессии,
работающие по принципу "обнаружение ошибки - запрос повтора". Такие алгоритмы
обязательно присутствуют в современных модемах, и хороши тем, что
исправляют ошибку вне зависимости от ее происхождения - раз не сошлась контрольная сумма
- кадр отправляется в помойку и запрашивается новый кадр.
Недостаток же... при попытках получить действительно предельные скорости,
когда сбойные биты начинают пролетать слишком часто (бит на килобайт или чаще)
бОльшая часть кадров (их нельзя делать слишком маленькими - растут накладные расходы: заголовок,
контрольная сумма, синхронизация) отправляется "в корзину", и модем в основном занят перезапросами
битых кадров, а не основной работой. При ошибках же порядка бита на сотню бит,
когда, казалось бы, еще можно работать и работать (всего-то 1% сбоев, фи)
классические протоколы коррекции-компрессии умирают вообще - 99.9% пакетов приходят битыми,
99% запросов на повтор не проходят по той же причине. И вот тут-то
и спасает TCM :-)
Идея треллис-кодирования в следующем. В поток "символов" ("символом" называется
то, что передается за один бод - как правило это несколько бит)
вводится дополнительная избыточность. Точнее, некоторые последовательности
символов (которым, как мы помним, соответствует некая последовательность
точек в сигнальном пространстве) объявлены "запрещенными".
При этом множество "запрещенных" последовательностей подобрано так,
что для каждой из них существует единственная "наиболее близкая" последовательность
(мы-то знаем, что как правило ошибка заключается в том, что точка сигнального созвездия
ошибочно детектируется как одна из ближайших к ней точек).
Получив "запрещенную" последовательность, декодер по специальному алгоритму
определяет наиболее вероятную неискженную последовательность, разворачивает ее в поток бит,
и уже его отдает вышележащему протоколу коррекции/компрессии. Фокус в том, что
приблизительно зная характер ошибок, и введя небольшую избыточность, получается
с некоторой вероятностью восстановить неискаженный сигнал,
и при этом вероятность восстановления оказывается достаточно большой,
чтобы с неправильно восстановленными последовательностями
(ясно, что декодер "придумает" что-то для любой входной последовательности,
но для нетипичной ошибки при этом сбой все-таки почти гарантирован)
успешно справлялся более высокоуровневый протокол коррекции/компрессии. Уфф.
На самом деле все еще веселее, и используется не "множество последовательностей символов" а
"пространство состояний кодера" (что похоже, но не совсем то), но я надеюсь, это упрощение
только улучшило понимание общей идеи треллис-кодирования :-)
А на слух v34 (скорость до 28800), а равно и v34bis (33600, шаг везде 2400) несильно
отличается от v32. Начальное пи-и'и-и'и-и'и-и (как v32), короткое бжумм-БЖУММ
(модемы убедились, что оба поддерживают v34 и обменялись "зондирующими сигналами"
для промера характеристик линии), дальше - привычное "пшшшшшшшш-ПШШШШШШШШ-ШШкх..."
- настройка эхогашения обоими сторонами, "вход" в соединение, гасим динамик - вперед!
...а теперь немного об отрывании выступающих частей. Протокол v34, как я уже говорил,
самый вылизанный из используемых сейчас для передачи данных по "каналам ТЧ",
и только парочка мелочей...
Зондирующий сигнал (бжумм-БЖУММ в самом начале соединения) передается на уровне +6дБ к номинальному.
С какого перепуга разработчики это сделали - неясно, а как результат - на некоторых каналах
сигнал этот перегружает канал, что заставляет уменьшать уровень, что (очевидно)
приводит к ухудшению соотношения сигнал/шум и ухудшению связи. Впрочем, сейчас вроде как-то
извернулись, и сигнал привели к разумному уровню.
Есть в стандарте v34 такая фича. Power Drop называется. Если удаленный модем слышит достаточно сильный (по его мнению),
но искаженный сигнал, и он (удаленный модем) считает, что искажения вызваны перегрузкой
звукового канала, он может запросить "сброс мощности" - попросить "не орать, я и так неплохо слышу".
А вот обратной процедуры предусмореть как-то не догадались. Как классический результат -
некоторые модемы motorolla на линиях с большими искажениями. "Сигнал искажен, сбрось мощность - Ок, сбросил
- все равно искажен, сбрось еще - ладно, сбросил - ой, что-то я тебя не слышу... тууу-тууу-тууу...).
Нечасто, но бывает.
TCM и прочие прелести превращаются в этакую палку о двух концах под названием "задержки"
- и если для выкачивания mp3 это абсолютно несущественно, то для, например, игр,
это может стать смертельным. Поэтому любителям Quake и прочего, советую сразу запретить в модеме v34.
В остальном же - некий шедевр мироздания. Так и застывший, увы, в точке 33600 (на
"аналоговых" АТС мешает шум, на "цифровых" же - мешает то, что QAM совершенно
не приспособлен для борьбы с характерными "цифровыми" искажениями сигнала).
...поскольку 56к протоколы в большинстве своем куда менее интересны.
Поскольку в мире наметился массовый переход на цифровые телефонные сети, качество же
обычной, "аналоговой" аппаратуры улучшаться не собирается, а протокол v34
отлично борется с "аналоговыми" искажениями сигнала, но беспомощен против "ступенек"
дискретизации - v34 с его QAM+TCM так и остался на 33600, а создатели 56к модемов пошли другим путем.
Искажения бывают разные. Белые, желтые, красные... ой, я не про то :-) Изначально,
когда модемные протоколы только-только разрабатывались, телефония была аналоговой, искажения были
в виде неровностей АЧХ и ФЧХ (амплитудно- и фазо-частотной характеристик), а шум был "подкрашенный белый"
(в достаточной мере случайный с гладким спектром),
потому и модуляция разрабатывалась в расчете на такие вот "мягкие агалоговые" искажения. Успехи были достигнуты
большие, но... Но на цифровых АТС это не слишком помогло. Сигнал на них дискретизуется, передается в виде
8-битных отсчетов, ~8000 отсчетов в секунду, и плавный входной сигнал превращается в "ступенчатый"
на выходе. "Классических" искажений (амплитудных, фазовых) практически нет, но зато появляется
"шум дискретизации" - разность между переданным и принятым сигналом, имеющая вид мелкой "пилы" (треугольных "пичков", следующих с частотой дискретизации),
хитрым образом зависящей от входного сигнала. Вообще-то в этой "пиле" тоже содержится информация(!), но v34,
как и другие QAM-based протоколы про это не в курсе, и для них это - шум. Причем шум резко "окрашенный",
да еще и зависящий от входного сигнала, что отнюдь не способствует.
Поэтому, собственно, v34* при реальных 64кбит,
бегающих "там, между станциями", наружу может вытащить 33600, не больше.
Первыми, пожалуй, выдвинули свое решение USR - заслуженно полузабытый протокол x2.
Идея проста. По телефонной сети один фиг идет цифровой поток до 64кбит/с. От АТС до клиента
идет неплохой такой медный провод, в котором полоса отнюдь не ограничена тремя килогерцами,
да и перегрузок он не боится. Давайте поставим прямо на АТС железяку, которая будет связана
с модемом клиента прямым медным проводом, один конец железяки воткнем непосредственно
в цифровой канал АТС, а другой - соответственно, отдадим клиенту. Цифровой канал дает
до 64кбит, а качество аналогового (провод) позволяет забыть про TCM и прочие тонкости,
а просто забабахать сигнал с полосой килогерц этак восемь, да помощнее, и обойтись
обычным QAM. Ну, а если клиент звонит обычным телефоном - то "модем" простаивает,
а работает стандартная аппаратура телефонной станции.
Достоинства - этот протокол действительно использует "цифровой" канал до последнего бита в секунду :-)
Недостатки... X2-server (та железка, что ставится на АТС) надо ставить на АТС клиента.
То есть, если в городе десять АТС - либо провайдер разоряется на десять стоек (и разговаривает
с руководством десяти АТС на тему установки абонентского оборудования, что само по себе геморройно),
либо - некоторые клиенты останутся без x2. Плюс к этому - неравномерность распределения клиентов по АТС,
неравномерность нагрузки... в-общем, оно круто, но дороговато получается. Поэтому x2 кое-где еще есть,
но уже мало.
К слову, поскольку идея-то хороша сама по себе, цикл реинкарнации уже идет вовсю.
Правда, уже не в виде классического "модема", а в виде разнообразных xDSL (по сути -
short-range модемов) с перекачкой данных непосредственно по каналам телефонной сети.
Дальше - больше. Помним старую шутку: "если я переименую zip в wav, запишу на магнитофон
а потом оцифрую обратно - разве не получится тот же самый zip?". Ну, в каждой шутке,
как известно, есть доля шутки :-) Протоколы k56flex и сегодняшний фактический стандарт
- v90 - работают именно так. Точнее, в "исходящую" сторону (от клиента к серверу)
используется все та же QAM+TCM, а вот во "входящую" - информация передается непосредственно
перепадами уровней, этими самыми "ступеньками" дискретизации, которые так мешают жить v34. :-)
Естественно, поскольку искажения в "медном проводе" таки есть, скорость редко достигает
теоретического предела (в х2, напомню, все лучше - "проводной" канал как правило не является
узким местом), и реально наблюдается что-то от 40 до 50 кбит, остальное уходит в
избыточность кодирования. Начальное установление соединения на v90 не спутаешь ни с чем -
после бжж-пшшш идет очень характерный "вечерний звон" - БОММмммм... БОМММмммм... -
калибровка АЦП принимающего модема под параметры линии и замеры переходных искажений.
Модуляция же в протоколе, можно сказать никакая - используется только цифровая
избыточность для компенсации неидеальности линии. По каналу же - "ентот зип переименован в вав
и записан на магнитофон" :-)
Достоинства. Главное - простота серверной части. На АТС клиента изменять не надо ничего абсолютно
- там и так уже все есть. На сервере (который теперь может быть один на город, а не по штуке на каждой
АТС) "модема" в его классическом понимании, собственно, и нет - провод с "цифрой" из АТС непосредственно
входит в коробочку "модема", минуя ненужную теперь аналоговую часть. Модемная стойка, кстати,
прикидывается для окружающего мира "ма-аленькой АТСкой", а наличие внутри 30 номеров вовсе не
означает наличия там 30 экземпляров модема - достаточно производительный процессор может
"обсчитывать" несколько соединений одновременно.
Недостатки... Скорость редко достигает предельной. Поскольку искажения есть всегда. Протокол
несимметричный - "вверх" идет обычное v34bis с потолком в 33600. Если позвонить с модема на v90
на другой такой же - получится v34bis, поскольку "серверная" часть требует прямого подключения к "цифре"
на АТС. Если по пути от АТС до абонента есть хоть что-то отличное от прямого медного провода
(скажем, офисная АТС или радиоудлиннитель) - v90 умирает, поскольку так нужные ему "ступеньки"
расплываются уже запредельно. В остальном же - простой как валенок и довольно надежный протокол.
| |
| |