ЧАСТЬ 3

 

ГЛАВА  10

 

ПРОТОКОЛЫ UMTS

Ары Ахтиайнен

(An Ahtiainen)

 

В предыдущих главах мобильная универсальная система UMTS рассматрива­лась с позиций подсистем и сетевых элементов. Элементы сети функцио­нально были разделены по закрепленным за ними функциям управления си­стемного уровня. В то же время были введены интерфейсы между различны­ми классами элементов сети.

В данной главе представлен обзор интерфейсов сети UMTS с акцентом на используемые системные протоколы. Протоколы UMTS управляют выполне­нием сетевых функций, обеспечивая согласование системных интерфейсов,

В разделах 10.1 — 10.6 рассматриваются основные протоколы сети UMTS (т. е. протоколы сети доступа UTRAN и базовой сети CN). Учитывая незави­симость мультимедийной подсистемы IP IMS от технологий доступа, прото­колы для организации сети IMS и предоставления соответствующих услуг рассматриваются отдельно в разделе 10.7.

 

10.1. Эталонные архитектуры протоколов 3GPP

 

Поскольку задача разработки протоколов была разделена между различными группами, то совершенно естественно, что каждая группа создала свою соб­ственную эталонную архитектуру для тех протоколов, на разработку которых получила полномочия. Это привело к появлению трех основных секторов, с собственными эталонными моделями протоколов каждый.

Прежде чем представить объединенную модель всех протоколов сети UMTS, рассмотрим каждую из этих трех эталонных моделей. Так случилось, что в этих моделях использовано несколько принципов построения основ­ных протоколов, которые мы можем использовать при синтезе структур ком­бинированных протоколов.

 

10.1.1. Эталонная модель протокола радиоинтерфейса

 

Радиоинтерфейс сети доступа UTRAN основывается на радиотехнологии широкополосного многостанционного доступа с кодовым разделением кана­лов WCDMA, которая имеет некоторые фундаментальные отличия от всех

 

Рис. 10.1. Эталонная модель протокола радиоинтерфейса

 

технологий радиодоступа второго поколения. Основная задача протоколов радиоинтерфейса — это мультиплексирование потоков трафика разного рода и от разных источников. Для эффективного управления мультиплексирова­нием используется строгое иерархическое разделение функций, что привело к трехуровневой эталонной модели протокола, показанной на рис. 10.1.

Названия уровней эталонной модели соответствуют их положению в ар­хитектуре — радиоинтерфейсы уровня 1, уровня 2 и уровня 3. Хотя в данном случае применен принцип иерархического представления, известный из мо­дели взаимодействия открытых систем ВОС (OSI), эти три уровня не могут рассматриваться как три низших уровня модели ВОС. Уровни имеют хорошо определенные функции и интерфейсы друг с другом, что дает возможность называть их следующим образом:

 

•  L1 — физический;

•  L2 — уровень радиоканала;

•  L3 — уровень радиосети.

 

Как показано на рис. 10.1, физический уровень предоставляет набор транспортных каналов WCDMA. Это делает физический уровень ответствен­ным за функцию первоначального мультиплексирования, за преобразование потоков из транспортных каналов в физические каналы WCDMA и наобо­рот. Преобразование транспортных каналов в физические каналы описано в главе 4.

Уровень радиоканала представляет еще один уровень мультиплексирова­ния, который вносит основной вклад в динамическое распределение емкости (пропускной способности) радиоинтерфейса WCDMA. Вместо широкого разнообразия транспортных каналов уровня L1 уровень L2 позволяет верхне­му уровню видеть только ограниченный набор несущих радиоканалов, по которым в радиоканал могут передаваться разные виды трафика. Этот радио­канал UTRAN представляет собой часть структуры каналов всей системы UMTS, которая уже была пояснена в главе 1.

Подуровень управления доступом к среде MAC управляет использова­нием емкости транспортных блоков так, чтобы решение о распределении емкости (принимаемое на стороне UTRAN) точно выполнялось на обеих сторонах радиоинтерфейса. Затем подуровень управления радиокана­лом RLC вводит в логические каналы, предоставленные подуровнем MAC, функции уровня регулярного канала. Для учета характеристик радиопереда­чи к функциям подуровня RLC добавлены некоторые специальные состав­ляющие.

Для целей протокола управления (сигнализации) уровня L3 достаточно услуги управления радиоканалом RLC, но данные пользователя имеют свою специфику и могут требовать дополнительных протоколов конвергенции при обслуживании радиоканала. Для данных домена с коммутацией каналов КК (например, транскодированной речи) функция конвергенции не нужна, но для домена с коммутацией пакетов КП требуется дополнительный подуро­вень конвергенции. Этот подуровень протокола конвергенции пакетов дан­ных PDCP1 делает радиоинтерфейс UMTS пригодным для передачи пакетов данных протокола IP. Еще один протокол конвергенции — ВМС предназна­чен для доменов радиовещания с передачей сообщений и доменов с режи­мом доставки сообщений многим абонентам. Основная задача этого прото­кола — распределение и доставка радиовещательных сообщений в пределах соты к оборудованию пользователей UE.

Разделение информации управления и пользовательских данных — еще один ключевой принцип проектирования, который уже давно применяется при разработке протоколов. В результате протоколы, используемые для управления, становятся частью плоскости (слоя) управления на системном уровне, тогда как протоколы, передающие данные конечного пользователя, относятся к плоскости пользователя — абонента.

Протокол плоскости управления L3 представляет собой протокол управ­ления радиоресурсами RRC. Как показано на рис. 10.1, элементы протоко­ла RRC как на конце UE, так и на конце UTRAN имеют интерфейсы управления со всеми остальными элементами протокола. Когда же элемент протокола, управляемый RRC, находится в другом элементе сети UTRAN, то для поддержания механизма управления необходимы стандартизирован­ные протоколы. Во всех остальных случаях интерфейсы управления пред­ставляют внутренние интерфейсы определенного UE или элемента сети UTRAN и поэтому точно не стандартизированы, однако их наличие кри­тично для подуровня RRC при выполнении его задач по управлению ра­диоресурсами.

 

10.1.2. Эталонная модель протокола UTRAN

 

Сеть доступа UTRAN полностью отвечает за радиоресурсы WCDMA. Сеть UTRAN осуществляет администрирование и управление собственными сете­выми элементами и создает каналы радиодоступа, позволяющие установить связь между оборудопанием пользователей UE и базовой сетью CN через всю инфраструктуру UTRAN. Этот процесс формируется согласно общей эталон­ной модели протокола UTRAN, представленной на рис. Ю.2. Эта модель об­щая в том смысле, что архитектурные элементы, несмотря на отсугствие точно определенных протоколов, одинаковы для всех интерфейсов UTRAN: Iu, lub, Iur. При ссылке на конкретные протоколы на рис. 10.2 используется только специальная система нумерации, принятая в 3GPP, что еще раз подчеркивает идею общей, совместно используемой архитектуры протоколов.

Основные элементы архитектуры протокола UTRAN — это уровни и плоскости. В случае сети UTRAN общие принципы иерархического пред­ставления сети применяются прежде всего для выделения двух основных частей стека протоколов. Гак. нее протоколы нижнею уровня вместе состав­ляют так называемый уровень транспортной сети UTRAN. Название «транс­портный» в данном случае применяется в контексте модели взаимодействия открытых систем ВОС (т. е. чтобы охватить набор протоколов, позволяющих

Рис. 10.2. Общая эталонная модель протокола UTRAN.

Обозначения   в документах  3GPP:  х=1   Iu-протоколы;  х = 2   lur-протоколы; х = 3 Iub-протоколы

 

 

несмежным сетевым узлам связываться друг с другом через объединенную сеть, которая может включать множество различных подсетей). Есть и еще один, более прагматичный аспект — необходимо было включить в уровень транспортной сети все протоколы, отобранные из существующих наборов и пригодные для использования, вместо того чтобы разрабатывать такие про­токолы специально для целей UTMS.

Другой набор протоколов находится на верхнем уровне транспортной сети — в соответствии с моделью протокола радиоинтерфейса — и называ­ется уровнем радиосети. Эти протоколы были разработаны специально для системы UMTS и предназначены для управления администрированием и ис­пользованием каналов радиодоступа через различные интерфейсы UTRAN.

На рис. 10.2 отмечено разделение между протоколами плоскости управ­ления и плоскости пользователя. Этот принцип проектирования, который уже упоминался для протоколов радиоинтерфейса, применен и ко всем ин­терфейсам UTRAN. Протоколы уровня транспортной сети отобраны с уче­том различных свойств, которые должны поддерживаться протоколами уров­ня радиосети (как в плоскости управления, так и в абонентской плоскости) лучшим образом. Для протоколов плоскости управления основным критери­ем служит надежность, а для протоколов плоскости пользователя — качество обслуживания QoS, предоставляемое транспортной сетью. Протоколы управ­ления для уровня радиосети были специально разработаны так, чтобы удов­летворить требования к управлению радиоканалами и каналами данных. Протоколы управления уровня радиосети UTRAN обычно называются про­токолами прикладной части UTRAN — АР1. В то же время протоколы плос­кости пользователя в пределах уровня радиосети, отвечающие за эффектив­ную передачу кадров пользовательских данных, известны как «кадровые про­токолы UTRAN».

Протоколы прикладной части и протоколы кадрирования вместе форми­руют слой доступа UMTS, охватывающий все те аспекты взаимодействия, которые зависят от выбранной технологии радиодоступа. В общих радио­каналах доступа используются протоколы вне сети доступа для непосредст­венной передачи управляющих сигналов и организации прозрачного потока кадров данных пользователя между оборудованием пользователя UE и ба­зовой сетью CN. Непосредственная передача обеспечивается вставкой полез­ной нагрузки верхнего уровня в сообщения протокола UTRAN.

Протоколы плоскости управления UTRAN разработаны по принципу клиент-сервер. По отношению к интерфейсу Iu, UTRAN играет роль сервера радиодоступа, а базовая сеть CN работает как клиент, запрашивающий услу­ги доступа у сети UTRAN. To же самое верно для интерфейса Iub, где в ка­честве сервера выступает базовая станция БС, а в качестве клиента — управ­ляющий контроллер радиосети CRNC. До некоторой степени это относится и к интерфейсу Iur, где в качестве сервера выступает дрейфующий контрол­лер радиосети DRNC, который фактически предоставляет обслуживающе­му контроллеру SRNC возможность управления удаленными базовыми стан­циями. В протоколе, построенном по принципу клиент-сервер, поведение элемента, выступающего в роли сервера, определяется функциями, которые он должен выполнять, принимая запрос на услугу от своего клиента. А по­ведение клиента, который формирует запрос на обслуживание, очень пере­менчиво.

Более подробно архитектура протокола UTRAN рассмотрена Холмой (Holma) и Тоскалой (Toskala) (2004).

 

10.1.3. Эталонная модель протокола базовой сети CN

 

Базовая сеть CN состоит из сетевых элементов, обеспечивающих поддержку работы сети и предоставление услуг абонентам. Поддержка включает функ­ции управления информацией о местоположении абонентов, управление се­тью и услугами, а также механизмами коммутации и передачи сигналов управления и информации абонентов.

Архитектура протоколов базовой сети заимствована системами 3GPP у систем GSM/GPRS. Следовательно, в ней можно выделить пять основных наборов протоколов:

 

•  протоколы между оборудованием пользователей UE и базовой сетью CN — вне сети доступа;

•  протоколы сетевой сигнализации между обслуживающими и домашни­ми сетями;

•  протоколы магистральной сети пакетной передачи данных;

•  протоколы управления транзитной сетью;

•  протоколы управления услугами.

 

Эти протоколы, унаследованные от сетей GSM/GPRS, имеют совершен­но разные происхождение и предпосылки для стандартизации.

Типичным примером могут служить протоколы вне сети доступа, кото­рые обслуживают оборудование пользователя UE. В них четко прослежива­ются свойства, характерные для GSM/GPRS. Это отражено в документе 3GPP TS 24.008, который представляет расширенную версию своего извест­ного «предшественника» — стандарта GSM 04.08. Цель разработки протоко­лов вне сети доступа состояла в обеспечении совместимости между система­ми GSM/GPRS и UMTS для совместного использования ими базовой сети CN и в предоставлении оборудованию пользователей UE возможности двух-режимной работы.

Стеки протоколов вне сети доступа UMTS представлены на рис. 10.3. Все эти протоколы передаются по соединениям сигнализации, которые устанав­ливаются между оборудованием пользователя и базовой сетью на этапе ини­циализации доступа и установки управляющего соединения. В доменах с коммутацией пакетов КП и коммутацией каналов КК можно выделить два подуровня в протоколах вне сети доступа. Нижний подуровень должен осу­ществлять управление мобильностью ММ; в домене КК этот протокол обо­значается как «ММ», а в домене КП — как «GMM» для отражения того об­стоятельства, что он имеет отношение к управлению мобильностью GPRS (GPRS MM). Выше этого общего подуровня работают протоколы управле­ния средствами связи СМ, в большей степени ориентированные на обслужи­вание. Перечислим протоколы СМ и их функции управления:

Рис. 10.3. Протоколы системы UMTS вне сети доступа

 

•  протокол  управления  сеансом   SM1,  управляющий  установлением   и разъединением   контекстов   (сеансов)   протокола   пакетной   передачи PDP для передачи пакетных данных в домене КП базовой сети;

•  протокол управления соединением СС2, управляющий установлением и разъединением соединений с коммутацией каналов в домене КК ба­зовой сети;

•  протокол  дополнительных услуг  SS3,  управляющий  активизацией  и дезактивизацией различных связанных и не связанных с соединением дополнительных услуг;

•  протокол службы коротких сообщений GSMS/SMS, управляющий до­ставкой коротких текстовых сообщений к оборудованию пользователя UE и от него.

 

Сетевая сигнализация между обслуживающей и домашней сетями ис­пользует набор протоколов мобильных приложений MAP, который первона­чально был разработан для управления услугами с коммутацией каналов м системах GSM. С внедрением услуг с коммутацией пакетов и подсистемы GPRS возникла необходимость расширить протокол MAP для организации интерфейсов между узлами поддержки GPRS и узлами домашних сетей. Вер­сия ЗО-протокола MAP используется для управления следующими интер­фейсами базовой сети третьего поколения (см. рис. 6.4):

 

•  интерфейсы С, D, E, F и G, унаследованные от систем GSM;

•  интерфейсы Gc, Gr, Gf и Gs, унаследованные от систем GPRS.

 

Это означает, что и управляющий узел поддержки GPRS — SGSN, и шлюзовой узел поддержки GPRS — GGSN для задач управления обычно должны быть оснащены средствами протокола MAP.

Протокол MAP использует схему обмена, ориентированную на операции. Каждая транзакция (операция) (например, регистрация местоположения абонента в регистре HLR) осуществляется как диалог между узлами базовой сети CN. Эта структура передачи создается для подуровня MAP находящим­ся непосредственно под ним подуровнем прикладной части функций обра­ботки операций ТСАР1. Для сигнализации между сетями разных операторов подуровень ТСАР использует в качестве магистральной сети транспортную сеть сигнализации на основе системы сигнализации № 7.

Набор протоколов для передачи пакетных данных в пределах домена КП базовой сети также был позаимствован у магистральной сети GPRS. Он основан на принципе межсетевого обмена и наборе протоколов ТР, который к моменту начала стандартизации GPRS уже был полностью сформирован. Фактически необходимо было добавить только один специфический прото­кол GPRS. Это протокол туннелирования GPRS — GTP2, который управляет передачей сообщений через магистральную сеть домена КП на интерфейсы Gn и Gp (см. рис. 6.4).

Протокол GTP может быть представлен как два подпротокола: под прото­кол управления сигнализацией GTP-C, который работает между узлами GGSN и SGSN, и подпротокол абонентской плоскости GTP-U, который рас­пространяется от шлюза GGSN через интерфейс lu в направлении сети UTRAN. Это окончание передачи GTP-U в контроллере радиосети RNC (вме­сто узла SGSN) отличается от исходных технических требований GPRS.

Любая сеть UMTS должна взаимодействовать с внешними телекоммуни­кационными сетями и сетями передачи данных. Это взаимодействие осущест­вляется через транзитную сеть, в качестве которой в случае услуг с коммута­цией каналов используется магистральная коммутируемая телефонная сеть об­щего пользования или цифровая сеть с интеграцией обслуживания ISDN, а в случае услуг с коммутацией пакетов — чаще всего другая магистральная сеть IP. Следовательно, протоколы на границах транзитной сети должны быть со­вместимыми с протоколами, используемыми в транзитной магистральной сети. В случае телефонной сети очевиден выбор протокола пользовательской части ISDN — ISUP3 или независимого от канала протокола управления со­единением — BICC4, а для взаимодействия с внешними сетями передачи дан­ных на основе IP используются протоколы IPv4 или IPv6. В базовой сети UMTS дополнительные услуги должны быть доступны абонентам не только внутри их домашних сетей, но также и в посещаемых обслуживающих сетях. Для этого из инфраструктуры GSM была перенесена прикладная часть САР' заказных приложений для усовершенствованной ло­гики мобильной сети CAMEL, как это было описано в главе 2 при анализе эволюции сетей. Еще один протокол— это САР, ориентированный на опера­ции, который может использовать услугу ТСАР и международную сеть сиг­нализации № 7 так же, как и рассмотренный выше протокол MAP.

 

10.2. Архитектура взаимодействия протоколов UMTS

 

Количество и широкое разнообразие протоколов системы UMTS, описанных в разделе I0.1, может показаться сбивающим с толку и — из соображений преемственности, которые следовало принять во внимание при отборе и раз­работке протоколов, — их нельзя рассматривать как единообразный и одно­родный набор протоколов. В данном разделе представлена модель архитекту­ры комбинированного протокола сети UMTS, которая в дальнейшем помо­жет нам при исследовании отдельных протоколов.

Обзор протоколов радиоинтерфейса, UTRAN и базовой сети позволил нам выделить два основных принципа разработки протокола:

 

•  разделение и иерархическое представление общих транспортных аспек­тов и специфических аспектов мобильной сети UMTS;

