СДСМ АДСМ Книги
return

telecom №0

25 февраля 2013, 10:29
like 2 views 42257 message 78

Всё началось с очень долгой дороги домой.
Это время нужно было чем-то занимать. Когда-то это были ESL (English is a Second Language) – весьма полезный в плане изучения языка, но обычные выпуски приедаются быстро, а интересные – English Cafe – выходят недостаточно часто. Потом я открыл для себя CBT-Nuggets – интереснейшая вещь, но курс довольно короткий. И наконец Радио-T, который, вроде бы, и ИТшный, но как-то сильно уж яблочный и программистский.
Был ощутимый голод по телекомовским темам. Спрос в количестве нескольких человек по крайней мере был, а предложения не было – ни одного подкаста в этой сфере. Были околосвязисткие вещи, но всё не то.
А там, где есть спрос, будет и предложение, пусть даже создавать его буду я.
Итак, мы рады представить нулевой выпуск подкаста для связистов ЛинкМиАп.
В этом выпуске обсуждаем:
1) Переносимость мобильных номеров между операторами и регионами. MNP – Mobile Number Portability.
2) Технологии для осуществления голосовых вызовов в сетях LTE: CSFB, IMS.
3) Практическая тема: как ведёт себя маршрутизатор, если настроить интерфейс в качестве Next Hop, вместо IP-адреса.
Ниже краткий бриф и схемы для того, чтобы разобраться в темах было проще.
Если у вас есть предложения, какие темы было бы интересно обсудить в следующих выпусках, с удовольствием принимаем их в комментариях.

MNP

Схематично GSM-сеть работает так: у каждого оператора сотовой связи есть некая база всех-всех его номеров. В ней содержится много всякой информации (разрешенные абоненту услуги, например), но главное то, что там записано, где находится каждый конкретный абонент в текущий момент. Понятно, что база огромная, поэтому у крупных операторов она поделена на части, например, одна база обслуживает первые 10000 номеров оператора, другая – следующие 10000.
Как работает эта база? Когда абонент звонит кому-то, оборудование, обрабатывающее звонок, смотрит, к какой базе обращаться, делает запрос в неё, узнает, на каком коммутаторе и в пределах покрытия какой базовой станции находится адресат, и маршрутизирует звонок туда. Никаких проблем, потому что мы знаем, кому этот диапазон принадлежит и что делать с вызовом.
Так это работает до введения MNP. C ним все становится сложнее: абонент переходит со своим номером к другому оператору, и теперь информация, необходимая для связи с абонентом, хранится у последнего. Но маршрутизировать как-то нужно. Возникает потребность в дополнительной базе, которая бы хранила номера абонентов, поменявших оператора, в которой бы говорилось, что, мол, такой-то абонент с номером от оператора A на самом деле является клиентом оператора Б, поэтому всю информацию нужно спрашивать у Б. Существует 3 вида такой «переадресации»:

  • прямая маршрутизация – оборудование оператора сети (например, С), из которой мы звоним, запрашивает централизованную базу перешедших номеров, и, получив ответ, маршрутизирует звонок в сеть B
  • косвенная – оборудование оператора сети, из которой мы звоним, по-старинке переправляет звонок оператору A (старому), а A уже переправляет звонок в B
  • третий вариант это сочетание первого и второго – если не срабатывает прямая маршрутизация, делается косвенная

В любом случае, нужна некая внешняя база перешедших абонентов, и в этом вся интрига: кто будет этим заниматься, ведь дело нешуточное, в случае отказа этой базы, перешедшие абоненты всех операторов остаются без связи.
Полезные ссылки:
pro-gsm.info/mnp.html
pro-gsm.info/cap-roaming.html

LTE

