19,2k 5

КАК СТАТЬ АВТОРОМ 90 аватарок украдено Мегапосты: Инсайдер Microsoft Agile без шелухи Artefact для музеев

WIBAttack. Так ли страшна новая

Все потоки Разработка Администрирование Дизайн Менеджмент Маркетинг Научпоп уязвимость SIM-карт
Войти Регистрация

13,8k 6

TyMaH 4 февраля 2010 в 10:19

В чипах Intel найдена потенциально
GPRS изнутри. Часть 2 уязвимая функция
2k 3
Чулан

Пробуем Smart Response на зуб

Продолжаем наше знакомство с пакетной передачей в сетях мобильных операторов, которое мы с
98,7k 30
Вами начали в первой части о GPRS/EDGE технологиях. В этой статье речь пойдет о процессе
аутентификации и авторизации, т.н. процедуре GPRS Attach, а также активирование услуги,
запрошенной абонентом — поднятие PDP Context'а. Посмотрим какие данные хранятся на стороне
Подкаст: Build 2020 глазами инсайдера
— ИИ, суперкомпьютеры, нейросети и
SGSN'а, а какие на стороне абонента.
Linux на Windows
Ну, что ж поехали…
Мегапост

GPRS Attach
Редакторский дайджест
Я упущу некоторые процессы, непосредственно предшествующие и сопровождающие процедуру GPRS Присылаем лучшие статьи раз в месяц
Attach, а конкретнее:
выделение радиоресурсов Электропочта

обмен служебной информацией по логическим каналам между базовой станцией и терминалом

абонента

установление канала передачи данных

изменение состояния терминала

Реклама
Если кого-то заинтересуют подробности, прошу задавать вопросы. Начнем мы сразу с процедуры GPRS
Attach, позволяющей идентифицировать абонента, определить какие сервисы доступны абоненту,
проверить легальность использования мобильного терминала абонента в сети оператора (процедура
IMEI Check — опциональна) и собственно, предоставить абоненту возможность активировать услугу,
которую он запрашивает.

Процесс аутентификации и авторизации, т.н. процедура GPRS Attach, изображен на схеме ниже
(картинка кликабельна).

1. Attach Request
Процедура GPRS Attach начинается с запроса абонента со своего мобильного терминала,
GPRS/EDGE сервиса (либо когда абонент выбирает на аппарате постоянное подключение к
пакетной сети: Меню -> Настройки -> Подключение устройств -> Пакетные данные -> Пакетное
подключение -> По требованию/Постоянный доступ), т.е. открытие мобильного браузера/проверка
почты/попытка отправить MMS/etc., что в свою очередь инициирует отправку запроса Attach
Request, если абонент был до этого еще не подключен к пакетной сети оператора. В случае если
абонент собирается подключиться к сети впервые, то в запросе будут присутствовать следующие
основные данные:

Attach type: GPRS Attach (подписка только на пакетную передачу данных), IMSI attach (подписка
только на голосовые услуги, если абонент регистрируется для совершения/принятия голосовых
услуг), Combined Attach (комбинированная подписка = голос + пакетные данные)