•  разделение и выделение плоскостей сетевого управления и пользова­тельских данных.

 

Прежде чем приступить к дальнейшему изложению на основе предло­женных принципов, остановимся на двух дополнительных ключевых момен­тах построения архитектуры единого сетевого протокола:

 

•  взаимодействия протоколов;

•  завершения (окончания) протоколов.

 

Взаимодействие протоколов имеет отношение к тем процессам, которые относятся одному уровню, но взаимодействуют через множество элементов сети и, следовательно, охватывают набор протоколов, которые участвуют в выполнении обших функций на системном уровне. Примерами таких функ­ций могут служить установление радиоканал доступа и обновление инфор­мации о местоположении. Установление радиоканала требует обеспечения межсетевого обмена между оборудованием пользователя UE и элементами базовой сети CN и согласованных действий протоколов RRC и АР в сети UTRAN. В случае корректировки местоположения «цепочка» протоколов взаимодействия включает протокол управления мобильностью ММ (между UE и базовой сетью CN) и протокол MAP между узлами базовой сети CN. Такую цепочку распределенных действий разработчики протоколов часто на­зывают (системной) процедурой.

Взаимодействие протоколов часто реализуется как расширение вышеупо­мянутой модели клиент-сервер. Как только на одном конце сети инициирует­ся событие, элемент первого протокола для того, чтобы обнаружить его, ста­новится клиентом и запускает процедуру запросом некоторых операций у своего сервера. В сети UMTS сервер редко способен удовлетворить такой за­прос самостоятельно: он должен принять на себя роль еще одного клиента и запросить дополнительные услуги у своего сервера (серверов). Так процедура работает до тех пор, когда серверы — чаше на стороне сети, противоположной той, где было инициировано событие, — уже не смогут передавать полномо­чия на выполнение задачи следующим серверам, а должны будут выполнять команды сами. При организации радиоканала доступа процедура инициирует­ся элементом базовой сети CN и в конечном счете выполняется базовой стан­цией БС и оборудованием пользователя UE, которые устанавливают радиока­нал между собой. При обновлении местоположения процедуру инициирует оборудование пользователя UE и в конечном счете домашний регистр HLR должен внести в свою базу данных информацию о новом местоположении.

Более полные примеры процедур системного уровня UMTS представле­ны в главе 11, но и в данной главе взаимодействие протоколов в пределах уровня предстаапяет ключевой аспект с точки зрения многоуровневого пред­ставления протоколов UMTS.

Окончание протокола можно считать конечной точкой цепочки протоко­лов, которая обеспечивает межсетевой обмен описанным выше способом. В сетевом элементе, где завершается протокол, системная функция или алго­ритм может идентифицироваться как источник или приемник данных или команд. Для упомянутых выше протоколов управления мобильностью ММ в примере с обновлением местоположения оконечными точками являются оборудование пользователя UE и домашний регистр HLR. Иногда понятие окончания применяют и по отношению к одному (отдельному) протоколу, но тогда оконечные точки — это просто две конечные точки этого отдельно­го протокола. Поэтому с точки зрения архитектуры протоколов на систем­ном уровне окончание набора протоколов взаимодействия намного важнее.

В оставшейся части данной главы для описания протоколов UMTS будет использован принцип разделения набора протоколов UMTS на три различ­ных протокольных уровня взаимодействия, каждый из которых охватывает множество элементов сети и может рассматриваться как отдельная логиче­ская сеть. Это разбиение не строго следует техническим требованиями 3GPP, а скорее представляет протокольно-ориентированный подход в масштабе всей сети, основные принципы которого — разбиение сети на уровни и сквозное межсетевое взаимодействие.

Прежде всего модель протокола UMTS делится на уровни горизонтально. Протоколы в пределах каждого из уровней работают через множество интер­фейсов и соответствуют друг другу с точки зрения описанных выше про­цедур межсетевого взаимодействия и окончания.

Как показано на рис. 10.4, можно выделить три уровня:

 

•  уровень транспортной сети;

•  уровень радиосети;

•  системный сетевой уровень.

Рис. 10.4. Архитектура взаимодействия протоколов UMTS

 

При таком разделении транспортная сеть (уровень транспортной сети) отвечает за предоставление транспортных услуг общего назначения всем эле­ментам сети UMTS, позволяя им таким образом взаимодействовать через все интерфейсы, описанные выше. Затем функции UMTS с помощью протоко­лов уровня радиосети и сетевого уровня распределяются по элементам сети. Протоколы уровня радиосети обеспечивают взаимодействие оборудования пользователей UE и базовой сети CN во всех аспектах, связанных с канала­ми радиодоступа. Протоколы системного сетевого уровня действуют в про­странстве от оборудования пользователей до границ базовой сети UMTS с транзитной сетью. Они обеспечивают межсетевое взаимодействие в аспектах услуг по передаче сообщений UMTS.

В пределах каждого из этих трех уровней можно выделить аспекты управ­ления и передачи пользовательских данных, что создает еще одно направ­ление структурирования модели протокола UMTS, представленной на рис. 10.4. Протоколы, связанные только с аспектами управления, относятся к плоскости управления, а протоколы, связанные с передачей пользователь­ских данных, — к плоскости пользователей. Разграничение между плоско­стью управления и плоскостью пользователей наиболее заметно в радиосети и на системном уровне, а в пределах транспортной сети многие протоколы являются общими для обеих плоскостей. Однако из соображений оптимиза­ции определенные протоколы транспортной сети специально отобраны для переноса только сигналов управления или пользовательских данных.

Протоколы плоскости управления взаимодействуют друг с другом на раз­личных интерфейсах UMTS, обеспечивая управление ресурсами и услугами системы. Подобным образом протоколы плоскости пользователей взаимо­действуют друг с другом для обеспечения сквозного потока пользовательских данных.

В системе UMTS различают два разных домена, отличающихся характе­ристиками абонентского трафика. В домене с коммутацией каналов КК про­пускная способность плоскости пользователей выделяется каналам связи на все время обслуживания (например, телефонного вызова). В домене с ком­мутацией пакетов КП пропускная способность плоскости пользователей вы­деляется пакетам данных. Различные требования двух этих доменов могут отражаться и на выборе протоколов транспортной сети, и на разработке про­токолов системного уровня; поэтому в данной главе при необходимости та­кие протоколы рассматриваются отдельно для каждого домена.

При таком разделении выполняемых функций три различные подсисте­мы протоколов можно без труда модернизировать при появлении новых тех­нологий. Фактически такая эволюция уже имела место при внедрении аль­тернативных протоколов транспортной сети и новой подсистемы IMS в 5-й версии технических требований 3GPP.

 

10.3. Протоколы транспортной сети

 

Хотя в идеальном случае пропускную способность плоскости пользователей и плоскости управления следовало бы разделить, это привело бы к расточи­тельному использованию емкости радиоресурсов и наземных средств сети. Поэтому были разработаны протоколы, обеспечивающие общее транспорт­ное обслуживание и для плоскости пользователей, и для плоскости управле­ния и реализованные как отдельная подсистема — «транспортная сеть».

Транспортная сеть UMTS, как следует из ее названия, фактически пред­ставляет собой отдельную сеть внутри сети UMTS. Более подробное ознаком­ление с технологией транспортной сети обнаруживает, что она не просто представляет собой отдельную сеть, а на самом деле состоит из нескольких се­тей, которые с точки зрения всей системы могут рассматриваться как отдель­ная (логическая) транспортная сеть UMTS.

Физическая передача бит данных осуществляется (сотовой) сетью переда­чи, основанной на технологии цифровой передачи. Пропускная способность (оптической) магистральной линии такой сети передачи разделяется для кол­лективного использования посредством статистического мультиплексирова­ния, под управлением узлов сети передачи. Затем эта пропускная способ­ность используется «второстепенной» (вторичной) сетью, реализованной по­верх сети передачи. В системах 3GPP в качестве стандартизованных вариан­тов реализации такой коммутационной сети предусмотрены технология асинхронного режима передачи ATM с коммутацией ячеек и технология IP с коммутацией пакетов. Это означает, что ячейки или пакеты данных проходят через множество узлов коммутации, прежде чем достичь своего пункта на­значения. Только на границах этой сети коммутации мы можем обнаружить подлинные элементы сети UMTS.

Принцип формирования сквозной транспортной сети из нескольких взаимосвязанных подсетей хорошо известен из архитектуры IP. Транспорт­ную сеть UMTS также можно рассматривать как объединенную сеть, хотя она не подчиняется единообразной структуре протоколов, как объединенные сети IP. Вместо этого транспортные услуги в пределах различных частей сис­темы UMTS — радиоинтерфейса, сети доступа RAN и базовой сети CN — разработаны и оптимизированы отдельно для каждой части. Как будет по­казано ниже, планируется создать гармонизированную архитектуру транс­портной сети на базе IP с возможностями передачи в реальном масштабе времени.

Поскольку транспортная сеть сама предоставляет возможности коммута­ции и маршрутизации, ей может потребоваться встроенная плоскость управ­ления для создания каналов транспортной сети или распределения информа­ции о маршрутизации. Протоколы этого класса выбираются в соответствии с технологией транспортной сети и здесь не рассматриваются.

Ключевое требование для транспортной сети UMTS — последовательная доставка пакетов данных пользователя. В случае ATM это обеспечивается са­мой технологией ATM, а в случае IP необходима хорошо спроектированная сеть. С точки зрения технических условий 3GPP это не проблема, так как транспортная сеть UMTS учитывает специфику оператора: это выделенная сеть, которая не используется для передачи трафика IP сетей общего поль­зования

.

10.3.1. Архитектура протокола транспортной сети

 

Транспортная сеть включает низшие уровни архитектуры протоколов UMTS, предоставляя средства для передачи и маршрутизации трафика управления и пользователей через все интерфейсы UMTS. На рис. 10.5 представлена архи­тектура протоколов верхнего уровня для транспортной сети передачи сигна­лизации и транспортной сети передачи пакетов.

Физический уровень управляет физической средой, по которой передает­ся информация управления и абонентский трафик. Как описано в главе 4, физический уровень радиоинтерфейса UMTS основан на радиотехнологии WCDMA. Протокол физического уровня обеспечивает верхние уровни набо­ром транспортных каналов WCDMA.

Для наземных интерфейсов техническими условиями 3GPP определены транспортные сети ATM и IP. В версии 99 3GPP наиболее популярным ва­риантом транспортной технологии была ATM со своими уровнями адапта­ции (AAL2/AAL5), в то время как транспортные средства IP были определе­ны для интерфейса Iu-PS только в качестве единственного варианта для плоскости пользователей и как необязательный вариант для плоскости управления. Начиная с 5-й версии проекта 3GPP, транспортные технологии ATM и IP представляют в равной степени обоснованный выбор для всех ин­терфейсов UTRAN как в плоскости пользователей, так и в плоскости управ­ления.

Выбор среды передачи физического уровня и соответствующих уровней каналов передачи данных для поддержки технологий ATM и IP остается от­крытым, чтобы не ограничивать использование технологий передачи, имею­щихся в сетях операторов. Однако очень важно отметить, что технические условия 3GPP технологии IP разработаны в предположении, что UTRAN — это частная сеть, предназначенная только для собственного трафика опера­тора. Это помогает преодолеть проблемы защиты информации и качества обслуживания QoS, которые иначе могли бы потребовать более подроб­ных технических требований к протоколам формирования сети IP и выбору

Рис. 10.5. Протоколы транспортной сети: а) протоколы плоскости управле­ния транспортной сети; б) протоколы плоскости пользователя транспортной сети (только домен КП)

 

технологий. Для выполнения транспортных функций UTRAN как частной сети оператора необходима хорошо спроектированная сеть IP с достаточной избыточностью.

Набор протоколов транспортной сети для радиоинтерфейса UTRAN, как показано на рис. 10.5, намеренно упрощен. Из-за особенностей внутренней структуры и функционального разделения протоколов UTRAN протоколы MAC и RLC завершаются в контроллере радиосети RNC. Поэтому возникает необходимость передачи кадров MAC/RLC через интерфейсы lub и [иг. Кад­ровые протоколы, используемые для передачи кадров MAC/RLC, не показа­ны на этом рисунке, но будут рассмотрены в подразделе 10.4.2.2. Эти кадро­вые протоколы также работают поверх транспортных функций ATM или IP. В сети UTRAN ответственность за связанные с радиоинтерфейсами функции обслуживания UE на уровне транспортных каналов WCDMA несет обслужи­вающий контроллер SRNC, в то время как базовые станции БС фактически обслуживают только физические каналы WCDMA.

 

10.3.2. Физический уровень WCDMA на интерфейсе Uu

 

Протокол физического уровня управляет физическими каналами WCDMA на интерфейсе Uu (рис. 10.6). Он обеспечивает верхние уровни сети набором транспортных каналов WCDMA, которые предоставляют различные вариан­ты передачи данных в радиосреде WCDMA. Преобразование данных между транспортными и физическими каналами выполняется с помощью протоко­ла физического уровня.

Физический уровень предоставляет услугу «ширина полосы по запросу», которая означает, что транспортные каналы поддерживают переменную скорость передачи бит. Физический уровень как низший уровень иерархии

 Рис. 10.6. Транспортные радиосредства на интерфейсе Uu: а) протоколы плоскости управления транспортной сети; б) протоколы плоскости пользователя транспортной сети (только домен КП)

 

ответственен за мультиплексирование на уровне кадров WCDMA. С этой целью физический уровень управляет транспортными форматами, использу­емыми в каналах передачи. Транспортный формат — это формат для достав­ки набора транспортных блоков в канал передачи в течение каждого интер­вала времени передачи. Наборы транспортных блоков представляют собой данные сигнализации SDU (Signaling Data Unit) физического уровня, сфор­мированные протоколом управления доступом к физической среде MAC. Интервал времени передачи определяет, насколько часто физический уро­вень может принимать данные от уровня MAC. Параметры (атрибуты) транс­портного формата перечислены в таблице 10.1.

 

Таблица 10.1. Параметры транспортного формата для системы WCDMA-FDD*

* FDD — дуплекс с разделением частоты.

 

Физический уровень осуществляет мультиплексирование транспортных блоков от разных транспортных каналов. Для обеспечения кадровой синхро­низации передачи радиосигнала WCDMA физический уровень разбивает транспортные блоки на радиокадры, Остальные функции физического уров­ня — канальное кодирование, чередование данных и выравнивание скоро-

Рис. 10.7. Интерфейсы и структура транспортной сети: а) протоколы плоско­сти управления транспортной сети; б) протоколы плоскости поль­зователя транспортной сети (только домен КП)

 

 

стей — выполняются до формирования кадров радиосигнала для передачи по разным физическим каналам.

Следует отметить, что по сравнению с протоколом физического уровня GSM на физическом уровне WCDMA отсутствует функция шифрования.

Кроме того, протокол физического уровня вводит в передаваемые на ра­диоинтерфейс транспортные блоки контрольную сумму циклической про­верки на четность CRC1 (0, 8, 12, 16 или 24 бита). На принимающей стороне физический уровень доставляет транспортные блоки на верхний уровень вместе с возможной индикацией ошибок в результате подсчета контрольной суммы CRC.

Услуги, предоставляемые протоколом физического уровня WCDMA, описаны в документе 3GPP TS 25.302, а более детальные технические требо­вания к протоколу физического уровня WCDMA изложены в документах 3GPP TS 25.211—25.215. Подробное описание физического уровня WCDMA можно найти в работе Холма и Тоскала (Holma, Toskala — 2004).

 

10.3.3. Интерфейсы и организация магистральной сети

 

В отличие от радиоинтерфейсов протоколы транспортной сети интерфейсов наземных средств системы UMTS не разрабатывались специально для задач UMTS. Вместо этого органы стандартизации 3GPP отобрали их из уже суще­ствующих протоколов (рис. 10.7). Как и при выборе всех протоколов транс­портных сетей, внимание было сосредоточено на возможностях мультиплек-сирования трафика различных пользователей или, говоря точнее, от различ­ных каналов UMTS, с учетом параметров качества обслуживания QoS.

С учетом обстоятельств нетехнического характера, неизбежно влияющих на политику в области стандартизации, было отобрано два основных набора протоколов: один — из широкополосной связи (семейство протоколов ATM), а другой — из сетей передачи данных Интернета (семейство протоко­лов IP). В версии 99 проекта 3GPP доминирующей технологией транспорт­ной сети на стороне UTRAN была ATM, а в домене КП на стороне базовой сети CN — технология протокола IP. В пределах домена базовой сети с ком­мутацией каналов КК транспортная сеть продолжает базироваться на маги­стральной сети ИКМ с временным разделением каналов. В 5-й версии 3GPP технологии ATM и IP могут в равной мере использоваться на всех интерфей­сах, включая передачу речи через интерфейс Iu-CS.

Применение сети ATM или IP в качестве транспортной сети UMTS требует использования набора протоколов адаптации и конвергенции для выполнения специальных транспортных протоколов UMTS поверх этих протоколов общего назначения. На рис. 10.8 представлены наборы (стеки) протоколов для различных интерфейсов, стандартизированные в 5-й вер­сии 3GPP.

 

10.3.3.1. Транспортные средства ATM

 

Основная идея технологии ATM заключается в разделении передаваемого информационного потока на небольшие части (ячейки), присоединении к ним адресных ярлыков и передаче по физическому тракту. На приемном конце из содержимого принятых пакетов формируется информационный по­ток, аналогичный исходному потоку. Пакет, содержащий передаваемую ин­формацию, называется ячейкой ATM.

Ячейка ATM (см. рис. 10.9) состоит из двух частей: заголовка длиной 5 байт (адресная информация) и полезной нагрузки (передаваемая информа­ция). В сравнении с «общепринятыми» протоколами и сообщениями заголо­вок очень короткий, Это накладывает некоторые ограничения на выполняе­мые функции, но в то же время эффективность пересылки информации очень высока: доля адресной информации составляет 5/(5 + 48) ~ 9,5 %. Еще одна цель, которой нужно было достичь, — это простота системы передачи без излишней «бюрократии». Поэтому полезная нагрузка ячейки ATM не за­щищается методами контрольных сумм. В настоящее время это возможно, так как для передачи трафика ATM используются сети очень высокого каче­ства и их оконечные устройства в состоянии при необходимости самостоя­тельно предусмотреть защиту от ошибок.

