NetMonitor.Ru Forum
Форум проекта по исследованию сетей мобильной связи
Вопрос экспертам: Autentification & TMSI Reallocation. — Общие вопросы, касающиеся принципов работы GSM-сетей
Вопрос экспертам: Autentification & TMSI Reallocation.
Сообщение Waveman » Ср, 04-04-2007, 12:22
Собственно вопрос в следующем:
С какой частотой целесообразно проводить эти процедуры (при Location Update (external, Internal, Periodic), MOC, MTC, SMS, IMSI Attach) чтобы получить оптимальное соотношение безопасности в сети и нагрузки?
И для каких видов соединений эти процедуры вообще не нужны?
Под частотой подразумевается: всегда\каждое N-ое соединение\никогда
Есть у кого-нибудь мнения на этот счет?
И вообще есть ли угрозы безопасности сети при полном отключении этих процедур? (кроме скажем IMSI Attach)
Сообщение WishMaster » Ср, 04-04-2007, 14:22
Сообщение Barabek » Ср, 04-04-2007, 16:13
Сообщение 2000 » Чт, 05-04-2007, 10:28
Сообщение Валентин » Чт, 05-04-2007, 11:51
Сообщение Waveman » Чт, 05-04-2007, 11:53
Сообщение Валентин » Чт, 05-04-2007, 12:15
Сообщение Waveman » Чт, 05-04-2007, 14:34
Сообщение Waveman » Чт, 05-04-2007, 14:38
Сообщение Barabek » Чт, 05-04-2007, 15:32
Re: Вопрос экспертам: Autentification & TMSI Reallocat
Сообщение utka » Пт, 06-04-2007, 14:45
Сообщение utka » Пт, 06-04-2007, 14:50
с трудом верится!
Я думаю, что просто в связи с множеством ЛАКов и тд и тп очень часто проходит локейшин апдейт, при котором и происходит TMSI-Realloc.+Auth.
Пришлите трейс на котором без смены лака происходят данные операции при МТС/MOC/SMS, поверю )
Сообщение Waveman » Пт, 06-04-2007, 17:19
с трудом верится!
Я думаю, что просто в связи с множеством ЛАКов и тд и тп очень часто проходит локейшин апдейт, при котором и происходит TMSI-Realloc.+Auth.
Пришлите трейс на котором без смены лака происходят данные операции при МТС/MOC/SMS, поверю )
Сообщение Waveman » Пт, 06-04-2007, 17:21
с трудом верится!
Я думаю, что просто в связи с множеством ЛАКов и тд и тп очень часто проходит локейшин апдейт, при котором и происходит TMSI-Realloc.+Auth.
Пришлите трейс на котором без смены лака происходят данные операции при МТС/MOC/SMS, поверю )
easynetwork
easynetwork easynetwork
Запись опубликована EasyNetwork. Пожалуйста оставляйте свои комментарии тут.
CC (Country Code) – Код страны, в которой подключался к сети абонент (там где выдали SIM).
SN (Subscriber Number)- Номер абонента.
Конкретные длины составляющих частей регулируются международным и локальным законодательствами, например: Россия: CC=1 цифра (7), NDC=3 цифры (например, 910), SN=7 цифр (1234567), итого — 11 цифр (итоговый пример: 7-910-1234567).
Проверить какому оператору связи принадлежит тот или иной номер можно например на сайте MTT.
MCC – Mobile Country Code. Код страны в которой находится оператор. Описывает “домашнюю” страну мобильного абонента. Например в России MCC=250.
MNC – Mobile Network Code. Код мобильной сети. Уникально описывает сеть абонента. MNC наших операторов. MNC = 01 МТС, MNC = 02 Мегафон, MNC = 99 Билайн, MNС = 20 TELE2 Россия.
IMSI идентифицирует абонента в HLR. При регистрации абонента в MSC или SGSN аппарат абонента передает IMSI, по которому происходит его идентификация в HLR (разрешить/запретить доступ к сети, информация о подключенных услугах и пр.). Во избежание перехвата, этот номер посылается через сеть настолько редко, насколько это возможно — в тех случаях, когда это возможно вместо него VLR и SGSN могут использовать случайно сгенерированный TMSI. При этом в VLR и SGSN содержится соответствие IMSI и TMSI для каждой MS. Для CS сервисов используется TMSI, а для PS P-TMSI.
TAC – Type Approval Code. Назначается сериям мобильных телефонов после тестирования. До 2002 TAC состоял только из 6 цифр, оставшиеся 2 цифры составляли код места окончательной сборки (FAC). С 2003 до 2004 проходил переходной период, во время которого все коды FAC равнялись цифрам 00. В 2004 FAC прекратил своё существование, а TAC был расширен до 8 цифр.
FAC – Final Assembly Code. Это код окончательно собранного изделия. Добавляется для идентификации производителя.
SNR – Serial Number. Серийный номер
Содержание
Процедура обновления локации
Процедура обновления местоположения позволяет мобильному устройству информировать сотовую сеть всякий раз, когда оно перемещается из одной области местоположения в другую. Мобильные телефоны отвечают за обнаружение кодов местоположения (LAC). Когда мобильный телефон обнаруживает, что код области местоположения отличается от его последнего обновления, он выполняет другое обновление, отправляя в сеть запрос на обновление местоположения вместе со своим предыдущим местоположением и своим временным идентификатором мобильного абонента (TMSI).
Мобильный телефон также сохраняет текущий LAC на SIM-карте, объединяя его со списком недавно использованных LAC. Это сделано для того, чтобы избежать ненужных процедур присоединения IMSI в случае, если мобильный телефон был принудительно выключен (например, путем извлечения аккумулятора), не имея возможности уведомить сеть об отсоединении IMSI, а затем включился сразу после его включения. выключенный. Принимая во внимание тот факт, что мобильный телефон все еще связан с центром коммутации мобильной связи / регистром местоположения посетителей (MSC / VLR) области текущего местоположения, нет необходимости выполнять какие-либо процедуры присоединения IMSI.
Когда абонент получает пейджинговый поиск в попытке доставить вызов или SMS, и абонент не отвечает на эту страницу, тогда абонент помечается как отсутствующий как в MSC / VLR, так и в домашнем регистре местоположения (HLR) (флаг недоступности мобильного телефона MNRF установлено). В следующий раз, когда мобильный телефон выполняет обновление местоположения, HLR обновляется, а флаг недоступности мобильного телефона сбрасывается.
Сеть также может изменить TMSI мобильного телефона в любое время. И обычно это делается для того, чтобы абонент не был идентифицирован и не отслеживался перехватчиками радиоинтерфейса. Это затрудняет отслеживание того, какой мобильный телефон является каким, кроме кратковременного, когда мобильный телефон только что включен, или когда данные в мобильном телефоне становятся недействительными по той или иной причине. В этот момент в сеть должен быть отправлен глобальный «международный идентификатор мобильного абонента» ( IMSI ). IMSI отправляется как можно реже, чтобы избежать его идентификации и отслеживания.
Размер TMSI составляет 4 октета с полными шестнадцатеричными цифрами, но не может быть полностью FF, поскольку SIM-карта использует 4 октета со всеми битами, равными 1, чтобы указать, что действительный TMSI недоступен.
Блуждая
Типы площадей
Район расположения
Если зоны расположения большие и умеренно населенные, вероятно, будет одновременно работать большое количество мобильных телефонов, что приведет к очень высокому пейджинговому трафику. Это связано с тем, что каждый запрос поискового вызова должен транслироваться на каждую базовую станцию в зоне расположения. В конечном итоге это приводит к потере пропускной способности и мощности мобильных устройств, требуя от них слишком частого прослушивания широковещательных сообщений. Точно так же, если, с другой стороны, существует слишком много небольших участков местоположения, мобильное устройство должно очень часто связываться с сетью для изменения местоположения, что также приведет к разрядке аккумулятора устройства. Следовательно, важно соблюдать баланс между размером области расположения и количеством пользователей мобильных устройств в области расположения.
Область маршрутизации
Пакетный характер трафика пакетов означает, что ожидается больше сообщений поискового вызова для каждого мобильного устройства, и поэтому стоит знать местоположение мобильного устройства более точно, чем при использовании традиционного трафика с коммутацией каналов. Переход от области маршрутизации к области маршрутизации (так называемый «Обновление области маршрутизации») осуществляется почти так же, как переход от области расположения к области расположения. Основные отличия заключаются в том, что задействованным элементом является «обслуживающий узел поддержки GPRS» ( SGSN ).
Область отслеживания
Операторы могут назначать разные списки TA разным UE. Это может избежать пиков сигнализации в некоторых условиях: например, UE пассажиров поезда могут не выполнять обновления области отслеживания одновременно.
Со стороны сети задействованным элементом является объект управления мобильностью (MME). MME настраивает списки TA с помощью сообщений NAS, таких как Attach Accept, TAU Accept или GUTI Relocation Command.
GPRS изнутри. Часть 2
Продолжаем наше знакомство с пакетной передачей в сетях мобильных операторов, которое мы с Вами начали в первой части о GPRS/EDGE технологиях. В этой статье речь пойдет о процессе аутентификации и авторизации, т.н. процедуре GPRS Attach, а также активирование услуги, запрошенной абонентом — поднятие PDP Context’а. Посмотрим какие данные хранятся на стороне SGSN’а, а какие на стороне абонента.
Ну, что ж поехали…
GPRS Attach
Процесс аутентификации и авторизации, т.н. процедура GPRS Attach, изображен на схеме ниже (картинка кликабельна).
RAI — Routing Are Identity
MCC — Mobile Country Code (международный код страны)
MNC — Mobile Network Code (международный код оператора в пределах страны)
LAC — Location Area Code (совокупность базовых станций, объединенных одним кодом)
RAC — Routing Area Code (зона, меньшая, либо равная LAC)
* — после успешной процедуры GPRS Attach, абоненту доступна только отправка коротких сообщений через сеть GPRS/EDGE, т.н. SMS over GPRS.
PDP Context Activation
После успешного прохождения процедуры GPRS Attach, пользователь может активировать PDP Context, что позволит ему воспользоваться услугами пакетной передачи данных.
Сама процедура активации контекста, чем-то напоминает процедуру активации коммуникации при Dial-Up соединении. Давайте посмотрим на эти две процедуры в сравнении.
Упрощенно, процедуру активации линка Dial-Up можно представить в качестве схемы:
Теперь давайте посмотрим на принципиальную схему активации PDP Context’a:
Как видим, похожесть между двумя этими процедурами, состоит в применении одинаковых протоколов, довольны похожи сами этапы и процедуры, которые используются на этапах установления соединения, а также схожи ключевые узлы, участвующие в процессе установления коммуникации.
Определив ключевые моменты, при активации PDP Context’a, рассмотрим полную процедуру и определим, какие же данные передаются во время этой процедуры.
Схема активации PDP Context’a представлена на рисунке ниже:
* — более детально про выбор и использование APN в процессе активации контекста, можно прочитать в статье: «Не важно кто ты… важно какая у тебя APN»
internet — APN, прописанная в терминале абонента,
mnc009.mcc255.gprs — GOI некоторого виртуального оператора (Украина).
Information stored before/after GPRS Attach
Давайте разберемся, какие данные хранятся на стороне абонента, а какие на стороне SGSN’а до и после процесса аутентификации и авторизации в пакетной сети оператора.
Сводная таблица представлена ниже:
| MS | SGSN | HLR | |
| Before GPRS Attach | IMSI MSISDN RAI Ki QoS profile | IMSI MSISDN Ki QoS profile | |
| After GPRS Attach | PMM State P-TMSI | PMM State P-TMSI MSISDN RAI Kc QoS profile | SGSN address |
APN — Access Point Name
CHAP — Challenge Handshake Authentication Protocol
EIR — Equipment Identity Register
GGSN — Gateway GPRS Support Node
GOI – GGSN Operator Identifier
GPRS — General Packet Radio Service
HLR — Home Location Register
HPLMN — Home PLMN
IMSI – International Mobile Subscriber Identity
IPCP – Internet Protocol Control Protocol
MS – Mobile Station
MSC – Mobile Switching Centre
MSISDN – Mobile Station Integrated Services Digital Number
PAP — Password Authentication Protocol
PDN — Packet Data Networks
PDP — Packet Data Protocol
PLMN — Public Land Mobile Network
PPP – Point-to-Point Protocol
RAS — Registration, Admission and Status
RNC — Radio Network Controller
SGSN — Serving GPRS Support Node
VLR — Visitors Location Register
VPLMN — Visitor PLMN
История про realloc (и лень)
Простой макрос
Все началось с простого макроса: (приблизительный код)
Для тех, кто не знаком с языком программирования C, поясню: этот простой макрос добавляет байт «C» в динамически выделяемый буфер (buffer), размер которого (в байтах) равен capa. Следующая позиция для записи определяется при помощи параметра offset. При каждом заполнении буфера происходит двукратное увеличение его объема (начиная с минимального размера в 16 байт).
Мы добавляем байты в динамический буфер — это одна из наиболее распространенных операций практически в любой программе (для работы со строками, массивами и т. п.).
Но как понять, насколько эффективна стратегия перераспределения? Если вы посмотрите на эту проблему с точки зрения сложности, принимая сложность realloc() равной O(N), то сразу поймете, что добавление одного байта имеет сложность в среднем O(1), что вполне неплохо.
Но какова сложность в наихудшем случае — если требуется перераспределение памяти под буфер?
Анонимус: Уверен, что это хорошая стратегия? Ты нарвешься на серьезные проблемы с производительностью, если станешь увеличивать размер большого массива, скажем, в один гигабайт. Только представь себе последствия, особенно если буфер нужно переместить из файла подкачки.
Я: Хм… Честно говоря, никогда не задумывался над этим… Но уверен, все не так страшно. Система должна успешно справиться с этой задачей.
Анонимус: А мне кажется, что связанная структура — более удачный вариант, пусть даже с той же экспоненциальной стратегией.
Я: Да нет, это пустая трата времени.
Ах вот так, значит?!
Ладно, придется обосновать свою позицию. Как и все программисты, я весьма ленив. Точнее: «Как подобает программисту, я весьма ленив». Лень — отличный стимул стать умнее и эффективнее. Вы слишком ленивы для того, чтобы решать повторяющиеся или рутинные задачи; вам нужно что-то более интеллектуальное, что-то максимально быстрое. Да, именно это иногда называют ленью. Но, по-моему, это не что иное, как эффективность.
Что-то подсказывает мне, что моя лень будет здесь как нельзя кстати. Ведь о маленьких блоках вовсе не стоит беспокоиться, а о больших позаботится виртуальная память системы.
Кстати, что такое realloc()?
Это обычная функция, соответствующая стандарту POSIX, которая реализована в библиотеке C. В случае с Linux это библиотека libc.so, в ней же находятся и родственные realloc функции malloc и free:
Для тех, кому это действительно интересно: «T» означает «text symbol» (текстовый символ), заглавная буква используется, чтобы показать, что символ этот общедоступный и видимый; текстовый сегмент программы — это код, сегмент данных — инициализированные данные (переменные), а сегмент bss — неинициализированные данные (переменные), а точнее данные (переменные), получившие в качестве начального значения ноль).
Для выделения, перераспределения и освобождения памяти используется распределитель памяти (спасибо, Капитан Очевидность!). Таких распределителей много (самый известный — buddy allocator).
Мы можем реализовать собственный простейший распределитель с помощью великого и ужасного вызова sbrk, который просто добавляет пустое пространство в конец сегмента данных:
[Примечание. Как справедливо заметил один из читателей Hacker News, здесь нужно значение old_size, которое, например, можно было записать в начало блока после того, как блок был выделен. Но нет, мы не должны были освободить исходный блок в случае ошибок в работе realloc :)]
Разумеется, настоящий распределитель будет чуточку посложнее, потребуются сложные структуры данных, чтобы ограничить число вызовов memcpy.
Чтобы понять, что происходит с большими блоками, нам придется поближе познакомиться с Glibc на Linux.
Знакомство с Glibc
Просто скачайте последнюю версию glibc и изучите дерево исходного кода.
Там есть один интересный каталог malloc. Найдите в нем файл malloc.c и откройте его в редакторе.
Нас больше всего интересует вот эта часть: «Для очень больших запросов (>= 128 Кб по умолчанию) используются системные средства сопоставления памяти, если они поддерживаются».
Порог в 128 Кб настраивается функцией mallopt():
Итак, как я уже сказал, служба виртуальной памяти системы сама позаботится о больших блоках.
Итак, что мы знаем о man mremap:
Ага, очень эффективный realloc. Насколько эффективный?
Во-первых, mmap, munmap и mremap описаны в библиотеке glibc. На самом деле, только точки входа:
Обратите внимание на то, что точки входа по умолчанию — это в данном случае «слабые» символы. То есть они могут быть переопределены кем-то другим во время динамической компоновки. Например:
… символы могут быть переопределены библиотекой linux-vdso.so.1 — это волшебная библиотека, которая отображается во всех программах под Linux и позволяет ускорить некоторые вызовы, включая системные вызовы.
В любом случае наши символы в библиотеке glibc — это только каналы к вызовам ядра системы (syscall), будь то glibc или vdso (см. реализации по умолчанию: sysdeps/unix/sysv/linux/mmap64.c). Например:
Итак, наш первоначальный вопрос уже связан не с glibc, а с ядром Linux.
Знакомство с ядром
Скачайте последнюю версию ядра, и давайте кратко рассмотрим принципы работы mremap.
Заглянув в руководство (The Linux Kernel Howto), вы найдете очень интересный каталог:
Каталог mm содержит весь необходимый код для работы с памятью. Код управления памятью, специфичный для конкретной архитектуры, размещается в каталогах вида arch/*/mm/, например arch/i386/mm/fault.c.
Отлично. Они-то нам и нужны!
Вот интересный файл: mm/mremap.c. В нем вы найдете точку входа для системного вызова функции mremap. Вот здесь:
Именно здесь мы входим в ядро при выполнении соответствующего системного вызова в пользовательском коде (через glibc или соответствующий канал vdso).
Изучив код этой функции, вы увидите различные проверки аргументов и обработку тривиальных случаев (например, уменьшение блока памяти — нужно просто освободить страницы в конце блока).
Затем ядро попытается расширить отображенную область путем ее увеличения (то же самое делал бы распределитель в библиотеке C при помощи sbrk). В случае успешного расширения функция возвращает результат.
Все эти тривиальные случаи реализованы со сложностью O(1) (даже если учитывать затраты на вход в ядро — они будут меньше, поскольку прерывания больше не используются, но все равно будут).
А что в наихудшем случае?
Вот вызов move_vma:
Определение можно найти здесь: include/linux/mm_types.h. Эта небольшая структура содержит всю информацию об области: начальный и конечный адрес, файл на диске (если область памяти используется для отображения файла) и т. д.
Итак, эта операция перемещения достаточно проста — O(1).
А что делает функция move_page_tables?
Самое интересное, похоже, вот в этом цикле:
Этот код несколько сложноват (кроме того, нет комментариев), но в основном это базовые арифметические операции и расчеты.
Функция move_ptes содержит внутренний цикл самого нижнего уровня:
Так что же в этом цикле происходит?! Мы просто перемещаем строки таблицы страниц (PTE, Page Table Entries), соответствующие области памяти, в другое место. По сути, это целые числа, назначенные каждой странице.
Да, кстати, вы знаете, что O(N) во многих случаях сбивает с толку?
В нашем случае максимальным значением N является 2 48 (максимальный размер виртуального пространства). Большинство компьютеров работают лишь с несколькими гигабайтами памяти — не более 64 Гб для большинства архитектур (то есть 2 36 байт). Большая станица — это 2 21 байт, максимальное число операций составляет 2 15 для move_ptes (да, это всего лишь 32 768 операций).
Итак, в наихудшем случае затраты всегда крайне низкие, и я почему-то не сомневался в этом с самого начала.
Также рекомендую к прочтению: книгу Understanding the Linux Virtual Memory Manager Мела Гормана (Mel Gorman).
«Ниасилил многабукаф»? Не парьтесь. Лень и realloc — наше все.