Вскоре после разработки и начала активного внедрения стандарта 3G, инженеры организации 3GPP (главной в области стандартов мобильной связи) поняли, что потребность в увеличении скорости передачи данных мобильными абонентами будет неизбежно расти, а объем трафика будет увеличиваться почти по экспоненте (для примера, трафик данных в сетях Мегафона составляет – 99%, а голос – всего 1%). Поэтому часть разработчиков села дорабатывать стандарт W-CDMA (3G) – плодами их усилий стали протоколы HSDPA, HSDPA+, HSUPA, позволившие увеличить пиковую скорость до 42 Мбит/с в DL, а другая же часть 3GPP принялась за совершенно новый стандарт связи – LTE (Long Term Evolution), который и был представлен в 2009 году, а уже в 2010 начался запуск первых коммерческих сетей в Швеции, США и Южной Корее.
С точки зрения разделения радиоканалов LTE делится на 2 подстандарта, имеющих свои плюсы и минусы.
1. FDD – частотное разделение каналов, данный подстандарт использует две разные полосы частотного спектра для DL и UL, т.е. абонентский радиоканал симметричен и является полностью дуплексным
2. TDD – временное разделение каналов, данный подстандарт использует для передачи в DL и UL одну частоту (или набор нескольких несимметричных частот), чередуя временные интервалы для перадчи от/к абоненту, т.е. является полудуплексным.
Сети FDD и TDD LTE имеют свои преимущества и недостатки. FDD в общем больше подходит для приложений типа видеоконференций, которые имеют симметричный трафик. Это из-за того, что трафик в обоих направлениях непрерывен, а использование TDD было бы тратой пропускной способности при постоянном переключении с одного режима на другой. TDD хорош для приложений, которые имеют несимметричный трафик, примером того может быть онлайн просмотр. TDD может отдавать больше времени частям данных, которые требуют большей пропускной способности, таким образом, балансируя загрузку. С FDD, пропускная способность не может быть динамично перераспределена и неиспользуемая пропускная способность теряется впустую.
Другим преимуществом связи FDD LTE является планирование мест для базовых станций. Из-за того, что базовые станции используют разные частоты для получения и передачи данных, это эффективно, так как разные частоты не перебивают друг друга и специального планирования не требуется, однако при этом нужна жесткая синхронизация eNodeB (БС в LTE) по времени, что усложняет построение сети.
FDD был реализован раньше TDD, поскольку большинство операторов имеет в своем распоряжении именно парные частоты в различных областях спектра, к тому же не встает проблема синхронизации БС по времени, однако, сейчас, в условиях нехватки частот, операторам становиться логичнее использовать TDD, поскольку он позволяет получить полноценную сеть имея в распоряжении разбросанные полосы частот (а не две полосы по 10 МГЦ, как в FDD), проблема синхронизации решается с помощью GPS и тактовой синхронизацией от других элементов сети (например, RNC – Radio Network Controller).
Пожалуй, самым главным отличием LTE от прежних стандартов связи, является тот факт, что основной в LTE является передача данных, а передача голоса отведена на второй план и осуществляется путем включения дополнительных фич и интерфейсов.
1. IMS и SRVCC. IMS – IP Multimedia subsystem – дополнительная часть мобильной сети, позволяющая передать голос на базе IP based протокола – SIP (т.е. по сути обычная IP-телефония), но в логике мобильной сети она обеспечивает возможность “безшовного” перехода абонента (soft-handover) при разговоре, из сети LTE в сеть GSM/W-CDMA – тем самым реализуя фичу SRVCC – Single-Radio Voice Call Continuity. Т.е. если абонент установил голосовое соединение в LTE, используя IMS подсистему, то реализовать неразрывность соединения при хэндовере в другие сети не составит труда – тип радиодоступа изменится, а звонок, как обрабатывался IMS, так и останется им обрабатываться.
2. Однако, далеко не каждый оператор готов инвестировать в строительство дополнительной подсистемы на своей сети, именно поэтому больше популярностью пользуется другой способ передачи голоса в LTE – CSFB – Circuit-switched fallback, применение данной фичи позволяет не передавать голос по сети LTE вообще. А именно – при попытке активации голосового вызова, абонент “проваливается” в CS Core 2G/3G сети, регистрируясь там и используя ее ресурсы, осуществляется это благодаря дополнительному SGs интерфейсу, связывающего MME и MSC, при этом при разговоре абонент не потеряет возможность передачи данных, хотя и скорость при этом снизиться до скорости 2G/3G сети. Данный способ позволяет использовать уже существующую структуру сети оператора, без необходимости дополнительных вложений.