Заголовок ячейки ATM содержит некоторую адресную информацию (см. рис. 10.10). Наиболее существенны следующие элементы:

•  VPI (Virtual Path Identifier) — идентификатор виртуального тракта VP или в более широком смысле идентификатор постоянно закрепленного полупостоянного соединения.

•  VCI (Virtual Channel Idntifier) — идентификатор виртуального канала VC. Это поле длинное, потому что могут быть тысячи каналов, подле-

Рис. 10.9. Структура ячейки ATM

 

жащих идентификации в одном тракте VP (например, мультимедийные приложения могут потребовать нескольких VCI одновременно, по од­ному VC на каждый компонент).

•  РТ (Payload Type) — тип полезной нагрузки: поле полезной нагрузки длиной 48 байт содержит пользовательские данные или данные управ­ления.

•  CLP (Cell Loss Priority) — приоритетность потери ячейки: это флаг, указывающий, является ли данная ячейка «важной» или «менее важ­ной». Если CLP = 1 (низкий приоритет / менее важная ячейка), то сис­тема ATM может при необходимости потерять эту ячейку.

•  НЕС (Header Error Control) — контроль ошибок заголовка: в ATM за­головок ячейки защищается от ошибок, поскольку повреждение заго­ловка ячейки ATM более серьезно, чем ошибки в полезной нагрузке (например,  из-за того,  что ячейка ATM может быть доставлена по ошибочному адресу именно вследствие ошибок в заголовке). Исполь­зуемый механизм коррекции ошибок дает возможность обнаружения всех ошибок в заголовке и исправления одной из них.

 

Рисунок 10.11 иллюстрирует тракт передачи ATM. Один тракт может со­стоять из нескольких виртуальных трактов, которые, в свою очередь, содер­жат виртуальные каналы.

Виртуальные тракты представляют собой полупостоянные соединения, од­новременно поддерживающие множе­ство виртуальных соединений — кана­лов. Фактически данные пересылаются в ячейках ATM по виртуальным кана­лам. С точки зрения системы UMTS тракт передачи ATM может быть орга­низован, например, между базовыми станциями БС и контроллером RNC. Если речь идет о передаче данных по кольцевой схеме, то тракт передачи со-

Рис. 10.10. Структура заголовка ячейки ATM.

GFC — общее управление потоком; VPI — идентификатор виртуального тракта; VCI — виртуальный канал; РТ — тип полезной на­грузки; CLP — приоритет потери ячейки; НЕС — контроль ошибок заголовка

Рис. 10.12. Уровни адаптации ATM—AAL

 

 

держит множество виртуальных трактов (по одному на каждую БС), и вирту­альные каналы в таком тракте выделяются по мере поступления вызовов. Ширина полосы виртуального канала изменяется в зависимости от исполь­зуемого носителя услуги (канала).

Уровень ATM как таковой представляет довольно простую транспортную среду и теоретически пригоден для целей передачи. На практике уровень ATM должен быть адаптирован к верхним протокольным уровням и нижне­му физическому уровню. Международный союз электросвязи МСЭ-Т уста­новил «классы услуг ATM», используя понятие уровня адаптации AAL1. Пер­воначальная идея состояла в том, что каждый класс услуг от А до D дол­жен соответствовать определенному уровню AAL — от 1 до 4. Как видно из рис. 10.12, со временем от этой идеи отказались.

Рис. 10.13. Обшая структура уровня адаптации AAL

 

Выделяют следующие классы услуг ATM:

•  постоянная битовая скорость передачи — CBR (Constant Bit Rate);

•  точно не установленная битовая скорость передачи — UBR (Unspecified Bit Rate);

•  доступная битовая скорость передачи — ABR (Available Bit Rate);

•  переменная битовая скорость передачи — VBR (Variable Bit Rate).

Любая прозрачная передача данных может использовать CBR, а ресурсы выделяются исходя из максимально возможной скорости передачи данных. Скорость UBR использует ту свободную ширину полосы, которая есть в на­личии. При отсутствии доступных ресурсов может возникнуть очередь. До­ступная скорость ABR может использоваться, когда абоненту предполагается предоставлять минимальную скорость передачи. Переменная скорость VBR предоставляет скорость передачи, изменяемую по статистике трафика.

В системе ATM существуют следующие уровни адаптации:

 

•  AAL1 — синхронный режим с установлением соединений и постоян­ной скоростью передачи для услуг, требующих такого рода адаптации;

•  AAL2 — синхронный режим с установлением соединений и перемен­ной скоростью передачи для услуг, использующих такую адаптацию;

•  AAL3/4 — асинхронный режим без установления соединения с пере­менной скоростью передачи;

•  AAL5 — асинхронный режим с установлением соединений и перемен­ной скоростью передачи.

 

Уровень адаптации AAL (см. рис. 10.13) делится на два подуровня. Пер­вый подуровень — конвергенции CS (Convergence Sublayer), а второй — под­уровень сегментирования и повторной сборки SAR (Segmentation And Re-as­sembly). Подуровень CS адаптирует AAL к верхним уровням протоколов, а подуровень SAR делит подлежащие передаче данные на соответствующие фрагменты полезной нагрузки, а на приемной стороне собирает эти фраг­менты и восстанавливает исходный поток данных. В зависимости от обстоя­тельств подуровень CS можно разделить на меньшие элементы.

С точки зрения транспортной сети UMTS наиболее интересные варианты представляют уровни адаптации AAL2 и AAL5. Уровень AAL2 — это подхо­дящее решение для соединений пользовательской плоскости с КК, а уровень AAL5 пригоден для обмена протоколами управления. Более подробный пере­чень этих вариантов AAL на различных интерфейсах протоколов UTRAN приведен в таблице 10.2.

 

Таблица 10.2. Уровни адаптации ATM, используемые на интерфейсах LJTRAN

 

Уровень адаптации ATM AAL5 используется в сети UTRAN для передачи на интерфейс Iu всех протоколов управления, а также пользовательских дан­ных домена КП. Уровень AAL2 используется в качестве общего носителя для пользовательских данных на всех интерфейсах, кроме данных домена КП на интерфейсе Iu.

Подуровни набора протоколов AAL на различных интерфейсах UTRAN, показанные на рис. 10.8, здесь подробно не описываются. Говоря об отборе этих протоколов конвергенции, следует отметить, что уже в версии 99 во всех протоколах плоскости управления для домена КП конвергенция могла быть реализована двумя альтернативными путями: либо с использованием протоколов конвергенции, определенных МСЭ-Т для передачи сигналов сиг­нализации на уровне AAL5, либо передачей данных AAL5 по протоколу IP. Кроме того, в версии 99 уже была предусмотрена конвергенция пользова­тельской плоскости для домена КП на интерфейсе !и, основанная на переда­че дейтаграмм пользователя UDP1 по протоколу IP. Это привело к тому, что в 5-й версии 3GPP передача на основе IP используется еще шире на всех ин­терфейсах UTRAN и базовой сети CN, как это будет показано ниже.

 

10.3.3.2. Транспортная технология IP

 

К тому моменту, когда получила широкое развитие транспортная технология IP, процесс стандартизации систем 3GPP версии 99 уже подходил к концу. Чтобы создать базу для полномасштабного использования транспортной тех­нологии IP в качестве обшей транспортной среды для дальнейшего развития сетей UMTS, возникла необходимость изучения возможностей применения IP для передачи сигналов сигнализации и пользовательских данных на всех интерфейсах UTRAN.

Со времени введения 5-й версии 3GPP пользовательские данные могут передаваться через все интерфейсы UTRAN с использованием стека прото­колов IP (см. рис. 10.8). Общая часть стека IP, используемая для передачи данных пользователя, представлена протоколом UDP/IP. Кадры радиосигна­лов передаются на интерфейсы lub и lur как обыкновенные дейтаграммы UDP. На интерфейсе Iu-PS для переноса пакетов пользовательских данных используется протокол туннелирования GTP-U; на интерфейсе Iu-CS для переноса циклов речевых сигналов используется протокол реального време­ни RTP поверх UDP/IP.

Технические условия 3GPP для транспортной сети UTRAN требуют, что­бы все узлы UTRAN поддерживали протокол IPv6. Поддержка версии IPv4 необязательна, и технические условия не запрещают использовать только IPv4. Однако для поддержки перехода от IPv4 к Ipv6 в узлах UTRAN реко­мендуется реализация двойного стека (IPv4 и IPv6).

Хотя технические условия 3GPP не обязывают использовать в транспорт­ной сети IP какой-либо один протокол канального уровня, имеется минима­льное требование — поддерживать протокол двухточечного соединения с кадровой синхронизацией по протоколу высокоуровневого управления кана­лом передачи данных HDLC1 в соответствии документами Проблемной груп­пы проектирования Интернета IETF RFC 1661 и RFC 1662. Могут использо­ваться и другие протоколы канального уровня, удовлетворяющие тем же тре­бованиям. Одно ключевое требование транспортной сети UTRAN — это по­следовательная доставка пакетов данных.

Транспортные каналы передачи данных IP на интерфейсах UTRAN иден­тифицируются парами номеров портов UDP и адресов IP (для узлов источ­ников и пунктов назначения). Для обеспечения качества обслуживания QoS, каждый узел IP в транспортной сети UTRAN должен поддерживать обозна­чения кодов дифференцированных услуг DSCP2 в соответствии с докумен­том IETF RFC 2474.

Для согласования технологий IP и ATM при передаче сигналов сигна­лизации UMTS оба стека протоколов должны предоставлять одинаковые транспортные услуги. Поэтому было решено «отделить поверхность» обоих стеков, используя сигналы, управляющие соединением SCCP (Signaling Con­nection Control Part), которые всегда предоставляет согласованные услуги по передаче сигнализации (более подробно структуры итоговых стеков протоко­лов представлены на рис. 10.8).

Поскольку базовая сеть UMTS основана на сетевой подсистеме GSM/GPRS. то и транспортные протоколы сигнализации также унаследо­ваны от GSM/GPRS. Системы 3GPP версии 99 все еще включают набор протоколов, основанный на общеканальной сигнализации ОКС № 7 (SS7). Со времени внедрения стандартов 3GPP версий 4/5 транспортное реше­ние сигнализации базовой сети CN может быть гармонизировано с транс­портной сетью UTRAN если протоколы сигнализации базовой сети будут вместо обычной системы ОКС № 7 работать поверх протоколов ATM или IP.

В традиционной сети сигнализации ОКС № 7 (SS7) протокол SCCP дей­ствует поверх протокола передачи сообщений 3-го уровня МТРЗ1, который отвечает за маршрутизацию сообщений сигнализации между точками сигна­лизации. Маршрутизация МТР базируется на кодах точек сигнализации SPC2 и позволяет передавать сообщения сигнализации в пределах только од­ной области адресации SPC, которая обычно администрируется одним сете­вым оператором. Для маршрутизации сигналов сигнализации через границы сети требуется протокол SCCP. Протокол SCCP использует систему глобаль­ной адресации заголовков, которая позволяет, например, гостевому регистру VLR посещаемой сети связаться с регистром HLR домашней сети абонента, используя глобальный заголовок GT3.

Адаптация протокола SCCP поверх протокольного стека ТР была достиг­нута с использованием двух протоколов конвергенции, разработанных и стандартизованных рабочей группой S1GTRAN в рамках IETF. Эти протоко­лы и соответствующие документы IETF включают:

 

•  транспортный протокол управления потоком — SCTP4, RFC 2960;

•  уровень адаптации пользователя МТРЗ — M3UA5 (проект документа Интернета).

 

Задача этих двух подуровней — представить уровень SCCP в таком виде, как если бы он был реализован поверх обычного протокола МТРЗ, как это было в сетях сигнализации на протяжении более двух десятилетий.

Протокол SCTP предполагает работу в сети IPv4 или IPv6 и, что более важно, в хорошо спроектированной сети IP. На практике это означает, что имеется сеть с резервной маршрутизацией, и это позволяет предотвратить сбой передачи в любой отдельный пункт. Для большей надежности SCTP ис­пользует многосвязные оконечные точки (т. е. оконечные точки с более чем одним кортежем адресов IP/номера порта). Кроме того, для предотвращения фрагментации уровня IP, протокол SCTP поддерживает функцию обнаруже­ния максимального количества блоков MTU6 — позволяющую определить размер MTU тракта данных.

Задача протокола SCTP — предоставить устойчивый и надежный канал сигнализации. Для этого SCTP поддерживает соответствующие процедуры управления перегрузками, быструю повторную передачу в случае потери со­общения и повышенную надежность. Он также обеспечивает дополнитель­ную защиту от нежелательных атак (попыток проникновения) и повышает уровень защищенности информации в соединениях сетей UMTS различных операторов.

Протокол M3UA предназначен для поддержки сигнализации SCCP таким образом, чтобы нижестоящие интерфейсы SCCP не требовали бы модифика­ции. Протокол M3UA при работе поверх стека IP нуждается в управлении используемым потоком SCTP и согласовании работы широкополосного про-токола передачи сообщений части 3 МТР-ЗВ1 (своего аналога ОКС № 7). M3UA обеспечивает преобразование адресной информации ОКС № 7 в ад­ресацию IP. Он поддерживает также механизм предотвращения отказов и пе­рераспределения нагрузки между оконечными точками.

M3UA имеет две структурные схемы: шлюз сигнализации с точкой сигна­лизации IP (IPSP2) и соединение IPSP—1PSP. Предполагается, что вариант IPSP—IPSP не только наиболее вероятен, но и наиболее прост.

 

10.3.4. Протоколы транспортной сети UMTS

 

Описанные выше протоколы, работающие поверх магистральной транспорт­ной сети (ATM или IP), обеспечивают адресацию и маршрутизацию сообще­ний сигнализации от одного узла сети UMTS к другому. Они также позво­ляют мультиплексировать трафик от различных пользователей в общую про­пускную способность транспортной сети. За исключением физического уровня WCDMA, на котором выполняются некоторые операции мультиплек­сирования трафика в физические каналы WCDMA, задача мультиплексиро­вания возлагается в транспортной сети на уровни выше физического.

 

10.3.4.1. Протоколы транспортной сети на интерфейсе Uu

 

Для передачи сигналов сигнализации и пользовательских данных (трафика КП и КК) через интерфейс Uu используются следующие протоколы транс­портной сети:

•  протокол MAC;

•  протокол RLC.

Эти два протокола работают вместе как радиоканал транспортной сети.

 

10.3.4.1.1. Протокол управления доступом к среде MAC

 

Протокол MAC используется абонентским оборудованием UE, базовыми станциями БС и контроллером радиосети RNC (рис. 10.14). MAC — это про­токол 2-го уровня, который как часть общей транспортной сети предоставля­ет услуги и плоскости управления, и плоскости пользователя. С самого нача­ла при разработке протокола MAC были приняты во внимание вопросы пе­редачи трафика КК и КП, а также трафика сигнализации. В этом заключает­ся основное отличие MAC от пакетных радиопротоколов второго поколения 2G, которые можно рассматривать как дополнения для передачи пакетов данных по стандартным радиоканалам соединений с КК (с временным раз­делением) второго поколения 2G.

Протокол MAC предоставляет свои услуги в виде набора логических ка­налов, с определенным типом передаваемых по ним данных. Среди этих ло­гических каналов (как описано в главе 4) имеется четыре класса каналов управления и два класса каналов передачи трафика.

Рис. 10.14. Транспортная сеть — управление доступом к среде MAC: а) про­токолы плоскости управления транспортной сети; б) протоколы плоскости пользователя транспортной сети (только домен К.П)

 

 

Протокол MAC несет общую ответственность за управление передачей сообщений по транспортным каналам WCDMA, предоставляемым физиче­ским уровнем. Чтобы иметь возможность распределять пропускную способ­ность транспортных каналов между логическими каналами, MAC использует в качестве элементов (единиц) передачи транспортные блоки. Возможные размеры транспортных блоков для каждого транспортного канала MAC зада­ются физическим уровнем WCDMA как часть определенного набора транс­портных форматов.

В соответствии с типом транспортных каналов, предоставленных физиче­ским уровнем, протокол MAC подразделяется на три части — общую, выде­ленную и вещания.

Общая часть протокола MAC реализуется в управляющем контроллере CRNC и оборудовании пользователя UE и обеспечивает управление по об­щим и совместно используемым транспортным каналам. Она позволяет мультиплексировать блоки протокольных данных PDU1 из верхних уровней в наборы транспортных блоков, передаваемые по этим транспортным кана­лам. В общих и совместно используемых каналах идентификация оборудова­ния пользователей UE осуществляется с помощью временного идентифика­тора (находящегося в RNC). Это могут быть временные идентификаторы со­товой радиосети (C-RNT12,16 бит) или радиосети UTRAN (U-RNTI, 32 бита) для общих каналов или временный идентификатор нисходящего совместно используемого канала радиосети (DSCH-RNTI3, 16 бита) для совместно ис­пользуемых транспортных каналов.

Рис. 10.15. Комбинации транспортных форматов в протоколе MAC

 

Выделенная часть протокола MAC реализуется в обслуживающем конт­роллере SRNC и оборудовании пользователя UE и обеспечивает управление по выделенным транспортным каналам. В этих каналах протокол MAC мо­жет осуществлять мультиплексирование, формируя наборы транспортных блоков из блоков PDU верхнего уровня. При этом все блоки набора должны принадлежать тому оборудованию пользователя UE, для которого был выде­лен транспортный канал, а мультиплексирование возможно только в том случае, если параметры качества QoS идентичны параметрам качества услуг, поддерживаемых выделенным каналом DCH.

Часть вешания протокола MAC может использоваться на базовых стан­циях БС и в оборудовании пользователя UE. Этот элемент обрабатывает один радиовещательный транспортный канал в каждой соте.

Прежде чем начать передачу данных по любому транспортному каналу, элемент протокола MAC выбирает подходящий для данного канала транспор­тный формат с учетом требований передачи данных остальных транспортных каналов. В результате в транспортных каналах образуются комбинации раз­личных транспортных форматов, определяемые мгновенной скоростью пере­дачи трафика в любой момент времени с учетом вопросов регулирования мощности. Эти комбинации транспортных форматов схематически показаны на рис. 10.15.