P-TMSI (замена IMSI, в случае если абонент уже «известен» SGSN'у)

RAI = MCC + MNC + LAC + RAC, т.е. координаты абонента в пределах подсети базовых станций

RAI — Routing Are Identity

MCC — Mobile Country Code (международный код страны)
MNC — Mobile Network Code (международный код оператора в пределах страны)
LAC — Location Area Code (совокупность базовых станций, объединенных одним кодом)
RAC — Routing Area Code (зона, меньшая, либо равная LAC)

MS network capability — возможности терминала абонента в плане передачи данных

MS radio access capability — возможности терминала абонента в плане радиопередачи

2. Identification Request
Если абонент находился до этого в зоне обслуживания другого SGSN'а, то при переходе к
обслуживанию в новый SGSN, абоненту нет необходимости заново предоставлять всю
информацию для своей идентификации, т.к. она будет запрошена с предыдущего элемента. В
случае если абонента в это время пользовался услугами GPRS/EDGE, т.е. у него был открыт PDP
Context, новый SGSN «заберет» абонента вместе с его сессией, без прерывания предоставления
сервиса.

3. Identity Request(Req)/Response(Res)
Эта процедура проводиться, для новых абонентов, либо для абонентов, данные о которых не были
переданы (либо переданы не корректно) со старого SGSN'а, тогда SGSN запрашивает заново все
данные от абонента, которые мы рассмотрели в процедуре Attach Request (вместо P-TMSI [Packet-
TMSI], TMSI [Temporary Mobile Station Identity] обязательно запрашивается IMSI [International Mobile
Subscriber Identity]).

4. Send Authentication Info Req/Res

В процессе этой процедуры, SGSN на основании IMSI абонента, производит запрос в HLR/AuC,
который представляет собой базу данных об абонентах сети оператора. На стороне HLR/AuC, IMSI
абонента соответствует определенная контрольная сумма/секретное число — Ki, также на стороне
HLR/AuC есть рандомный генератор, который формирует случайное число для нашего запроса.
Затем формируется, т.н. триплет [TRIPLETS = RAND + SRES (Signed Response) + Kс] данных, который
состоит из:

RAND — случайное число

SRES — результат, «прогонки» случайного числа RAND через алгоритм А3

Kс — результат, «прогонки» числа Ki через алгоритм А5

Затем триплет данных отправляется на SGSN.

5. Authentication and Cyphering Req/Res

Значения полученные от HLR/AuC сохраняются на стороне SGSN'a, а к мобильному терминалу
абонента передается значение числа RAND, на основании которого на стороне абонента
«рассчитываются» значения — SRES и Kс, т.к. в SIM карте абонента «зашиты» алгоритмы
шифрования А3/А5, а также секретное число Ki.

6. Identity Check Request(Req)/Response(Res)

Эта процедура является опциональной и позволяет проверить легальность использования
терминала абонента в сети оператора, т.е. производиться запрос IMEI кода терминала и его
сравнение с базами Белых, Серых и Черных списков. Если абонент окажется в Черном списке, то
ему уже на этом этапе будет отказано в обслуживании, но это все в теории. На практике выходит
все наоборот, т.к. реально блокировка по черному списку все еще не работает (говорю за
территорию Украины).

7. Check IMEI Req/Res

Проверка IMEI на EIR, собственно на основании которой будет принято решение о легитимности
использования терминала абонента в сети оператора.

8. Location Update Procedures Req/Res

В процессе GPRS Attach процедуры происходит обновление информации о местоположении
абонента, т.е. SGSN обновляет информацию в HLR, а затем HLR обновляет данные в MSC/VLR.
Если абонент совершает Combined Attach, то SGSN обновляет информацию об абоненте и в
MSC/VLR

9. Attach Accept
После успешного выполнения всех вышеуказанных операций, SGSN сообщает абоненту, что GPRS
Attach принят и абонент теперь может воспользоваться услугами пакетной передачи данных в сети
оператора.

10. TMSI Realocation Complete

Окончательным этапов является обновление/уведомление MSC/VLR о новом значении TMSI,
назначенного абоненту.

Вот собственно так происходит аутентификация и авторизация абонента, для предоставления передачи
пакетных данных в сети оператора. После этой процедуры на терминале абонента появится буковка «G»
(или «Е» :), сообщающая об успешном завершении подключения к пакетной сети, но это еще не
позволит абоненту воспользоваться какой-либо услугой* в пакетной сети, т.к. необходимо еще
активировать PDP Context по запрашиваемой услуге.

* — после успешной процедуры 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 представлена на рисунке ниже:

1. Activate PDP Context Request

В этом запросе передается довольно много различных данных, нас же больше будут интересовать
следующие:

QoS requested — запрашиваемый профиль обслуживания абонента, качественные

характеристики соединения, если же это поле будет пустым, то решение о назначенном
профиле примет SGSN

PDP type — определяет, какой тип протокола будет использован терминалом, для
определенного сервиса IP/X.25/etc.

Address — тип адреса, выдаваемый абоненту для коммуникации в сети [IPv4, IPv6, auto]

APN* [Access Point Name] — имя точки доступа, определяющие адрес GGSN'а, который будет
обслуживать сессию пользователя.

* — более детально про выбор и использование APN в процессе активации контекста,

можно прочитать в статье: «Не важно кто ты… важно какая у тебя APN»

2. DNS Query/Response
Получив от абонента в запросе конкретную APN, SGSN сформирует полный адрес, добавив к APN,
т.н. GOI [GGSN Operator Identifier], полный адрес будет иметь примерно такой вид:

internet.mnc009.mcc255.gprs, где

internet — APN, прописанная в терминале абонента,

mnc009.mcc255.gprs — GOI некоторого виртуального оператора (Украина).

Затем, формируется запрос к локальному DNS серверу оператора, результатом которого будет IP
адрес(а) GGSN'ов, которые предоставляют пользователю запрашиваемую услугу.
В случае если локальный DNS сервер не может «распознать» полный адрес (допустим, для
роумингового абонента), то запрос перенаправляется в DNS серверу высшего уровня (здесь, все
очень похоже на структуру IP сетей).

3. Create PDP Context Req/Res

Все собранные данные от авторизированного пользователя, включая запросы на выдачу IP адреса,
IMSI, MSISDN, APN (в случае доступа к внутренней сети, например) передаются специальным
запросов [Create PDP Context Request] на GGSN. По этому событию открывается биллинговая запись
на сессию абонента.

4. Activate PDP Context Accept

В ответном сообщении, которое направляется терминалу абонента содержится все необходимая
информация для завершения активации PDP Context'a. Этим сообщением пользователю
назначается определенный IP адрес в сети оператора, согласовываются профили обслуживания, а
также начинается предоставление запрошенной услуги.

После успешной процедуры активации PDP Context'a, на терминале пользователя буковка «G» (или «Е»
:), обводиться квадратом и символизирует об использовании пакетной передачи данных.

