telecom №0
Всё началось с очень долгой дороги домой.
Это время нужно было чем-то занимать. Когда-то это были 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. C ним все становится сложнее: абонент переходит со своим номером к другому оператору, и теперь информация, необходимая для связи с абонентом, хранится у последнего. Но маршрутизировать как-то нужно. Возникает потребность в дополнительной базе, которая бы хранила номера абонентов, поменявших оператора, в которой бы говорилось, что, мол, такой-то абонент с номером от оператора A на самом деле является клиентом оператора Б, поэтому всю информацию нужно спрашивать у Б. Существует 3 вида такой «переадресации»:
В любом случае, нужна некая внешняя база перешедших абонентов, и в этом вся интрига: кто будет этим заниматься, ведь дело нешуточное, в случае отказа этой базы, перешедшие абоненты всех операторов остаются без связи.
Полезные ссылки:
pro-gsm.info/mnp.html
pro-gsm.info/cap-roaming.html
С точки зрения разделения радиоканалов 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 сети. Данный способ позволяет использовать уже существующую структуру сети оператора, без необходимости дополнительных вложений.
Краткий бриф по проблеме.
В такой схеме маршрутизатор А имеет следующую конфигурацию:
Когда он получает (или формирует) пакет предназначенный маршрутизатору С, он должен инкапсулировать его в 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/
Это время нужно было чем-то занимать. Когда-то это были 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
Поддержите нас:
58 комментариев
Маршрут фактически тоже будет указывать на интерфейс (Dialer), но arp-cache засоряться не будет.
по поводу того какие телефоны поддерживают LTE: Sony Xperia V, Samsung Galaxy S3 (в специальной редакции для мегафон), HTC One SV, Nokia Lumia 920, Blackberry Z10/Q10… Это не полный список =)
Это телефоны, которые поддерживают Российский LTE?
А рпод и саундклауд написаны робатами для робатов.
Не нашел как подписаться на подкаст.
Помогите!
1. Ведущему перестать перебивать ораторов и завести одно мнение на весь подкаст. От ракировок линий повествования закружилась голова.
2. Либо унца есть, либо её нет. Зачем кусками?..
3. Господа, ну не спектакль в детском садике, ну побольше естественности и поменьше постановки, почему у какого-то appleinsider и Radio-T это получается а у вас нет? Мы — pod-слушатели вас не съедим, я гарантирую это!©
4. Послешоу перед последней темой — интересный вареант, но как-то выдранно с корнями из контекста…
а в остальном ща пойду ваши RSS-ы к себе в папочку подкастов подшивать.
з.ы. via: habrahabr.ru (для статистики, если нужно)
Мне очень лестно сравнение с эплинсайдерам и радиотом, но нужно сделать скидку на то, что это первый раз и ведущие никогда прежде не вели подкасты, не занимались звуком, особо нигде не выступали публично. Вероятно, в будущем всё будет получаться живее и лучше.
Спасибо за критику и советы.
Тогда буду слушать всегда)
Как дурак слушаю выпуск с компьютера через браузер без нормальной возможности подписаться. :(
P.s. подкаст про телеком это шикарно, молодцы ребята!
Спасибо за поддержку!
Кстати, rpod сам генерирует ссылку для itunes (кнопка вверху на странице ленты).
Сделал такую ошибку, когда публиковал свой подкаст ПОДзарядка на rpod. Источник фоновой музыки администрации не понравился. Хотя это был podsafe, но не из числа рекомендуемых терминалом.
К подфм у вас тоже могут возникнуть вопросы. Может не понравится реклама, которую вставят в подкаст. Или останетесь недовольны возможным распространением подкаста в качестве платного премиум-контента для некоторых сотовых операторов.
Еще много подводных камней, с которыми сталкивались многие, гораздо более популярные подкастеры, чем я. И тогда приходилось изобретать способы оповещения слушателей об изменении адреса ленты, просить переподписаться в другом месте и т.п. Автономный хостинг или варианты вроде libsyn.com/ к которому рано или поздно приходят популярные подкасты это скорее вынужденный шаг.
P.S. Ваш подкаст понравился. Спасибо. Я три года назад, решив попробовать себя в подкастинге, начинал с того, что неплохо знаю: рассказывал основы теории телекоммуникаций, историю телефонии. Сейчас кажется, что первые подкасты ужасны, но ваш подкаст хоть и первый, но на высоком уровне. И тема интересная. Удачи!
С рекламой вопрос тоже спорный. Я не уверен, что захочу её добавлять в подкаст.
Как бы то ни было — уже поздно, скормил рподовскую ссылку айтьюнсу.
А насчёт подфм не понял — они сами вставляют в подкаст релкаму?
Буду решать проблемы по мере их поступления.
Кстати, не знал, что всё-таки было телекомовский подкаст — искал в инете, спрашивал у всех знакомых итшников, даже на хабре вопрос размещал — ничего не нашёл.
Начинать с простых тем не хотелось — сразуотсеивается большой пласт инженеров высокого уровня. А так и им интересно, надеюсь, и маленькие в общих словах будут понимать о чём речь идёт.
Мой телекомовский подкаст alexey-rubtsov.podfm.ru/teleguide/ давно заброшен. Начинался на основе курса лекций, который я когда-то читал в университете, поэтому рассказывал основы. Первые выпуски ужасны, никак не мог привыкнуть говорить с микрофоном, а не аудиторией. Потом добавил выпуски по истории телефонии, стал рассказывать о некоторых железках, с которыми работаю, но в конце концов забросил эту ленту. Про «простые» и «сложные» темы поддерживаю, если есть желание слушатели найдут возможность поискать информацию на темы, которые заинтересовали.
А ещё надо будет послушать ваш подкаст, темы выглядят заманчивыми. Особенно SDH.
Кстати, сначала у нас хотела в подкаст девушка — телефонист со своей собственной радиостанцией. Тогда мы планировали тоже историю телефонии рассказать.
Тут некто выше написал что радиоты живее и менее наиграны. Однако те обладают несоизмеримым ЧСВ, не надно становиться такими же как они :)
Вобщем все отлично но на rpod'е хорошо бы сделать отдельную ленту, чтобы была возможность была подписаться выборочно на вас.
Про rpod обязательно посмотрю, но пока не понимаю, о чём идёт речь.
P.s.
Мне кажется, что у Ростелекома чистая прибыль > 300 млн рублей))
Молодцы, очень интересно было послушать Ваши рассуждения, хотя порой чувствовалось, что тема не глубоко копалась.
Жду следующего выпуска!
Была поднята тема, о том что не по всей России еще 2G есть… Все мы прекрасно знаем размеры нашей Родины ну и понимаем, что нерентабельно было бы в некоторых районах делать сотовую связь. НО ведь у нас есть спутниковая мобильная связь! Например Глобалтел. Было бы интересно послушать про это! Могу кстати выступление подготовить :D
Спасибо за предложение. Я думаю, через несколько выпусков мы начнём приглашать гостей. Я вас добавлю в список) Тема спутниковой телефонии была бы особенно интересна. И теоретически ей можно посвятить весь выпуск. Будет кстати ваша электронка на info@linkmeup.ru.
будем стараться посвящать более глубоким техническим вопросам.
Мегафон в Питере работает через свою сеть? Или через Скартел?
через скартел… по всей стране ёта строит сети лте, а мегафон работает по модели «виртуального» оператора.
в дальнейшем к этой модели планируют присоединиться мтс и ростелеком…
вот что с билайном не понятно… на сколько я понял они все таки собираются строить собственные сети…
Спасибо огромное за подкаст, давно искал что-нибудь подобной тематики, найти не мог, а тут такое счастье! Радиот прикольный, но все-таки более программистский. Первый блин вышел не комом, на мой взгляд очень даже неплохо. Буду рад, если регулярность выхода будет стабильной, а впоследствии сократится хотябы до двух недель ;)
Многие моменты предыдущие комментаторы уже озвучили, но хочу присоединиться к мнению по поводу музыкального сопровождения. На мой вкус пусть лучше оно или будет или нет, а то немного напрягает, когда музыка появляется и пропадает.
По теме LTE уже сказали, что есть довольно много телефонов, поддерживающих российский стандарт. И в Москве проблема использования LTE и телефонных звонков частично решена. На мегафоне, если абонент сидит в интернете по LTE, и в этот момент ему поступает вызов, звонящий слышит оповещение, типа «подождите звонок сейчас будет установлен». Абонента перекидывает с LTE на 2/3G и происходит голосовое соединение.
Был несколько удивлен о том, что один из авторов не знал о наличии handover'а на мобильном WiMax'е. А также о таких граблях с ним у Huawei. Я в свое время работал в компании, эксплуатировавшей сеть WiMax-Comstar в Москве, у нас практически не было никаких проблем с работой handover'a. Оборудование было израильское — Alvarion.
Забавными показались, что на циске далется оборудование доступа, а агрегирующие/ядровые железки мол используют другие. Обидно даже как-то стало за циску))
Еще раз спасибо за подкаст, желаю вам всяческих творческих успехов. С удовольствием продолжу слушать ваши творения. Да и «сети для самых маленьких» смотрел и читал с удовольствием: что-то напомнил себе, были и новые нюансы. Кстати на грабли с arp-proxy не наступал, спасибо за инфу. При правильной архитектуре, по-идее, таких траблов быть не должно.
Спасибо за критику и советы.
Но, повторюсь, что мы учимся вместе с вами, поэтому некоторые вещи можем действительно не знать.
В WiMAX, кстати, хендовер — вещь очень привередливая. На 3.5ГГц качественного хендовера уже довольно сложно добиться. Ну а 5.5 — это вообще фикса.
Надеюсь, со временем поднимем планку.
У нас был WiMax 802.16e — мобильный WiMAX. Несущая частота была 2,4 ГГЦ. Проблем с хендовером мы практически не знали.
Я оттуда уже ушёл, но насколько мне известно, они добились нормального хендовера.
Желаю вам не остыть и продолжать, очень уважаю этот труд.
Спасибо!
не вспомню где точно читал… но где то представители мегафона писали что будут проверять работоспособность обоих способов…
а так ИМХО, поставил «мультифон» и в лте разговариваешь через него, профит, проблема решена =)
P.S. я невнимателен и просто не заметил тут упоминания подкастов от пакетпушерс.нет? У них есть просто исключительные подкасты. Много познавательной информации о всяком хай-енде и bleeding edge нашей индустрии, тот же SDN и что с ним связано. Ну это для тех, кому ширпотребные радиоты не интересны :)