Благодаря тому обстоятельству, что MAC — это также и часть плоскости пользователя, этот протокол работает в реальном масштабе времени. MAC должен соответствовать жестким требованиям синхронизации физического уровня и быть готовым передать новый набор транспортных блоков в соот­ветствии с временными интервалами передачи, указываемыми физическим уровнем. В каждом временном интервале MAC должен выбрать оптималь­ную комбинацию транспортных форматов, исходя из характеристик данных, подлежащих передаче, и текущего состояния трафика.

Основная услуга уровня MAC — это обеспечение передачи блоков дан­ных сигнализации SDU1 между равноправными элементами MAC. С точки зрения верхних уровней не имеет значения то, что эта услуга предоставляет­ся без какого-либо подтверждения или сегментации.

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

MAC также собирает статистическую информацию о трафике, которая затем используется уровнем RRC. Для этого MAC выполняет измерения в каждом логическом канале, определяя коэффициент занятия буфера, среднее значение и дисперсию. Данные о состоянии MAC (недогруженности или пе­реполнении), определяемом для каждого транспортного канала, и режиме измерений (событийном или периодическом) передаются на уровень RRC.

Уровень MAC выполняет алгоритм шифрования данных, передаваемых в прозрачном режиме RLC. Блоки данных сигнализации MAC-SDU пересы­лаются в выделенные логические каналы (DCCH и DTCH) и вставляются в выделенные транспортные каналы и, как описано в главе 9, шифруются по алгоритму блочного шифрования K.ASUMI с использованием специального ключа, присвоенного данному UE.

MAC имеет только один формат блока PDU — так называемый «PDU данных», состоящий из блока данных сигнализации SDU и заголовка про­токола MAC. Заголовок формируется в соответствии с используемым транспортным каналом. В некоторых случаях (например, когда оборудова­ние пользователя UE имеет только один выделенный канал DCH без како­го-либо мультиплексирования логических каналов) заголовок может быть пропущен.

Согласно техническим условиям 5-й версии 3GPP протокол MAC также поддерживает высокоскоростной пакетный доступ по нисходящему каналу HSDPA. Для этого был введен новый элемент — высокоскоростная часть протокола MAC. Он отвечает за управление новым транспортным каналом — высокоскоростным нисходящим распределенным каналом HS-DSCH. Один такой канал коллективного пользования существует в каждой соте, поддер­живающей высокоскоростной пакетный доступ HSDPA. Этот канал между оборудованием пользователя UE и базовой станцией БС управляется рав­ноправными элементами высокоскоростной части MAC на обоих концах. Для передачи высокоскоростного трафика между БС и обслуживающим кон­троллером SRNC используются так называемые «выделенные потоки MAC» — еще одно усовершенствование MAC в 5-й версии. С точки зрения выделенной части MAC выделенный поток MAC рассматривается как еще один тип выделенного транспортного канала (подобный DCH).

Из-за того что транспортный канал HS-DSCH однонаправленный (суще­ствует только в нисходящем направлении), равноправные элементы высоко­скоростной части MAC выполняют несимметричные функции. На базовой станции БС это функции, связанные с передачей данных, такие как распре­деление и установка приоритетов пользователей, формирование очереди по приоритету, а также выбор транспортного формата. В оборудовании пользо-вателя UE высокоскоростная часть MAC обеспечивает прием данных, вклю­чая переупорядочение данных в очереди в соответствии с приоритетами и расформирование блоков PDU.

Для повышения надежности передачи данных высокоскоростная часть MAC обеспечивает быструю повторную передачу ошибочно доставленных блоков данных PDU. Каждый блок PDU высокоскоростной части MAC под­тверждается приемником по соответствующему восходящему каналу сигна­лизации. На основании принимаемого подтверждения передатчик может инициировать повторную передачу. Однако, когда приемник высокоскорост­ной части MAC обнаруживает ошибку, он не отбрасывает принятый пакет, а сохраняет его в эластичной памяти и затем последовательно восстанавливает сохраненный пакет с повторно передаваемыми пакетами до тех пор, пока он не станет узнаваемым. Высокоскоростная часть MAC в оборудовании поль­зователя UE может выполнять эластичное объединение. Емкость программ­ного буфера конфигурируется уровнем RRC.

Быстрая повторная передача и программное комбинирование выполня­ются канальным функциональным элементом гибридной системы автомати­ческого повторного запроса HARQ. В оборудовании пользователя UE в вы­сокоскоростной части MAC имеется один элемент HARQ, а на базовой стан­ции БС — по одному элементу HARQ на каждую соту. В каждом элементе может быть до восьми старт-стопных каналов.

Элемент высокоскоростной части MAC на базовой станции БС принимает данные из выделенных потоков MAC и помещает их в очереди в соответствии с приоритетами. В каждом временном интервале передачи TTI1 (продолжи­тельность которого может составлять всего 2 мс), выделяемом физическим уровнем для передачи, могут обрабатываться данные только одной очереди. Скорость распределения для каждой очереди (т. е. то, как часто она получает право на передачу/повторную передачу по каналу HS-DSCH) зависит от алго­ритма распределения. Поэтому для предотвращения переполнения очередей необходима функция управления потоком между высокоскоростной частью MAC на базовой станции БС и выделенной частью MAC в контроллере SRNC. Управление потоком обеспечивается с помощью протокольной про­цедуры распределения емкости кадра HS-DSCH.

Полные технические требования к протоколу MAC приведены в доку­менте 3GPP TS25.321, а более подробное описание этого протокола можно найти у Холма и Тоскала (Holma, Toskala — 2004).

 

10.3.4.1.2. Протокол управления радиоканалом RLC

 

Протокол RLC работает в контроллере RNC и в оборудовании пользователя UE и выполняет на радиоинтерфейсе WCDMA обычные функции канально­го уровня (рис. 10.16). RLC действует одновременно и в плоскости управле­ния, и в плоскости пользователя, предоставляя услуги канала данных для со­единений с КК и КП.

Операционная среда RLC зависит от рассматриваемой плоскости: в плос­кости пользователя RLC используется протокол PDCP, а в плоскости управления — протокол RRC.

 

Рис. 10.16. Транспортная сеть — управление радиоканалом RLC: а) протоко­лы плоскости управления транспортной сети; б) протоколы плос­кости пользователя транспортной сети (только домен К.П)

 

 

Для RLC протокол MAC является протоколом ниж­него уровня, предоставляющим услуги передачи данных (блоков данных сиг­нализации SDU) по логическим радиоканалам. Поскольку режим передачи данных MAC не предусматривает подтверждения, ответственность за достав­ку блоков PDU верхнего уровня, требующих обеспечения надежности, воз­лагается на протокол RLC. Кроме того, поскольку уровень MAC не может сегментировать более крупные блоки SDU в соответствии с доступными транспортными форматами, эти функции также выполняет RLC. Таким об­разом, транспортные форматы на уровне RLC представлены, как это показа­но на рис. 10.17.

Протокол RLC обеспечивает передачу блоков данных PDU верхнего уровня, преобразуя их в блоки данных сигнализации SDU RLC. Эта услуга называется услугой радиоканала. Для RLC определено три режима работы: прозрачный, без подтверждения (неподтверждасмый) и подтверждаемый.

В прозрачном режиме RLC передает блоки SDU без добавления какой-либо протокольной информации. Функция SAR возможна, но при организа­ции радиоканала должна оговариваться на уровне RRC. Такой режим может использоваться для услуг класса поточной передачи.

В режиме без подтверждения RLC передает блоки SDU, не гарантируя их доставки к равноправному элементу. Этот режим используется некоторыми процедурами управления RRC, когда подтверждение обеспечивается самим протоколом RRC.

В режиме с подтверждением RLC передает блоки SDU и гарантирует их доставку к равноправному элементу. Гарантированная доставка обеспечива­ется средствами повторной передачи. Если RLC не в состоянии правильно доставить данные, то пользователь RLC на передающем конце извещается об этом. Такой режим используется для передачи пакетных данных по выделен­ным логическим каналам.

Рис. 10.17. Взаимодействие RLC с MAC в выделенных каналах.

TF — транспортный формат; TFC — комбинация транспортных форматов; TFI — индикатор транспортного формата; TBS — набор транспортных блоков

 

На уровне RLC выполняются следующие функции:

 

•  SAR;

•  каскадирование (сцепка);

•  заполнение;

•  исправление ошибок;

•  последовательная доставка блоков SDU;

•  выявление копий;

•  управление потоком;

•  проверка порядкового номера;

•  обнаружение и устранение ошибок протокола;

•  функции приостановки/возобновления;

•  отбрасывание блоков SDU;

•  шифрование.

 

Функция SAR обеспечивает выравнивание переменной длины блоков PDU верхнего уровня при их загрузке в блок PDU уровня RLC или выгрузке из него. Размер блоков PDU уровня RLC подстраивается к фактическому набору транспортных форматов.

Каскадирование (сцепка) используется в случаях, когда содержимое бло­ков SDU уровня RLC не заполняет целое число блоков PDU RLC. Так, пер­вый сегмент следующего SDU может быть помещен в PDU, сцепленный с последним сегментом предыдущего SDU. Если каскадирование (сцепка) не применяется и остающиеся данные не полностью заполняют блок PDU заданного размера, то остаток поля данных заполняется битами заполнения. Биты заполнения могут быть заменены дополнительной информацией о со­стоянии для обратного канала.

Многие функции протокола RLC должны выполняться с обнаружением и исправлением ошибок. Фактически битовые ошибки могут обнаруживать­ся проверкой CRC на физическом уровне, но ответственность за их исправ­ление несет уровень RLC. Наиболее эффективное исправление ошибок обес­печивается повторной передачей в режиме пересылки данных с подтвержде­нием. Для работы с различными схемами повторной передачи (например, избирательный повтор, возврат на N или старт-стопный метод), протокол RLC можно сконфигурировать на уровне RRC.

Последовательная доставка блоков SDU сохраняет порядок следования блоков данных PDU верхнего уровня, представленных услугой передачи дан­ных с использованием подтверждения. Если эта функция не используется, то может иметь место несвоевременная доставка пакетов.

Протокол RLC позволяет обнаруживать дубликаты принятых блоков дан­ных PDU и обеспечить лишь однократную доставку результирующего PDU верхнего уровня на вышестоящий уровень. Управление потоком позволяет приемнику RLC управлять скоростью, на которой равноправные элементы RLC могут передавать информацию.

Функция проверки порядкового номера может использоваться в режиме передачи без подтверждения для обеспечения целостности формируемых блоков PDU. Эта функция позволяет выявлять искаженные блоки SDU уровня RLC посредством проверки порядковых номеров блоков PDU уровня RLC, когда они объединяются в блоки SDU. Искаженный блок SDU уровня RLC будет отброшен.

Функция обнаружения и устранения ошибок протокола обнаруживает и исправляет ошибки, вызванные работой протокола RLC. Для выхода из ошибочного состояния используется процедура сброса. В случае непоправи­мой ошибки элемент RLC извещает об этом уровень RRC.

Протокол RLC может приостанавливать и возобновлять передачу данных по запросу от уровня RRC.

Функция отбрасывания SDU позволяет удалять из буфера на передаю­щей стороне любые оставшиеся блоки данных PDU уровня RLC в сомни­тельном блоке SDU, если передача блоков PDU уровня RLC длительное время была безуспешной. Функция отбрасывания SDU помогает избежать переполнения буфера. Для этой функции предусмотрено несколько альтер­нативных режимов работы.

Шифрование проводится на уровне RLC для тех радиоканалов, которые используют режимы работы без подтверждения или с подтверждением. Шифрование, как описано в главе 9, выполняется по алгоритму блочного шифрования KASUMI, с применением специального ключа, присвоенного данному UE.

Полные технические требования к протоколу RLC приведены в докумен­те 3GPP TS25.322, а более подробное описание этого протокола можно най­ти у Холма и Тоскала (Holma, Toskala — 2004).

 

10.3.4.2. Протоколы транспортной сети на других интерфейсах

 

10.3.4.2.1.  Передача сигнализации по протоколу SCCP

На интерфейсах UTRAN и базовой сети CN используется общий транспорт­ный протокол сигнализации — SCCP (см. рис. 10.18).

Протокол SCCP разработан на основе протокола сигнализации ОКС № 7 и предоставляет услуги как с установлением, так и без установления соеди­нения. Услуга с установлением соединения используется для поддержки ка­налов сигнализации.

 

10.3.4.2.2.  Транспортное средство IP для данных пользователя — протокол

GTP-U

 

Протокол GTP-U для пакетных данных пользовательской плоскости — это основной протокол пользовательской плоскости, предоставляющий услугу передачи через интерфейс Iu в домене КП базовой сети (см. рис. 10.19). Как видно из названия, этот протокол заимствован из системы второго поколе­ния GSM/GPRS, но со значительными архитектурными отличиями. В систе­мах 2G протокол GTP-U используется только между узлами поддержки GPRS (SGSN и GGSN), а в системах 3G он был расширен для того, чтобы обслуживать также контроллеры RNC через интерфейс Iu-PS.

GTP-U — это протокол транспортной сети, поддерживающий передачу данных плоскости пользователя в сети UMTS. Протокол GTP-U принадле­жит домену КП сети UMTS и реализован в контроллере RNC на стороне UTRAN и в узлах SGSN и GGSN на стороне базовой сети CN.

GTP-U работает на трех различных интерфейсах: Gn, Gp и ln-PS. Интер­фейс Gn находится между узлами поддержки GPRS (т. с. SGSN и GGSN),

 

Рис. 10.18. Транспортная сеть — передача сигнализации: а) протоколы плос­кости управления транспортной сети; б) протоколы плоскости пользователя транспортной сети (только домен КП)

Рис. 10.19. Транспортная есть — протокол туннелирования GPRS для поль­зовательской плоскости GTP-U: а) протоколы плоскости управле­ния транспортной сети; б) протоколы плоскости пользователя транспортной сети (только домен КП)

 

 

принадлежащими домену КП одной сети UMTS. Интерфейс Gp использует­ся для межсетевого взаимодействия между двумя узлами SGSN или между узлами SGSN и GGSN, относящимися к доменам КП разных сетей UMTS. Интерфейсом между RNC и SGSN служит Iu-PS.

На всех интерфейсах протокол GTP-U работает поверх семейства прото­колов UDP/IP. Протокол UDP обеспечивает передачу сообщений без уста­новления соединений между двумя узлами сети IP. Адресация UDP исполь­зуется для идентификации оконечных точек GTP-U в сетевых элементах ис­точника и пункта назначения. Также UDP поддерживает механизм подсчета контрольной суммы для обнаружения ошибок при передаче пакетов данных. Общеизвестно, что основная услуга протокола IP — это маршрутизация со­общений между сетевыми элементами источника и пункта назначения. Эта маршрутизация основывается на сетевых адресах IP (в транспортной сети UMTS могут использоваться и IPv4, и IPv6).

Протокол GTP-U предоставляет вышестоящим уровням услуги передачи данных без установления соединения и позволяет туннелировать (прозрачно передавать) многопротокольные пакеты пользовательских данных через ин­терфейсы Iu-PS, Gn и Gp. Механизмы инкапсуляции (формирования паке­тов данных) и туннелирования (прозрачной передачи) позволяют передавать пакеты пользовательских данных, несмотря на то что в магистральной сети IP используются различные протоколы маршрутизации. Кроме того, элемен­ты сети UMTS и протоколы передачи пакетов пользовательских данных между UTRAN и GGSN не нуждаются в информации о различных механиз­мах адресации на уровне IP для того, чтобы быть в состоянии связывать па­кеты пользовательских данных с определенными контекстами PDP.

Поскольку основное назначение протокола GTP-U состоит в передаче данных пользователя, он оптимизирован для этой конкретной задачи. Про-токол GTP-U мультиплексирует пакеты, принимаемые от одного интерфейса (например, Gi на узле GGSN) и адресованные нескольким пунктам назначе­ния (различным абонентским терминалам UE). Протокол GTP-U принимает пакеты пользовательских данных из внешней пакетной сети, интерпретирует пункт назначения пакета и отсылает пакет на следующий узел тракта. Задачи установки туннелей — сквозных соединений между оконечными точками GTP-U — не относятся к функциям протокола GTP-U, для этих целей ис­пользуются протоколы плоскости управления. Для управления установкой туннелей GTP-U на интерфейсе Gn используется протокол GTP для плоско­сти управления GTP-C, а на интерфейсе Iu-PS — протоколы прикладной ча­сти сети радиодоступа RANAP.

Во время передачи пакетов элементы GTP-U должны взаимодействовать с другими протокольными элементами. На шлюзовом узле GGSN элемент GTP-U связан с функцией пакетной передачи, размещенной на границе сети UMTS (т. е. на интерфейсе Gi). На управляющем узле SGSN элемент GTP-U со стороны интерфейса Iu-PS взаимодействует с элементом GTP-U со сторо­ны интерфейса Gn. В контроллере RNC элемент GTP-U завершает туннель и направляет пакеты к элементу кадрового протокола на уровне радиосети.

Взаимодействие GTP-U с элементами соседних протоколов реализуется довольно просто, потому что каждый параметр, связанный с передачей паке­тов пользовательских данных, заблаговременно согласован с плоскостью управления. Пакеты пользовательских данных просто продвигаются к следу­ющему элементу, который в состоянии обрабатывать пакет в соответствии с заданными для него параметрами PDP-контекста.

Основные функции протокола GTP-U состоят в следующем:

•  передача пакетов данных;

 

•  инкапсуляция и туннелирование;

•  упорядочение пакетов данных;

•  проверка работы тракта.

 

Максимальный размер пакета пользовательских данных составляет 1500 октетов. Пакеты пользовательских данных, содержащие 1500 или ме­нее октетов, должны передаваться как один пакет. Если пакет, принятый шлюзом GGSN из внешней сети, превышает предел 1500 октетов, то GGSN будет фрагментировать или отбрасывать такой пакет, в зависимости от типа PDP. Поскольку фрагментация IP неэффективна и не допускает ошибок передачи, то ее следует избегать. Поэтому во всех каналах, устанав­ливаемых между элементами сети по протоколу GTP-U, длина максималь­ного блока передачи MTU должна превышать 1500 октетов, не считая раз­мера заголовков GTP-U, UDP и IP.