Information stored before/after GPRS Attach

Давайте разберемся, какие данные хранятся на стороне абонента, а какие на стороне SGSN'а до и после
процесса аутентификации и авторизации в пакетной сети оператора.
Сводная таблица представлена ниже:

MS SGSN HLR

Before GPRS Attach IMSI IMSI

MSISDN MSISDN
RAI Ki
Ki QoS profile
QoS profile

After GPRS Attach PMM State PMM State SGSN address

P-TMSI P-TMSI
MSISDN
RAI
Kc
QoS profile

Небольшой помощник:

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

Ссылки по теме (en):

GPRS attach

GSM/GPRS Sequence Diagrams

Теги: GPRS, GSM, mobile internet, mobile, мобильный интернет, мобильная связь, PS Core Network

Хабы: Чулан

+23 101 25,2k 67 Поделиться

Гуляев Борис @ TyMaH

Product Manager

ПОХОЖИЕ ПУБЛИКАЦИИ

26 января 2018 в 13:30

Как создатели Speedtest оценивают мобильный интернет в России

+18 13,7k 10 23

22 января 2015 в 09:46

We Are Social: интернет, мобильная связь и социальные сети в 2015

+17 11,2k 17 2

25 января 2010 в 10:44

GPRS изнутри. Часть 1

+67 24,9k 144 86

КУРСЫ

Веб-аналитик
27 июня 2020 • 18 недель • 22 495 ₽ • GeekBrains

SEO-специалист
29 июня 2020 • 4 месяца • 34 900 ₽ • Нетология

Android-разработчик (базовый курс)

29 июня 2020 • 5 месяцев • 70 000 ₽ • OTUS

Профессия Андройд разработчик с нуля

29 июня 2020 • 7 месяцев • 79 900 ₽ • Нетология

Android-разработчик. Продвинутый курс

29 июня 2020 • 5 месяцев • 60 000 ₽ • OTUS

Больше курсов на Хабр Карьере

18+ ₽

Русская стратегия 2020

Эта игра прокачивает стратегическое мышление

ПОДРОБНЕЕ TRIUMPH.TOTALBATTLE.COM

Реклама

Комментарии 67 ЧТО ОБСУЖДАЮТ

