ПРИМЕРЫ ПРОЦЕДУР
Хеши Кааранен, Ари Ахтианен, Сымек Найян
(Heikki Kaaranen, Ari Ahtiainen, Siamak Naghian)
Чтобы дать читателю общее представление о некоторых наиболее важных функциональных возможностях мобильной универсальной системы UMTS, рассмотренных в предыдущих главах, в данной главе приведено несколько примеров работы системы UMTS. Эти примеры иллюстрируют, каким образом координируются операции, выполняемые всеми элементами сети, а также показывают роль протоколов UMTS в управлении операциями.
11.1. Элементарные процедуры
В настоящей главе представлена базовая модель последовательности проведения действий при интенсивном обмене информацией в масштабе всей системы. Понятие операции используется, чтобы подчеркнуть то обстоятельство, что эти системные процедуры выполняются до успешного установления соединения, а последующие процедуры представляют достаточно независимые действия по обмену информацией.
Иерархическая структура и взаимодействие протоколов, описанных в главе 10, позволяют нам представить набор элементарных процедур, которые можно использовать в качестве строительных блоков при планировании сетевых операций. Как известно, в зависимости от вида операций (исходящие или входяшие вызовы), состав и параметры элементарных процедур могут изменяться, а некоторые элементарные процедуры могут вообще не использоваться.
Модель взаимодействия протоколов UMTS (см. рис. 10.4) полезна здесь в том смысле, что различные процедуры используют различные уровни в сети UMTS. Транспортная сеть используется в каждой процедуре: всегда требуется передача сигналов управления и многие операции предполагают транспортировку данных пользователя. Функции радиосети необходимы всякий раз, когда в пределах элементарной процедуры используется сеть доступа. Общее управление действиями системы производится в соответствии с системой сетевых протоколов, которые активизируют элементарные процедуры в пошаговом режиме и определяют, какие операции выполняются на разных этапах.
Рис. 11.1. Базовая модель операций сети UMTS
В принципе любые действия сети можно разделить на восемь шагов, представленных на рис. 11.1, На каждом этапе можно выделить элементарные процедуры.
Поиск (пейджинг) — это одна из процедур поддержания мобильности ММ, которая используется при поиске заданного абонента в зоне покрытия сети. Эти действия выполняются только тогда, когда запрос инициирует сеть. Остальные семь шагов одинаковы, независимо от того, какая это операция — исходящего или входящего соединения UE.
Управление установлением радиосоединения RRC — это элементарная процедура по организации радиоканала управления между оконечным оборудованием UE и сетью радиодоступа RAN, которая включает и операции и последовательность сообщений. Детали этой процедуры изменяются в зависимости от конкретного случая.
Обоснование операции — элементарная процедура, в которой оконечное оборудование указывает базовой сети CN тип запрашиваемой операции. Исходя из этой информации, базовая сеть CN может принять решение продолжать операцию или завершить ее.
После этих шагов обычно проводятся процедуры аутентификации (подтверждения подлинности или права на доступ) и безопасности. Эта элементарная процедура подтверждает подлинность абонента UMTS и сети, а позже активизирует необходимые механизмы безопасности для соединения сети доступа.
Операции по установлению соединения и выделению радиоканала доступа RAB — элементарная процедура, которая выделяет реальные ресурсы для информационного обмена. Поэтому детали этой процедуры зависят от режима работы — с коммутацией каналов КК или с коммутацией пакетов КП.
Элементарные рабочие операции — это фаза, когда соединение в пользовательской плоскости уже установлено, т. е. UE располагает каналом по всей сети UMTS.
Операции разъединения и освобождения радиоканалов RAB — элементарная процедура освобождения ресурсов сети, связанных с соединением.
Освобождение радиосоединения RRC — элементарная процедура, содержащая механизмы, посредством которых радиоканал управления между UE и сетью доступа освобождается.
11.1.1. Поиск (пейджинг)
Процедура поиска востребована каждый раз, когда выполняется установление соединения с мобильным аппаратом UE. В отличие от GSM в UMTS существует два метода поиска (пейджинга) — 1-го и 2-го типа. Первый тип поиска используется доменами базовой сети CN и представляет «традиционный» способ поиска (см. рис. 11.2). Поиск — это часть плоскости управления радиосетью, и по сообщению RANAP PAGING активизируется на интерфейсе Iu. Домен базовой сети CN, инициирующий поиск, адресует его в те области местоположения или маршрутизации LA/RA, в которых разыскиваемый аппарат UE последний раз давал о себе знать, т. е. обновлялись данные о его местоположении или области маршрутизации.
Сообщение «RANAP PAGING» содержит два обязательных параметра — запрашивающий домен базовой сети CN и международный идентификатор мобильного абонента IMSI (International Module Subscriber Identity). С точки зрения безопасности системы передача IMSI через опорную точку Uu без шифрования нежелательна, и поэтому контроллер радиосети RNC может проводить (или не проводить) несколько преобразований IMSI. Например, контроллер RNC может выдавать сообщение «RRC PAGING TYPE 1», содержащее вместо
Рис. 11.3. Поиск (пейджинг) 2-го типа
IMSI временный идентификатор зоны радиосети RNTI (Radio Network Temporary Identifier). Это значение задается при подсоединении UE к сети или после выполнения предыдущей операции.
Как правило, прием и распознавание сообщения «RRC PAGING TYPE I» оборудованием пользователя UE ведет к установлению соединения RRC, необходимого для выполнения операции, которая была инициирована при поиске. Кроме того, сообщение «RRC PAGING TYPE 1» в сети радиодоступа RAN имеет некоторые особенности. Когда оборудование UE несвободно, а изменения информационных параметров системы должны стать известными UE, контроллер RNC может использовать сообщение «RRC PAGING TYPE I», чтобы «пробудить» UE и, таким образом, дать ему возможность считывать исправленную системную информацию или определенную ее часть. Если UE неактивно в соединении с коммутацией пакетов КП, то контроллер RNC использует сообщение «RRC PAGING TYPE 1» для информирования UE о том, что соединение КП следует активизировать. В этом случае имеются некоторые пакеты, которые базовая сеть CN должна передать в оборудование UE. Это засташтяет UE провести обновление соты, после чего контроллер-.RNC может маршрутизировать пакеты данных к соответствующему оборудованию UE.
Предполагается, что оконечные устройства UMTS могут поддерживать несколько соединений одновременно, т. е. может иметь одновременно более одного соединения с доменами базовой сети CN. Когда оборудование UE уже имеет соединение с одним доменом CN и устанавливается другое соединение с тем же доменом, то CN, как и в предыдущих случаях, передает сообщение «ranap PAGING». Сообщение поиска, посылаемое оборудованию UE обслуживающим контроллером RNC — SRNC, в данном случае представляет собой сообщение «RRC PAGING TYPE 2» (см. рис. 11.3).
Разделение между операциями поиска 1-го и 2-го типа выполняется контроллером RNC, где поиск RANAP всегда выглядит одинаково. Различие между операциями поиска 1-го и 2-го типа заключается в том, что первая используется для поиска UE, находящихся в нерабочем режиме, режиме поиска в соте Cell-PCH или режиме поиска в области регистрации URA_PCH сети доступа UTRAN. Следовательно, поиск 1-го типа может использоваться для нескольких или всех устройств UE в пределах одной или нескольких сот. В то же время режим 2-го типа используется для поиска тех устройств UE, которые находятся в режиме выделенного сотового канала Cell_DCH или режиме сотового канала прямого доступа Cell_FACH и поэтому всегда относится и адресуется только к одному UE .
11.1.2. Установление соединений RRC
Рисунок 11.4 иллюстрирует принцип установления радиосоединения между UE и RNC на интерфейсе Uu и внутреннем интерфейсе Iub области доступа. Установление соединений RRC всегда начинается с запроса соединения оборудованием UE — сообщения «RRC CONNECTION REQUEST», передаваемого по общему каналу управления СССН. Как показано в главе 4, канал СССН в восходящем напра&пении представляет собой канал случайного доступа RACH, и процедура доступа инициируется запросом «RRC CONNECTION REQUEST» абонентского терминала UE по физическому каналу RACH. Это сообщение поступает в контроллер RNC через порт данных интерфейса Iub по каналу случайного доступа RACH. При получении этого сообщения элемент RRC на стороне RNC изменяет свое состояние — переходит из состояния IDLE (не занят) в состояние CONNECTED CelI_FACH (связь по каналу прямого доступа) или CONNECTED CelI_DCH (связь по выделенному каналу доступа). Затем контроллер RNC связывается с UE по общим каналам управления (для этого используются каналы FACH и RACH соответственно).
Сообщение «Rrc CONNECTION REQUEST» (запрос соединения) содержит большой объем информации, имеющей отношение к запрашиваемому радиоканалу, терминалу и идентификации абонента; в этом сообщении UE посылает сети: идентификатор абонента 1MS1 или временный идентификатор абонемента TMSI, международный идентификатор мобильного оборудования 1МЕ1, идентификатор местоположения LAI и идентификатор области маршрутизации RAI. Запрос соединения «Rrc CONNECTION REQUEST» должен указывать, сколько этих значений введено в сообщение, и соответственно, содержать эти величины. Кроме этих идентификаторов, запрос «Rrc
Рис. 11.4. Установление соединения RRC
Рис. 11.5. Обоснование операции
11.1.3. Обоснование операции
После установления соединения RRC аппарат UE передает сообщение «ггс INITIAL DIRECT TRANSFER» (начало прямой передачи), которое в поле полезной нагрузки содержит первое системное сетевое сообщение операции UE (рис. П.5).
После получения этой информации RNC добавляет к сообщению еще несколько параметров и направляет эту комбинацию в соответствующий домен базовой сети в виде сообщения «ranap ue INITIAL». Это сообщение в своей полезной нагрузке вместе с первым сообщением, сформированным оборудованием UE, содержит исходное сообщение «ггс INITIAL DIRECT TRANSFER» (начало прямой передачи). Содержание сообщения «ranap ue INITIAL» дает базовой сети достаточно информации об операции, инициируемой UE. Среди этой информации — заявленная идентификация абонента UMTS (TMSI или IMSI), его настоящее местоположение и класс запрашиваемой операции. Вся эта информация используется узлом базовой сети для принятия решений — как лучше поступить с запросом на работу.
11.1.4. Аутентификация и управление безопасностью
В главе 9 уже обсуждались функции и алгоритмы безопасности. На рис. 11.6 показан поток сообщений, связанный с безопасностью сети доступа в контексте операции.
Во время организации соединения RRC оборудование пользователя UE, используя параметр указателя категории услуг, уже предоставило RNC информацию о многих своих возможностях, одна из которых — поддерживаемые им алгоритмы защиты информации.
Оборудование UE и сеть проводят опознание друг друга. Сеть посылает к UE сообщение «MM AUTHENTICATION REQUEST» (запрос аутентификации ММ) в поле полезной нагрузки сообщений «RANAP AND RRC DIRECT TRANSFER». После выполнения аутентификации универсального модуля идентификации абонента USIM UE отвечает сообщением «mm AUTHENTICATION RESPONSE» (подтверждение аутентификации ММ) в поле полезной нагрузки сообщений «rrc AND ranap DIRECT TRANSFER». В этом диалоге RNC действует как переключатель, который посылает содержимое
Рис. 11.6. Аутентификация и управление безопасностью
«гапар DIRECT TRANSFER» к «rrc DIRECT TRANSFER» и наоборот.
В сообщении «ranap SECURITY MODE COMMAND» (команда режима безопасности протокола гапар) соответствующий домен базовой сети CN указывает сети UTRAN, должна ли быть зашифрована операция. Это сообщение указывает выбранные алгоритмы безопасности и доставляет сети UTRAN ключи проверки целостности шифрования.
На основе этой информации контроллер RNC посылает сообщение «RRC SECURITY MODE COMMAND», дает оборудованию UE команду начать шифрование, используя соответствующие ключи и алгоритмы. Выдавая сообщение «rrc SECURITY MODE COMPLETE», UE указывает, что оно успешно перешло на выбранные алгоритмы зашиты целостности и шифрования, защищая, таким образом, дальнейшую передачу сообщений в данной операции.
Кроме того, контроллер RNC должен информировать соответствующий домен базовой сети о завершении процедуры закрытия, передав сообщение «гапар SECURITY MODE COMPLETE».
11.1.5. Операция установления с распределением радиоканала доступа RAB
До сих пор в нашем изложении содержание элементарных процедур было однотипным и независимым от характера доменов базовой сети. Операция установления и выделения радиоканалов доступа RAB — это первый этап, где должен быть принят во внимание различный характер доменов базовой сети CN.
В операциях с коммутацией каналов КК рабочая информация по установке соединения доставляется сообщениями «rrc/ranap DIRECT TRANSFER». Эти сообщения могут содержать в поле полезной нагрузки сообщение «ее SETUP» (установка управления вызовом), как показано на рис. 11.7. Это
Рис. И.7. Операции установления соединения и выделения каналов RAB (режим КК)
сообщение идентифицирует операцию и указывает требования к качеству QoS; другими словами, тип запрашиваемого канала передачи данных, услуги и параметры, которые он должен содержать:
• идентификатор операции (TI);
• идентификатор потока;
• класс трафика;
• индикатор асимметрии (асимметричный трафик — передача информации в прямом и обратном направлениях с разными скоростями);
• максимальная скорость (бит/с);
• гарантируемая скорость (бит/с).
Идентификатор TI дает оборудованию UE и узлу базовой сети CN возможность определять направление вызовов. Каждый запрос имеет собственное значение TI. Идентификатор потока распознает канал данного вызова. Если значения идентификатора потока еще не существует, это означает, что протокол управления вызовами СС оборудования UE хочет установить новый канал. Если значение идентификатора потока уже используется, то протокол СС будет обслуживать несколько соединений с использованием существующего канала (заданного идентификатором потока).
После приема сообщения «СС SETUP» (СС: Установка) в работу включается сервер MSC. Сначала он проверяет, имеют ли данный абонемент и аппарат UE право на запрашиваемую операцию. Если да, то сервер MSC начинает процесс выделения канала RAB, закрепляя идентификатор ID канала RAB и запрашивая установку RAB с необходимыми параметрами качества QoS. Для этого через интерфейс Iu передается сообщение «гапар rab ASSIGNMENT REQUEST» (запрос на выделение канала радиодоступа rab).
Когда контроллер RNC принимает запрос «ranap rab ASSIGNMENT REQUEST», он начинает процедуру выделения радиоканала, сначала проверив, достаточно ли в наличии ресурсов для удовлетворения запрашиваемого качества QoS. Если это так, то в соответствии с запросом выделяется радиоканал. В противном случае контроллер RNC может либо продолжить процедуру выделения канала с пониженными параметрами качества обслуживания QoS, например с пониженной скоростью передачи, или поставить запрос в очередь, до освобождения требуемых радиоресурсов. Эти случаи требуют некоторого дополнительного обмена сигналами управления по сравнению с сигналами, показанными на рис. 11.7.
RNC уведомляет оборудование UE о выделении канала, передавая сообщение «RRC RADIO BEARER SETUP» (установление радиоканала). Когда оборудование UE принимает это сообщение, оно имеет возможность объединить информацию, которую первоначально передало сети в своем сообщении «СС SETUP», с полученным идентификатором радиоканала. Затем UE может маршрутизировать трафик абонентских данных (в плоскости пользователя) в соответствующий радиоканал. Как только аппарат UE сможет принимать данные из нового радиоканала, то он подтверждает это, посылая контроллеру RNC сообщение «RRC RADIO BEARER SETUP COMPLETE» (завершение установки радиоканала). Контроллер RNC также должен установить канал lu для новой операции. После этого RNC указывает, что канал RAB уже выделен, посылая серверу MSC сообщение «RANAP RAB ASSIGNMENT RESPONSE» (ответ на запрос о выделении канала радиодоступа RAB). Если RNC сделал какие-либо изменения параметров QoS, запрашиваемых сервером MSC, то они указываются в этом сообщении. Теперь, когда канал RAB установлен, то процедура продолжается на уровне протокола СС.
Когда канал RAB должен быть установлен для операций с коммутацией пакетов КП, то процесс в основном протекает точно так же (см. рис. 11.8), а отличия содержатся в сообщениях. Вместо протокола СС оборудование UE теперь использует протокол управления сеансом SM (Session Management). Оборудование UE передает сети управляющее сообщение SM «ACTIVATE PDP CONTEXT REQUEST» (запрос активизации контекста протокола PDP), как в сообщении «rrc DIRECT TRANSFER MESSAGE», а контроллер RNC транслирует его как сообщение «ranap DIRECT TRANSFER» в направлении узла SGSN базовой сети CN. Радиоканал выделяется так же, как и при коммутации каналов КК, за исключением параметров качества обслуживания QoS. Например, гарантируемая скорость передачи в бит/с представляет важный показатель радиоканала доступа RAB с коммутацией пакетов КП, но не существенна для каналов радиодоступа RAB с коммутацией каналов КК. После того как канал RAB установлен, домен базовой сети CN подтверждает установление сеанса пакетной передачи, передавая сообщение SM «ACTIVATE PDP CONTEXT ACCEPT» (протокол PDP активизирован). В терминологии управления сеансом SM это означает, что состояние SM теперь активно и что UE и домен базовой сети CN в состоянии обмениваться данными в режиме коммутации пакетов КП.
Рис. 11.8. Операции установления соединения и выделения каналов RAB (режим КП)
11.1.6. Работа (элементарные рабочие операции)
В большинстве случаев операции на этом этапе поддерживают активное соединение в плоскости пользователя. Примеры операций этого класса приведены в данной главе позже (например, см. раздел 11.4). Однако если соединение RRC запрашивалось просто для обмена сигналами управления (например, управления мобильностью ММ), то никаких каналов в плоскости пользователя не требуется. Вместо этого для выполнения операций управления мобильностью ММ используется канал обмена сигналами управления (например, как это показано в разделе 11.3.3).
11.1.7. Операции разъединения и освобождения радиоканалов RAB
Если операции содержат активную плоскость пользователя1, то сначала отключается плоскость пользователя. Процедура разъединения зависит от типа операции. На рис. 11.9 показано, как происходит разъединение при коммутации каналов КК. В этом случае отбой начинается с оборудования UE, но базовая сеть CN также может начинать отключение плоскости пользователя. В общем случае любая сторона может прекращать обычный запрос КК, и это не зависит от того, которая из сторон запрашивала вызов.
После того как плоскость пользователя отключена, система освобождает канал RAB по отдельной процедуре. Когда это осуществляется с помощью
Рис. 11.9. Обмен сигналами при разъединении и освобождении канала RAB (режим с КК)
сообщений «RANAP RAB ASSIGNMENT REQUEST» и «RANAP RAB ASSIGNMENT RESPONSE», которые проводят освобождение, как показано на рис. 11.9, то сигнальное соединение еще сохраняется. Оборудование UE все еще имеет соединение RRC с UTRAN, и для этого UE все еще может поддерживать любые другие каналы радиодостула RAB. В общем случае, когда имеется один запрос RANAP RAB ASSIGNMENT REQUEST (запрос на выделение канала радиодоступа RAB), базовая сеть CN может выделить, удалить или модифицировать несколько радиоканалов доступа RAB.
Если между UE и базовой сетью CN освобождаются все радиоканалы доступа RAB, то одновременно также освобождаются и связанные с ними радиоресурсы. Как покачано на рис. 11.10, это может осуществляться с помощью команды «ranap iu RELEASE». После приема этого сообщения контроллер RNC через интерфейс lub инициирует освобождение радиоканала «RRC RADIO BEARER RELEASE». Кроме того, освобождаются всевозможные радиоканалы, установленные через дрейфующие контроллеры RNC (DRNC). При освобождении радиоканалов освобождаются также и соединения RRC. После освобождения всех радиоканалов и соединений RRC контроллер RNC передает базовой сети CN сообщение «ranap iu RELEASE COMPLETE» (освобождение интерфейса Iu завершено).
В соединениях с коммутацией пакетов КП плоскость пользователя и радиоканалы доступа RAB освобождаются так же, как и в соединениях с коммутацией каналов КК. И снова имеют место некоторые отличия на уровне параметров сообщений. Рисунок 11.11 иллюстрирует случай, когда соединение с КП закрывается при дезактивации контекста протокола данных PDP (Packet Data Protocol). Закрытие соединения с КП — задача протокола управления сеансом SM, при этом SM изменяет состояние с активного на неактивное. Процедура сигнализации, используемая для этой смены состояния, называется дезактивацией протокола PDP. Когда оборудование UE хочет сделать это, то оно посылает контроллеру SRNC сообщение «RRC DIRECT TRANSFER»,
Рис. 11.10. Сигнализация прекращения работы с освобождением Iu (режим КК)
содержащее запрос «SM DEACTIVATE PDP CONTEXT REQUEST» о дезактивации протокола pdp. Затем обслуживающий контроллер SRNC транслирует его как сообщение «гапар DIRECT TRANSFER» к домену КП базовой сети CN. Запрос дезактивации контекста PDP указывает обслуживающему контроллеру SGSN, что выделенный для данного соединения с КП канал радиодоступа RAB больше не нужен и, таким образом, должен быть освобожден.
Рис. 11.11. Операции освобождения канала RAB (режим КП)
Рис. 11.12. Обмен сигналами протокола RANAP при освобождении Iu (режим КП)
Освобождение канала радиодоступа RAB осуществляется таким же образом, как и при соединении с коммутацией каналов КК.
Когда канал радиодоступа RAB освобожден, узел SGSN, посылая оборудованию UE сообщение «SM DEACTIVATE PDP CONTEXT ACCEPT» (дезактивация контекста протокола PDP принята) подтверждает, что теперь соединение с КП дезактивировано. После этого UE все еще имеет соединение RRC с сетью и может иметь другие открытые соединения с КК и КП. Если все соединения с КП должны быть завершены и радиоресурсы освобождены, то система использует команду «ranap iu RELEASE» таким же образом, как и при соединении с КК (см. рис. 11.12).
11. 1. 8. Освобождение соединения RRC
Показанная на рис. 11.13 процедура освобождения соединения RRC всегда начинается с контроллера радиосети RNC. Контроллер RNC определяет, какое соединение RRC должно быть освобождено, и затем посылает эту информацию в оборудование UE в сообщении «RRC CONNECTION RELEASE» (освобождение соединения RRC). Оборудование UE подтверждает освобождение соединения RRC передачей сообщения «RRC CONNECTION RELEASE COMPLETE» (освобождения соединения rrc завершено).
Затем RNC начинает освобождать ресурсы интерфейса Iub. Это осуществляется с помощью обмена сообщениями «NBAP RADIO LINK DELETION» (удаление радиоканала) и «NBAP RADIO LINK DELETION RESPONSE» (ответ на запрос удаления радиоканала). Когда удаление радиоканала согласовано на уровне протокола NBAP, транспортный канал на интерфейсе Iub
Рис. 11.13. Освобождение соединения RRC
освобождается. Все другие радиоканалы, установленные через дрейфующие RNC (DRNC), также должны быть освобождены с помощью процедур Iur (не показанные на рис. 11.13).
11.2. Примеры процедур RRM
Как показано в главе 5, управление радиоресурсами RRM — это совокупность алгоритмов, необходимых для установления и обслуживания радиотракта хорошего качества между контроллером RNC и UE. Таким образом, практически каждый алгоритм RRM представлен во всех операциях сети UTRAN. Алгоритмы RRM — это передача обслуживания от одной базовой станции к другой НО (Handover), управление мощностью PC (Power control), управление по входу AC (Admission Control), планирование пакетов PS (Packet Scheduling) и управление кодированием CM (Code Management). Алгоритмы PC, АС и СМ используются «постоянно» (т. е. с самого начала операции они используются на всех этапах). Планирование пакетов используется для собственных операций PS, а НО используется в режимах КК и КП при необходимости. Поскольку в границах UTRAN операции КК и КП равноценны, то необходимость передачи обслуживания НО определяется профилем QoS соединения (см. главу 8) и в большей степени типом используемого радиоканала, а не режимом КК или КП. В соответствии с профилем QoS, если операция проводится в реальном масштабе времени, то требуются процедуры НО. Если операция использует один или более выделенных каналов DCH, то алгоритм НО должен использоваться независимо от того, используется ли режим с коммутацией каналов КК или пакетов КП.
Те элементы RRM, которые расположены в UE и контроллере RNC, обмениваются между собой информацией RRM, используя протокол RRC. Поэтому организация соединения RRC, как описано в разделе 11.1.2, обязательна для каждой операции. Однако важно иметь в виду то, что для любого UE достаточно одного соединения RRC с UTRAN независимо от того, сколько радиоканалов одновременно открыто для различных операций на системном уровне.
В данном подразделе мы представляем некоторые примеры передачи обслуживания НО. Сначала в соответствии с принципами, изложенными в главе 5, поясняется мягкий режим НО. После примеров мягкого режима НО дается краткий обзор процедур перераспределения SRNS без участия устройств UE. Последний пример процедуры RRM — это случай межсистемной передачи обслуживания НО, когда происходит передача обслуживания UE от системы радиодостуиа WCDMA к GSM.
11.2.1. Режим мягкой передачи обслуживания — добавление и удаление канала
При использовании услуги аппаратом UE существует активное соединение RRC с UTRAN. В этом случае UE непрерывно оценивает радиососдинение и посылает отчеты об измерениях в обслуживающий контроллер SRNC. Содержание отчета об измерениях было представлено в главе 5 в контексте алгоритмов RRM.
Алгоритм передачи обслуживания НО в контроллере SRNC предусматривает обработку полученных сообщений об измерениях и вычисление средней величины. По этим результатам SRNC видит, что оборудование UE оценивает состояние радиоканала соты БС 2 как удовлетворяющее критериям передачи обслуживания НО, определенным в контроллере SRNC. Основываясь на информации радиосети, хранящейся в базе данных, SRNC удостоверяется, что данная сота БС 2 не принадлежит к той же подсистеме RNS.
Контроллер SRNC принимает меры на стороне UTRAN, посылая по интерфейсу lur запрос дрейфующему контроллеру DRNC на установление нового радиоканала. Запрос выполняется передачей сообщения «RNSAP RL SETUP REQUEST» (запрос на установление радиоканала). Это заставляет контроллер DRNC организовывать радиоканал с БС 2 по интерфейсу Iub, используя протокол обмена NBAP. После этого устанавливаются каналы Iub и lur, а кадровые протоколы синхронизируются в нисходящем и восходящем направлениях между SRNC и БС 2. Кадровые протоколы на интерфейсах Iub и lur обеспечивают организацию плоскости пользователя радиосети и непосредственную передачу потока данных пользователя. В этом примере мы предполагаем, что используемая услуга будет телефонным вызовом. Таким образом, кадровый протокол, используемый в данном примере, — Iub/Iur DCH-FP.
Когда в восходящем направлении контроллер SRNC установил синхронизацию кадрового протокола FP, он посылает оборудованию UE сообщение «RRC ACTIVE SET UPDATE» (обновить активный список RRC). В этом сообщении контроллер SRNC показывает UE, что в активный список добавлен новый радиоканал для соединения с сотой, расположенной в БС 2, и что это соединение готово к использованию. Оборудование UE подтверждает получение, отвечая сообщением «RRC ACTIVE SET UPDATE COMPLETE» (обновление активного набора RRC завершено).
С точки зрения структуры канала этот пример иллюстрирует ситуацию, в которой UE использует активный радиоканат RAB в режиме КК. Этот радиоканал доступа RAB реализован в пределах UTRAN с помощью каналов Ти,
Рис. 11.14. Режим мягкой передачи обслуживания НО — добавление канала
один из которых расположен между обслуживающим контроллером SRNC и базовой сетью, а другой — между SRNC и UE через соту БС 1. Процедура, описанная на рис. 11.34 с точки зрения качества каналов представляет случай, когда контроллер SRNC добавляет к уже существующему соединению дополнительный радиоканал. Канал радиодоступа RAB и канал передачи данных Iu остаются неизменными. Когда кадровые протоколы синхронизированы, SRNC вставляет радиоканал доступа RAB в несущий радиоканал. Эту ситуацию и соответствующие протоколы обмена на общем уровне показаны на рис. 5.35.
Когда терминал UE перемещается по сети во время работы, то наступает момент, когда контроллер SRNC из принятого отчета об измерениях обнаруживает, что радиосоединение, несущее радиоканал через соту БС 2, больше не удовлетворяет критериям радиосоединения. Когда это происходит, то контроллер SRNC сообщает оборудованию UE, что это радиосоединение
Рис. 11.15. Режим мягкой передачи обслуживания НО — удаление канала
может быть удалено из активного списка. Это осуществляется передачей оборудованию UE сообщения «RRC ACTIVE SET UPDATE» (обновить активный список RRC), указывающего, что радиосоединение должно быть удалено. Терминал UE подтверждает удаление радиосоединения, посылая к SRNC сообщение «RRC ACTIVE SET UPDATE COMPLETE» (обновление активного списка RRC завершено).
После получения подтверждения от оборудования UE контроллер SRNC может инициировать удаление радиосоединения между собой и БС 2. Это осуществляется передачей по интерфейсу Iur запроса на удаление радиоканала «RNSAP RL Deletion REQUEST», который, в свою очередь, побуждает DRNC удалить радиосоединение на интерфейсе lub по протоколу обмена NBAP. Как только радиосоединение на lub и Iur удалено, связанные с lub и Iur радиоканалы также освобождаются. Поток сообщений, связанный с мягкой передачей обслуживания НО при удалении радиоканала, показан на рис. 11.15.
С точки зрения структуры несущего канала, этот пример удаления радиоканала иллюстрирует случай, когда контроллер SRNC удаляет один несущий радиоканал, но RAB между базовой сетью и UE остается.
11.2.2. Перераспределение SRNS — при коммутации каналов
Что касается отдельного UE, то роль SRNC заключается в том, чтобы RNC поддерживал несущий канал на Iu и вставлял каналы RAB в несущие радиоканалы. Поскольку компоненты несущих радиоканалов — радиосоединения — могут непрерывно меняться благодаря режиму мягкого переключения НО (см. раздел 11.2.1), то обслуживающий контроллер SRNC может оказаться в таком положении, когда он больше не управляет радиосоединениями с собственными БС непосредственно через Tub. Когда это случается, функции вставки RAB должны быть переданы тому RNC, который в состоянии выполнять это лучше. Поскольку вставка RAB требует наличия несущего канала на интерфейсе Iu на том же RNC, то соединения базовой сети CN также изменяются.
Процедура управления RRM, по которой функция завершения несущего канала Iu (а также одновременно и радиоканалов) переходит от одного RNC к другому, называется перераспределением подсистем сети SRNS. Обмен сообщениями при этой процедуре проиллюстрирован на рис. 11.16. На этом рисунке RNC 1 — это исходный SRNC, a RNC 2 — это RNC, который примет функции обслуживания — SRNC. Процедура перераспределения подсистем SRNS может выполняться двумя различными способами: с активным привлечением UE или без него. Представленный пример иллюстрирует ситуацию, когда оборудование UE не вовлечено в процесс.
Когда исходный SRNC RNC I узнает, что функции SRNC должны быть переданы лучшему из контроллеров-кандидатов RNC 2, он инициирует эту процедуру, связываясь с соответствующим доменом базовой сети CN и отсылая сообщение «ranap RELOCATION REQUIREMENT» (запрос перераспределения протокола ranap). Это сообщение содержит информацию о причинах перераспределения, идентификатор сети назначения RNS и указатель категории услуг UE. По идентификатору сети назначения RNS домен базовой сети может переслать этот запрос далее к сети назначения. Этот перенаправленный запрос представляет собой сообщение «ranap RELOCATION REQUEST». Кроме другой информации, связанной с перераспределением, сообщение «ranap RELOCATION REQUEST» содержит информацию о контекстах канала, базовых сетях и в то же время эффективно перемещает каналы RAB и оконечные точки соединения RRC от исходного SRNC (RNC 1) к SRNC назначения (RNC 2).
Если подключаемый RNC может предоставить ресурсы для поддержки переданных функций SRNC, то он посылает подтверждение в обратном направлении к базовой сети CN, которая транслирует это подтверждение к исходной подсети RNS. С точки зрения RNC 1 это подтверждение служит командой начала перераспределения, так как теперь все должно быть готово на подключаемом контроллере RNC. После получения команды на перераспределение «ranap RELOCATION COMMAND», исходный контроллер SRNC (RNC1) начинает отправлять данные к адресуемому контроллеру SRNC (RNC2). Предполагаемый SRNC (RNC2) обнаруживает поступающие данные и уведомляет домен базовой сети CN о том, что обнаружено перераспределение SRNS, передавая сообщение «ranap RELOCATION DETECT». При необходимости исходный контроллер SRNC (RNC 1) может посылать
Рис. 11.16. Перераспределение SRNS н режиме КК без участия UE
адресуемому контроллеру SRNC (RNC 2) по интерфейсу lur сообщение «rnsap srnc RELOCATION COMMIT» {зафиксировать перераспределение). В случае перераспределения контроллера SRNC без привлечения оборудования UE UE не знает об этом описанном выше потоке сообщений. Если необходимо выполнить какие-либо процедуры RRC, то они выполняются после сообщения «RANAP RELOCATION DETECT» (обнаружение перераспределения). Сеть доступа UTRAN может, например, посылать оборудованию UE сообщение «rrc utran MOBILITY INFORMATION» (информация о мобильности). По этому сообщению UTRAN обновляет на оборудовании UE идентификаторы регистрационной зоны C-RNTI и U-RNTI и, возможно, другую информацию, связанную с ММ.
Когда выполнены все процедуры RRC, новый SRNC (RNC 2) сообщает базовой сети CN, что процедура перераспределения SRNC завершена, посылая сообщение «ranap RELOCATION COMPLETE» (перераспределение завершено). Это позволяет базовой сети CN освободить ресурсы, связанные с прежним SRNC (RNC 1), используя сообщение «RANAP Ш RELEASE» (команда освобождения Iu), которое подтверждается прежним SRNC (RNC1). Теперь потоки данных пользователя пройдут через новый SRNC и в зависимости от его роли он действует как пункт объединения разнесенных макрокоманд для UE, а также управляет всеми операциями RRC данного UE.
11.2.3. Межсистемная передача обслуживания от UMTS к GSM — коммутация каналов
Технические условия 3GPP как обязательное требование определяют передачу обслуживания НО между двумя сетями радиодоступа. С точки зрения UMTS это означает, что система должна быть в состоянии проводить передачу обслуживания НО между UTRAN и GERAN. Как можно видеть из рис. 11.17, межсистемная передача обслуживания ISHO (Inter System Hand Over) между UTRAN и GERAN представляет особый случай процедуры перераспределения подсетей SRNS. Фактически RANAP переносит гораздо больше информации того же рода, что передает протокол BSSMAP в сети GSM. Если переключение НО осуществляется от UTRAN к GERAN, то сообщения на стороне UTRAN точно такие же, как и при перераспределении подсетей SRNS, но содержание этих сообщений изменяется. Например, при перераспределении SRNC сообщение RANAP Relocation Required (требование перераспределения) содержит идентификатор адресуемого контроллера радиосети — RNC ID. Когда адресуемый элемент находится на стороне GSM, идентификатор целевого контроллера радиосети RNC ID заменяется глобальным идентификатором соты, более привычным контроллеру базовой станции BSC системы GSM.
В отличие от перераспределения подсети SRNS, ISHO — это процедура, к которой всегда привлекается оборудование пользователя UE. Оборудование UE для организации доступа к GERAN должно проводить операции с радиоресурсами RR. Обратите внимание, что GERAN не обязательно может обрабатывать каждый вид информации, применяемый в UTRAN. Оборудование UE по результатам измерений должно уметь оценивать состояние ближайших сот GSM, окружающих данную соту (или соты) UTRAN. Эту возможность сети UTRAN дает использование режима выделения временных интервалов (см. главу 5). В этом режиме оборудованию UE предоставляется некоторое время для проведения измерений в полосе GSM и нахождения возможных вариантов «хэндовера» НО. Информация об этих вариантах сот GSM доставляется RNC с отчетами о результатах измерений таким же образом, как и в сотах UTRAN.
Как только контроллер RNC распознает, что сота GSM представляет лучший вариант, а подходящие соты UTRAN отсутствуют, то SRNC начинает запрашивать от базовой сети CN информацию для перераспределения. Базовая сеть CN проверяет содержание сообщения «ranap RELOCATION REQUIRED» (требование перераспределения) и обнаруживает, что адресуемая сота для этого случая НО принадлежит подсистеме базовой станции BSS GERAN. Тогда базовая сеть CN посылает сообщение «gsm bssmap HANOVER REQUIRED» (требование переключения) адресуемому контролеру BSC сети GSM. Этот запрос побуждает адресуемый контроллер BSC организовать канал трафика ТСН так, чтобы на него могло быть передано соединение. При успешной
Рис. 11.17. Межсистемная передача обслуживания ISHO (Inter System Hand Over) между UTRAN и GERAN (режим коммутации каналов)
передаче канала ТСН в пределах сети GERAN базовая станция BSS посылает подтверждение базовой сети CN. Базовая сеть CN транслирует это сообщение в обратном направлении к обслуживающему контроллеру SRNC в сообщении «ranap RELOCATION COMMAND» (команда на перераспределение).
По команде на перераспределение «ranap RELOCATION COMMAND» контроллер SRNC начинает процедуру перемещения. Поскольку в данном случае в процесс привлечено оборудование UE, контроллер SRNC отдает команду оборудованию UE выполнить межсистемное переключение ISHO в сообщении «ггс HANDOVER FROM utran». Это сообщение содержит информацию об адресумой системе, а также может нести в поле полезной нагрузки любую дополнительную информацию, связанную с ISHO.
После приема команды «rrc HANDOVER FROM utran» оборудование UE проверяет, указано ли в сообщении какое-либо конкретное время для выполнения передачи обслуживания НО (по умолчанию он выполняется немедленно) и соответственно начинает операции НО. Поскольку адресуемая сеть радиодоступа находится в сети GERAN, оборудование UE посылает сообщение «gsm rr HANDOVER ACCESS» адресуемой соте в подсистему BSS сети GERAN. Когда адресуемая сота подсистемы BSS сети GERAN обнаруживает это сообщение, то оно указывает контроллеру базовой станции BSC, что UE имеет доступ к сети GERAN. Контроллер BSC, в свою очередь, ставит в известность базовую сеть CN о появлении UE, посылая сообщение «gsm bssmap HANDOVER DETECT» (обнаружено переключение от GSM).
Оборудование UE принимает от соты подсистемы базовой станции BSS сети GERAN сообщение «gsm rr PHYSICAL INFO» как подтверждение в ответ на сообщение «gsm rr HANDOVER ACCESS». Это сообщение содержит информацию {например, посылаемые UE описания каналов), при наличии которой UE может начать процедуру радиодоступа GERAN. Наконец, когда оборудование UE успешно завершило доступ к адресуемой соте, оно посылает контроллеру базовой станции BSC сообщение о завершении переключения НО — «gsm rr HANDOVER COMPLETE» (Переключение завершено). Контроллер BSC, в свою очередь, транслирует эту же информацию в базовую сеть CN, указывая этим, что UE теперь вошло в подсистему базовой станции BSS сети GERAN и межсистемное переключение ISHO успешно завершено. Так как UE больше не использует ресурсы сети UTRAN, все связанные с данным оборудованием UE ресурсы могут быть освобождены, и базовая сеть CN выдает команду «ranap iu RELEASE». Эта команда, в свою очередь, вынуждает контроллер RNC освободить соединение RRC, и таким образом, освобождаются все ресурсы, связанные с UE. После выполнения этих операций RNC подтверждает освобождение, направляя базовой сети CN сообщение о завершении освобождения интерфейса «ranap iu RELEASE COMPLETE» (освобождение Iu завершено).
11.3. Примеры процедур управления мобильностью ММ
Если сравнить GSM и UMTS, то управление мобильностью ММ проводится в целом одинаково, но имеются некоторые различия. По сути ММ охватывает все процедуры, методы и идентификаторы, необходимые для получения сведений о местоположении оборудования пользователей UE, при его перемещении в сети. Из-за наличия операций планирования PS, в ММ была введена модель состояний (см. главу 6). В сетях GSM, управление ММ полностью реализуется на участке между мобильной станцией MS и подсистемой сети NSS. В сетях UMTS большинство функций управления ММ на участке между оборудованием UE и базовой сетью CN выполняется однотипно, но есть исключения. Контроллер радиосети RNC, отслеживая перемещение UE в пределах сети радиодоступа RAN, частично использует для этой цели процедуры RRC. Операции ММ, поддерживаемые контроллером RNC, — это обновление соты и регистрационной зоны URA.
11.3.1. Обновление соты
Во время операций с КК базовая сеть располагает информацией о местоположении оборудования UE с точностью до области местоположения LA, a RNC — с точностью до соты или, вернее, — до сот, если UE находится в состоянии мягкого режима переключения НО. Информация из соты в течение операции непрерывно изменяется. Скорость изменения зависит от состояния радиосети и от того, перемешается ли UE и с какой скоростью.
При операциях с КП информация о местоположении распределяется таким образом, чтобы домен КП базовой сети CN располагал информацией о местоположении UE с точностью до области местоположения LA и области маршрутизации RA, a RNC — с точностью до соты. Поскольку в режиме с КП соединение по своему характеру прерывисто, информация о соте в контроллере RNC будет устаревшей всякий раз, когда соединение для передачи данных между UE и базовой сетью CN временно прерывается. Следовательно, в этом случае с точки зрения UE и базовой сети соединение с КП есть, но RNC не может маршрутизировать пакеты данных. Если аппарату UE нужно передать пакеты данных, а данная сота отличается от его предыдущего местоположения, то UE выполняет процедуру протокола RRC по обновлению соты (рис. 11.18), оповещая контроллер RNC о соте, в которой он находится. После этого возможны любые действия протокола RRC (например, может быть организован радиоканал).
Если же домен КП базовой сети CN имеет несколько пакетов данных для передачи оборудованию UE, то он сначала выдает сообщение «гапар PAGING», побуждая RNC передать оборудованию UE сообщение Rrc «PAGING TYPE 1». После его получения UE проверяет, необходима ли процедура обновления соты. Если да, то оборудование UE проводит обновление соты, после чего оно готово начать прием пакета. Итак, у UE есть следующие причины для обновления соты:
• повторный выбор соты;
• периодическое обновление соты;
• передача данных в восходящем направлении;
• отклик на разыскивание (пейджинг);
• повторное вхождение в область обслуживания;
• сбой в работе радиоканала;
• невосстанавливаемая ошибка RLC.
При процедуре обновления ячейки контроллер RNC может присваивать соединению RRC новый временный идентификатор радиосети RNTI.
11.3.2. Обновление зоны URA
Контроллер RNC поддерживает регистрацию текущей регистрационной зоны URA каждого UE. Как описано в главе 6, регистрационная зона URA состоит из нескольких сот, принадлежащих одному или нескольким RNC. Подобно областям LA и RA, область URA — это один из идентификаторов, хранящихся в универсальном модуле идентификации USIM оборудования UE. Когда оборудование UE включено, оно непрерывно контролирует принимаемую информацию идентификации регистрационной области URA. Если принимаемая информация URA отличается от хранящейся в USIM, оборудование UE выполняет процедуру обновления области регистрации — «rrc ura UPDATE» (рис. 11.19).
Процедура обновления URA также проводится при истечении установленного времени периодического обновления URA или если оборудование UE повторно вошло в зону обслуживания сети. Как и в случае обновления соты, контроллер RNC изменяет временный идентификатор RNTI, присвоенный UE.
11.3.3. Обновление местоположения в домене КК базовой сети CN
Рисунок П.20 иллюстрирует обмен управляющими сигналами между UE и доменом базовой сети CN с коммутацией каналов КК при обновлении местоположения LU (Location Update). Если UE не имеет соединения RRC с сетью UTRAN, то сначала устанавливается соединение RRC. Фактически процедура обновления местоположения LU запускается идентификатором области местоположения LA (Location Area). Оборудование UE хранит информацию LA в карточке USIM. Если идентификатор области местоположения LA, в которой в данное время находится оборудование UE, отличается от идентификатора, хранящегося в его карточке US1M, то, чтобы проинформировать базовую сеть CN о своем настоящем местонахождении, оборудование UE начинает процедуру обновления местоположения LU.
Сообщение протокола управления мобильностью Mm — «lu REQUEST» (запрос обновления) передается в оболочке «RRC INITIAL DIRECT TRANSFER» контроллеру RNC, откуда транслируется в базовую сеть CN в сообщении «ranap ue INITIAL». Сообщение Mm «lu REQUEST» содержит прежний и новый идентификаторы местоположения LA, прилагается также информация об идентификации абонента. В обычном случае этот идентификатор — номер TMSI, заранее присвоенный сервером MSC.
Гостевой регистр VLR сервера MSC проверяет, есть ли у данного абонента идентификационные векторы. Если они отсутствуют, параметры безопасности берутся из центра аутентификации (АиС), который посылает в регистр VLR
Рис. 11.20. Обновление местоположения LU в домене с коммутацией каналов КК базовой сети
заранее определенный номер в сообщении «MAP SEND PARAMETERS». После получения этих параметров регистр VLR в состоянии инициировать процедуры безопасности на уровне доступа для аутентификации (установления подлинности) и шифрования. Если прежний и новый идентификаторы области LA отличаются, то гостевой регистр VLR сообщает домашнему регистру HLR информацию о новом местоположении. Домашний регистр HLR удаляет координаты старого местоположения UE сообщением «MAP CANCEL LOCATION» и запускает операцию «MAP INSERT SUBSCRIBER DATA». Эта операция MAP (Mobile Application Part) передает профиль абонента новому гостевому регистру VLR. Профиль абонента содержит всю необходимую информацию по идентификации, детали предоставления услуг и возможные ограничения относительно их использования. После обновления информации местоположения абонента в регистре VLR домен базовой сети CN сообщает UE об успешном завершении процедуры, посылая сообщение «mm iu ACCEPTED». Это сообщение содержит также новый временный идентификатор абонента TMSI. Контроллер радиосети RNC транслирует эту информацию в UE, посылая сообщение «rrc DIRECT TRANSFER». Оборудование UE подтверждает обновление LU и получение нового значения идентификатора TMSi, посылая серверу MSC сообщение «MM TMS! RELOCATION COMPLETE».
Гостевой регистр VLR после получения подтверждения о перераспределении TMSI инициирует освобождение соединения сигнализации. Интерфейс Iu освобождается по команде «гапар iu RELEASE» (освобождение Iu), при получении которой контроллер RNC освобождает соединение RRC. Когда соединение установлено, контроллер RNC подтверждает освобождение, посылая серверу MSC сообщение «ranap iu RELEASE COMPLETE» (освобождение Iu завершено).
11.3.4. Обновление области маршрутизации в домене КП базовой сети
Как уже обсуждалось в главе 6, домен с коммутацией пакетов КП базовой сети CN обеспечивает собственную регистрацию мобильности оборудования UE. Хотя домен КП распознает области местоположения LA, более важной в данном контексте представляется область маршрутизации RA (Routing Area). После выполнения обновления области маршрутизации оборудование UE хранит последнюю информацию о маршрутизации RA. Из информации, распространяемой в соте, в которой находится аппарат UE, он получает текущий идентификатор области маршрутизации RA. Если она отличается от информации, хранящейся в USTM, то UE инициирует операцию обновления области маршрутизации RAU (см. рис. 11.21).
Сначала UE посылает запрос на обновление области маршрутизации — сообщение «gmm rau REQUEST». Это сообщение содержит прежнее и новое значения идентификаторов области маршрутизации RA. Оно поступает через интерфейс Iu в новый узел SGSN. Новый узел SGSN располагает информацией о состоянии дел в управлении мобильностью ММ (т. е. о соседних областях маршрутизации RA и связях с другими узлами SGSN сети). На основе этой информации новый SGSN может определить прежний SGSN, у которого он запрашивает информацию об абоненте, посылая запрос «GTP-C SGSN CONTEXT REQUEST». Другими словами, новый узел SGSN запрашивает, действительно ли UE, выполняющий процедуру RAU, уже имеет PDP-контекст.
Впоследствии новый узел SGSN может запросить у центра аутентификации абонентов АиС идентификационные векторы. Центр АиС вычисляет их и возвращает набор векторов новому SGSN в сообщении «MAP SEND PARAMETERS». Новый узел SGSN теперь имеет возможность инициировать аутентификацию и управлять безопасностью данного аппарата UE в сети UTRAN. Об успешном завершении аутентификации и операций безопасности новый SGSN уведомляет шлюз GGSN, посылая ему сообщение об обновлении контекста протокола пакетированных данных — «gtp-c UPDATE PDP CONTEXT». Новый узел SGSN сообщает шлюзу GGSN, что SGSN уже изменен и, соответственно, была изменена информация контекста PDP.
Новый узел SGSN может теперь обновить информацию местоположения в регистре HLR, посылая сообщение «MAP UPDATE LOCATION». После его получения домашний регистр HLR удаляет информацию о прежнем местоположении UE из старого SGSN.
Рис. 11.21, Обновление области маршрутизации в домене с КП базовой сети CN
После удаления информации о старом местоположении регистр HLR перелает данные о профиле абонента в новый узел SGSN, используя сообщение «MAP INSERT SUBSCRIBER DATA» (ввод данных абонента).
После обновления профиля абонента новый узел SGSN посылает в оборудование UE сообщение «GMM RAU ACCEPTED» (обновление принято). В этом ообщении в UE передается новый номер P-TMSI. Оборудование UE хранит этот P-TMS1 в своем универсальном модуле USIM и подтверждает его получение, посылая к SGSN сообщение подтверждения «gmm ACK-NOWLEGEMENT». Теперь, когда обновление области маршрутизации RA завершено, новый узел SGSN освобождает используемое в этой операции соединение сигнализации. На рис. 11.21 показан обмен сообщениями при обновлени RAU в случае изменения узла SGSN. Узел SGSN не изменяется при каждом обновлении области RA. Если узел SGSN не изменяется, то процедура проше, так как не нужен диалог MAP между узлом SGSN и домашним регистром HLR.
11.4. Пример процедуры управления вызовом СС
Рисунок 11.22 иллюстрирует обмен управляющими сообщениями, завершающимися в оборудовании UE, при вызове от телефонной сети общего пользования ТСОП с коммутацией каналов КК. Предполагается, что в ТСОП и между узлами MSC используется абонентская сигнализация сети ЦСИО (ISDN) - ISUP (ISDN User Part).
Вызывные сигналы ТСОП поступают сначала в шлюзовой сервер MSC в сообщении iam — «isup INITIAL ADDRESS MESSAGE» (инициализация адреса). Это сообщение содержит номер мобильного абонента ISDN — MSISDN (Mobile Subscriber ISDN) вызываемого абонента UMTS. В это же время данный номер MSISDN идентифицирует желаемую услугу. Чтобы организовать тракт с КК между сетью UMTS (CS-MGW) и ТСОП, шлюзовой сервер GMSC отвечает сообщением «isup ADDRESS COMPLETE MESSAGE» (ACM).
Сервер GMSC запрашивает у домашнего регистра HLR информацию о маршрутизации абонента, посылая сообщение «MAP SEND ROUTING INFORMATION». В этом сообщении шлюзовой сервер GSMC посылает HLR принятый номер MSISDN, в котором HLR может обнаружить идентификатор IMSI абонента. Он также находит последнее сообщение о местоположении абонента с точностью до текущего адреса сервера MSC. Затем HLR выдает сообщение «MAP PROVIDE ROAMING NUMBER REQEST» (запрос номера роуминга) серверу MSC, который присваивает и возвращает номер роуминга мобильной станции MSRN (Mobile Station Roaming Number) для соединения в тракте с КК. После его приема HLR транслирует номер MSRN в шлюзовой сервер GMSC.
Номер MSRN содержит необходимую информацию для маршрутизации вызовов, так как каждый сервер MSC в сети присваивает номера MSRN из определенной области нумерации и эта область нумерации распознается в элементах протокола СС шлюзового сервера MSC GMSC. Сервер GMSC использует полученный номер MSRN для маршрутизации вызовов к серверу MSC, используя сообщения «isup iam» и «isup acm», как описывалось ранее.
Сервер MSC распознает выделенный ему номер MSRN и определяет, что этот запрос должен завершиться на одном из управляемых им устройств UE. Тогда он посылает сообщения «RANAP PAGING» тем контроллерам RNC, которые обслуживают соты, принадлежащие областям LA, где адресуемое оборудование UE проводило последнее обновление местоположения LU. Контроллер RNC посылает на интерфейс Uu сообщения «RRC PAGING TYPE I» (поиск 1-го типа), а разыскиваемый аппарат UE отвечает инициированием процедуры организации соединения RRC. Отклик на поиск передается в сообщении «RANAP UE INITIAL» (инициация UE), при получении которого базовая сеть CN начинает операции аутентификации и безопасности данного
Рис. 11.22. Установление вызова и освобождение UE при соединении с ТСОП (режим КК)
вызова. Если операции безопасности выполнены успешно, то базовая сеть CN начинает установление соединения, посылая UE сообщение «СС SETUP» о входящем вызове и его характере.
Если UE принимает данный вызов, то базовая сеть CN инициирует выделение несущего канала RAB. После выделения RAB оборудование UE оповещает абонента и сообщает об этом сети, посылая сообщение «ее ALERT» (готово). Эта информация передается через сеть (или сети) до коммутационной станции вызывающего абонента. Когда абонент отвечает, в сети UTRAN приводится в действие процедура «СС CONNECT» (соединение) и по сети (сетям) передается ответная информация посылкой ответного сообщения «isup ans».
Вызывной тракт с КК теперь в состоянии пройти через шлюзы среды передачи CS-MGW, которые находятся под управлением серверов MSC и GMSC. Начинается загрузка, запускаются соответствующие кодеки речи, и система готова передавать поток данных пользователя, поскольку соединение плоскости пользователя теперь открыто.
В этом примере мы предполагаем, что соединение прекращается по инициативе UE.
Используется три варианта процедуры разъединения с обменом в сети UTRAN сообщениями «СС DISCONNECT», «СС RELEASE» и «СС RELEASE COMPLETE». На стороне ISUP происходят подобные вещи при передаче сообщений «isup rel» (освобождение) и «isup rlc» (завершение освобождения). Эти сообщения прекращают загрузку и разъединяют соединение между узлами. После разьединения тракта с КК, базовая сеть CN освобождает несущие каналы RAB и соединение RRC, активизируя процедуру освобождения lu.
11.5. Пример передачи пакетов данных
На рис. П.23 показан небольшой пример того, что происходит во время сеанса передачи пакетов. Мы опять предполагаем, что оборудование UE непрерывно перемещается в зоне сети UTRAN. При этом приложению пользователя в UE необходимо передать пакеты данных в сеть (в восходящем направлении). Так как оборудование UE непрерывно перемещается, то оно должно сначала выполнить обновление соты. Делая это, аппарат UE гарантирует, что информация о его местоположении в обслуживающем контроллере SRNC верна — она должна быть определена с точностью до соты.
После обновления соты UE может запросить активизацию контекста PDP через текущую соту, и для передачи пакетов данных может быть выделен радиоканал RAB. На рис. 11.8 показан полный поток сообщений, вовлеченных в эту процедуру. При открытии сеанса пакетной передачи UE передает в восходящем направлении пакеты данных, которые сначала поступают на обслуживающий контроллер SRNC по радиоканалу, сформированному для данного сеанса. Пакетный трафик затем пропускается между RNC и шлюзом GGSN по протоколу GTP-U. Физически этот путь состоит из двух частей: канала lu на интерфейсе Iu и магистрального канала домена КП между узлом SGSN и шлюзом GGSN. Путь заканчивается на шлюзе GGSN, откуда пакеты данных пользователя направляются к внешней сети передачи данных, в соответствии с методом, задаваемым параметром «тип соединения» контекста PDP. Это, например, может быть протокол «точка—точка» РРР (Point-to Point Protocol) или Х.25. Когда больше нечего передавать, контекст PDP дезактивируется и канал RAB освобождается. Полный поток сообщений, вовлеченный в этот процесс, представлен па рис. 11.11.
В нисходящем направлении шлюзовой узел GGSN может обнаружить, что пакеты поступают из других сетей. Тогда он активизирует процедуру уведомления «SM pdu NOTIFICATION», которая приводит к инициируемой сетью активизации PDP. После получения сообщения запроса уведомления «SM pdu
Рис. 11.23. Передача пакетов данных в восходящем и нисходящем направлениях
NOTIFICATION REQUEST» узел SGSN посылает оповещение котроллерам RNC, которые управляют теми областями маршрутизации маршрутизацией RA, где оборудование UE последний раз проводило процедуру RAU. Контроллеры RNC выполняют процедуру поиска UE, посылая в его направлении сообщение «RRC PAGING TYPE I». Так как оборудование UE непрерывно перемещается, оно должно снова выполнить обновление соты, с тем чтобы на RNC была зарегистрирована действительная информация о соте.
После обновления соты активизируется контекст PDP так же, как и несущий канал RAB, и пакеты данных начинают следовать от GGSN к UE. Если в UE есть какие-либо пакеты данных, подлежащие передаче, они могут передаваться в это же время. Пакеты данных, передаваемые в восходящем направлении, обрабатываются, как описано ранее. При отсутствии подлежащих передаче данных контекст PDP снова дезактивируется и канал RAB освобождается.
11.6. Примеры мультимедийных услуг IP-IMS
Ранее (глава 6) мы представили структуру мультимедийной системы IP—IMS и некоторые примеры услуг IMS, которые могут быть предложены. В этом разделе мы представим два упрощенных примера функциональных возможностей IMS. Мультимедийная система IP IMS — относительно сложный элемент. Желающим ознакомиться с деталями рекомендуем работу Poikselka и др. (2004), приведенную в списке литературы.
В качестве примеров мы выбрали две процедуры, первая — регистрация IMS, вторая — упрощенная версия мультимедийного сеанса IMS.
11.6.1. Пример регистрации IMS
Предмет данной процедуры состоит в регистрации и предоставлении абоненту полномочий на использование услуг Интернета и организацию мультимедийного сеанса. На рис. 11.24 показаны основные объекты, вовлеченные в процедуру регистрации IMS.
В этом примере мы предполагаем, что реализация услуг IMS проводится на основе существующей системы GPRS, в которой операторы обычно не допускают использования группового имени точки доступа APN (Access Point Name) (т. е. пользователь вынужден установить соединение GPRS через шлюз GGSN, расположенный в домашней сети пользователя).
Прежде чем может быть установлена сигнализация протокола PDP, оборудование UE и сеть должны организовать соединение RRC так, как это пояснялось ранее в данной главе. В данном примере SGSN определяет с помощью сервера доменных имен DNS (Domain Name Server) адрес шлюза GGSN в домашней сети абонента. Если абонент имеет право использования услуг IMS, то для организации соединения IMS потребуются некоторые параметры. Самый первый — это адрес прокси-функции (функции представительства) управления сеансом связи P-CSCF. Он может быть заранее сконфигурирован и сохранен в идентификационном модуле IMS—ISIM, но это очень ограничивает использование адресного пространства. Вместо этого оборудование UE будет в выигрыше, используя свою возможность запрашивать адрес P-CSCF во время формировании контекста PDP. Когда требуется, то во время этого запроса активизации контекста PDP шлюз GGSN возвращает оборудованию UE префикс адреса IPv6 P-CSCF. В еще одном альтернативном варианте может быть использована динамическая схема распределения адреса, когда протокол динамической конфигурации ведущего узла (DHCPv6) выдает адрес P-CSCF. В этом случае любое дальнейшее определение адреса P-CSCF может проводиться с помощью сервера DNS.
Когда оборудованию UE известен адрес P-CSCF, то оно передает P-CSCF в сообщении регистрации — «SIP REGISTER». Структура сообщения «SIP REGISTER» использует некоторые параметры, находящиеся в
Рис. 11.24. Процедура регистрации IMS
модуле IS1M оборудования UE. Эти параметры представляют собой различные идентификаторы, используемые в контексте IMS:
• личный идентификатор пользователя;
• общедоступный идентификатор пользователя (поскольку их может быть несколько, то по умолчанию первый в списке используется для регистрации IMS);
• домен домашней сети;
• адрес IP, выделенный для UE в гостевой сети.
Общедоступные и личные идентификаторы были представлены в главе 6 в подразделах 6.2.1.1.7 и 6.2.1.1.8. Личная идентификация будет кратко обсуждаться, когда мы рассмотрим аспекты, связанные с защитой информации.
Из соображений безопасности идеальной ситуацией для среды IMS было бы использование собственных специализированных идентификаторов IMS. Однако IS1M не обязательно всегда имеется в оборудовании UE. В таких случаях идентификаторы должны выделяться с помощью стандартного универсального модуля USIM. По соображениям безопасности результаты этого процесса никогда не должны раскрываться за пределами среды IMS. Например, если бы личный идентификатор пользователя был построен таким образом, то он стал бы очень похож на идентификатор IMSI.
Прежде чем прокси-функция управления сеансом связи P-CSCF сможет передать сообщение «REGISTER» дальше, она должна разработать маршрут к соответствующей обслуживающей функции управления сеансом связи S-CSCF. Для этой цели IMS содержит запрашивающую функцию управления сеансом связи I-CSCF, которая запрашивает сервер HSS. В этом примере (рис. 11.24) предполагается, что, поскольку P-CSCF и S-CSCF поддерживаются одним и тем же элементом IMS в одной и той же физической сети, то функции I-CSCF и P-CSCF объединены. Когда определен верный адрес S-CSCF, сообщение «REGISTER» маршрутизируется к S-CSCF.
По принятому в сообщении «REGISTER» идентификатору пользователя S-CSCF может получить от сервера HSS данные аутентификации. В сети UMTS эти данные содержат описания безопасности UMTS (как было описано в главе 9). Эти наборы параметров безопасности известны как «векторы аутентификации», и каждый из них содержит:
• случайный вызов (RAND);
• ожидаемый результат (XRES);
• признак аутентификации сети (AUTN);
• ключ целостности (IK);
• ключ шифрования <СК).
На этом этапе никакой точной информации о пользователе нет: с точки зрения функции S-CSCF это означает, что кто-то вышел на контакт под правильно выглядящим адресом без каких-либо гарантий. Чтобы проверить подлинность контактного лица (т. с. что пользователь является именно тем лицом, которым он себя заявляет), S-CSCF посылает в оборудование UE вызов в виде сообщения «SIP 401 UNAUTHORIZED». S-CSCF заполняет это сообщение данными векторов аутентификации (например, параметрами RAND и AUTN). Однако ключи IK и СК, размещенные в полях, P-CSCF считывает и сохраняет; эти значения никогда не попадают в оборудование UE.
UE вычисляет ответ на вызов P-CSCF и отвечает новым сообщением «SIP REGISTER», которое на сей раз содержит личный идентификатор пользователя, RAND, AUTN и вычисленный ответ RES. В то же время UE вычисляло IK. И вот теперь прокси-функция P-CSCF и оборудование UE могут проверить целостность трафика между ними.
Сообщение «SIP REGISTER» достигает функции S-CSCF, которая проверяет ц сравнивает XRES и значение RES, переданное оборудованием UE. Если они совпадают, пользователь аутентифицирован (подлинность пользователя подтверждена). Аутентификация в обратном направлении была выполнена, когда UE приняло вызов (например, то сообщение содержало признак AUTN, который позволил UE определить, была ли сеть реальной или поддельной). Успешное установление подлинности завершается сообщением «SIP 2D0 OK», которое S-CSCF посылает в оборудование UE.
Когда проблемы безопасности решены, выполняется так называемая подписка, абонирование — «абонемент IMS». Подписка (или абонирование) — это процедура, в течение которой устанавливается срок регистрации. По умолчанию продолжительность регистрации IMS составляет 600 000 секунд (приблизительно 7 дней). Кроме того, процедура абонирования ответственна за регистрацию общедоступных идентификаторов пользователя, отличающихся от устанавливаемого по умолчанию (пока единственного зарегистрированного).
Подписка сначала проводится между UE и S-CSCF. Эта процедура уведомляет UE не только обо всех общедоступных идентификаторах пользователя, которые данный пользователь IMS имеет, но также и о состоянии регистрации этих идентификаторов.
Эта же информация должна быть представлена в P-CSCF. Абонирование проводится отдельно между P-CSCF и S-CSCF. Когда подписка выполнена, то UE получает соединение с IMS и может организовать мультимедийные вызовы и/или использовать другие услуги, доступные через IMS.
11.6.2. Пример сеанса IMS
В этом примере показано, как организовывается сеанс IMS (рис. П.25), как в передаче сообщений участвуют элементы сети плоскости пользователя (рис. II.26) и как прекращается сеанс IMS (рис. 11.27).
Здесь используются те же предположения, что и в предыдущем примере (т.е. оборудование UE А перемещается, а соединение GPRS завершается в шлюзе GGSN домашней сети). Оборудование UE В расположено в домашней сети. Устройства UE А и UE В относятся к одной домашней сети. Они оба выполнили регистрацию IMS и, таким образом, доступны друг другу.
На рис.11.25 показана схема обмена сигналами оборудования UE А, связывающегося с оборудованием UE В. Организация сеанса IMS начинается запросом-приглашением «SIP INVITE». Заголовок этого запроса содержит два общедоступных идентификатора: один — идентификатор вызывающей стороны (в данном случае — А), а другой — идентификатор вызываемой стороны (в данном случае — В). Эта информация принимается функцией P-CSCF, которая затем маршрутизирует ее к функции S-CSCF оборудования пользователя UE А. На этом этапе система располагает информацией только о конечном адресате запроса «SIP INVITE» (т.е. о зарегистрированном общедоступном идентификаторе UE В). Функция 1-CSCF состоит в том, чтобы связаться с HSS и выяснить, где этот общедоступный идентификатор был зарегистрирован, т. е. в какой S-CSCF он может быть найден. После получения этой информации запрос «INVITE» направляется к S-CSCF оборудования UE В, которая, в свою очередь, маршрутизирует его на UE В через функцию P-CSCF UЕ В. Запрос «INVITE» содержит всю требуемую для
Рис. 11.25. Организация сеанса IMS
организации мультимедийного сеанса информацию о средствах и кодировании. Это так называемое первое предложение SDP (SDP — протокол описания сеанса).
Во время перемещения запроса INVITE различные функции CSCF добавляют к нему свою адресную информацию. Когда запрос INVITE достигает UE В, оно добавляет собственный IP адрес к списку, указывающему все остальные участвующие в процессе элементы, например адреса всех других сообщений в рамках этого диалога. Оборудование UE В также добавляет номер порта, который необходимо использовать для этого сеанса. Таким образом, все последующие сообщения будут использовать установленную ассоциацию безопасности SA протокола IPSec.
Рис. 11.26. Плоскость пользователя сеанса IMS
Оборудование UE А после передачи запроса INVITE запускает таймер (отсчет времени) на 2 с. Все это время UE А ждет ответ от сети. Ожидаемый ответ представляет собой сообщение SIP 183 SESSION PROGRESS. С большой долей вероятности этот ответ не вернется через выделенные 2 секунды; поэтому используется промежуточный ответ SIP 100 TRYING. Сообщение SIP 100 TRYING сообщает оборудованию UE А, что повторная передача запроса INVITE нецелесообразна и что при необходимости повторных передач их будет проводить прокси-функция P-CSCF.
Сообщение SIP183 SESSION PROGRESS проходит в обратном направлении к UE А. Функция P-CSCF UE A — последний элемент, обрабатывающий это сообщение, прежде чем оно фактически достигает UE А. На этом этапе P-CSCF добавляет к сообщению номер своего порта; при выполнении этого соединения используется ассоциация безопасности SA протокола IPSec. Когда сообщение SIP 183 SESSION PROGRESS достигает оборудования UE А, в нем сохраняется адрес IP UE В, а также информация о маршрутизации. Это сообщение содержит ответ на «первое предложение SDP», включенное в исходный запрос INVITE. Ответ в сообщении SIP 183 SESSION PROGRESS включает информацию о средах и кодах передачи и называется первым ответом SDP.
После получения сообщения SIP 183 SESSION PROGRESS UE А отвечает сообщением «prack PROVISIONAL ACKnowlegement» {временное ответное подтверждение). Это сообщение также называется «вторым предложением SDP»; оно содержит информацию, определяющую по одному кодеку для каждого вида передачи. UE В подтверждает прием prack сообщением SIP 200 ok, указывая, что обе стороны договорились использовать кодек и среду данного типа. Это называется «вторым ответом SDP».
После этого обе стороны инициируют резервирование ресурсов. Фактически резервирование ресурсов — это то же самое, что и установление контекста PDP, связанного со средой передачи, который, в свою очередь, представляет собой набор параметров, описывающих плоскость пользователя для данного мультимедийного сеанса (например, определения QoS).
До сих пор оборудование UE В не показало своему пользователю, что будет установлен входящий мультимедийный сеанс, поскольку все еще нет никаких гарантий в установлении сеанса. Эти гарантии появляются только после того, как обе стороны успешно зарезервировали ресурсы. Как только оборудование UE А это сделало, оно передает в направлении оборудования UE В сообщение обновления — SIP UPDATE. Это сообщение называется
Рис. 11.27. Прекращение сеанса IMS
третьим предложением SDP и показывает, было ли успешным резервирование ресурсов и все ли требования выполнены. Если резервирование ресурсов со стороны UE В прошло успешно, то оно посылает сообщение SIP 200 ok, которое называется третьим ответом SDP. После этого обмена сообщениями в плоскости пользователя все готово к маршрутизации.
UE В уведомляет UE А, что собирается сообщить своему пользователю о входящем мультимедийном сеансе и делает это с помощью сообщения SIP 180 RINGING. UE А подтверждает состояние соединения, посылая SIP prack. Когда пользователь UE В реагирует на вызов, оборудование UE В посылает SIP 200 ok, показывая, что плоскость пользователя может быть открыта. Это подтверждается сообщением SIP ack. И вот теперь сеанс IMS установлен, a UE А и UE В имеют между собой мультимедийное соединение с желательными и согласованными типами средств и кодеков. На рис. 11.26 показан пример того, как может проходить плоскость пользователя через различное оборудование.
В этом примере предполагается, что соединение прерывается по инициативе UE В. Разъединение начинается передачей сообщения SIP bye. Как только сообщение SIP bye передано, UE В освобождает средства PDP-koh-текста и закрывает плоскость пользователя. Когда SIP bye достигает UE А, то оно, соответственно, также освобождает средства PDP-контекста. Оборудование UE А отвечает на сообщение SIP bye, посылая SIP 200 ok. Этим сообщением оно дает указание CSCF на очистку всей информации и адресных таблиц, связанных с этим мультимедийным сеансом.
1G — 1-е поколение
2G — 2-е поколение
3GPP — 3G Partnership Project — Объединение по разработке стандартов мо-
бильной связи 3-го поколения
3GPP R4 (5) — 4-я (5-я) версия (редакция) проекта 3GPP
3GPP R99 - редакция проекта 3GPP 1999 г.
16QAM — Quadrature Amplitude Modulation — квадратурная амплитудная моду-
ляция, 16-позиционная — КАМ16
8-PSK — Phase Shift Keying, octagonal — фазовая манипуляция, 8-кратная
(ФМН-8)
ААА — Authentication, Authorization and Accounting — аутентификация,
авторизация и учет
AAL — ATM Adaptation Layer — уровень адаптации ATM
ABR — Available Bit Rate — доступная скорость передачи
AC — Admission Control — управление по входу
ACK — acknowledgement — уведомление (об успешном приеме данных)
ACM — Address Complete Message — исполнение адресного сообщения
ACTS — Advanced Communications Technology and Services — программа
совершенствования средств и услуг связи
AGCH — Access Grant CHannel — канал предоставления доступа.
АН — Authorization Header — заголовок авторизации
AICH — Acquisition Indication CHannel — канал обнаружения захвата
АК — An anonymity key — анонимный ключ
АКА — Authorization and Key Agreement — соглашение об авторизации
и ключе
AM — Acknowledged Mode — режим подтверждения
АМС — Adaptive Modulation and Coding — адаптивная модуляция и кодиро-
вание
AMF — Authentication Management Field — поле управления аутентификацией
AMPS — American Mobile Phone System — американская система мобильной
связи
AMR — Adaptive Multi Rate — многоскоростная адаптация
AOA — Angle of Arrival — угол падения
АР — Access Point — точка доступа
АР — Application Part — прикладная часть
API — Application Programming Interface — интерфейс программных прило-
жений
APN — Access Point Name — имя точки доступа
ARIB — Association of Radio Industries and Business — Ассоциация радиопро-
мышленности и предпринимательства, Япония.
ARQ — Automatic Repetition Query/Repeat Request — автоматический запрос
повторенной передачи
AS — Application Server — сервер приложений
AS — Autonomous System — автономная система (совокупность маршрути-
заторов, находящихся в распоряжении единого административного звена сети и использующих общий внутренний шлюзовой протокол маршрутизации пакетов)
ATD — Absolute Time Difference — абсолютная разница во времени
ATM — Asynchronous Transfer Mode — асинхронный режим передачи, а также
одноименная технология с пакетами (ячейками) фиксированной длины AuC — Authentication Centre — центр аутентификации AUTN — An authentication token — метка аутентификации AUTS — An authentication key in re-synchronization — ключ аутентификации при повторной синхронизации
AV — Authentication Vector — вектор аутентификации
ВССН — Broadcast Control Channel — канал управления вещательного типа ВССН — logical Broadcast Control CHannel — логический вещательный канал
управления
ВСН — Broadcast Channel — канал вещания, канал радиовещания BCFE — Broadcast Control Function Entity — элемент функции управления вешанием
BGCF — Breakout Gateway Control Function — функция управления коммутационным шлюзом
BICC — Bearer Independent Call Control — независимое управление каналами B-1SDN - Broadband ISDN - широкополосная ЦСИО (Ш-ЦСИО) BML — Business Management Layer — уровень управления предприятием (бизнесом)
BS — Base Station — базовая станция БС
BSA — Basic Service Area — базовая, основная зона обслуживания BSC — Base Station Controller — контроллер базовой станции BSS — Base Station Subsystem — подсистема базовой станции
BSS — Base Station System — система базовой станции BSS — Basic Service Set — основной, базовый набор услуг BSSI — Basic Service Set Identifier — идентификатор основного комплекта
обслуживания
BTS — Base Transceiver Station — базовая приемопередающая станция СА — Certification Authority — орган сертификации
CA-ICH — Channel Assignment Indicator CHannel — индикации присвоенного канала CAMEL — Customized Application for Mobile network Enhanced Logic — заказные
приложения для усовершенствованной логики мобильной сети САРЕХ — Capita! Expenditure — капиталовложения СС — Country Code — код страны
СС — Call Control — управление вызовом
ССА — Clear Channel Assignment — выделение свободных каналов СССН — Common Network Channel — общий канал управления ССН — Common CHannel — общий канал
CCF — Charging Collection Function — функция сбора информации тарификации ССК — Complementary Code Keying — дополняющая кодовая манипуляция ССРСН — Common Control Physical CHannel — физический общий канал управления
CD-ICH — Collision Detection Indicator CHannel — индикация обнаруженных коллизий CDMA — Code Division Multiply Access — многостанционный доступ с кодовым разделением каналов
CF — Connection Frame — кадр соединения
CFN — Connection Frame Number — номер кадра соединения CFP — Connection Free Period — период, свободный от соединения CGI — Cell Global Identity — глобальный идентификатор соты CI — Cell ID — идентификатор соты
СК — Ciphering Key — ключ шифрования
CLP — Cell Loss Priority — приоритет потерь ячеек CLPC — Closed Loop Power Control — регулирование мощности с замкнутой
цепью управления
СМ — Communication Management — управление средствами связи СМ — Communication Management — управление связью CN — Core Network — базовая, основная есть
CN-id — Core Network Identifier — идентификатор базовой сети СРСН — Common Packet Channel — общий пакетный канал
CPICH — Common Pilot Channel — общий контрольный канал
CPICH — Primary Common Pilot Channel — общий первичный контрольный
канал
CQI — Channel Quality Indication — индикация качества канала
CRC — Cyclic Redundancy Check — контроль с помощью циклического
избыточного кода
CRNC — Controlling RNC — управляющий RNC
CS — Channel Switching — коммутация каналов КК
CS — Circuit Switching — коммутация каналов КК
CSCF — Call Session Control Function — функция управления сеансом
CSMA/CA — Carrier Sense Multiple Access with Collision Avoidance — многостанционный доступ с контролем несущей и предотвращением конфликтов
CSPDN — Circuit Switched Public Data Network — СПД общего пользования
с КК
СТСН — Common Traffic Channel — общий канал трафика
CTS — Clear-to-Send — готовность для передачи
CWTS — China Wireless Telecommunication Standard group — группа стандар-
тизации беспроводной связи, Китай
DBPSK — Differential Binary Shift Keying — относительная (дифференциаль-
ная) двоичная фазовая манипуляция — ОФМН
DCCH — Dedicated Control Channel — выделенный канал управления
DCF — Distributed Coordinating Function — функция распределенной коор-
динации
DCH — Dedicated CHannel — выделенный канал
DHCP — Dynamic Host Configuration Protocol — протокол динамической
конфигурации хоста (сетевой стандарт, регламентирующий процесс присваивания сервером IP-адресов и другой информации)
DL — Down link — нисходящий (обратный, входящий по отношению
к абоненту) канал или направление передачи
DNS — Domain Name Server — сервер доменных имен (служебный компь-
ютер сети, переводящий имена компьютеров в доменных записях в адреса IP)
DPCCH — Dedicated Physical Common CHannel — выделенный общий физический канал
DPCH — Dedicated Physical Channel — выделенный физический канал
DPDCH — Dedicated Physical Data CHannel — выделенный физический канал данных
DQPSK — Differential Quadrature (quaternary Shift Keying) — относительная
квадратурная фазовая манипуляция ОФМ-4
DRNC - Drifting RNC - дрейфующий RNC
DSCH — Downlink Shared Channel — исходящие каналы совместного исполь-
зования
DSSS — Direct Sequence Spread Spectrum — метод расширения спектра пря-
мой последовательностью
DS-WCDMA — FDD — WCDMA с частотным разделением дуплексных каналов и с расширением спектра прямой последовательностью
DTCH — Dedicated Traffic Channel — выделенный канал трафика
E2L IP — End-to-End IP — сквозной Интернет
EDGE — Enhanced Data for GSM Evolution — усовершенствованная система
передачи данных в GSM
E1R — Equipment Identity Register — регистр идентичности оборудования
ETSI — European Telecommunications Standards Institute — Европейский ин-
ститут стандартизации в электросвязи
FACCH — Fast Associated Control CHannel — быстрый канал управления
FACH — Forward Access Channel — канал прямого доступа
FBI — Feedback Information — информация обратной связи
FCCH — Frequency Correction CHannel — канал коррекции частоты
FDD — Frequency Division Duplex — дуплекс с частотным разделением
(направлений) — ЧРД
FDMA — Frequency Division Multiply Access — многостанционным доступом
с частотным разделением каналов
FHSS — Frequency Hopping Spread Spectrum — расширение спектра методом
частотных скачков
FPLMTS — Future Public Land Mobile Telephony System — система мобильной телефонии общего пользования будущего
FPS — Fast Packet Scheduling — быстрое пакетное планирование
FR — Frequency Reuse — коэффициент повторного использования частот
FRAMES — Future Radio Wideband Multiple Access System — проектная группа:
система широкополосного многостанционного радиодоступа будущего
GERAN — GSM/EDGE Radio Access Network — сеть радиодоступа с GSM/ EDGE
GGSN — Gateway GPRS Support Node — шлюз ядра сети GPRS
GMLC — Gateway Mobile Location Center — шлюз мобильного центра опреде-
ления местоположения
GMM — GPRS Mobility Management — управление мобильностью GPRS
GMSC - Gateway MSC - шлюз MSC
GMSK — Gaussian Minimum Shift Keying — гауссовская манипуляция с мини-
мальным частотным сдвигом
GPS — Global Positioning System — глобальная радионавигационная система
позиционирования
GPRS — General Packet Radio Service — общая служба передача пакетов в ра-
диосети
GSM — Global System Mobile — глобальная система мобильной связи
GT — Global Title — глобальный заголовок
GTD — Geometric Time Difference — геометрическая разность времени
GTP — GPRS Tunnelling Protocol — протокол туннелирования (сквозной
передачи GPRS
HARQ — Hybrid Automatic Repeat Request — гибридная система автоматиче-
ского повторного запроса
HSC — Hierarchical Cell Structure — иерархическая структура ячеек (сети)
HSDPA — High Speed Downlink Packet Access — высокоскоростной НК пакетного доступа
HS-DPCCH — High Speed Dedicated Shared Control Channel — высокоскоростной совместно используемый выделенный канал управления
HS-DSCH — High Speed DSCH — высокоскоростной исходящий канал совместного использования
HSISD — High Speed Circuit Switched Data — высокоскоростная передача дан-
ных с коммутацией каналов
HS-PDSCH — High Speed Physical Downlink Shared Channel) — высокоскоростной физический нисходящий канал совместного использования
HS-SCCH — High Speed Shared Control Channel — высокоскоростной канал управления совместного использования
HTML — HyperText Markup Language — язык HTML
HW — Hard Ware — аппаратное обеспечение
1BSS — Independent Basic Service Set — независимое обслуживание базового
комплекта
I-CSCF — Intcrrogating-Call Session Control Function — опрашивающая функция управления сеансом
IEFT — Internet Engineering Task Force — рабочая группа по проблемам Ин-
тернета
IMEI — International Mobile Equipment Identity — международный идентифи-
катор мобильного оборудования
IMEISV — International Mobile Equipment Identity and Software Version — расширенный вариант международный идентификатор мобильного оборудования с указанием версии программного обеспечения
IMS — IP Multimedia Subsystem — подсистема мультимедиа на основе про-
токола IP, мультимедийная подсистема IP
IMT2000 — International Mobile Telephony 2000 — Международная система мобильной телефонии-2000
IN — Intelligence Network — интеллектуальная сеть
IP — Internet Protocol — интернет-протокол
ISCP — Interference Signal Code Power — мощность помехи в кодовом сигнале
ISDN — Integrated Services Digital Network — ЦСИО (цифровая сеть с интегра-
цией обслуживания).
LA — Location Area — область местоположения
LAC — Location Area Code — кол области местоположения
LAI — Location Area Identity — идентификатор области местоположения
LAN — Local Area Network — локальная вычислительная сеть
LCS — Location Based Services — местные услуги
LOS — Line of Sight — линия прямой видимости
MAC — Medium Access Control — управление доступом к среде передачи
MAP — Mobile Application Part — раздел мобильных приложений
MCS — Modulation Coding Scheme — схема кодовой модуляции
ME — Mobile Equipment — мобильное оборудование
МЕНО — Mobile Evaluated HandOver — переключение на основе оценки абонента
MIB — Master Information Block — ведущий информационный блок
ММ — Mobility Management — управление мобильностью
MS — Mobile Station — мобильная станция (МС), абонентский телефон
(терминал)
MSC — Mobile Switching Center — коммутационный центр мобильной связи
MSIN — Mobile Subscriber Identification Number — идентификационный номер
мобильного абонента
NAV — Network Allocation Vector — вектор распределения ресурсов сети
NE — Network Element — сетевой элемент СЭ
NEHO — Network Evaluated HandOver — переключение на основе оценки сети NMS — Network Management Subsystem — подсистема управления сетью
NMT — Nordic Mobile Telephone — северная мобильная телефония NRT — Non Real Time — режим относительного времени
NSS — Network Subsystem — подсистема сети (в GSM)
NSS — Nodal Switching System — узловая коммутационная система
О&М — Operation and Maintenance — техническая эксплуатация и обслуживание OFDMA — Orthogonal Frequency Division Multiple Access — многостанционный
доступ с ортогональным частотным разделением OHG — Operator Harmonization Group — группа гармонизации деятельности
операторов
OLPC — Open Loop Power Control — разомкнутая цепь регулирования мощности ОМА — Open Mobile Alliance — открытый мобильный альянс
ОРЕХ — Operation and Maintenance Expenditure — расходы на эксплуатацию
и техобслуживание РАССН — Packet Associated Control CHannel — канал управления пакетным
доступом PAGCH — Packet Access Grant CHannel — канал предоставления пакетного доступа
РВСС — Packet Binary Convolution Code — двоичный сверточный код пакета PBS — Physical Bearer Service — служба физических трактов
РССН — Paging Control Channel — канал управления поиском Р-ССРСН — Primary Common Control Physical CHannel — первичный физический обший канал управления
PCF — Point Coordinating Function — функция координации пунктов
РСН — Paging Channel — пейджинговый, поисковый канал
РСРСН — Physical Common Packet CHannel — физический общий пакетный
канат Р-СРСН — Primary Common Control Physical CHannel — первичный общий канал
управления PCS — Personal Communication System — персональная система связи, аналог
GSM в США
P-CSCF — Proxy-Call Session Control Function — прокси-функиия управления сеансом
PDC — Pacific Digital Communications — Тихоокеанская цифровая связь, японский стандарт мобильной связи второго поколения — 2G
PDF — package definition file — файл определения пакета
PDF — Policy Decision Function — функция принятия решений
PDP — Packet Data Protocol — протокол пакетных данных
PDSCH — Physical Downlink Shared CHannel — нисходящий совместно используемый физический канал
PDTCH — Packet Data Traffic Channel — транспортный канал с пакетной передачей данных
PDU — Protocol Data Unit — протокольная единица обмена, модуль данных протокола
PICH — Paging Indicator Channel) — выделенный каналом пейджинговой индикации
РММ — Packet Mobility Management — управление мобильности при коммутации пакетов
РРСН — Packet Paging CHannel — пакетный пейджинговый канал
PRACH — Packet Random Access CHannel — пакетный канал со случайным доступом
PRACH — Physical Random Access CHannel — физический канал со случайным доступом.
PRN — Pseudo-Random Numerical sequence — псевдослучайная (числовая) последовательность ПСП
PS — Packet Scheduler — планировщик пакетов
PS — Packet Scheduler — пакетное планирование
PS — Packet Switching — коммутация пакетов КП
PSPDN — Packet Switched Public Data Network — пакетная сеть передачи данных общего пользования
QAM — Quadrature Amplitude Modulation — квадратурная амплитудная модуляция
QoS — Quality of Service — качество и класс предоставляемых услуг
QPSK — Quadrature (quaternary Phase-Shift Keying — фазовая манипуляция с четвертичными сигналами
RA — Routing Area — область маршрутизации
RAB — Radio Access Bearer — несущие радиосишалы доступа
RAC — Routing Area Code — код области маршрутизации
RACE — Research in Advanced Communications in Europe) — программа НИР
и ОКР Европейского союза по созданию усовершенствованной системы мобильной связи 3-го поколения для Европы, программа RACE
RACH — Random Access CHhannel — канал случайного доступа
RAN — Radio Access Network — есть радиодоступа
RANAR — Radio Access Network Application Part — прикладная часть сети радиодоступа
RAP — Random Access Procedure — процедура случайного доступа
RB — Radio Bearer — несущие радиочастоты
RIR — Signal to Interference Ratio — защищенность, отношение сигнал-помеха
RL — Radio Link — радиоканал
RLC — Radio Link Control — управление радиоканалом
RMC — Maximum Ratio Combining — Максимальный коэффициент объединения
RNC — Radio Network Controller — контроллер радиосети
RNS — Radio Network Subsystem — подсистема радиосети
RNTI — Radio Network Temporary Identifier — идентификатора регистрационной зоны радиосети
RRC — Radio Resource Control — управления радиоресурсами
RRM — Radio Resource Management — управление радиоресурсом
RT — Radio Termination — радиоокончание
RT — Real Time — реальное время
RTS — Request-to-Send — готовность к передаче
SAC — Service Area Code — код зоны обслуживания
SACCH — Slow Associated Control CHannel — медленный канал управления
SAI — Service Area identifier — идентификатор зоны обслуживания
SAW — Stop-and-Wait — процедура повторной передачи, называемая «стой
и жди»
SB — Scheduling Block — блок планирования
SCCP — Signaling Connection Control Part — управляющие сигналы соединения
SCH — Synchronization CHannel — канал синхронизации
SCR — System Chip Rate — скорость следования чипов в системе
S-CSCF — Serving-Call Session Control Function — обслуживающая функция управления сеансом
SDCCH — logical Stand-alone Dedicated Control Channel — автономный логический выделенный канал управления
SDCCH — Stand alone Dedicated Control Channel — автономный выделенный канал управления
SDP — Session Description Protocol — протокол описания сеанса
SF — Spread Factor — коэффициент расширения
SGSN — Service GPRS Support Node — коммутатор пакетов ядра сети GPRS
(управляющий узел поддержки GPRS)
SIB — System Information Block — системный информационный блок
SNA — Shared Network Area — совместно используемая зона сети
SNAC — Shared Network Area Code — код совместно используемой зоны сети
SNF — System Frame Number — система нумерации циклов
SNR — Serial Number — серийный номер телефона
SNRC — Serving RNC — обслуживающий RNC
SRB — Signaling Radio Bearer — несущие радиочастоты сигнализации
SRNS — Serving RNS — обслуживающая RNS
SSDT — Site Selection Diversity Technique — способ управления мощностью
с возможностью выбора станции
SVN — Software Version Number — номер версии программного обеспечения
данного оборудования
SW — Soft Ware — программное обеспечение
Т — Telecommunications — сектор телекоммуникации американского на-
ционального института стандартизации — ANSI
ТА — Transmitter Address — адрес передатчика
ТАС — Type Allocation Code — код типа оборудования, определяющий
производителя и тип телефона
ТСН — logical Traffic CHannel — логический канал трафика
ТСН — Traffic CHannel — транспортный канал
TCP — Transmission Control Protocol — протокол управления передачей
TDD — Time Division Duplex — дуплекс с временным разделением (направ-
лений — ЧРД
TDM — Time Division Multiplexing — временное разделение каналов ВРК.
TDMA — Time Division Multiple Access — многостанционный доступ с времен-
ным разделением — МДВР
TFRC — Transport Format and Resource Combination — комбинирование
транспортных форм и ресурсов
THIG — Topology Hiding Inter-network Gateway — межсетевой типологически
скрытый шлюз
TMN — Telecommunication Management Network — сеть управления телеком-
муникациями
ТРС — Transmission Power Command — команда регулирования мощности
ТРС — Transmit Power Control — регулировка мощности передачи
TR — Receiver Address — адрес приемника
TRAN — Transcoding and Rate Adaptation Unit — блок транскодирования
и адаптации скорости
TRFI — Transport Format and Resource Indicator — указатель формата переда-
чи и комбинации ресурсов
TRX — Transmitter-Receiver — приемопередатчик
ТТЛ — Telecommunication Technology Association — ассоциация телекомму-
никационных технологий
ТТС — Telecommunications Technology Committee — комитет телекоммуни-
кационных технологий Японии
TTI — Transmission Time Interval — временной интервал передачи
TTP — Traffic Termination Points — оконечная точка (трафика)
UE — User Equipment — оборудование абонента, оборудование пользова-
теля, абонентский терминал
UL — Up link — восходящий (исходящий от абонента) канал (ВК) или на-
правление передачи
UMTS — Universal Mobile Telecommunication System — универсальная мобиль-
ная телекоммуникационная система (УМТС)
URA — UTRAN Registration Area — регистрационная зона UTRAN
URI — Uniform Resource Identifier — унифицированный идентификатор ре-
сурсов
URL — Uniform Resource Locator — унифицированный определитель ресурсов
U-RNTT — Radio Network Temporary Identify — временный идентификатор радиосети
USAT — UMTS SIM Application Toolkit — прикладной набор SIM UMTS
UTRA — Universal Terrestrial Radio Access — универсальная наземная система
радиодоступа УМТС Uu — радиоинтерфейс
VAS — Value Added Service — добавленная (дополнительная) услуга
VMSC — Visited Mobile Switching Centre — гостевым мобильным коммутаци-
онным центром
VSF — Variable Spreading Control — управление переменным коэффициен-
том расширения спектра WAP — Wireless Application Protocol — протокол беспроводных приложений
Интернет WCDMA — широкополосный многостанционный лоступ с кодовым разделением
каналов
WEP — Wired Equivalent Privacy — эквивалент проводной конфиденциальности
Wi-Fi — Wireless Fidelity Alliance — беспроводное качество
WLAN — Wireless Local Area Network — беспроводная локальная вычислитель-
ная сеть
Русскоязычные сокращения
БС — базовая станция — BS
ВК — восходящий канат — UL, с точки зрения абонента, это исходящее
направление канала, прямой канал — «туда» ВРК — временное разделение каналов — TDM
ЗМ — область местоположения — Location Area — LA
ЗП — зона поиска (пейджинга) — Paging Area — PA
КК — коммутация каналов — CS
КП — коммутация пакетов — PS
МДВР — многостанционный доступ с временным разделением — TDMA
МС — мобильная станция — Mobile Station — MS
НК — нисходящий канал — DL, с точки зрения абонента, это входящее,
обратное направление канала — «обратно» ПЦИ — плезиохронная цифровая иерархия — PDH — Plesiochronous Digital
Hierarchy
СПД — сеть передачи данных — Public Data Network — PDN
СПДОП — сеть передачи данных общего пользования — PSPDN СПДОПКК — СПД общего пользования с КК — CSPDN
СЦИ — синхронная цифровая иерархия - SDH - Synchronous Digital Hierarchy
СЭ — сетевой элемент — NE — Network Element
ТСОП — телефонная сеть (коммутируемая) общего пользования — PSTN
ЦСИО — цифровая сеть с интеграцией обслуживания — ISDN
ЧРД — дуплекс с временным разделением (направлений) — TDD
ЧРД — дуплекс с частотным разделением (направлений) — FDD
ЧРК — частотное разделение каналов — FDM
Ш-ЦСИО — широкополосная ЦСИО - B-ISDN