Перед передачей в пакетную сеть UMTS каждый пакет данных пользова­теля инкапсулируется. При этом к пакету добавляется заголовок GTP, содер­жащий информацию туннелирования. Информация туннелирования включа­ет 32-битовый идентификатор оконечной точки туннеля TEID1, выполняю­щий две важные функции. Во-первых, TEID используется для адресации контекста PDP в оконечной точке туннеля. Таким образом, TEID косвенно направляется к различным абонентским терминалам UE сети UMTS, кото­рые имеют по одному или несколько активных контекстов PDP. Во-вторых, туннелирование дает возможность мультиплексировать пакеты данных поль­зователя, предназначенные для различных адресов, в один тракт, который идентифицируется двумя IP-адресами.

Как необязательная функция, протокол GTP-U может сохранять порядок следования пакетов данных пользователя между контроллером RNC и шлю­зом GGSN. Во время установки контекста PDP в плоскости управления мо­жет проводится переупорядочивание. В случае переупорядочивания пакетов данных пользователя, заголовок GTP будет содержать 16-битовый номер по­следовательности, который GTP-U использует для определения того, в пра­вильном ли порядке приняты пакеты пользовательских данных или следует подождать недостающих пакетов. Однако в случае пропадания недостающего пакета данных пользователя механизм восстановления потерянного пакета не предусмотрен, Задача восстановления потерянного пакета пользователь­ских данных решается на других уровнях.

Элемент GTP может периодически проверять, работает ли равноценный равноправный элемент GTP, посылая ему сообщение — запрос отклика. Равноправный элемент GTP отвечает на этот запрос сообщением отклика. На интерфейсе Gn процедуру проверки работоспособности тракта можно было бы отнести к функциям протокола GTP-C, но на интерфейсе lu-PS есть только один элемент GTP — GTP-U, который и выполняет процедуру проверки работоспособности тракта. На интерфейсе Gp проверка работоспо­собности тракта осуществляется таким же образом, как и на интерфейсе Gn.

Основные процедуры сети UMTS, используюшие протокол GTP-U, глав­ным образом сводятся к передаче пакетов пользонательских данных между се­тью UTRAN и управляющим узлом SGSN, а также между узлами SGSN и GGSN. Когда для процедуры обновления области маршрутизации требуется переключение туннеля GTP-U от одного узла SGSN к другому, прото­кол GTP-U используется для передачи от старого SGSN к новому тех пакетов пользовательских данных, которые еще не были отправлены к оборудованию пользователя UE. GTP-U используется так же, как часть процедуры пере­мещения обслуживающего контроллера SRNC для туннелирования пакетов пользовательских данных, еще не отосланных к оборудованию пользователя UE, от одного контроллера RNC к другому через пару узлов SGSN, связанных с этими RNC.

Протокол GTP-U определен в технических условиях 3GPP TS 29.060.

 

10.4. Протоколы радиосети

 

В архитектуре протокола межсетевого обмена (см. рис. Ю.4) протоколы ра­диосети занимают следующий уровень поверх протоколов транспортной сети, рассмотренных выше. Радиосеть простирается от оборудования пользо­вателя UE через всю сеть UTRAN и заканчивается на граничных узлах базо­вой сети CN. Протоколы радиосети необходимы для управления установкой, обслуживанием и освобождением каналов радиодоступа и для передачи по этим каналам пользовательских данных между оборудованием пользователя UE и базовой сетью.

 

10.4.1. Плоскость управления радиосети

 

Протоколы плоскости управления на уровне радиосети выполняют все необ­ходимые функции по управлению каналами радиодоступа. В соответствии с концепцией клиент-сервер, примененной при разработке плоскости управ­ления UTRAN, эти протоколы обеспечивают управление радиоресурсами и поддерживают каналы радиодоступа для всех абонентских устройств UE, даже когда эти устройства перемещаются в пределах сети UTRAN.

 

10.4.1.1. Прикладной протокол сети радиодоступа RANAP

 

Интерфейс Iu связывает сеть радиодоступа UMTS и базовую сеть CN. Такой же интерфейс Iu используется для подключения к сети UTRAN доменов услуг с коммутацией каналов КК и с коммутацией пакетов КП (см. рис. 10.20). Интерфейс Iu разработан для поддержки независимого развития технологий UTRAN и базовой сети. Кроме того, домены КК и КП внутри базовой сети также могут развиваться независимо друг от друга, по-преж­нему используя один и тот же интерфейс Iu для подключения к сети доступа UTRAN.

С точки зрения сети UTRAN желательно, чтобы соединения с доменами услуг КК и КП были как можно более сходными. Поэтому был разработан единый протокол сигнализации между UTRAN и базовой сетью CN. Это протокол прикладной части сети радиодоступа — RAN АР1, определенный в технических условиях 3GPP TS25.413. Домены КК и КП используют RANAP для доступа к услугам сети UTRAN.

Рис. 10.20. Радиосеть — протокол RANAP: а) протоколы плоскости управле­ния радиосети; б) протоколы плоскости пользователя радиосети (только домен КП)

 

 

Протокол RANAP управляет ресурсами на интерфейсе Iu. Один элемент RANAP находится в контроллере RNC, а другой равноправный элемент — на сервере MSC или в управляющем узле SGSN.

Протокол RANAP расположен поверх транспортного уровня сигнализа­ции Iu. Транспортный протокольный стек состоит из нескольких протоколь­ных уровней, но самый верхний уровень всегда занимает протокол SCCP. Несмотря на два возможных варианта транспортных технологий (ATM или IP), интерфейс для доступа к услугам транспортного протокольного стека протоколу RANAP всегда предоставляется от элемента SCCP.

Протокол RANAP выдвигает определенные требования к транспортным уровням, лежащим ниже его. Это предполагает, что каждое сообщение (PDU), посылаемое RANAP равноправному элементу, достигает пункта на­значения без каких-либо ошибок. Иными словами, транспортный прото­кольный стек несет ответственность за обеспечение надежной передачи дан­ных через интерфейс Iu в блоки PDU протокола RANAP.

Каждый блок PDU услуг выделенного управления должен передаваться в течение однозначно определяемого соединения сигнализации. На интерфей­се Iu такое соединение организуется в канале сигнализации Iu. По запросу транспортные уровни предоставляют протоколу RANAP средства динамиче­ской установки и освобождения каналов сигнализации для интерфейса Iu. Каждое активное оборудование пользователя UE получает собственный ка­нал сигнализации Iu. Ответственность за обслуживание этих каналов несут транспортные уровни. Если по какой-то причине соединение в канале сиг­нализации Iu прерывается, то SCCP проинформирует об этом RANAP.

RANAP предоставляет свои услуги протоколам верхнего уровня: со сто­роны сервера MSC и узла SGSN услуги RANAP могут использовать протоко­лы вне уровня доступа. Взаимодействуя с протоколом RRC в контроллере RNC, RANAP участвует в передаче сообщений сигнализации протоколов верхнего уровня между UE и базовой сетью.

Услуги протокола RANAP подразделяются на две группы: услуги общего управления и услуги выделенного управления. Услуги общего управления от­носятся ко всему интерфейсу Iu между контроллером RNC и базовой сетью. Услуги выделенного управления обеспечивают разделение различных аппара­тов UE на интерфейсе Iu и всегда относятся только к одному оборудованию UE. Большинство услуг RANAP составляют выделенные услуги. Все сообще­ния RANAP, относящиеся к услугам выделенного управления, передаются в течение отдельного соединения. Это соединение называется «соединением сигнализации».

Одна из основных услуг протокола RANAP — это общее управление ка­налами радиодоступа RAB. RANAP предоставляет базовой сети средства для управления установкой, модификацией и освобождением каналов RAB меж­ду оборудованием пользователя UE и базовой сетью. Кроме того, RANAP поддерживает мобильность абонентского оборудования UE, передавая канал RAB новой подсистеме радиосети RNS при перемещении оборудования UE из области одной обслуживающей подсистемы SRNS в другую. Эта услуга называется перемещением SRNS. Еще одна услуга RANAP управляет режи­мом безопасности в сети UTRAN. Все эти услуги относятся к услугам выде­ленного управления. Услуги общего управления необходимы только в исключительных случаях. Например, RANAP предоставляет средства управления нагрузкой на интер­фейсе Iu, если объем пользовательского трафика становится слишком боль­шим. В случае фатального отказа на любом из двух концов интерфейса Iu RANAP предлагает услугу возврата в исходное состояние. Он устанавливает в исходное состояние весь интерфейс Iu и сбрасывает все активные соединения.

Подробное описание протокола RANAP приведено в технических усло­виях 3GPP TS25.413.

 

10.4.1.2. Прикладной протокол подсистемы радиосети RNSAP

 

RNSAP1 — это протокол плоскости управления на уровне радиосети (рис. 10.21). Он обеспечивает обмен сигнализацией управления через интерфейс Iur. Этот протокол выполняется двумя контроллерами радиосети RNC, один из которых играет роль обслуживающего контроллера SRNC, а другой — дрейфующего контроллера DRNC. Обслуживающий контроллер SRNC спо­собствует установлению соединения сигнализации RANAP с базовой се­тью CN.

Протокол RNSAP всегда работает поверх протокола SCPP. Как и в слу­чае RANAP, для SCCP предусмотрено два варианта передачи сигнализации: на основе технологии ATM с уровнем адаптации AAL5 или на основе IP с использованием протоколов SCTP и M3UA в качестве уровня адаптации. SCCP предоставляет протоколу RNSAP возможность передачи сигнализации в двух разных режимах: с установлением и без установления соединения.

 

Рис. 10.21. Радиосеть — протокол RNSAP: а) протоколы плоскости управле­ния радиосети; б) протоколы плоскости пользователя радиосети {только домен КП)

 

Протокол RNSAP отвечает за управляющую сигнализацию каналов на интерфейсе lur. RNSAP используется для установки радиоканалов и позво­ляет обслуживающему контроллеру SRNC управлять этими радиоканалами, используя выделенные ресурсы в дрейфующем контроллере DRNC.

RNSAP использует по одному соединению сигнализации для каждого дрейфующего контроллера DRNC и оборудования пользователя UE, в то время как UE имеет один или более активных радиоканалов для передачи сообщений 3-го уровня. Передаваемая через интерфейс Tur информация мо­жет быть классифицирована следующим образом:

 

•  Сигнализация управления радио- и мобильностью: интерфейс lur обес­печивает           механизм поддержки мобильности радиоинтерфейса между подсистемами радиосети RNS, через которые абонентские терминалы UE соединяются с сетью доступа UTRAN. Этот механизм включает поддержку передачи обслуживания, управление радиоресурсами и син­хронизацию между подсистемами RNS.

•  Потоки данных выделенного канала DCH между интерфейсами lub и lur: интерфейс lur обеспечивает средства для передачи в восходящем и нисходящем направлениях по выделенному каналу DCH между интер­фейсами lub и lur кадров данных пользователя и информации управле­ния между обслуживающим контроллером SRNC и удаленной БС че­рез дрейфующий контроллер DRNC.

•  Потоки данных совмещенного нисходящего канала DSCH на интер­фейсе lur: поток данных канала DSCH на интерфейсе lur соответствует данным, переносимым в одном транспортном канале DSCH для одного оборудования UE. Одно UE может иметь множество таких потоков данных. Кроме того, интерфейс обеспечивает средства для регистрации очередей к SRNC и для DRNC для распределения емкости к SRNC.

•  Потоки данных канала случайного доступа и общего пакетного канала (RACH/CPCH): только в варианте WCDMA-FDD.

•  Потоки данных канала прямого доступа FACH на интерфейсе lur.

•  Потоки данных канала USCH на интерфейсе lur: только в варианте WCDMA-TDD (дуплекс с временным разделением).

•  Потоки данных канала HS-DSCH на интерфейсе lur: поток данных ка­нала HS-DSCH на интерфейсе lur соответствует данным, переносимым одним выделенным потоком MAC для одного оборудования UE. Одно UE может иметь множество таких потоков данных.

 

Основные функции управления UTRAN, поддерживаемые обменом RNSAP, заключаются в следующем:

 

•  управление транспортной сетью;

•  управление трафиком  общих транспортных  каналов  (например,  по­иск — пейджинг);

•  управление трафиком выделенных транспортных каналов (например, установка радиоканала, добавление и удаление, а также регистрация результатов измерений);

•  управление трафиком нисходящих совместно используемых транспорт­ных каналов (например, установка радиоканала, добавление и удале­ние, а также распределение емкости);

•  регистрация результатов измерений для общих и выделенных объектов;

•  перераспределение SRNS — эта функция координирует работу, если роль SRNS должна быть передана другой подсистеме RNS.

 

Протокол RNSAP участвует в процедуре организации радиоканала, фор­мируя в дрейфующем контроллере DRNC необходимые ресурсы для создания одного или более радиоканатов. В сочетании с этой процедурой реализуется услуга организации канала сигнализации с установлением соединения.

Среди других процедур сети UTRAN, которые могут потребовать участия элементов протокола RNSAP, — плавная и жесткая передача обслуживания, обновление ячейки, обновление регистрационной зоны UTRAN (URA) и по­иск (пейджинг), операции управления мощностью в нисходящем канале, а также освобождение и восстановление соединения RRC всякий раз, когда это должно выполняться на интерфейсе Iur.

Полное описание протокола RNSAP приведено в технических условиях 3GPP TS25.423.

 

10.4.1.3. Прикладной протокол узла В — NBAP

 

NBAP — это протокол уровня радиосети, который поддерживает сигнализа­цию плоскости управления через интерфейс lub и, таким образом, управляет ресурсами на интерфейсе lub и обеспечивает связь между БС и контролле­ром RNC (рис. 10.22). На каждой БС находится равноправный элемент про­токола NBAP, а другой равноправный элемент находится в контроллере ра­диосети RNC, обслуживающем данную БС.

Протокол NBAP расположен выше транспортных уровней lub и исполь­зует их услуги для передачи своих сообщений через интерфейс lub. В версии R99 3GPP в качестве основной транспортной технологии для передачи сигнализации

 

Рис. 10.22. Радиосеть — протокол NBAP: а) протоколы плоскости управления радиосети; б) протоколы плоскости пользователя радиосети (толь­ко домен КП)

Рис. 10.23. Операционная среда протокола NBAP

 

 

 

NBAP через интерфейс Iub выбрана технология ATM. Соедине­ние ATM вместе с необходимыми уровнями адаптации ATM предоставляет канал сигнализации для протокола NBAP, как это определено в технических условиях 3GPP TS25.432. Технические условия 3GPP версии R5 определяют два варианта основной транспортной технологии: первый — ATM версии R99, второй — SCTP через стек протоколов IP. Стандарт 3GPP версии R5 позволяет операторам выбрать для передачи сообщений NBAP один из двух протокольных стеков.

Канал сигнализации для NBAP обеспечивает надежное соединение точ­ка-точка. То есть протокол NBAP предполагает, что каждое сообщение, от­правленное им к равноправному элементу, достигнет пункта назначения без каких-либо ошибок. На интерфейсе Jub может быть множество каналов точ­ка-точка для сигнализации NBAP.

Базовая станция БС самостоятельно не принимает никаких решений о радиоресурсах или управлении каналами RAB, а только отрабатывает коман­ды, поступающие от контроллера радиосети RNC. NBAP предоставляет услу­ги модулям управления контроллера RNC и базовой станции БС. NBAP имеет также интерфейс с протоколом RRC, обеспечивая элемент RRC в БС информацией, подлежащей размещению в логическом вещательном канале управления ВССН. Других интерфейсов с протоколами уровня радиосети UTRAN протокол NBAP не имеет, и все взаимодействие с ними осуществля­ется через модуль управления RNC.

Рисунок 10.23 иллюстрирует операционную среду протокола NBAP, при этом все интерфейсы NBAP обозначены жирными черными стрелками.

Все ресурсы, физически реализованные в базовой станции БС, логически принадлежат контроллеру радиосети RNC и управляются им. Поэтому физи­ческие ресурсы БС воспринимаются управляющим контроллером CRNC как логические ресурсы. Этот RNC управляет уровнем логических ресурсов, в то время как физическая реализация ресурсов и процедуры управления в БС пока не определены. Выполняемые в БС физические процедуры изменяют со­стояние логических ресурсов, принадлежащих RNC, и это требует некоторого информационного обмена между RNC и БС для обновления информации в RNC в соответствии с произошедшими изменениями. Такой информацион­ный обмен называется логической эксплуатацией и сопровождением О&М ба­зовой станции БС и составляет неотъемлемую часть сигнализации NBAP.

Среди других важных функций протокола NBAP — установка и обслужи­вание соединения плоскости управления через интерфейс Iub, инициализа­ция установки и освобождения выделенных соединений плоскости пользова­теля через интерфейс Iub и формирование команд для БС на активизацию ресурсов для новых радиоканалов через интерфейс Uu. Все функции сигна­лизации NBAP делятся на общие и выделенные процедуры.

Общие процедуры NBAP не связаны с каким-либо конкретным оборудова­нием UE, но связаны с общими ресурсами через интерфейс Iub. Основную часть общих процедур NBAP составляет сигнализация, относящаяся к логиче­ской эксплуатации и сопровождению О&М базовой станции БС. Это процеду­ры управления конфигурацией логических ресурсов и процедуры, дающие БС возможность информировать RNC о состоянии логических ресурсов. Общие процедуры NBAP также позволяют контроллеру RNC инициировать опреде­ленные измерения на базовой станции БС, а базовой станции — сообщать ре­зультаты измерений. Кроме логической эксплуатации и сопровождения О&М используется еще одна процедура для доставки информации, подлежащей пе­редаче в широковещательном канале от RNC к БС. Существует также общая процедура NBAP, инициирующая создание на базовой станции БС нового контекста каждого абонентского оборудования UE с помощью организации радиоканала для этого UE и процедуры обслуживания соединения сигнализа­ции в плоскости управления на интерфейсе Iub. Поэтому на интерфейсе Iub всегда имеется один канал сигнализации для общих процедур NBAP, который оканчивается на общем порту управления базовой станции БС.