MadManx 4 февраля 2010 в 10:27 +1 Сейчас Вчера Неделя

спасибо…
НЛО прилетело и оставило этот пост
здесь
3,2k 117
AddRemover 4 февраля 2010 в 10:45 0

Спасибо за подробную статью! Нетбуки: забытый временем форм-

Пожалуйста, сделайте все картинки кликабельными. фактор
8,2k 41

TyMaH 4 февраля 2010 в 10:55 +1 PHP — какая ниша у языка и поможет

Поправил… ли PHP8 решить насущные проблемы
(спойлер: имхо нет)
15,8k 218

eucariot 4 февраля 2010 в 11:55 0

Как научиться программировать на
Спасибо. Не всё удалось понять — нужно садиться разбираться. Java: почему стоит и где начать
Если собрать с хабра все статьи такой тематики и систематизировать, получится небольшой учебник по
различным беспроводным технологиям. 7,2k 12

Agile для банка: кейс о том, как

выстроить ИТ-подразделение
TyMaH 4 февраля 2010 в 11:59 0
Мегапост
Спрашивайте, вместе разберемся )

eucariot 4 февраля 2010 в 12:02 +3

Да не, не люблю я как только появится вопрос, задавать его. Сам посижу)

reagent 4 февраля 2010 в 12:15 +2

Было бы еще очень интересно почитать, как работает активация ПДП-контекста в роуминге. Насколько мне
известно, там немножко по другому все работает.

TyMaH 4 февраля 2010 в 12:19 +1

Да там есть несколько различий, в основном касающихся определения IP адреса «домашнего» GGSN'a,
вопросов биллинга, взаимодействия сетей операторов через GRX (GRPS Roaming eXchange)…
Ок, заявка принята :)

AndryX 4 февраля 2010 в 15:30 +1

А мне бы было интересно почитать про прослушку мобильников в домашних условиях, сбор устройства и т.п.
=)

TyMaH 4 февраля 2010 в 15:39 +1

Могу посоветовать довольно не плохой сайт с описание многих моментов в GSM архитектуре, в том числе
и по поводу прослушки.

reagent 4 февраля 2010 в 15:50 0

как раз хотел предложить сайт Адепта :)

reagent 4 февраля 2010 в 15:50 +1

вряд ли кто-то тебе об этом в публичном доступе напишет.

Хотя, насколько мне технических познаний хватает, то метод фейковой соты весьма несложно
реализовать. Стоимость решения приближается к 4-5 тысячам американских убитых президентов.

TyMaH 4 февраля 2010 в 15:53 0

Реализовать-то может и не сложно, а как с ней бегать за самим абонентом? :)

reagent 4 февраля 2010 в 16:00 0

если не пико- фемто- БС использовать, то можно вполне спокойно в радиусе 1-го километра ездить
на небольшом фургончеге :)

TyMaH 4 февраля 2010 в 16:03 0

Да, но при этом мощность Вашей соты должна быть больше всех окружающих абонента… а еще
вопросы питания самой фейксоты, Ваша защита от излучения, незаметный фургончик… :)

reagent 4 февраля 2010 в 16:12 +1

поэтому оптимально для стационарных малоперемещающихся пользователей — 2-3

фемтосоты в дипломатах, если нужно кого-то, кто перемещается, слушать, то тогда уже
фургончег...:)

DeSh 4 февраля 2010 в 20:11 0

Все эти рассуждения на уровне домыслов. С ходу дам Вам несколько мыслей:
Если стоит задача собрать компромат либо это ОРМ, то сомневаюсь, что Вы будете
прослушивать слесаря Васю и его разговоры о том, где достать чекушку. А значит будут и
средства, направленные против прослушки.
Например, неужели Вы думаете, что Ваш мощный источник высоко частотного сигнала
останется не замеченным?
Ваша фемто-сота должна быть не тупой железкой, а устройство с набором логики, чтобы
организовать связь между подставной сотой и контроллером.
Насколько долго Вам хватит источника питания, для запитывания подставной БТС?
Хранилище, куда Вы будете сливать весь кодированный поток в A5/1, для последующего его
анализа?

