Pull to refresh

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

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


GPRS Attach

Я упущу некоторые процессы, непосредственно предшествующие и сопровождающие процедуру GPRS Attach, а конкретнее:
  • выделение радиоресурсов
  • обмен служебной информацией по логическим каналам между базовой станцией и терминалом абонента
  • установление канала передачи данных
  • изменение состояния терминала

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

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

image

  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 можно представить в качестве схемы:

image

Теперь давайте посмотрим на принципиальную схему активации PDP Context'a:

image

Как видим, похожесть между двумя этими процедурами, состоит в применении одинаковых протоколов, довольны похожи сами этапы и процедуры, которые используются на этапах установления соединения, а также схожи ключевые узлы, участвующие в процессе установления коммуникации.

Определив ключевые моменты, при активации PDP Context'a, рассмотрим полную процедуру и определим, какие же данные передаются во время этой процедуры.

Схема активации PDP Context'a представлена на рисунке ниже:

image

  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):
Tags:
Hubs:
Total votes 27: ↑25 and ↓2+23
Comments67

Articles