Выделенные процедуры NBAP всегда связаны с конкретным оборудова­нием UE, которое уже имеет контекст UE на базовой станции БС. Это про­цедуры управления и контроля существующих радиоканалов, оборудование UE которых подключено к БС. Выделенные процедуры NBAP позволяют контроллеру RNC выдавать базовым станциям БС команды на организацию или освобождение радиоканалов для контекста UE. Выделенные процедуры NBAP также дают возможность БС уведомлять о сбое или восстановлении передачи в радиоканале. Имеются также выделенные процедуры управления реконфигурацией радиоканала и поддержки измерений, использующих вы­деленные ресурсы и соответствующие операции управления мощностью, что позволяет RNC регулировать уровень мощности в нисходящих каналах.

Выделенная сигнализация NBAP осуществляется через один из портов управления передачей логической модели БС. Через интерфейс Iub может проходить несколько выделенных каналов сигнализации для выделенных процедур NBAP.

Полное описание протокола NBAP приведено в технических условиях 3GPP TS25.433.

 

Рис. 10.24. Радиосеть — RRC: а) протоколы плоскости управления в радиосети; б) протоколы плоскости пользователя радиосети (только домен КП)

 

10.4.1.4. Протокол управления радиоресурсами RRC

 

Протокол RRC — это ключевой протокол управления радиоресурсами в сети UTRAN (рис. 10.24). Он поддерживает рассмотренную в главе 5 функ­цию управления радиоресурсами RRM, координируя исполнение запросов управления ресурсами, по решениям, инициируемых алгоритмами RRM. С помощью протокола RRC влияние решений RRM может распространять­ся на все элементы сети UTRAN, к которым относятся эти решения. Сооб­щения протокола RRC также переносят в поле своей полезной нагруз­ки все сигналы сигнализации, относящиеся к протоколам вне уровня до­ступа.

Протокол RRC работает между оборудованием пользователя UE и конт­роллером радиосети RNC. Для передачи сообщений сигнализации элементы протокола RRC используют каналы сигнализации, предоставляемые под­уровнем RLC. Как показано на рис. 10.25, все три режима RLC пригодны для использования в качестве точек доступа к услуге SAP1 различных клас­сов. Например, прозрачный режим TM-SAP используется в случаях, когда оборудованию UE необходимо связаться с контроллером RNC до установки полного соединения RRC (например, первоначальный доступ или процедуры обновления соты или зоны URA при перемещении абонента в новую соту). Прозрачный режим также используется для часто повторяемых сообщений, подобных поисковым (пейджинговым) сообщениям, чтобы избежать ненуж­ной избыточности. Режим с подтверждением AM-SAP используется для сигнализации управления, относящейся к одному оборудованию UE, когда необходимо обеспечить надежность обмена сообщениями.  В то же время

Рис. 10.25. Логическая    структура   элемента   протокола    RRC    в    системе WCDMA-FDD

 

 

режим без подтверждения UM-SAP используется для предотвращения воз­можной задержки, имеющей место в режиме сигнализации с подтверждени­ем (например, если при освобождении соединения RRC сообщение осво­бождения повторяется много раз — функция быстрых повторений, то для повышения вероятности его приема оборудованием UE используется режим UM-SAP).

На рис. 10.25 показана также логическая структура элемента протокола RRC. Элемент функции выделенного управления DCFE1 используется для обработки всех сигналов сигнализации, относящихся к одному UE. В об­служивающем контроллере SRNC имеется по одному элементу DCFE для каждого UE, имеющего соединение RRC с данным RNC. Элемент функций поиска (пейджинга) и извещения PNFE2 обрабатывает пейджинговые сооб­щения, посылаемые на незанятые устройства UE. В управляющем контрол­лере CRNC имеется, по крайней мере, один элемент PNFE для каждой соты, подлежащей управлению. Элемент функции управления радиовеща­нием BCFE3 обрабатывает системную информацию радиовещания в логи­ческих каналах ВССН и FACH. В управляющем контроллере CRNC имеет­ся, по крайней мере, один элемент BCFE для каждой соты. Кроме этих функциональных элементов в верхней части рис. 10.25 показан также спе­циальный элемент функции маршрутизации RFE4. Его назначение — мар­шрутизировать сообщения вне уровня доступа5 к различным элементам ММ/СМ на стороне UE и различным доменам базовой сети CN на сторо­не RNC.

Элементы RRC в оборудовании UE и RNC играют ключевую роль в рас­пределении радиоресурсов, и поэтому управляют соответствующими элемен­тами протоколов LI, MAC и RLC. Для выполнения команд управления на этих элементах протоколов низшего уровня элементы протокола RRC исполь­зуют специальные контрольные точки доступа к услуге SAP (см. рис. 10.25). Эти контрольные точки также используются для отчетных измерений и не­обычных условий, определяемых нижними уровнями.

Основная функция протокола RRC — управление радиоканалами, транспортными и физическими каналами. Это осуществляется посредством организации, реконфигурации и освобождения радиоканалов разных видов. До выполнения таких операций необходимо инициировать передачу прото­кола RRC с помощью нескольких (минимум четырех) радиоканалов сигна­лизации. Полученное соединение сигнализации вместе с любыми други­ми каналами, организованными позже, называется соединением RRC. Во время соединения RRC организация, реконфигурация и освобождение других радиоканалов для трафика пользовательской плоскости могут осу­ществляться посредством обмена командами и информацией о статусе между равноправными элементами RRC по радиоканалам сигнализации. Соединение RRC будет продолжать существовать до тех пор, пока все ка­налы пользовательской плоскости и соединение RRC между UE и RNC не будут освобождены.

Механизм защиты информации, применяемый в радиоканалах, активи­зируется и дезактивируется под управлением протокола RRC. Кроме активи­зации защиты конфиденциальности посредством шифрования, протокол RRC может также обеспечивать целостность всех сообщений сигнализации верхнего уровня и большинства своих собственных сообщений сигнализа­ции. Это свойство рассматривается в главе 9, а реализуется благодаря присо­единению к каждому блоку данных PDU протокола RRC 32-битового кода аутентичности сообщения, который подсчитывается и проверяется самими элементами RRC. Это позволяет элементу RRC удостовериться на приеме в том, что данные сигнализации не были модифицированы и действительно сформированы заявленным равноправным элементом. Операции по замене ключей, используемых этими функциями, выполняются протоколом RRC по командам, поступающим из базовой сети CN.

Управление мобильностью оборудования UE—ММ на уровне UTRAN осу­ществляется с использованием сигнализации протокола RRC. Среди функций ММ, выполняемых протоколом RRC — обновление соты, обновление зоны URA и списка активации. Все эти функции были рассмотрены в главе 5, а не­которые их примеры будут приведены в главе 11.

Протокол RRC отвечает за управление радиоизмерениями и составление отчетов о них. Всего в оборудовании UE может быть активизировано семь различных категорий измерений, среди них измерение по определению мес­тоположения UE. Каждое измерение может отдельно использоваться и реги­стрироваться последующими измерениями.

Помимо вышеупомянутых задач, протокол RRC также управляет переда­чей системной информации в вещательном режиме и при поиске UE, а так­же изменяет параметры при регулировании мощности.

Как протокол RRC довольно сложен: в целом он имеет около 40 различ­ных процедур и более 60 различных классов PDU.

Протокол RRC описан в технических условиях 3GPP TS 25.331.

 

10.4.2. Пользовательская плоскость радиосети

 

10.4.2.1. Протокол конвергенции пакетных данных PDCP

 

Как видно из названия, протокол PDCP разработан, чтобы сделать радио­протоколы WCDMA пригодными для передачи от пользователя к пользова­телю самого распространенного протокола пакетных данных— TCP/IP. Элементы PDCP можно найти на обеих сторонах радиоинтерфейса WCDMA: RNC и UE (см. рис. 10.26). Основное свойство протокола PDCP — это его способность сжимать заголовки протоколов полезной на­грузки, которые при передаче без сжатия привели бы к излишней трате бесценной емкости радиоканала (например, размер заголовка RTP/UDP/IP без сжатия составляет, по крайней мере, 40 байт для IPv4 и, по крайней мере, 60 байт для IPv6). Поскольку размер поля полезной нагрузки пакета для услуг IP передачи речи составляет около 20 байт или менее, то избы­точность без сжатия очевидна.

В модели протоколов радиоинтерфейса 3GPP протокол PDCP относится к уровню радиоканала (L2), самый верхний подуровень которого специально разработан для радиоканалов пользовательской плоскости, переносящих па­кетные данные.

PDCP использует услуги уровня RLC в трех различных режимах. Эти услуги предоставляются в трех различных точках доступа SAP:

 

•  передача данных подтверждается (AM-SAP);

•  передача данных не подтверждается (UM-SAP);

•  передача данных в прозрачном режиме (TM-SAP).

 

Протокол PDCP предполагает, что SAP обеспечивается уровнем RLC, находящимся ниже. Когда поддерживается перераспределение SRNS без потерь, протокол PDCP использует режим с подтверждением AM-SAP и пред­полагает последовательную доставку блоков SDU уровня RLC.

 

Рис. 10.26. Плоскость пользователя радиосети — PDCP: а) протоколы плос­кости управления радиосети; б) протоколы плоскости пользовате­ля радиосети (только домен КП)

 

 

Когда требуется надежная передача данных, протокол PDCP использует режим с подтверждением AM-SAP. В этом случае уровень RLC может отбро­сить некоторые блоки SDU, если он сконфигурирован соответствующим об­разом. При этом предполагается, что уровень RLC может сообщать протоко­лу PDCP обо всех отброшенных блоках SDU — как на передаче, так и на приеме. Такая индикация стала необходимой из-за того, что PDCP, как про­токол сжатия, не передает в радиоканал явные порядковые номера, исполь­зуя вместо этого схему виртуальной нумерации. Поэтому необходимо инфор­мировать протокол PDCP о возможном сбросе соединения RLC и реконфи­гурации радиоканала, особенно в случае выполнения перераспределения SRNS без потерь.

При использовании прозрачного режима TM-SAP предполагается, что размеры блоков данных PDU протокола PDCP должны быть фиксированны­ми. Это означает очень строгие требования либо к размерам блоков PDU верхнего уровня (например, протокола IP), либо к применяемому сжатию за­головка IP. В общем случае ни один из определенных сейчас методов сжатия заголовков IP на верхних уровнях домена КП не может удовлетворить этим требованиям, поэтому режим TM-SAP должен использоваться очень осто­рожно и только в хорошо изученных случаях.

Элемент PDCP, работающий в контроллере RNC, должен взаимодей­ствовать с кадровыми протоколами UTRAN для того, чтобы передавать пакеты данных в нисходящем направлении от Iu к Iub/Iur и в восходящем направлении от Iub/Iur к Iu. Обычно это достигается простым копирова­нием пакетов с одного интерфейса на другой и выполнением установлен­ной процедуры сжатия/восстановления заголовка. Дела обстоят сложнее, когда требуется организовать межсистемную передачу обслуживания или перераспределение SRNS без потерь. Поэтому для взаимодействия с кад­ровыми протоколами Iu и с протоколом RRC протокол PDCP снабжен специальными правилами, служащими для того, чтобы пакеты не терялись и не дублировались и порядковые номера пакетов можно было восстано­вить после передачи обслуживания или перераспределения в адресуемой системе.

В версии R99 3GPP был предусмотрен только один алгоритм сжатия за­головка IP — в соответствии с документом IETF RFC 2507. Однако общая структура протокола PDCP позволит в будущем использовать и другие алго­ритмы сжатия. В версии R4/R5 для протокола PDCP добавлен еще один ал­горитм сжатия заголовка — помехоустойчивое сжатие заголовка ROHC1 в со­ответствии с документом IETF RFC 3095.

Полное описание протокола PDCP дано в технических условиях 3GPP TS 25.323, а более подробную информацию можно найти у Холма и Тоскала (Holma, Toskala - 2004).

Рис. 10.27. Плоскость пользователя радиосети — кадровые протоколы UTRAN: а) протоколы плоскости управления радиосети; б) про­токолы плоскости пользователя радиосети (только домен КП)

 

10.4.2.2. Кадровые протоколы UTRAN

 

Кадровые протоколы UTRAN — это протоколы плоскости пользователя уровня радиосети, которые переносят данные пользователя UMTS по общей транспортной сети UTRAM (рис. 10.27). Они работают через интерфейсы UTRAN Iu, Iur и Iub. Как было рассмотрено в подразделе 10.3.3, услуга транспортной сети, используемая кадровыми протоколами, базируется на наборе протоколов ATM или IP.

 

10.4.2.2.1. Кадровый протокол на интерфейсе Iu

 

Протокол обработки кадров на интерфейсе Iu был разработан для удовлетво­рения требованиям передачи абонентского трафика в доменах КК и КП. Транспортные услуги для этих двух доменов различны, и поэтому кадровый протокол на интерфейсе Iu имеет два режима:

•  прозрачный  режим,   который   используется   в   радиоканалах  доступа RAB, не требующих каких-либо специальных протокольных операций, подобных разбиению на кадры. Поэтому данные пользователя в этом режиме просто пропускаются к стеку транспортной сети без добавле­ния какой-либо протокольной информации. Следовательно, прозрач­ный режим образует нулевой протокол. Он может использоваться для переноса пакетов данных не в реальном масштабе времени в их обыч­ном формате GTP-U их плоскости от RNC к SGSN и обратно;

•  опорный режим,  который принимает форму реального  протокола с управлением блоками данных PDU и создания кадров (или циклов) данных пользователя. Эти форматы протоколов применимы к каналам RAB, которые могут переносить в домене с КК речевые сигналы в коде AMR. Следовательно, управление PDU в опорном режиме обеспечива­ет управление скоростью и временное согласование, необходимые для передачи речи в реальном масштабе времени. В этом случае протокол опорного режима непосредственно использует услугу AAL2 или сеанс RTP, предоставляемые нижележащей транспортной сетью.

 

10.4.2.2.2.  Кадровый протокол для выделенных каналов на интерфейсах iur и lub

 

Как показано на рис. 10.28, для выделенных каналов DCH на интерфейсах lub и Iur существует общий кадровый протокол. С помощью этого протокола об­служивающий контроллер SRNC может обмениваться кадрами пользователь­ских данных с устройствами пользователей UE, обслуживаемыми данным контроллером или удаленными базовыми станциями БС. Кроме обычной пе­редачи данных в восходящем и нисходящем направлениях, этот кадровый протокол может выполнять множество функций управления, связанных с вре­менным выравниванием и синхронизацией. В сообщениях кадрового прото­кола DCH в направлении базовых станций БС могут посылаться команды управления мощностью и команды обновления других параметров радио­интерфейса.

 

10.4.2.2.3.  Кадровые протоколы для общих транспортных каналов на интерфейсах lur и lub

 

Для передачи и приема кадров данных по общим транспортным каналам су­ществует два различных протокола с обработкой кадров: один для интерфей­са lub, а другой — для Iur. Взаимодействие этих протоколов осуществляется в дрейфующем контроллере DRNC, как показано на рис. 10.29.

Рис. 10.28. Кадровый протокол для выделенных каналов lub/Iur

 

Кроме передачи данных в восходя­щем и нисходящем направлениях, кото­рая в некоторой степени определяется типом транспортного канала, эти про­токолы выполняют также задачи управ­ления. На интерфейсе Iur реализуется управление потоком с обработкой кад­ров на основе разрешения на передачу очередного пакета данных. Функции обработки кадров на интерфейсе Iub включают синхронизацию и временное согласование, а также управление пото­ком в канале HS-DSCH.

Рис. 10.29. Кадровый    протокол   для общих транспортных каналов Iub/Iur

 

10.5. Системные сетевые протоколы

 

Как только протоколы радиосети создают тракт для подключения мобильных терминалов к подсети UTRAN, системные сетевые протоколы предоставляют пользователям этих терминалов услуги связи. Системные (сетевые) протоко­лы работают поверх радиосети и в пределах самой базовой сети CN UMTS.

 

10.5.1. Протоколы вне уровня доступа

 

Протоколы вне уровня доступа относятся к группе протоколов плоскости управления, контролирующих передачу между устройствами пользователей UE и базовой сетью CN. Общее название «вне уровня доступа» означает, что эти протоколы переносятся через сеть радиодоступа RAN прозрачно.

Протоколы этой группы относятся к двум подуровням сети, как это по­казано на рис. 10.3. Подуровень ММ работает поверх соединений сигнализа­ции, предоставляемого радиосетью. Подуровень управления мобильностью ММ, помимо выполнения собственных функций, выступает в качестве сре­ды передачи для протоколов подуровня управления связью СМ.

 

10.5.1.1. Протокол управления мобильностью ММ для домена КК

 

Протокол ММ работает между оборудованием пользователя UE и MSC/VLR (см. рис. 10.30). Этот протокол плоскости управления обеспечивает основ­ные механизмы сигнализации для управления мобильностью ММ и выпол­нения функций аутентификации между устройствами пользователей UE и доменом КК базовой сети. Протокол ММ поддерживается оборудованием пользователей UE, работающим как в режиме КП/КК, так и только в режи­ме КК.

Протокол ММ использует соединение сигнализации, предоставляемое протоколами уровня радиосети. Это соединение сигнализации, которое ино­гда называют соединением радиоресурсов RR, состоит из соединений прото­кола RRC по радиоканалу сигнализации и соединений протокола RANAP по каналу сигнализации Iu. Прежде чем активизируется протокол ММ, должно

Рис. 10.30. Системный сетевой протокол вне уровня доступа — протокол ММ

домена КК: а) протоколы плоскости управления сети (домен КК); б) протоколы плоскости управления сети (домен КП)

 

 

быть установлено соединение сигнализации. Внутри базовой сети CN эле­мент протокола ММ на стороне коммутационного центра MSC/VLR для поддержки регистрации местоположения в регистре HLR должен взаимодей­ствовать с протоколом MAP.