reagent 5 февраля 2010 в 10:22 +1

при ОРМ иногда нет возможности узнать номер того, кого надо слушать и нет
возможности оперативно использовать СОРМ (тк на это нужно время).
Сигнал от фемтосоты не столь уж и большой, чтобы быть замеченным сразу да и время
для реагирования частотных органов нужно.
фемтосоты, которые используются в таких штуках это не тупые железка, а устройства с
ждовольно неплохой логикой.
касательно источника питания, то все опять таки зависит от условий (соту можно
закамуфлировать, использовать соту в фургоне.
Со стораджем то же, что и с устройствами питания (винты нынче емкие, небольшие и
недорогие)

DeSh 5 февраля 2010 в 12:53 +1

>Сигнал от фемтосоты не столь уж и большой, чтобы быть замеченным сразу да и

время для реагирования частотных органов нужно.

Но все-таки он должен быть довольно мощным, чтобы в результате cell reselection

зацепиться за нее, правильно?

>фемтосоты, которые используются в таких штуках это не тупые железка, а устройства

с ждовольно неплохой логикой.

Да, но сомнительно, что они могут делать то, о чем идет в разговоре — т.е. для того,
чтобы пропустить трафик через себя, она должна уметь:
1)Брать управляющую сигнализацию, дальше гнать ее на BSC — вы согласны, что если
она этого делать не будет, то и никакого разговора не будет? :)
2)В момент выделения канала TRH писать весть трафик, проходящий через него.

DeSh 4 февраля 2010 в 19:28 0

Как раз реализовать не просто и сложно:

1)Организация соединения микро-бтс с BSC.
2)Невозможность доставить входящий вызов абоненту, находящемуся в зоне действия данной БТС,
по причине невозможности осуществить paging
3)Декодирование A5/1 на лету либо полное его отключение, что заметно на терминале
4)И самое простое — залочка терминала абонента, например с помощью FTA на правильный канал :)

DeSh 4 февраля 2010 в 19:28 0

4)Блин, имел ввиду FTD

reagent 5 февраля 2010 в 10:12 +1

1. Не нужно. Для выходного канала для звонков может использоваться SIP, либо GSM-gateway
2. Энто да… но есть возможность немножко поиграться (с помощью веб-интерфейса кабинета
управления услугами для абонента) и установить переадресацию на номер карточки в GSM-
gateway
3. это уже другой метод. Его тоже не так то им сложно реализовать.

DeSh 5 февраля 2010 в 12:55 0

3)Вы читали недавние материалы по декодированию? Как раз там все глухо :)

DeSh 5 февраля 2010 в 13:21 0

Т.е. Вы хотите сказать, что данная пикосота будет:

1)вычленять из трафика, идущего по Um интерфейсу, CC Setup message, который содержит
called party number.
2)Конвертить Circuit-switched в packed-switched, при этом конвертирую все это дело в SIP и
гнать на шлюз, у которого есть выход на внешние сети.
Прошу заметить, что 1 пункт происходит при ciphering on (т.е. к этому времени радиотракт
уже кодирован).
Вам не кажется это, по крайней мере, трудно выполнимой задачей :) А я скажу, что
малореальной :) Особенно пукт 1 :)

DeSh 5 февраля 2010 в 13:23 0

А. ну и понятное дело, все те же самые процедуры, только в обратную сторону от шлюза, к

пикосоте, дальше к ME.
Имхо, БРЕД! :)

DeSh 4 февраля 2010 в 19:32 +1

Короче, хотел сказать, что кому надо, те слушают уже декодированный канал за радиочастью.
Ну сам знаешь, СОРМ и все такое :)

reagent 5 февраля 2010 в 10:09 +1

как ни странно, но догадываюсь

DeSh 4 февраля 2010 в 19:36 0

А, кстати, тут подумалось, что возможно предполагалось, что БТС будет, как бы ретранслировать
данные между ME и подлинной BTS, предварительно забивая подлинный сигнал. Но, ИМХО, все
это сложно :)

reagent 5 февраля 2010 в 10:23 +1

это, имхо, не совсем реально

AndryX 4 февраля 2010 в 17:09 0