IP Routing

Что происходит, если в качестве Next Hop указано имя интерфейса, а не IP-адрес узла. В каких случаях рекомендуется его использование, чем это грозит.
Краткий бриф по проблеме.
В такой схеме маршрутизатор А имеет следующую конфигурацию:
Когда он получает (или формирует) пакет предназначенный маршрутизатору С, он должен инкапсулировать его в Ethernet-кадр. Логично, что MAC-адрес отправителя он подставляет адрес интерфейса FE0/0, получателя – адрес интерфейса FE0/1 маршрутизатора B.
Загвоздка в том, как он получит этот MAC-адрес.
В обычном случае, когда настроен ip route 0.0.0.0/0 10.1.2.2, хост А отправляет ARP запрос, где спрашивает – «Какой MAC у 10.1.2.2?», В в ответ отправляет свой МАС и всем счастье.
Сейчас у А нет даже IP-адреса В, сказано только куда отправлять пакет. Как быть? Ведь в ARP-запросе мы не можем поставить пустой IP, не можем и широковещательный – это бессмысленно.
Выход из ситуации обеспечивает ARP-Proxy. А отправляет ARP-запрос, где запрашивает MAC-адрес устройства с IP-адресом 3.3.3.3 (несмотря на то, что оно в другой подсети).
В получает такой ARP-запрос и, если на интерфейсе активирован механизм ARP-Proxy, проверяет, что в его таблице маршрутизации есть маршрут до получателя (хотя бы даже дефолт), и отправляет А ARP-ответ с ожидаемым содержимым:
То есть он возвращает MAC-адрес своего интерфейса.
Маршрутизатор А добавляет эту запись в ARP-кэш.
Таким образом каждый адрес, доступный через такой маршрут будет добавлен как directly connected в ARP-кэш.
Приятного в этом мало. Огромное количество широковещательных запросов, переполненный ARP-кэш, высокая загрузка процессора.
Нужно избегать таких конфигураций. Применима она по сути только к Point-to-Point интерфейсам (PPP, HDLC, FR).
Полезные ссылки:
ciscoexpert.wordpress.com/2008/06/28/proxy-arp/
blog.initialdraft.com/archives/2605/

Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Группа в linkedin

Скачать все выпуски подкаста вы можете с яндекс-диска.
Добавить RSS в подкаст-плеер.
Пообщаться в общих чатах в тг:
t.me/linkmeup_chat t.me/linkmeup_sysadm_chat

Поддержите нас:
like 2 views 42257 message 78

78 коментариев

Ещё выпуски
Play
telecom №158. ICANN, gTLD, RSP
Вот уж тема так тема! Сегодня мы поговорим о том, как устроен мир доменных имён изнутри — от базовых понятий вроде gTLD и ...
like 0 471 0
25 апреля 2026
Play
telecom №139. Облачные SDN. OVN
На этот раз у нас тема, которую мы потрогали уже со всех сторон с разной глубиной проникновения - SDN. И более конкретно - ...
like 0 2350 0
25 сентября 2024
Play
telecom №102. Аппаратное ускорение сети, DPU
Мы поговорили про сети в Linux, про обработку пакетов на CPU с помощью ванильного сететвого стека ядра, DPDK/VPP, eBPF/XDP, про оверлейные сети. Но ...
like 3 5120 3
25 августа 2021
Play
LTE №14. Open Source Software
Бар 256ttl осторожно приоткрывает двери. На этот раз для иностранного гостя. Обсудим неновости. За что Network to Code так поступил с Джереми Стрейчем ...
like 0 4247 0
7 августа 2021
00:00 00:00
1x
1x 1.2x 1.5x 2x
Изображение подкаста

telecom №0

like 2