Протокол управления мобильностью ММ управляет состоянием ММ обо­рудования пользователя UE и соответствующего равноправного элемента на стороне сети. Основные состояния элементов этого протокола определяют статус обновления местоположения UE, от которого в основном зависит воз­можность UE использовать услуги подуровня управления связью СМ. По этой же причине протокол ММ используется для переноса сообщений протоколов подуровня СМ между UE и MSC/VLR.

Протокол ММ имеет три основные категории процедур:

 

•  процедуры соединения ММ;

•  общие процедуры ММ;

•  частные, специальные процедуры ММ.

 

Процедуры соединения ММ используются для установки и освобожде­ния соединений ММ, а также для передачи сообщений подуровня СМ. Уста­новление соединения ММ не предусматривает обмена какими-либо иниции­рующими сообщениями протокола ММ. Соединение ММ устанавливается и освобождается по запросу элемента СМ.

Когда установка соединения ММ инициируется оборудованием пользо­вателя UE, элемент протокола ММ выдает запрос на услугу СМ (СМ SERVICE REQUEST), содержащий следующие параметры:

 

•  идентификатор UE (например, TMSI);

•  указатель категории услуг 2-й мобильной станции;

•  порядковый номер ключа шифрования;

•  тип услуги СМ, идентифицирующий запрашиваемую операцию, на­пример установление исходящего соединения, экстренный вызов, SMS или активизация дополнительных услуг.

Элемент протокола ММ, принимающий этот запрос на стороне базовой сети CN, анализирует эти параметры и принимает решение о принятии и об­работке запроса на услугу.

Запрос на установку соединения ММ может поступить и от элемента СМ со стороны сети. Этот запрос выполняется при установке оборудованием UE соединения ММ с помощью процедуры поиска (пейджинга).

Когда соединение ММ установлено, оно может использоваться элемен­том подуровня СМ для передачи информации. Каждый элемент СМ будет иметь собственное соединение ММ. Различные соединения ММ идентифи­цируются дискриминатором протокола PD1 и дополнительно идентификато­ром операции XI2.

Установленное соединение ММ может освобождаться локальным эле­ментом СМ. Затем происходит локальное освобождение соединения на по­дуровне ММ (т. е. для этих целей через радиоинтерфейс не посылается ника­ких сообщений).

Общие процедуры ММ могут инициироваться в любое время, пока ак­тивно соединение ММ. Эти процедуры используются главным образом для выполнения функций защиты информации, когда идентификатор и место­положение оборудования UE известны базовой сети CN и между базовой се­тью и UE существует соединение ММ. Ниже перечислены обязательные об­щие процедуры ММ.

 

•  Перераспределение TMSI, используемое для обеспечения конфиденци­альности идентификатора пользователя (т. е. для защиты пользователя от идентификации и определения его местоположения злоумышленни­ком). MSC/VLR выделяет для использования в процедурах радиоинтер­фейса временный идентификатор мобильного абонента TMSI вместо постоянного и, следовательно, доступного для отслеживания иденти­фикатора 1MSI. Данная процедура инициируется базовой сетью CN и обычно выполняется в шифрованном режиме.

•  Аутентификация,  позволяющая базовой сети CN проверять правиль­ность полученного идентификатора оборудования UE и предоставлять абонентскому модулю USIM параметры для вычисления новых ключей шифрования и целостности. В запросе идентификатора сети UMTS про­цедура аутентификации расширена, чтобы дать оборудованию пользова­теля UE возможность проверить подлинность базовой сети CN (см. гла­ву 9), что, например, позволяет обнаружить ложную базовую станцию БС. Процедура аутентификации всегда инициируется базовой сетью CN.

•  Идентификация, используемая базовой сетью CN для запроса у обору­дования пользователя UE его идентификационных параметров, таких как международный идентификатор мобильного абонента IMSI и меж­дународный идентификатор мобильного оборудования IMEI.

•  Отсоединение IMSI, которое инициируется оборудованием пользовате­ля   UE,   когда  оно дезактивируется   или   когда  абонентский  модуль USIM отсоединяется от мобильного оборудования ME. Каждая сеть UMTS может транслировать в системном информационном блоке спе­циальный флаг (признак) для индикации того, запрашивалась ли про­цедура отсоединения оборудованием UE. При приеме сообщения ин­дикации отсоединения IMSI (MM IMSI DETACH INDICATION) сеть может установить для данного IMSI неактивную индикацию. Ответа к оборудованию UE при этом не посылается. После этого сеть будет час­тями освобождать действующие соединения ММ и запустит обычную процедуру освобождения соединения сигнализации.

•  Преждевременное прекращение, которое может использоваться базо­вой сетью CN для прерывания устанавливаемого или уже установлен­ного соединения ММ из-за сбоя в работе сети или при обнаружении несанкционированного оборудования ME.

 

Частные, специальные процедуры ММ обрабатывают сообщения, исполь­зуемые в процедурах обновления местоположения. Пример потока сообщений процедуры обновления местоположения приведен в главе 11. Существует три варианта основной процедуры обновления местоположения:

•  Обычное обновление местоположения используется в случаях, когда оборудование UE, обнаружив изменение области своего местоположе­ния, должно информировать об этом базовую сеть CN. Новое местопо­ложение обнаруживается при сравнении значения идентификатора об­ласти местоположения LAI, распространяемого сетью, с текущим зна­чением LAI, хранящимся в модуле USIM. Обычная процедура обновле­ния местоположения будет также запускаться в ответ на запрос услуги, если сеть обнаруживает, что данное UE неизвестно гостевому регистру VLR. Оборудование UE должно поддерживать хранящийся в модуле USIM список «запрещенных для роуминга областей местоположения», составленный по неудачным запросам обновления местоположения.

•  Периодическое обновление местоположения, используемое для перио­дического оповещения базовой сети CN о доступности и местоположе­нии UE по времени, установленному в UE. Значение лимита времени для этого берется из информационного блока, передаваемого системой в режиме радиовещания,

•  Процедура присоединения модуля 1MSI, выполняется при вхождении (или включении) оборудования UE в ту же область сети, от которой оно раньше было отсоединено (т. е. когда значение индикатора LA1, распространяемое в текущей соте, равно значению индикатора LAI в модуле USIM).

 

Характерная особенность, общая для всех частных процедур ММ, состо­ит в том, что они могут быть инициированы только тогда, когда не выполня­ется другая частная процедура ММ или когда не существует никакого соеди­нения ММ. Следует отметить, что любые описанные выше общие процедуры ММ (за исключением отсоединения IMSI) могут быть инициированы во время работы частной процедуры ММ.

Рис. 10.31. Системный сетевой протокол вне уровня доступа — протокол ММ домена КП: а) протоколы плоскости управления сети (домен КК); б) протоколы плоскости управления сети (домен КП)

 

Поскольку протокол ММ — это прямое расширение его предшественни­ка, используемого в системах GSM, читателю, нуждающемуся в более по­дробной информации о нем, следует обратиться к любой книге по GSM, приведенной в списке литературы. Полное описание протокола ММ, вклю­чая особенности его использования в UMTS, приведено в технических усло­виях 3GPP TS 24.008.

 

10.5.1.2. Протокол управления мобильностью GPRS — GMM1 для домена КП

 

Протокол GMM работает между оборудованием пользователя UE и управля­ющим узлом поддержки GPRS — SGSN (см. рис. 10.31). Название «управле­ние мобильностью GPRS» используется потому, что протокол в основном сформирован на основе соответствующего протокола для услуг с КП, ис­пользуемого в системе GSM/GPRS. Этот протокол плоскости управления обеспечивает основные механизмы сигнализации для управления мобиль­ностью ММ и выполнения функций аутентификации между устройствами пользователей UE и доменом КП базовой сети CN. Протокол GMM поддер­живается оборудованием пользователей UE, работающим как в режиме КП/КК, так и только в режиме КП.

Подобно протоколу ММ, протокол GMM использует соединение сигна­лизации между UE и SGSN. Это соединение сигнализации, иногда называе­мое соединением сигнализации КП, обеспечивается протоколами уровня ра­диосети — с использованием протокола RRC по радиоканалу сигнализации и протокола RANAP по каналу сигнализации Iu. Элемент протокола GMM на стороне SGSN должен взаимодействовать с элементом GTP-C для обмена информацией о местоположении.

Оборудование UE, работающее в режиме КП/КК, может иметь соедине­ние сигнализации с MSC/VLR и SGSN одновременно. Из соображений оп­тимизации принято, что в таких случаях элементы GMM и в UE, и в SGSN могут выполнять так называемые комбинированные процедуры. Задача ком­бинированных процедур — предотвратить одновременную передачу сообще­ний ММ и GMM, когда домен КП базовой сети CN может просто информи­ровать домен КК о таких комбинированных операциях внутри базовой сети. Для выполнения этих операций на стороне базовой сети используется необя­зательный интерфейс Gs.

С точки зрения услуг пакетной передачи данных очень важно различать состояния, когда UE вместе со своим идентификатором и информацией о местоположении распознается или не распознается доменом КП базовой сети CN. Важность этого обусловлена тем, что пакетные пользовательские данные защищены шифрованием, осуществляемым с помощью специальных пользовательских ключей. Это разделение лежит в основе понятия контекста GMM. Если пользователь распознается доменом КП базовой сети CN, то контекст GMM существует, в противном случае — нет.

Существуют следующие процедуры GMM для явного установления и освобождения контекста GMM:

 

•  Присоединение GPRS и комбинированное присоединение GPRS, пре­доставляющие   сети   информацию   об   идентификаторе   пользователя (обычно P-TMSI) и текущей области маршрутизации и устанавливаю­щие контекст GMM для данного пользователя. Эта процедура обычно выполняется при включении оборудования UE в пакетном режиме или при введении в него модуля USIM. В случае процедуры комбинирован­ного присоединения GPRS, выполняются операции обычного присо­единения IMSI.

•  Отсоединение GPRS или комбинированное отсоединение GPRS, кото­рые активизируются, когда оборудование UE отключается или из него удаляется модуль USIM, а также при сбое в работе сети. Эти процеду­ры фиксируют неактивное состояние оборудования UE только в доме­не КП базовой сети или в случае комбинированной процедуры отсо­единения GPRS также и в домене КК.

 

Когда контекст GMM уже существует, для управления определением местоположения используются следующие процедуры:

 

•  Обычное или комбинированное обновление области маршрутизации, выполняемые в случае, когда оборудование UE распознает, что область маршрутизации изменилась и ему необходимо проинформировать об этом событии домен КП базовой сети. Процедура комбинированного обновления области маршрутизации включает также обновление облас­ти местоположения для домена КК базовой сети.

•  Периодическое  обновление  области   маршрутизации,   которое  может использоваться для периодического оповещения базовой сети CN о до­ступности оборудования UE в соответствии с установленным в UE ин­тервалом времени.

Когда для пользователя установлен контекст GMM, в целях защиты ин­формации могут быть инициированы следующие общие процедуры GMM:

•  Перераспределение   P-TMSI,   которое  обеспечивает  использование  в процедурах   радиоинтерфейса   временного   идентификатора   P-TMSI вместо постоянного и, следовательно, отслеживаемого идентификатора IMSI. Обычно процедура перераспределения P-TMSI выполняется в сочетании с другой процедурой GMM, такой как обновление области маршрутизации.

•  Аутентификация и шифрование GPRS, всегда инициируемые базовой сетью CN, позволяют базовой сети проверять правильность полученно­го идентификатора оборудования UE. Эта процедура также предостав­ляет абонентскому модулю USIM параметры для вычисления ключей шифрования и целостности UMTS и дает оборудованию пользователя UE   возможность   идентифицировать  базовую  сеть.   Более  подробно функции защиты информации изложены в главе 9.

•  Идентификация  GPRS,  которая  используется доменом  КП  базовой сети CN для запроса у оборудования пользователя UE его идентифика­ционных параметров, таких как IMSI и IMEI.

Для предоставления услуг уровню СМ поверх протокола GMM, требует­ся еще одна процедура GMM:

•  Запрос услуги,  инициируемый оборудованием пользователя UE, ис­пользуется для установки безопасного соединения с сетью и/или за­проса на организацию канала передачи данных. Эта процедура обычно применяется,   когда  оборудование   UE должно  посылать  сообщения сигнализации, требующие защиты информации (например, ответные сообщения SM или поиска — пейджинга).

Более подробное описание протокола GMM можно найти в технических условиях 3GPP TS24.008.

 

10.5.1.3 Протокол управления вызовами СС

 

Протокол СС обеспечивает основные механизмы сигнализации для организа­ции и освобождения соединений при предоставлении услуг с КК (например, при обслуживании речевых или мультимедийных вызовов) (см. рис. 10.32). Этот протокол применяется между MSC/VLR и устройствами пользователей UE, работающими в режиме КК/КП или только КК. Протокол СС использует услугу соединения, предоставляемую подуровнем ММ для переноса сообще­ний протокола СС.

Управление обычными телефонными вызовами осуществляется во мно­гом так же, как и в телефонии ISDN. Следовательно, элемент протокола СС в GMSC должен взаимодействовать с протоколом ISUP для организации вы­зывного тракта к внешней сети ISDN.

Мультимедийные вызовы с КК обслуживаются сетью UMTS в соответст­вии с документом 3G-324M, который представляет собой вариант Рекомен­дации МСЭ-Т Н.324. С деталями можно ознакомиться, обратившись к тех­ническим условиям 3GPP TS26.111.

Рис. 10.32. Системный сетевой протокол вне уровня доступа — протокол СС: а) протоколы плоскости управления в сети (домен КК); б) прото­колы плоскости управления в сети (домен КП)

 

Процедуры организации вызова устанавливают соединение СС между оборудованием UE и базовой сетью CN и при необходимости приводят в действие голосовой/мультимедийный кодек и функции взаимодействия. Элемент протокола СС в MSC/VLR взаимодействует также с элементом протокола RANAP, чтобы организовать радиоканалы RAB для обслужива­ния вызова с КК. Это означает, что требования качества обслуживания QoS, принимаемые элементом протокола СС в сообщении СС SETUP (установка СС), должны в том же MSC/VLR преобразовываться в запрос RAB для элемента протокола RANAP. Только после того, как сеть UTRAN подтверждает выделение канала RAB, установление соединения может быть продолжено.

Устанавливаемые соединения могут быть исходящими или входящими. Для мультимедийных вызовов с КК применяется обычная процедура уста­новления соединения с некоторыми дополнительными элементами для сооб­щений протокола СС. Процедура освобождения соединения, инициируемая UE или базовой сетью, используется с целью освобождения ресурсов, выде­ленных для данного вызова.

На стороне сети не возникают конфликты вызовов, потому что любые одновременные входящие и исходящие вызовы обрабатываются отдельно — на основе различных идентификаторов операций, заданных в протоко­ле СС.

Протокол СС как функция базовой сети CN рассматривался в главе 6. Пример потоков сообщений для установки и освобождения соединения с КК приведен в главе 11.

Поскольку протокол СС — это прямое расширение его предшественника, используемого в системах GSM, читателю, нуждающемуся в более подроб­ной информации о нем, следует обратиться к любой книге по GSM, привс-денной в списке литературы. Полное описание протокола СС, включая осо­бенности его использования в UMTS, приведено в технических условиях 3GPP TS 24.008.

 

10.5.1.4. Протокол управления сеансом SM

 

Элементы протокола SM расположены в оборудовании пользователя UE и управляющем узле поддержки GPRS — SGSN (рис. 10.33). Этот протокол представляет собой аналог протокола СС для вызовов с КП и использует­ся для установки и освобождения сеансов передачи пакетных данных. Чтобы подчеркнуть возможность использования в сети UMTS несколь­ких протоколов пакетных данных, эти сеансы называют контекстами PDP, как это было описано в главе 6. На практике же должен поддерживаться единственный наиболее важный протокол пакетных данных — IP (особен­но IPv6).

Основное назначение протокола SM — поддерживать обработку контек­ста PDP в оборудовании пользователя UE. В узле SGSN элемент протокола SM взаимодействует с элементом протокола GTP-C на стороне интерфейса Gn для того, чтобы распространить управление контекстом PDP до шлюза GGSN. Контекст PDP содержит необходимую информацию для маршрути­зации пакетов данных пользовательской плоскости от GGSN к UE и наобо­рот. Оборудование UE может иметь несколько контекстов PDP, действую­щих одновременно, в этом случае каждый из них управляется элементом протокола SM отдельно.

Для идентификации пользователя процедуры SM требуют наличия кон­текста GMM. Если контекст GMM для данного пользователя отсутствует, то уровень ММ должен инициировать процедуру GMM для установки контекста GMM (см. протокол GMM в подразделе 10.5.1.2).

Рис. 10.33. Системный сетевой протокол вне уровня доступа — протокол SM: а) протоколы плоскости управления сети (домен КК); б) протоко­лы плоскости управления сети (домен КП)

 

 

После установки кон­текста GMM протокол SM использует услуги, предлагаемые подуровнем ММ. При выполнении процедур GMM действующие процедуры SM при­останавливаются .

Процедуры SM могут инициироваться шлюзом GGSN или оборудовани­ем пользователя UE. Ниже перечислены основные процедуры SM.

 

•  Активизация контекста PDP, которая устанавливает новый контекст PDP в оборудовании UE, SGSN и GGSN с необходимыми параметра­ми маршрутизации и качества обслуживания QoS для данного сеанса.

•  Модификация контекста PDP, которая активизируется, если необходи­мо изменить его параметры во время сеанса, например параметры ка­чества QoS или потока трафика. Модификация может инициироваться оборудованием пользователя UE или шлюзом GGSN.

•  Дезактивизация контекста PDP, которая разрушает контексты PDP в оборудовании пользователя UE и элементах базовой сети, когда соот­ветствующий сеанс больше не нужен.

Более подробное описание протокола SM дано в технических условиях 3GPPTS 24.008.

 

10.5.1.5. Протокол дополнительных услуг SS

 

Протокол SS обеспечивает дополнительные услуги, предоставляемые в со­единениях с К.К (рис. 10.34). Это понятие унаследовано от систем второго поколения GSM, и, следовательно, терминал UMTS, работающий в режиме КК, может обеспечивать те же дополнительные услуги, что и мобильный те­лефон GSM.