А нет способов снифинга, как это делается с WiFi? Чтобы можно было перепаять пару моб. тебефонов в
прослушивающее устройство? :)

Я такой идеалист…

reagent 4 февраля 2010 в 17:13 +2

даже если у Вас есть возможность снифить радиоэфир в нужном диапазоне и снимать с него сигналы
(это уже, как минимум, устройство от 2к усд), то нужно еще дешифровать поток GSM данных. Пока
это практически невозможно. Посмотрите в users.livejournal.com/_adept_/ там в нескольких
последних постов по поводу этого кое что есть.

AndryX 4 февраля 2010 в 17:15 0

Насколько помню в странах СНГ используется более слабый алгоритм шифрования, или это
только теоретически?

reagent 4 февраля 2010 в 17:23 +1

Комментировать не буду. Такие вопросы уже граничат с конфиденциальной информацией

оператора сотовой связи, а мне моя работа еще дорога…
Хотя даже если у оператора траффик абонента, которого Вы будете снифать, установлен более
слабый механизм шифрования, Вы все равно не сможете в режиме реального времени
декодировать и соответственно слушать звонки.

reagent 4 февраля 2010 в 17:26 0

кроме того, информацией по поводу типов шифрования на сетях операторов сотовой связи,
я не обладаю, поскольку немного другими вещами занимаюсь

AndryX 4 февраля 2010 в 20:31 0

Об этом недавно писали на хабре, жаль не помню где.

А почему цена прослушивающего устройства столь высока? Мы же нацеливаемся на

определённого абонента, нельзя использовать стандартную антену моб. телефона или не
слишком сложное устройство ручной сборки?

TyMaH 5 февраля 2010 в 11:01 0

По-моему текущий алгоритм шифрования можно посмотреть в том же Netmonitor'e… или

я ошибаюсь, просто сейчас нет под рукой аппарата с Netmonitor'ом.

DeSh 5 февраля 2010 в 12:57 0

Можно, хотел скриншот сделать, но не работает софтина под симбиан. В момент

разговора отображается алгоритм.

DeSh 4 февраля 2010 в 20:16 0

Ничего сверх-секретного, все есть в открытом доступе на той же википедии

reagent 5 февраля 2010 в 11:53 0

алгоритм, который используется конкретным оператором, это закрытая информация

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

DeSh 5 февраля 2010 в 12:58 0

Смотрите выше. У всех Украинских опсосов радиоинтерфейс кодируется именно им! :)

Netmonitor Вам подтвердит :)

Kastrulya 4 февраля 2010 в 15:59 0

познавательно)

Mirowind 4 февраля 2010 в 16:07 0

Пользуясь тематикой статьи…

После года использования GPRS дома (максимальная зафиксированная скорость была 15 кб/сек, средняя 6
кб/сек), я купил CDMA модем. 250-300 кб/сек… Господа, вот оно, счастье! :)

За статью спасибо, достаточно информативно.

eucariot 5 февраля 2010 в 05:19 +1

6 кбит/с? Думаю, это не совсем проблема GPRS. А вообще согласен. Сам с GPRS на CDMA перешёл. Много
где в городе больше мегабита показывает. А там где я живу 10-15 кБ/с. Одно слово: Скайлинк.

anjolio 4 февраля 2010 в 19:22 +1

Значения полученные от HLR/AuC сохраняются на стороне SGSN'a, а к мобильному терминалу абонента

передается значение числа RAND, на основании которого на стороне абонента «рассчитываются»
значения — SRES и Kс, т.к. в SIM карте абонента «зашиты» алгоритмы шифрования А3/А5, а также
секретное число Ki.

Здесь, кстати особенно важно, что в радиоэфире ключ Ki никогда не передаётся и именно за ним охотятся
клонировщики SIM-карт.

reagent 5 февраля 2010 в 10:29 0

а сейчас уже и не вычисляется брутфорсом для новых типов карт, коих сейчас 90%.

TyMaH 5 февраля 2010 в 11:23 0

Я бы уточнил, что обычно клонировщики «охотятся» за парой значений: IMSI и Ki

