Продолжаем наше знакомство с пакетной передачей в сетях мобильных операторов, которое мы с Вами начали в первой части о GPRS/EDGE технологиях. В этой статье речь пойдет о процессе аутентификации и авторизации, т.н. процедуре GPRS Attach, а также активирование услуги, запрошенной абонентом — поднятие PDP Context'а. Посмотрим какие данные хранятся на стороне SGSN'а, а какие на стороне абонента.
Ну, что ж поехали…
Я упущу некоторые процессы, непосредственно предшествующие и сопровождающие процедуру GPRS Attach, а конкретнее:
Если кого-то заинтересуют подробности, прошу задавать вопросы. Начнем мы сразу с процедуры GPRS Attach, позволяющей идентифицировать абонента, определить какие сервисы доступны абоненту, проверить легальность использования мобильного терминала абонента в сети оператора (процедура IMEI Check — опциональна) и собственно, предоставить абоненту возможность активировать услугу, которую он запрашивает.
Процесс аутентификации и авторизации, т.н. процедура GPRS Attach, изображен на схеме ниже (картинка кликабельна).
Вот собственно так происходит аутентификация и авторизация абонента, для предоставления передачи пакетных данных в сети оператора. После этой процедуры на терминале абонента появится буковка «G» (или «Е» :), сообщающая об успешном завершении подключения к пакетной сети, но это еще не позволит абоненту воспользоваться какой-либо услугой* в пакетной сети, т.к. необходимо еще активировать PDP Context по запрашиваемой услуге.
После успешного прохождения процедуры GPRS Attach, пользователь может активировать PDP Context, что позволит ему воспользоваться услугами пакетной передачи данных.
Сама процедура активации контекста, чем-то напоминает процедуру активации коммуникации при Dial-Up соединении. Давайте посмотрим на эти две процедуры в сравнении.
Упрощенно, процедуру активации линка Dial-Up можно представить в качестве схемы:
Теперь давайте посмотрим на принципиальную схему активации PDP Context'a:
Как видим, похожесть между двумя этими процедурами, состоит в применении одинаковых протоколов, довольны похожи сами этапы и процедуры, которые используются на этапах установления соединения, а также схожи ключевые узлы, участвующие в процессе установления коммуникации.
Определив ключевые моменты, при активации PDP Context'a, рассмотрим полную процедуру и определим, какие же данные передаются во время этой процедуры.
Схема активации PDP Context'a представлена на рисунке ниже:
После успешной процедуры активации PDP Context'a, на терминале пользователя буковка «G» (или «Е» :), обводиться квадратом и символизирует об использовании пакетной передачи данных.
Давайте разберемся, какие данные хранятся на стороне абонента, а какие на стороне SGSN'а до и после процесса аутентификации и авторизации в пакетной сети оператора.
Сводная таблица представлена ниже:
Небольшой помощник:
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
Я упущу некоторые процессы, непосредственно предшествующие и сопровождающие процедуру GPRS Attach, а конкретнее:
- выделение радиоресурсов
- обмен служебной информацией по логическим каналам между базовой станцией и терминалом абонента
- установление канала передачи данных
- изменение состояния терминала
Если кого-то заинтересуют подробности, прошу задавать вопросы. Начнем мы сразу с процедуры GPRS Attach, позволяющей идентифицировать абонента, определить какие сервисы доступны абоненту, проверить легальность использования мобильного терминала абонента в сети оператора (процедура IMEI Check — опциональна) и собственно, предоставить абоненту возможность активировать услугу, которую он запрашивает.
Процесс аутентификации и авторизации, т.н. процедура GPRS Attach, изображен на схеме ниже (картинка кликабельна).
- 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 — возможности терминала абонента в плане радиопередачи
- Identification Request
Если абонент находился до этого в зоне обслуживания другого SGSN'а, то при переходе к обслуживанию в новый SGSN, абоненту нет необходимости заново предоставлять всю информацию для своей идентификации, т.к. она будет запрошена с предыдущего элемента. В случае если абонента в это время пользовался услугами GPRS/EDGE, т.е. у него был открыт PDP Context, новый SGSN «заберет» абонента вместе с его сессией, без прерывания предоставления сервиса.
- Identity Request(Req)/Response(Res)
Эта процедура проводиться, для новых абонентов, либо для абонентов, данные о которых не были переданы (либо переданы не корректно) со старого SGSN'а, тогда SGSN запрашивает заново все данные от абонента, которые мы рассмотрели в процедуре Attach Request (вместо P-TMSI [Packet-TMSI], TMSI [Temporary Mobile Station Identity] обязательно запрашивается IMSI [International Mobile Subscriber Identity]).
- 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
- Authentication and Cyphering Req/Res
Значения полученные от HLR/AuC сохраняются на стороне SGSN'a, а к мобильному терминалу абонента передается значение числа RAND, на основании которого на стороне абонента «рассчитываются» значения — SRES и Kс, т.к. в SIM карте абонента «зашиты» алгоритмы шифрования А3/А5, а также секретное число Ki.
- Identity Check Request(Req)/Response(Res)
Эта процедура является опциональной и позволяет проверить легальность использования терминала абонента в сети оператора, т.е. производиться запрос IMEI кода терминала и его сравнение с базами Белых, Серых и Черных списков. Если абонент окажется в Черном списке, то ему уже на этом этапе будет отказано в обслуживании, но это все в теории. На практике выходит все наоборот, т.к. реально блокировка по черному списку все еще не работает (говорю за территорию Украины).
- Check IMEI Req/Res
Проверка IMEI на EIR, собственно на основании которой будет принято решение о легитимности использования терминала абонента в сети оператора.
- Location Update Procedures Req/Res
В процессе GPRS Attach процедуры происходит обновление информации о местоположении абонента, т.е. SGSN обновляет информацию в HLR, а затем HLR обновляет данные в MSC/VLR.
Если абонент совершает Combined Attach, то SGSN обновляет информацию об абоненте и в MSC/VLR - Attach Accept
После успешного выполнения всех вышеуказанных операций, SGSN сообщает абоненту, что GPRS Attach принят и абонент теперь может воспользоваться услугами пакетной передачи данных в сети оператора.
- 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 представлена на рисунке ниже:
- Activate PDP Context Request
В этом запросе передается довольно много различных данных, нас же больше будут интересовать следующие:
- QoS requested — запрашиваемый профиль обслуживания абонента, качественные характеристики соединения, если же это поле будет пустым, то решение о назначенном профиле примет SGSN
- PDP type — определяет, какой тип протокола будет использован терминалом, для определенного сервиса IP/X.25/etc.
- Address — тип адреса, выдаваемый абоненту для коммуникации в сети [IPv4, IPv6, auto]
- APN* [Access Point Name] — имя точки доступа, определяющие адрес GGSN'а, который будет обслуживать сессию пользователя.
* — более детально про выбор и использование APN в процессе активации контекста, можно прочитать в статье: «Не важно кто ты… важно какая у тебя APN»
- 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 сетей).
- Create PDP Context Req/Res
Все собранные данные от авторизированного пользователя, включая запросы на выдачу IP адреса, IMSI, MSISDN, APN (в случае доступа к внутренней сети, например) передаются специальным запросов [Create PDP Context Request] на GGSN. По этому событию открывается биллинговая запись на сессию абонента.
- 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 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
Ссылки по теме (en):