Рис. 10.34. Системный сетевой протокол вне уровня доступа — протокол SS: а) протоколы плоскости управления сети (домен КК); б) протоко­лы плоскости управления сети (домен КП)

Система 3GPP поддерживает все дополнительные услуги SS для трафика с КК. Перечислим некоторые типичные дополнительные услуги:

 

•  Услуги переадресации вызова при различных условиях включения: або­нент не отвечает, занято, абонент вне зоны доступа или безусловная переадресация.

•  Услуги запрета вызова для всех входящих, всех исходящих, всех исхо­дящих международных или роуминговых вызовов.

•  Услуги во время вызова, например ожидание и удержание вызова.

Полный перечень и описание дополнительных услуг можно найти в тех­нических условиях 3GPP TS 24.080.

Дополнительные услуги SS управляются протоколом SS, который пред­ставляет часть подуровня СМ. Элементы протокола SS в оборудовании поль­зователя UE и на стороне MSC/VLR взаимодействуют через соединение ММ. Такое взаимодействие необходимо для активизации и дезактивизации дополнительных услуг SS. На стороне базовой сети CN протокол SS взаимо­действует с протоколом MAP, используемым в случаях, когда команда SS требует доступа к информации об абоненте, хранящейся в регистре HLR.

 

10.5.2. Плоскость управления между узлами базовой сети CN

 

В разделе 10.5.1 кратко представлены протоколы плоскости управления вне уровня доступа между оборудованием пользователя UE и базовой сетью CN. Элементы базовой сети также должны обмениваться друг с другом некоторы­ми сообщениями сигнализации (особенно с регистрами, расположенными в домашней базовой сети).

Протоколы MAP и САР уже упоминались в разделе 10.1.3; читателю, жела­ющему более подробно ознакомиться с этими протоколами, следует обратить­ся к любой книге по GSM, приведенной в списке литературы. Версия 3G про­токола MAP определена в технических условиях 3GPP TS 29.002.

 

10.5.2.1. Протокол туннелирования GPRS для плоскости управления — GTP-C

 

Протокол GTP-C относится к домену КП базовой сети и находится в SGSN и GGSN (см. рис. 10.35). GTP-C — это протокол плоскости управления, реа­лизующий управление туннелированием и процедуры контроля таким обра­зом, чтобы узлы SGSN и шлюзы GGSN могли взять на себя передачу пакетов пользовательских данных. GTP-C используется также для передачи сообще­ний сигнализации GMM между узлами SGSN, что соответствует интерфейсу MAP/G в случае КК.

Протокол GTP-C работает на двух различных интерфейсах: Gn и Gp. Интерфейс Gn совместно используется узлами SGSN и шлюзами GGSN, от­носящимися к домену КП сети UMTS. Интерфейс Gp используется при взаимодействии доменов КП двух сетей UMTS (см. рис. 6.4).

На обоих интерфейсах (Gn и Gp) протокол GTP-C работает поверх се­мейства протоколов UDP/IP.  UDP обеспечивает передачу сообщений без

Рис. 10.35. Плоскость управления сетевой системой — протокол туннелиро-вания GPRS (GTP-C): а) протоколы плоскости управления сети (домен КК); б) протоколы плоскости управления сети (домен КП)

 

 

установления соединения (т. е. нет необходимости устанавливать соедине­ние). Основная услуга, предоставляемая IP, — это маршрутизация сообще­ний между сетевыми элементами источника и пункта назначения.

В узле SGSN элемент протокола GTP-C взаимодействует не только с элементом протокола GTP-U на стороне Gn, но также и с элементами про­токолов GMM и SM. В шлюзе GGSN элемент GTP-C взаимодействует с элементом протокола GTP-U, расположенным на интерфейсе Gn и с функ­цией взаимодействия внешней сети на интерфейсе Gi (например, для пере­распределения динамических адресов для контекстов PDP).

Протокол GTP-C должен обеспечивать надежную передачу сообщений сигнализации через интерфейсы Gn и Gp. Следовательно, его разработка должна была решить проблему ненадежной передачи сообщений на транс­портных уровнях UDP/IP. Протокол GTP-C содержит средства отсчета вре­мени и порядковые номера сообщений, необходимые для управления, детек­тирования пропадания сообщений и повторной их передачи.

 

10.5.2.1.1. Процедуры GTP-C между SGSN и GGSN

 

Протокол GTP-C применяется для создания, удаления и модификации тун­нелей GTP, используемых для передачи пакетов пользовательских данных. GTP-C также проверяет работоспособность тракта в направлении равноправ­ного GTP-C.

После активизации контекста PDP протокол GTP-C в узле SGSN иници­ирует установление туннеля в направлении шлюза GGSN. Назначение про­цедуры установки туннеля состоит в согласовании параметров, связанных с передачей пользовательских данных между SGSN и GGSN. Среди них — па­раметры качества обслуживания QoS и связанные с активизированным адре­сом, как, например, параметры потока трафика.

После дезактивации контекста PDP протокол GTP-C удаляет из SGSN и GGSN информацию туннелирования GTP.

Процедура модификации контекста PDP предусматривает гибкий и ди­намический способ реагирования на изменяющиеся условия. Когда контекст PDP модифицируется (например, из-за измененных параметров QoS или ре­жима нагрузки), протокол GTP-C инициирует процедуру модификации тун­неля GTP, во время которой и SGSN, и GGSN могут модифицировать почти все параметры, согласованные во время процедуры установки туннеля GTP. Процедура модификации контекста PDP выполняется так же, как часть про­цедуры обновления области маршрутизации между SGSN и процедуры пере­распределения SRNS, которая затрагивает два узла SGSN, уведомляя GGSN о новом SGSN для обслуживания UE.

С точки зрения сети поддерживается активизация запрашиваемого кон­текста PDP, но шлюз GGSN не содержит необходимых протоколов для свя­зи с домашним регистром HLR через интерфейс Gc. Поэтому протокол GTP-C передает сообщения к другому узлу поддержки GPRS, который пре­образует эти сообщения в протокол MAP.

Затем протокол MAP используется для связи с HLR через интерфейс Gc. Связь с регистром HLR необходима шлюзу GGSN для того, чтобы устано­вить, присоединено ли оборудование UE к сети, и найти адрес узла SGSN, обслуживающего данное оборудование UE. Эта информация требуется шлю­зу GGSN, прежде чем он сможет запросить у узла SGSN запуск процедуры активизации контекста PDP.

 

10.5.2.1.2. Процедуры GTP-C между узлами SGSN

 

Протокол GTP-C используется узлами SGSN для обмена информацией, от­носящейся к оборудованию пользователя UE. Связь инициируется, когда UE выполняет процедуру присоединения GPRS или процедуру обновления об­ласти маршрутизации между SGSN или когда сеть UTRAN принимает реше­ние выполнить процедуру перераспределения SRNS, затрагивающую два узла SGSN.

Применение протокола GTP-C для обмена информацией, относящейся к UE, между узлами SGSN минимизирует необходимость использования ра­диоинтерфейса. Например, когда выполняется процедура обновления облас­ти маршрутизации между SGSN или процедура перераспределения SRNS, затрагивающая два узла SGSN, то новый узел SGSN, обслуживающий UE, получает почти всю необходимую информацию об этом UE от прежнего SGSN. Такая информация содержит параметры GMM, а именно IMSI и контекст GMM, и параметры, относящиеся к SM, например активные кон­тексты PDP.

Использование протокола GTP-C для обмена информацией, относящей­ся к UE, между узлами SGSN усиливает также защищенность системы. На­пример, когда UE выполняет процедуры присоединения GPRS, идентифика­тор IMSI может быть получен от прежнего узла SGSN, а не от оборудования UE по радиоинтерфейсу.

Протокол GTP-C определен в технических условиях 3GPP TS 29.060.

Рис. 10.36. Плоскость пользователя в сетевой системе: а) плоскость пользова­теля в сети (домен КК); б) плоскость пользователя в сети (домен КП)

 

10.5.3. Плоскость пользователя в сетевой системе

 

Для домена КК роль протоколов пользовательской плоскости играют функ­ции речевого кодека, которые активизируются в оборудовании пользовате­ля UE и обслуживающем коммутационном центре MSC/VLR (рис. 10.36). Для выполнения этих функций определен адаптивный многоскоростной ре­чевой кодек AMR1. Кроме транскодирования между UMTS и внешней сетью (телефонной сетью общего пользования или ISDN) должны выполняться функции взаимодействия (уже описанные в главе 6).

В домене КП оборудование пользователя UE и шлюз GGSN обменива­ются пакетами данных в соответствии с некоторым протоколом точка—точка или протоколом доставки пакетных данных множеству абонентов2. Вероят­нее всего, самым распространенным протоколом пользовательской плоско­сти и впредь будет протокол IP.

 

10.6. Итоговый обзор сетевых протоколов UMTS

 

Завершая исследование основных сетевых протоколов UMTS, мы можем обобщить полный состав стеков протоколов домена КП (см. рис. 10.37 и 10.38).

Рисунок 10.37 иллюстрирует наборы протоколов плоскости управления во всех сетевых элементах сети с КП. На нем показаны те протоколы плоскости управления, которые участвуют в типовой процедуре сигнализации уровня се­тевой системы (например, активизация контекста PDP). Канал сигнализа­ции устанавливается и обслуживается с помощью протоколов управления

UTRAN — RANAP, RNSAP и NBAP, а также протокола RRC, который взаи­модействует с остальными для того, чтобы осуществлять управление радиоре­сурсами. Сигнализация управления уровня сетевой системы (например, сооб­щения протокола SM) транслируется через элементы UTRAN в сообщениях сигнализации RRC, которые далее помещаются в сообщения RLC/MAC и со­общения кадрового протокола выделенного канала DHC-FP. Трансляция со­общений RLC/MAC проиллюстрирована на рис. 10.37 двумя протокольными стеками DHC-FP в элементе CRNC. Передача может осуществляться через все интерфейсы UTRAN транспортной сетью IP или ATM, как описывалось ранее.

Для управления контекстом PDP на стороне базовой сети CN протокол SM взаимодействует с протоколом GTP-C. Подобным же образом протокол GMM взаимодействует с протоколом MAP для управления мобильностью оборудования UE. Протокол GTP-C работает поверх транспортного уровня IP, а протокол MAP может работать поверх как ATM, так и IP.

Рисунок 10.38 иллюстрирует стеки протоколов плоскости пользователя во всех сетевых элементах сети с КП во время типового сеанса передачи пакет­ных данных (например, когда действуют любые из процедур IMS). Поток па­кетов пользователя IPv6 между UE и шлюзом GGSN переносится протокола­ми плоскости пользователя сети UTRAN и протоколом туннелирования GTP-U. Чтобы адаптировать пакеты IP для передачи по радиоинтерфейсу WCDMA, в обслуживающем контроллере SRNC протокол туннелирования GTP взаимодействует с протоколом PDCP и протоколами плоскости пользо­вателя RLC.

На рис. 10.38 предполагается, что поток пакетных данных использует усовершенствованный метод радиопередачи WCDMA — высокоскоростной нисходящий канал пакетного доступа HSDPA. Поэтому сообщения MAC-d с помощью кадрового протокола высокоскоростного совмещенного нисходя­щего канала (HS-DSCH-FP или для краткости HS-FP) передаются из SRNC на базовую станцию БС, где действующий высокоскоростной канал поддер­живается протоколом MAC-hs через интерфейс Uu.

В домене КП базовой сети CN туннель GTP использует передачу по про­токолу IP через интерфейс Iu и интерфейсы базовой сети CN. Пакеты IP пе­редаются через интерфейс Gi в соответствии с транспортным стеком IP, вы­бранным для транспортных функций IMS.

 

10.7. Обзор протоколов IMS

 

В данном разделе кратко описываются протоколы, используемые подсисте­мой IMS, и варианты их применения в различных опорных точках. На мо­мент написания этой книги работа над 6-й версией все еще продолжается, и поэтому таблица 10.3 может обобщить только уже установленные опорные точки IMS и перечислить связанные с ними протоколы.

В качестве протокола управления сеансом для систем 3GPP выбран про­токол инициирования сеанса SIP, определенный в документе RFC 3261. SIP — протокол прикладного уровня, используемый для организации, моди­фикации и завершения мультимедийного сеанса в сети IP. Он представляет часть мультимедийной архитектуры, протоколы которой постоянно стандар­тизируются IETF. Приложения этого протокола включают речь, видео, игры, обмен сообшениями, управление вызовами и услугу присутствия, но не огра­ничиваются ими. Для функционирования системы IMS недостаточно только базового протокола SIP. IMS требует поддержки многих других функций, снизанных с SIP, в соответствии с документами RFC 2327, 3262, 3264, 3265. 3311, 3312, 3313, 3325, 3327 и т.д. Более детальную информацию можно по­лучить в документе 3GPP TS24.229 или в работе Poiksclka et al. (2004),

Таблица 10.3. Сведенная информация об опорных точках IMS

Для целей тарификации и работы с базами данных необходим протокол, отличный от SIP. Для использования в системах 3GPP выбран протокол «Dia­meter-, с помощью которого элементы IMS связываются с домашним або­нентским регистром HSS или элементами тарификации.

«Diameter» — это протокол аутентификации, авторизации (проверки пол­номочий) и учета (ААА1), разработанный IETF. Он используется для предо­ставления услуг ААА в различных технологиях доступа. Протокол «Diameter» не был разработан с нуля, а возник на основе протокола дистанционной аутентификации пользователей (услуг) с набором номера RADIUS, кото­рый определен в документе RFC 2865 и используется для предоставления услуг ААА в системах доступа с коммутируемыми соединениями или с тер­минальным сервером. Протокол «Diameter» обеспечивает режим, в котором возможна обратная совместимость с протоколом RADIUS.

Фактически «Diameter» подразделяется на две части: базовый протокол и приложения. Базовый протокол необходим для доставки блоков данных протокола «Diameter», согласования характеристик, обработки ошибок и обеспе­чения расширяемости.

 

 

Рис. 10.39. Структура заголовка протокола «Diameter»

 

Приложения протокола «Diameter» определяют прикладные специальные функции и блоки данных. Каждое такое приложение задается отдельно. В настоящее время кроме базового протокола, определенного в RFC 3588, имеется несколько приложений протокола «Diameter», которые либо уже определены, либо находятся в процессе разработки. Кроме того, документ RFC 3539, определяющий транспортный профиль ААА, включает анализ и рекомендации по использованию протоколами ААА транспортных средств, а в версии 5 3GPP введен специальный набор командных кодов протокола «Diameter» (в соответствии с RFC 3589).

В качестве транспортных средств базовый протокол «Diameter» использу­ет и TCP, и SCTP. Однако использование SCTP предпочтительнее из-за ори­ентированного на установление соединений взаимодействия между равно­правными элементами протокола «Diameter». Чтобы обеспечить защиту ин­формации в этих соединениях, используются как защита IP (IPsec в соответ­ствии с RFC 2401), так и защита транспортного уровня (TLS в соответствии с RFC 2246).

«Diameter» — это одноранговый протокол, так как любой его узел (эле­мент) может инициировать запрос. Протокол «Diameter» предусматривает три различных типа сетевых узлов: клиенты, серверы и агенты. Клиенты — это чаще всего оборудование на границах сети, которое осуществляет управ­ление доступом. Агенты протокола «Diameter» предоставляют услуги ретран­сляции, программ-посредников (прокси), переадресации или трансляции. Сервер протокола «Diameter» обрабатывает запросы ААА для отдельного домена или области. Сообщения протокола «Diameter» маршрутизируются в соответствии с идентификатором доступа к сети NAI1 (RFC 2486) конкрет­ного пользователя. Сообщения протокола «Diameter» включают заголовок, за которым следуют пары значений атрибутов протокола «Diameter» AVP2. Заголовок содержит двоичные данные и имеет сходство с заголовками АР или TCP (см. рис. 10.39).

Рис. 10.40. Архитектура IMS

 

Пары значений атрибутов AVP содержат инкапсулированные информа­ционные элементы ААА, а также информационные элементы маршрутиза­ции, защиты и конфигурации, относящиеся к определенному запросу прото­кола «Diameter» или ответному сообщению.

В подсистеме IMS стандарта 3GPP протокол «Diameter» используется для управления размещением и обслуживанием, обработки пользовательских данных, аутентификации пользователя и проверки полномочий в опорных точках Сх, Dx, Sh и Dh, а также для тарификации как в нереальном, так и в реальном масштабе времени в опорных точках Rf и Ro.

Для целей стратегии управления IP используется услуга общей открытой стратегии COPS1 (в соответствии с RFC 2748). COPS — это протокол IETF, используемый для общего управления (администрирования), конфигурации и внедрения стратегий. Он определяет простой протокол (типа запрос-ответ) для обмена стратегической информацией между стратегическим сервером (например, функцией политики принятия решений PDF2) и его клиентами (шлюзами GGSN). Опорные точки между PDF и GGSN используют прото­кол COPS для осуществления авторизации среды (т. е. процедуры, в процес­се которой легальные пользователи получают доступ к среде передачи) и тарификации. Они также используют COPS для обеспечения стратегии рас­ширяемости (в соответствии с RFC 3048). Кроме того, в стандартах 3GPP введено понятие стратегической информационной базы, которая определяет политику предоставления данных. Для передачи специализированных дан­ных стратегического управления подсистемы IMS в системе 3GPP пред­усмотрена собственная база стратегической информации, детали которой можно найти в документе 3GPP TS 29.207.

В таблице 10.3 архитектура подсистемы IMS представлена в упрощенной форме. Не представляется возможным включить все в одну таблицу, поэтому обратите внимание на то, что в этой таблице не показаны:

•  функции или опорные точки, связанные с начислением платы за услуги;

•  различные типы серверов приложений AS;

•  соединения  пользовательской  плоскости  между  различными  сетями IMS и AS.

На рис. 10.40 представлена архитектура системы IMS с опорными точка­ми. Однако для ясности некоторые детали были опущены:

•  на рисунке не показан шлюз безопасности SEG в опорных точках Mm, Mk, Mw;

•  пунктирной линией между элементами обозначают прямой канал;

•  ISC, Cx, Dx, Mm, Mw оканчиваются на S-CSCF и I-CSCF.