Пользователь
0,0
рейтинг
25 февраля 2013 в 15:48

Администрирование → LinkMeUp. Выпуск 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-адреса.

Нас можно слушать на нашем сайте или на rpod.

Ниже краткий бриф и схемы для того, чтобы разобраться в темах было проще.

Если у вас есть предложения, какие темы было бы интересно обсудить в следующих выпусках, с удовольствием принимаем их в комментариях.



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
Марат @eucariot
карма
568,0
рейтинг 0,0
Пользователь

Самое читаемое Администрирование

Комментарии (43)

  • +2
    предложения не было – ни одного подкаста в этой сфере.

    Рекомендую packetpushers.net/category/podcast-post :)

    По поводу ip routing. На самом деле (в случае ethernet) интерфейс указывать стоит вместе с next hop'ом. Упражнение: что будет, если физический интерфейс, на котором изначально был next hop, перейдет в down, а откуда-нибудь со стороны прилетит анонс по IGP на содержащую next hop сеть?
    • 0
      Спасибо, Дима.
      Ты не перестаёшь удивлять своей осведомлённостью)
      • 0
        Грабли, шишки на лбу…
        • 0
          ip route… permanent не даст пропасть маршруту при дауне интерфейса
          • 0
            То есть вы подумали, что при наличии маршрута:
            ip route 10.0.0.0 255.255.255.0 192.168.0.1

            и интерфейса:
            int fa0/0
            ip address 192.168.0.2 255.255.255.252

            переход интерфейса fa0/0 в down автоматически означает пропадание роута? Но это не так :)
            И тот факт, что это не так, способен вызвать проблемы в определенных сценариях — когда на самом деле надо, чтобы маршрут пропал из таблицы маршрутизации.
            • 0
              Хм. permamnet описывается как «Specifies that the route will not be removed, even if the interface shuts down»
              Т.е. это относится к случаям, когда маршрут не на ип, а на интерфейс указан? Или как тогда понимать это описалово параметра.
              • 0
                Вы все правильно понимаете, но проблема-то как раз в том, что если линк, где находится next hop, падает, маршруту следовало бы покинуть таблицу маршрутизации, но он вовсе не всегда это делает, перенацеливаясь в другую сторону и создавая L3 луп для указанного префикса :) Как тут поможет permanent?
                • 0
                  А в каких случаях он этого не делает? Сколько раз я ни сталкивался с такой ситуацией — при падении интерфейса из таблицы удаляется маршрут, если эта сеть была directly connected.
                  • 0
                    Если из примера дмитрия фа0 задаунить, но при этом будет существовать маршрут на 192.168.0.0 (он может быть даже не по IGP придет, а может уже присутствовать как защитный статик с более широкой маской), то исходный ip route 10.0.0.0 255.255.255.0 192.168.0.1 не исчезнет.
                  • 0
                    Ну к примеру есть железка, у которой есть маршрут:
                    D 10.0.46.0/24 [90/3072] via 10.0.0.4, 6w1d, GigabitEthernet0/1

                    Где-то далеко.
                    Я ввожу левый статический маршрут:
                    R00(config)#ip route 1.1.1.0 255.255.255.0 10.0.46.1

                    Т.е. next hop вовсе не connected.
                    Смотрим таблицу маршрутизации:
                    S 1.1.1.0 [1/0] via 10.0.46.1
                    D 10.0.46.0/24 [90/3072] via 10.0.0.4, 6w1d, GigabitEthernet0/1

                    Маршрут есть.
                    Смотрим CEF:
                    R00#show ip cef 1.1.1.1 detail
                    1.1.1.0/24, epoch 0
                    recursive via 10.0.46.1
                    recursive via 10.0.46.0/24
                    nexthop 10.0.0.4 GigabitEthernet0/1

                    Т.е. ответ: статический маршрут дает железке next hop к префиксу, и если в самом маршруте не указан явным образом интерфейс, то железка выполняет рекурсивный запрос к таблице маршрутизации в поисках next hop'а к next hop'у. Если потребуется — несколько раз подряд. Надеюсь, понятно, что в 99,999% случаев такое поведение нежелательно?
                    А теперь кто скажет, что будет на уровне IGP с маршрутом на префикс 1.1.1.0/24, если сказать «redistribute static»? :)
                    Если надо, могу вечерком нарисовать топологию, в которой факт непропадания маршрута из таблицы маршрутизации ломает доступ к 1.1.1.0/24.

                    А был ли он connected на какой-то момент времени — не имеет никакого значения.
                    • 0
                      Спасибо. Будет интересно попробовать.
                • 0
                  Попробовал, вроде понятно. Дауним интерфейс. Но его подсеть начинает роутиться куда-то в другое место. От того, что маршрут на нехт-хоп не пропал и исходный маршрут не исчезает. Вроде так. Тогда ключевое слово перманент получается актуально только в том случае, когда интерфейс в дауне, маршрутов на нехт-хоп нету и тогда перманент не дает статик роуту слинять… Поправьте, если это не так.
                  • 0
                    Тогда ключевое слово перманент получается актуально только в том случае, когда интерфейс в дауне

                    Вы все правильно понимаете, но permanent никак не решит проблему «маршрут не исчезает, когда интерфейс с ожидаемым next hop'ом переходит в down», скорее наоборот — усугубит. Он уж почти гарантирует, что железка не станет пользоваться резервными путями для доступа к префиксу, или воспользуется неправильными путями.
                    • 0
                      Тогда сформулирую иначе. Когда он (перманент) нужен? При каком сценарии? То, что в приведенном выше примере ситуация усугубляется — понятно. Я уже отказался от идеи, что так ситуацию можно решить. Я второй частью своего текста «гда ключевое слово перманент получается актуально только ...» уже не рассматриваю изначальный пример, а пытаюсь понять, когда вообще этот перманент нужен. В общем, так скажем, случае. Ведь при таком хитром поведении не понятно, зачем городить огород для НЕпропадания маршрута, если ему и так очень сложно пропасть. В сложной сети описанный пример с «прилетанием» маршрута, охватывающего некст-хоп совсем не редкость.
                      • 0
                        Тогда сформулирую иначе. Когда он (перманент) нужен?

                        Единственное, что приходит в голову — сценарий «когда нет пути через указанный интерфейс, то нульрутить». Так как это будет аналог нульрута, одной строчкой вместо двух (но не зная шестеренки внутри каждой конкретной железки — не могу гарантировать, что прибитый таким образом трафик не будет пунтиться на CPU, надо смотреть).
                        Зачем так делать? Понятия не имею.

                        Я никогда не пользовался ключевым словом permanent.
                        • 0
                          Хм.

                          supportforums.cisco.com/thread/194350

                          Sure. Sometimes it is «better» to have a more stable network than it is to have exact precision in your routing table. One scenario: you have some destinations for which you have static routes which you redistribute into your dynamic protocol. And you have some remote locations where you do not want to consume bandwidth with routing updates that you could avoid or you have some routers where you do not want routing updates and convergence to chew up CPU cycles if you can avoid it. So you configure your static routes as permanent. They always stay in the routing table, no bandwidth used for routing updates, no CPU cycles for convergence. The downside is that some traffic gets sent to you that you can not forward and must discard.

                          Second scenario: probably even more common. You are running BGP with multiple service providers. You have some static routes in your routing table so that the BGP network statements will have a match. To prevent flapping of your advertisements to the providers you want the static route to always be present in the routing table. (Of course many of us accomplish this with static routes to null 0 — but the static permanent is another alternatie).
                          • 0
                            no CPU cycles for convergence

                            Об этом уж точно можно не заботиться. IGP куда больше ресурсов потребует даже на кипалайвы. Разве что какой интерфейс сильно флапится, но на это можно (и нужно) ответить dampening'ом.
                            You have some static routes in your routing table so that the BGP network statements will have a match.

                            Только я подумал об очевидном и общепринятом решении этой задачи, как в последнем предложении его упомянули.
                      • 0
                        Боюсь ошибиться, но может быть когда за одни интерфесом используеться несколько сетей с разными адресациями не входящими непосредственно в адресацию интерфейса?
                        • 0
                          Все статические маршруты на одинаковый next hop, т.е.:
                          ip route x.x.x.0 255.255.255.0 10.0.0.1
                          ip route y.y.y.0 255.255.255.0 10.0.0.1
                          и так далее будут ложиться или подниматься одновременно, в зависимости от достижимости 10.0.0.1. Если он недоступен, то статическому маршруту лучше бы покинуть таблицу маршрутизации — толку от него все равно не будет.

                          Или речь про широковещательный сегмент, напрямую висящий за интерфейсом, где у разных групп устройств разные подсети? В таких случаях назначают secondary адрес.
                          • 0
                            Или речь про широковещательный сегмент, напрямую висящий за интерфейсом, где у разных групп устройств разные подсети? В таких случаях назначают secondary адрес.


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

                            понимаю что уже попахивает бредом и в реальности это будет огород из костылей и велосипедов, но можно же так извратиться:)
                            • 0
                              а если адресаций больше 2-х?

                              Навесить больше двух secondary…
                              А без них как вы собираетесь принимать входящий трафик от расположенных там хостов? Кого укажете в качестве первого хопа?
                              Еще проблема: если есть маршрут вида ip route 192.168.0.0 255.255.255.0 vlan100, то роутер наверняка пошлет arp request со своего адреса из другой подсети — но я чертовски сомневаюсь, что клиент отправит reply на явную липу.
                              (да, статья говорит «так делать не надо», но я говорю «для небольших сеток так делать плохо, но не очень вредно»)
                              а если есть не одна точка входа в сеть, а больше? и точки связаным между друг другом с помощью динамической маршрутизации, и нельзя допустить что бы при пропадании интерфейса трафик шел через другие хопы, а просто дропался?

                              Вы не сможете поднять соседство по IGP с помощью secondary адреса. А несколько VLANов или сабов завести религия не позволяет? :)
                              Без хоть какого-то адреса на интерфейсе не получится, собственно, устроить двухстороннее общение между хостами одновременно в разных подсетях.
                              Впрочем, у меня уже взорван мозг, так что я не понял фразу «нельзя допустить что бы при пропадании интерфейса трафик шел через другие хопы, а просто дропался?» — если речь идет про IGP, то зачем статика? Связность нарушена => трафик не идет, так как нет обмена маршрутами.
                              • 0
                                «но я чертовски сомневаюсь, что клиент отправит reply на явную липу»

                                Никаких проблем. Что помешает? Я даже больше скажу. В вин2008 периодически наблюдаю попытки прорезолвить виндой по arp ипшники из радикально чужой подсети.

                                C:\>ipconfig

                                Настройка протокола IP для Windows

                                Подключение по локальной сети — Ethernet адаптер:

                                DNS-суффикс этого подключения..:…
                                IP-адрес............: 10.16.1.217
                                Маска подсети..........: 255.255.255.224
                                Основной шлюз..........: 10.16.1.193

                                10:40:05.344028 arp who-has 10.16.1.217 (00:0c:29:a0:99:f8) tell 10.16.2.1
                                10:40:05.344043 arp reply 10.16.1.217 is-at 00:0c:29:a0:99:f8

                                • 0
                                  Буду знать :)
                                  А раз так… Статическая arp запись у клиента на 10.16.1.193 (даже если такого IP адреса у роутера нет, но есть мак в нужном VLANе) — и транзитный трафик вполне будет ходить через роутер… Да и в принципе, arp reply от клиента тоже не особенно нужен, так как и на роутере можно статику создать… Нет, это абсолютно кошмарно, так делать нельзя, но оно может работать.
                                  • 0
                                    Чего только в малых провайдерских сетях не насмотришься. Выпиливание лобзиком лаукост решений (рабочих, что самое интересное) — интересная и ностальгическая тема.

                                    Вот про то, что ваяли на основе arp пионернеты еще сравнительно недавно.

                                    nag.ru/articles/article/16988/upravlyaem-neupravlyaemyim.html
                              • 0
                                Линукс тоже ниче против такого запроса не имеет

                                10:47:42.340969 ARP, Request who-has 192.168.10.1 (00:0c:29:90:4d:6a) tell 10.16.2.1, length 28
                                10:47:42.352337 ARP, Reply 192.168.10.1 is-at 00:0c:29:90:4d:6a, length 46
                            • 0
                              Кстати, любителям всяких извращений рекомендую прочитать книгу (вроде бы) нашего соотечественника, знающего примерно всё про шестеренки, благодаря которым работают IGP (да и статический роутинг) — www.amazon.com/Cisco-Routing-Forwarding-Intra-domain-Protocols/dp/0201604736/. Эта книга устарела, часть сказанного в ней неверно в случае современных версий IOS, но в целом она дает весьма глубокое понимание устройства IOS по части маршрутизации. Многие вопросы отпадут.
                    • 0
                      И кстать, а если есть дефолт роут? Т.е. в вашем примере некст хоп 10.0.46.1 доступен через статический 0.0.0.0? Тот же эффект?
                      • 0
                        Дефолтный роут — исключение. Потому проблема не настолько массовая, как ожидалось бы.
    • 0
      +1 за packetpushers. Местами бывает реальный хардкор =)
      • 0
        Ну там ого-го какие люди приглашаются…
        • 0
          Вот за это я его и люблю =) Да и ведущие тоже отменные.

          Надеюсь ЛинкМиАп тоже с гостями не подкачает ;)
          • 0
            Я прямо сейчас слушаю ЛинкМиАп — очень даже неплохо. Много новых слов узнаю. Действительно грамотно сделано. Ну авось через годик сам Dino будет отвечать на их вопросы про LISP :)

            Кстати: а периодически играющая в фоне музыка — это чей-то забытый мобильник (такое ощущение, что слышится виброзвонок), или фича? Если фича, то лучше бы переделать, так как уж очень на баг смахивает и несколько отвлекает.
        • 0
          А когда в ITunes вас ждать?
          • 0
            Переадресую вопрос eucariot, ибо я не в теме.
          • 0
            Не задумывался даже об этом. Спасибо за идею. Постараюсь следующий выпуск уже туда.
      • 0
        Только вот что-то в последнее время они на DC и все что вокруг него зациклились. Раньше было разнообразнее.
  • 0
    А если там будет VTI с ip unnumbered?
    • 0
      Ну да, в этом случае мы вынуждены указывать интерфейс.
      • 0
        … но ничего страшного, так как это тоже point to point интерфейс.
  • +1
    Спасибо, было интересно послушать. Хорошая инициатива, надесь у вас хватит энтузиазма надолго.

    По ходу подкаста я понял, что вы все живете в разных городах, но при этом все неплохо знакомы. Как это случилось, есть какая-то телекомовская тусовка про которую я не знаю?
    • 0
      Марат нас всех собрал) я лично никого из участников подкаста (Марата в том числе) никогда не видел вживую. Интернет объединяет!
  • 0
    Спасибо большое, послушал с большим интересом. Жду следующих выпусков.
    Не хватает вам по радиочасти кого-нибудь только :) Хэндоверы, инициируемые трубкой это что-то новое :)
    • +1
      Да, так получилось, что радиочасть осталась несколько вне нашей компетенции :)

      Про хэндоверы имелась ввиду BSS подсистема в целом :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.