reagent 5 февраля 2010 в 11:56 +2

IMSI можно и подсмотреть…

TyMaH 5 февраля 2010 в 12:32 0

Ты имеешь в виду с аппарат или за пределами BTS? )

anjolio 5 февраля 2010 в 12:40 0

Иногда пейджинг осуществляется по IMSI, это какие-то ненормальные случаи, но я такое встречал
и видел чужие IMSI в TEMS'е.

TyMaH 5 февраля 2010 в 12:53 0

Ну так пейджинг по новому абоненту и будет по IMSI.

reagent 5 февраля 2010 в 17:18 +1

имел в виду с апарат

anjolio 4 февраля 2010 в 19:30 0

Ещё меня всегда интересовали некоторые вещи связанные с PDP-context'ами:

1. Насколько реально в GPRS используется QoS, как он определяется на стороне телефона? Если используется,
то насколько часто GGSN его удовлетворяет? Просто у меня такое ощущение, что QoS всегда один в GPRS.
Здесь, кстати, вопрос больше не к автору статьи, наверное, а к разработчикам ПО для мобильных телефонов
— есть ли в тулкитах какие-то функции, которые при запросе активации соединения ещё могут отправить
желаемый QoS?

2. Насколько часто случаются глюки с IntraSGSN cell reselect'ами? У меня на практике, когда ездишь по Москве
часто случается так, что перестаёт работать GPRS, после закрытия всех приложений и нового открытия их всё
возвращается на круги своя. Я это связываю с тем, что я перехожу из зоны действия одного SGSN в зону
действия другого и между ними глючно PDP-context'ы передаются… Насколько оправданы мои догадки?

anjolio 4 февраля 2010 в 19:33 0

3. Ещё такой вопрос — вот я запускаю аську и браузер на телефоне. У меня для каждого приложения свой
PDP-context создаётся, или же они по одному работают?

reagent 5 февраля 2010 в 10:24 +1

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

TyMaH 5 февраля 2010 в 11:34 +1

Для каждого приложения может создаваться свой PDP Context, при этом количество одновременно
открытых контекстов может ограничиваться как возможностями терминала абонента, так и на стороне
SGSN'a. Среднестатистическое значение на стороне SGSN'a — 10-15 (для оптимальной нагрузки).

TyMaH 5 февраля 2010 в 11:47 +1

Давайте по-порядку…
1. Профили довольно часто испльзуются при активировании сессий, значения передаются при GPRS
Attach'e, но также могут быть заменены на другие на стороне SGSN'a. Выбором профиля можно частично
«регулировать» качество предоставляемой услуги.

2. Здесь все зависит от того как работает локальный DNS сервер оператора, т.к. в GPRS/EDGE сетях, даже
при смене соты происходит т.н. Routing Area Update [RAU], в том числе и при IntraSGSN Update, т.е. есть
некое соответствие комбинации racxxx.lacyyy.mncaaa.mccbbb.gprs и юнита в SGSN'e, который в данный
момент обслуживает пользовательскую сессию (обычно этот юнит имеет IP адрес в пределах IP Backbone
оператора).
И при RAU, новый/старый SGSN, получая новое местоположение абонента
(racxxx.lacyyy.mncaaa.mccbbb.gprs), делает DNS запрос на локальный сервер оператора, получая в ответ IP
адрес нового юнита (в старом или новом SGSN'e) для перенаправления PDP Context'a абонента, и
естественно если при запросе, SGSN не получит ответ от сервера, то ему «придется» заново проводить
аутентификацию и авторизацию абонента и открывать новый контекст.
Так, что Ваше догадки не лишены смысла…
Есть еще такие понятия для KPI показателей по GPRS/EDGE архитектуре, как Intra SGSN RA Successful
Rate/Inter SGSN RA Successful Rate, приемлемые значение которых порядка 95% и выше, вот собственно по
этим показателям и судят об успешных RAU как внутри одного SGSN'a, так и между различными SGSN'ами.

nAggOHOK 4 февраля 2010 в 20:31 +1

Спасибо.
Не могли бы прояснить про Network Operating Mod —
«GPRS network 130 can be designed to operate in three network operation modes (NOM1, NOM2 and NOM3). A network
operation modes of a GPRS network is indicated by a parameter in system information messages transmitted within a cell.
The system information messages dictates a MS where to listen for paging messages and how signal towards the network.
The network operation mode represents the capabilities of the GPRS network. In a NOM1 network, a MS can receive pages
from a circuit switched domain (voice call) when engaged in a data call. The MS can suspend the data call or take both
simultaneously, depending on the ability of the MS, In a NOM2 network, a MS may not received pages from a circuit
switched domain when engaged in a data call, since the MS is receiving data and is not listening to a paging channel In a
NOM3 network, a MS can monitor pages for a circuit switched network while received data and vise versa. „

Очень интересует описание ввиду возникшей проблемы

TyMaH 5 февраля 2010 в 12:07 0

Давай те я просто включу, описание про NOM в статье про Gs интерфейс, т.к. ответ постом получиться
довольно большим :)

