Продолжаем наше знакомство с пакетной передачей в сетях мобильных операторов, которое мы с Вами начали в первой части о GPRS/EDGE технологиях. В этой статье речь пойдет о процессе аутентификации и авторизации, т.н. процедуре GPRS Attach, а также активирование услуги, запрошенной абонентом — поднятие PDP Context'а. Посмотрим какие данные хранятся на стороне SGSN'а, а какие на стороне абонента.
Ну, что ж поехали…

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 абонента соответствует определенная контрольная сумма/секретное число — K_i, также на стороне HLR/AuC есть рандомный генератор, который формирует случайное число для нашего запроса. Затем формируется, т.н. триплет [TRIPLETS = RAND + SRES (Signed Response) + K_с] данных, который состоит из:
   
   • RAND — случайное число
   • SRES — результат, «прогонки» случайного числа RAND через алгоритм А3
   • K_с — результат, «прогонки» числа K_i через алгоритм А5
   Затем триплет данных отправляется на SGSN.
   
5. Authentication and Cyphering Req/Res
   Значения полученные от HLR/AuC сохраняются на стороне SGSN'a, а к мобильному терминалу абонента передается значение числа RAND, на основании которого на стороне абонента «рассчитываются» значения — SRES и K_с, т.к. в SIM карте абонента «зашиты» алгоритмы шифрования А3/А5, а также секретное число K_i.
   
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 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):

• GPRS attach
• GSM/GPRS Sequence Diagrams