malferov 5 февраля 2010 в 01:23 +1

Часто слышу жалобы, мол, во время GPRS-сессии мне никто не может дозвониться/отправить SMS.

Интересно, имеется ли возможность произвести такие настройки оборудования, чтобы во время

непосредственно приема/передачи GPRS-данных удавалось принять входящий вызов или SMS (over GSM),
прекратив (поставив «на паузу») прием/передачу в GPRS-сети (если телефон одновременно может работать
только в одной сети — либо GSM, либо GPRS)?

DeSh 5 февраля 2010 в 01:57 +1

>Часто слышу жалобы, мол, во время GPRS-сессии мне никто не может дозвониться/отправить SMS.
Да, для этого имеется интерфейс между MSC/VLR и SGSN, в котором используется BSSAP+ протокол. Когда
этот интерфейс создан, то есть возможность осуществлять paging во время активной GPRS-сессии

DeSh 5 февраля 2010 в 02:01 0

Кстати, об этом кратко упоминалось в первой статье TyMaH'а

TyMaH 5 февраля 2010 в 12:21 0

Это вопрос я раскрою более подробно в статье об интерфейсе Gs.

eucariot 5 февраля 2010 в 05:15 0

Вот что хочу спросить: иногда в транспорте загрузка страницы прекращается и пока не запустишь снова, так и
стоит. Это связано с перемещением между БС?

reagent 5 февраля 2010 в 10:32 0

очевидно, что да.

TyMaH 5 февраля 2010 в 13:16 0

Скорее всего, что да… но может быть из-за повышенной нагрузки на одной соте.

eucariot 31 мая 2012 в 08:53 +1

Спасибо тебе, Борис, прошло 2 года и мне чертовски понадобилась твоя статья по работе)

TyMaH 31 мая 2012 в 10:25 0

Рад, что материал оказался полезным.

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

САМОЕ ЧИТАЕМОЕ РЕКОМЕНДУЕМ Разместить

Сутки Неделя Месяц

Не хочу Visual Studio Code: 7 open source альтернатив

+20 24,1k 73 126
Промо

Путин одобрил меру о бессрочном снижении налога на прибыль для IT-компаний с 20% до 3%
Когда щедр на маски, потому что
+40 15,3k 11 102 экономишь с промокодом

Ликбез про электронные трудовые книжки

+23 16,2k 65 70

Segway сворачивает производство электроциклов. Их признали слишком надежными

+21 11,9k 3 57 Мегапост

Подкаст: Build 2020 глазами инсайдера — ИИ, суперкомпьютеры, нейросети и Linux на Windows AR в музее глазами разработчика,
аналитика, домохозяйки
Мегапост

Ваш аккаунт Разделы Информация Услуги

Войти Публикации Устройство сайта Реклама

Регистрация Новости Для авторов Тарифы

Хабы Для компаний Контент

Компании Документы Семинары

Пользователи Соглашение Мегапроекты

Песочница Конфиденциальность

Если нашли опечатку в посте, выделите ее и нажмите Ctrl+Enter, чтобы сообщить автору.

© 2006 – 2020 «TM» Настройка языка О сайте Служба поддержки Мобильная версия