Способ и устройство для самоконфигурирования базовой станции

Способ и устройство для самоконфигурирования базовой станции

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Настоящая заявка относится к беспроводной связи. Более конкретно, настоящая заявка относится к самоконфигурированию и признакам защиты базовой станции в беспроводной связи.

Уровень техники

В соответствии с Проектом Партнерства 3-его Поколения (3GPP) инициирована программа долгосрочного развития (LTE) для введения в действие в сетях сотовой беспроводной связи новой технологии, новой сетевой архитектуры, новых конфигураций, новых приложений и новых услуг для обеспечения повышенной эффективности использования спектра и ускорения работы для удобства пользователя.

Хотя продолжается спрос на большие функциональные возможности, также требуются системы LTE с техническим обслуживанием небольшого объема, особенно в условиях развертывания сети и оптимизации обслуживания в процессе работы.

На фиг.1 изображена универсальная система мобильной связи (UMTS) 3GPP, архитектуры UTRAN, используемой до LTE. Опорная сеть 100 связи осуществляет связь с UTRAN 110, которая состоит из нескольких систем 120 сети беспроводной связи (RNS). Каждая RNS состоит из контроллера 130 сети беспроводной связи (RNC) 130 и одного или большего количества Узлов-В 135. RNC 139 полностью осуществляет управление конфигурациями и операциями развернутых Узлов-В 135 с использованием явных команд через линию 140 связи. Iub 140 является интерфейсом из-RNС-в-Узел-В, который был определен предварительно. Обновление конфигураций и услуг Узлов- В зависит от RNC и от результатов других технических работ и работ по планированию ячейки. До LTE не существовало соединений между Узлами-В 135 UTRAN, и не существовало требований на самоконфигурирование и оптимизацию. Не существовало средств самоконфигурирования и определенных процедур, функционирующих между Узлами-В.

Как иллюстрирует фиг.2, в новой системе сети связи LTE была изменена архитектура UTRAN. Больше не существует прежнего узла RNC. Разработанные Узлы-В (eNB) 200, 205, выполняющие функциональные возможности радиодоступа к сети для E-UTRAN 210, соединены непосредственно с Опорной Сетью (ЕРС) 220 и соединены совместно между собой. В E-UTRAN новые eNB 200, 205 предусматривают функциональные возможности контроля над управлением, конфигурированием RAN и функционированием, а также операции и конфигурации интерфейса беспроводной связи. Дополнительно, каждый новый eNB, такой как 200, теперь взаимодействует непосредственно с Опорной Сетью 220 LTE через интерфейс S1, а также взаимодействует с соседними eNB 205 через интерфейс 240 Х2 и интерфейс управления соединением Х2 (Х2С) (не изображен) для обработки задач управления мобильностью беспроводного блока приема/передачи (WTRU) для E-UTRAN.

При включении недавно разработанный eNB 200, 205 выполняет задачи самоконфигурирования, включая операции через интерфейс Х2С для взаимодействия с соседними действующими eNB. Это первоначальное взаимодействие используют для сбора информации, сертификации eNB и для обеспечения возможности конфигураций и взаимодействия, когда eNB готовит себя к входу в рабочий режим E-UTRAN для обслуживания блоков WTRU в своей зоне обслуживания.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Настоящая заявка относится к рабочим процедурам через соединение между базовыми станциями на стадии самоконфигурирования.

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

Согласно одному варианту осуществления изобретения предложен способ функционирования базовой станции при беспроводной связи, содержащий: включение базовой станции, получение уникального IP-адреса для базовой станции, выполнение аутентификации сети, включение межстанционного интерфейса, инициацию межстанционной синхронизации через интерфейс, передачу запроса на параметры сети и прием параметров сети, обеспечивающих возможность взаимодействия с опорной сетью.

Согласно еще одному варианту осуществления изобретения предложена беспроводная базовая станция, содержащая: приемник, сконфигурированный для получения уникального IP-адреса из опорной сети, процессор, сконфигурированный для выполнения аутентификации сети, включения межстанционного интерфейса и инициации межстанционной синхронизации через интерфейс, и передатчик, сконфигурированный для передачи запроса на параметры сети, причем приемник дополнительно сконфигурирован для приема параметров сети, обеспечивающих возможность взаимодействия с опорной сетью.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 - блок-схема существующей системы беспроводной связи.

Фиг.2 - иллюстрация существующей архитектуры LTE.

Фиг.3 - блок-схема одного варианта осуществления способа настоящего раскрытия.

Фиг.4 - блок-схема второго варианта осуществления способа настоящего раскрытия.

Фиг.5 - блок-схема третьего варианта осуществления способа настоящего раскрытия.

Фиг.6 изображает известный вид бреши в системе защиты.

Фиг.7 - блок-схема четвертого варианта осуществления способа настоящего раскрытия.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

При упоминании далее, термин "беспроводной блок приема/передачи (WTRU)" включает в себя пользовательское оборудование (UE), мобильную станцию, стационарный или мобильный абонентский блок, устройство поискового вызова, сотовый телефон, персональное цифровое информационное устройство (PDA), компьютер и т.д. или любой другой вид пользовательского устройства, выполненного с возможностью функционирования в среде беспроводной связи. При упоминании далее, термин "базовая станция" включает в себя Узел-В, базовый контроллер, точку доступа (АР) и т.д. или любой другой вид интерфейсного устройства, выполненного с возможностью функционирования в среде беспроводной связи.

Хотя здесь варианты осуществления описаны в контексте LTE, они должны рассматриваться как возможные варианты, не ограниченные этой конкретной технологией беспроводной связи.

Фиг.3-6 изображают временные последовательности событий, возникающих в eNB, осуществляющем самоконфигурирование, в eNB, соединенном (то есть "соседнем") с eNB, осуществляющим самоконфигурирование, и в шлюзе доступа. Последовательность начинается сверху, продвигаясь со временем вниз. События на одном горизонтальном уровне происходят одновременно.

Теперь, согласно фиг.3, при включении eNB, осуществляющего самоконфигурирование, предпочтительно сначала включают его интерфейс S1 (этап 305). Общая функция Интернет-протокола (IP) или функция преобразования IP-адреса, определенная для eNB, получает уникальный IP-адрес для eNB, осуществляющего самоконфигурирование, через интерфейс S1 (этап 300).

Затем eNB, осуществляющий самоконфигурирование, должен выполнить аутентификацию сети для eNB посредством обслуживающего шлюза доступа (aGW) его первичного оператора (этап 310).

Затем при успешной аутентификации сети для eNB, осуществляющего самоконфигурирование, он включает и инициирует (этап 320), с использованием своего IP-адреса, либо сконфигурированного либо полученного через интерфейс S1, интерфейсы Х2, которые соединяют eNB, осуществляющий самоконфигурирование, с другими соседними eNB LTE.

В виде возможного более раннего действия eNB может затем получать идентификаторы соседних с ним eNB, соединенных через Х2, например их идентификатор(ы) eNB-Id и/или идентификатор (ы) Id-ячейки, идентификатор(ы) наземной сети мобильной связи общего пользования (PLMN)-Id и другую неконфиденциальную информацию, такую как текущее рабочее состояние (этап 330). Затем ENB может информировать обслуживающий aGW, так чтобы eNB получал необходимые инструкции сети и/или авторизации, относящиеся к соседним eNB, соединенным через Х2, для авторизованных и разрешенных операций, таких как передача обслуживания WTRU или измерение eNB и восстановление отчетов. Хотя это возможное более раннее действие (этап 330) изображено на фиг.3, как "обмен с квитированием" (подтверждение связи), этим действием может быть также пара сообщений с запросом и ответом, как изображено на фиг.7, или любая другая соответствующая процедура. Соседними eNB, с которыми нужно осуществить связь для такой информации, являются eNB, которые предварительно сконфигурированы в список соседних eNB, заданный по умолчанию, такой как хранится в устройстве смарт-карты UMTS (UICC).

Этот способ для более раннего действия обеспечивает возможность поддерживания сетью некоторого ввода или управления операциями между-E-UTRAN в среде многих-поставщиков/многих-операторов. Во-первых, процесс обеспечивает возможность сбора eNB точной информации относительно соседних eNB из тех eNB, которые отвечают, по сравнению с предварительно сконфигурированным списком соседних eNB, так что eNB может информировать сеть/ЕРС о новом eNB и соединенных с ним соседях и их действительном рабочем состоянии. Во-вторых, eNB может получать рабочие руководства из сети относительно политик интерфейса Х2С с соседними eNB LTE, так как соседние eNB могут принадлежать или не принадлежать одному поставщику/оператору сети. ENB может также получать другую важную рабочую информацию.

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

Затем, после первоначального сбора данных, eNB должен передавать через S1 запрос 340 на параметры E-UTRAN с использованием информации, которую он получил на более раннем этапе Х2С, раскрытом выше. В виде варианта, если не предпринято более раннее действие Х2С, eNB передает Запрос через S1. В ответе 350 с параметром E-UTRAN 350, eNB, осуществляющий самоконфигурирование, получает требуемые рабочие параметры для E-UTRAN, включая параметры для аутентификации Между-eNB и для процедур согласования ключей защиты через Х2С, такие как универсальный мандат eNB, универсальный секретный ключ eNB общего пользования, алгоритм защиты между-eNB, который должен быть использован, и универсальную совокупность ключей защиты eNB.

Необходимость защиты подлинности, целостности и конфиденциальности на Х2С была документирована предварительно. Поверхностная аутентификация, определенная здесь как аутентификация Между-eNB, и согласование целостности и/или ключей шифрования, определенное здесь, как процедура ассоциации ключей защиты, раскрыты ниже для аутентификации между-eNB LTE и ассоциации ключей защиты между любыми парами eNB, в том числе между eNB, осуществляющим самоконфигурирование, и его уже развернутыми рабочими соседними eNB.

Следует отметить, что процедура аутентификации Между-eNB при самоконфигурировании eNB требуется для аутентификации пар eNB на уровне узла. Аутентификация, выполняемая ниже, без управления на уровне узла и без участия параметра уровня узла, не будет обеспечивать идентичный уровень аутентификации eNB.

Раскрыты два варианта осуществления, один с использованием базовой Защиты Протокола Интернет (IPsec) с усовершенствованиями, и один для прямых взаимодействий на уровне eNB с использованием базового "Ручного" режима IPsec.

В первом варианте осуществления используют базовой Протокол Защиты Интернет связи eNB-B-eNB для LTE, и он структурирован в соответствии с обычным набором протокола TCP/IP. Понимание существующей защиты протокола Интернет и ее потенциальных слабостей способствует оценке нововведения этого варианта осуществления, и поэтому далее следует ее описание.

В пределах протокола TCP/IP защита области информации заголовка IP считается критической для предотвращения обычных атак, которые приводят к «спуфингу» адреса и которые часто ведут к перехвату сеанса связи. Соответственно применяют конфиденциальность и аутентификацию сетевого уровня с использованием совокупности стандартизированных процессов Целевой Группы Инженерной Поддержки Интернет (IETF), называемой Защитой Протокола Интернет (IPsec). Аутентификация, которая в этом контексте означает целостность данных и защиту исходного адреса, является обязательной для IPsec, в то время как конфиденциальность (шифрование) - не является обязательной.

Тремя базовыми компонентами IPsec являются Защита Аутентификации, Защита Конфиденциальности и Ассоциация Защиты. Механизмы защиты аутентификации и конфиденциальности реализуют посредством дополнительных полей в пакете IP. Полем для аутентификации, которое является обязательным в IPsec, является Заголовок Аутентификации (АН). Он расположен непосредственно после заголовка IP. Это поле содержит различные подполя, которые определяют криптографические алгоритмы, которые должны быть использованы, последовательный номер для предотвращения повторного воспроизведения и хеширование целостности, определенное, как Значение Проверки Целостности (ICV).

Поле конфиденциальности, которое следует за полем аутентификации, является дополнительным и называется Полезной нагрузкой Защиты Инкапсулирования (ESP). Оно содержит подполя, подобные АН: определения уникального криптографического алгоритма, такого как DES, AES, 3DES или BLOWFISH, подполе последовательного номера, шифрованные данные полезной нагрузки, и подполе, содержащее случайные данные для защиты целостности шифрованных данных. Случайные данные, применяемые ESP, защищают целостность только шифрованных данных, при этом случайные данные АН в целом защищают пакет IP, который, как это обозначено для IPsec, всегда содержит поле АН и иногда содержит поле ESP.

Для определения, используют ли аутентификацию и конфиденциальность, в противоположность только аутентификации, устанавливают ассоциацию защиты (SА) в IPsec. SA состоит из трех частей: определение алгоритмов защиты и других параметров, IP- адрес абонента получателя и идентификатор для АН или ЕSР. SА реализуют посредством Протокола Обмена Ключами Интернет (IKE), описанного следующим образом.

До того, как могут использоваться аутентификация/целостность и конфиденциальность, в Ipsec должны быть согласованы криптографические алгоритмы, параметры и ключи шифрования. Протокол IKE содержит много протоколов для требуемого согласования и используется в различных сценариях. Ниже описан упрощенный вид протокола IKE, относящийся к настоящему раскрытию.

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

Первая пара устанавливает использование криптографического алгоритма и выполняет обмен Диффи-Хелмана (Diffie-Hellman) до поступления начального числа (генерации псевдослучайных чисел), из которого получают ключи конфиденциальности и целостности. Вторая пара использует ключи, сгенерированные из первого обмена, для аутентификации первой совокупности сообщений, идентификаторов свопинга, сертификатов, и обеспечивает установку для последующих порожденных SА.

Инициатор (I) протокола передает следующую полезную нагрузку:

1. I→R: HDR_I, SA_I, g^x _I, N_I

Ответчик (R) отвечает следующим:

2. R→I: HDR_R, SA_R, g^y _R, N_R

Это - первая пара сообщений первоначальной ассоциации защиты. HDR содержит информацию заголовка, которая прежде всего поддерживает состояние связи между этими двумя объектами. SA_I и SA_R являются механизмами согласования параметров и алгоритма защиты, где инициатор предлагает совокупность вариантов выбора, из которых ответчик осуществляет выбор. Для обработки протокола Диффи-Хелмана осуществляют обмен значениями g^x _I и g^y _R для формирования секретного значения g^xy общего пользования, которое служит в качестве начального числа для формирования ключей целостности и конфиденциальности с использованием предварительно согласованных алгоритмов. Величина g является генератором циклической группы Fp^* (порядка р-1), где р - очень большое простое число. Значения р и g общеизвестны, и все вычисления выполняют по модулю р. В заключение, осуществляют обмен данными, сформированными для данного случая, N_I и N_R для предотвращения повторного воспроизведения.

Вторая пара сообщений составляет

3. I→R: HDR_I, SK{ID_I, Cert_I, AUTH, SA2_I, …, другие поля для формирования порождаемых SА}

4. R→I: HDR_R, SK{ID_R, Cert_R, AUTH, SA2_R, …, другие поля для формирования порождаемых SА}

Сообщения три и четыре несколько упрощены относительно сообщений, определенных в протоколе IETF. В этой второй паре применяют информацию ключа защиты, полученную из первой пары сообщений, которая описана выше. SK обозначает операцию ключа защиты, в зависимости от аргумента, представленного внутри фигурных скобок. Два ключа защиты, SК_а (аутентификации, здесь означающей целостность) и SК_е (шифрования) формируют из g^xy (из Диффи-Хелмана). Их используют для защиты целостности и конфиденциальности соответственно при обмене. Идентификаторы инициатора и ответчика (ID_I и ID_R) и их соответствующие секреты идентичности подтверждаются каждым объектом перед другим; AUTH содержит значения проверки целостности для каждого направления. Сертификаты (Cert_I и Cert_R обеспечивают информацию ключей, кроме SК_а и SK_e, для верификации AUTH в обоих направлениях.

До тех пор, пока не происходит перехват сообщений 1 и 2, SА, установленная между инициатором и ответчиком, является безопасной для последующих порожденных обменов, которые будут осуществляться. Однако эта первоначальная пара сообщений может быть уязвима в отношении известного вида "атак человек-в-середине", при которых атакующий может принуждать каждый валидный объект использовать начальные числа (для генерации) ключа, которые может использовать атакующий. Описанная здесь атака компрометирует процесс связи между инициатором и ответчиком в целом, где атакующий имеет возможность маскироваться под каждого (из них).

Обычная атака человек-в-середине для первоначального обмена IKE между I и R изображена на фиг.6. На этапах с 1 по 4 А принимает g^x _I из I и g^y _R из R; дополнительно, А передает g^m _R, свое значение Диффи-Хелмана, в I и R, где оба предполагают, что другой был создателем того значения вместо реального создателя А. Имея информацию о том, что каждая сторона содержит его, просто показать, что А использует начальные числа Диффи-Хелмана g^mx и g^my соответственно совместно с валидными коммуникаторами I и R. Теперь А вычисляет ключи шифрования (SK_e) и аутентификации/целостности (SК_а), идентичные ключам I, с использованием g^mx, и подобным образом, в отношении R, с использованием g^my.

Функции SK на этапах с 5 по 8 не защищают ни целостность, ни конфиденциальность передачи сообщений, при предположении, что А обманно использует связь, организуя использование ключей и успешно маскируясь под I и R. Отсутствие предварительно совместно используемой информации секретного ключа препятствует защите первых двух обменов между I и R. Ниже описаны варианты осуществления способа и устройства для предотвращения атак этого вида.

Первый вариант осуществления изображен на фиг.7, признак 600. На уровнях узлов eNB₁ и eNB₂, (таких как eNB, осуществляющий самоконфигурирование, и соседний eNB, как описано выше и изображено на фиг.7)) узлы eNB совместно используют распределенный в сети секретный ключ Ks, который известен только eNB₁ и eNB₂.

При таком строгом секрете на уровне узла первоначальный обмен между I (инициатором) и R (ответчиком) может быть защищен следующей парой сообщений 600:

1. eNB₁→eNB₂: HDR₁, SA₁, g^x ₁, N₁, {HDR ₁ , SA ₁, g ^x ₁. N₁}_Ks

2. eNB₂→eNB₁: HDR₂, SA₂, g^y ₂, N₂, {HDR ₂ , SA ₂, g ^y ₂. N₂}_Ks

Символы соответствуют определенным выше. Для сообщений 1 и 2 IPsec примечание в фигурных скобках обозначает, что добавляют значения кода (MAC) аутентификации сообщений, каждое из которых представляет случайные данные, использующие ключ аутентификации/целостности, то есть совместно используемый секрет Ks, всех компонентов соответственно для каждого сообщения. Каждый вариант случайных данных с использованием Ks защищает соответствующее ему сообщение IPsec. Если после атаки, изображенной на фиг.6, то есть атаке человек-в-середине, атакующий пытается передать q^m _I в R или q^m _R в I, то случайные данные (MAC) в соответствующем сообщении не будут соответствовать вычисленным получателем сообщения. В результате, такие попытки или любые попытки спуфинга, будут обнаружены и будут неудачны. Фиг.7 иллюстрирует эту Ассоциацию Защиты Ipsec, усовершенствованную относительно операций ассоциации ключей и аутентификации Х2С eNB.

Во втором варианте осуществления, указанном на этапе 630 на фиг.7 и детализированном на фиг.4, осуществляют прямую аутентификацию eNB через Х2С.Для защиты против возможной атаки/подмены или другого вмешательства окружающих eNB здесь описана поверхностная аутентификация для того, чтобы удостовериться, что на уровне узла обеспечена аутентификация между-eNB. Это в противоположность тому предположению, что соседние eNB все уже являются защищенными конечными точками, как изображено на фиг.4, между любыми двумя парами eNB в LTE.

Согласно фиг.4 сеть LTE подготавливает универсальный секретный ключ К общего пользования и универсальный мандат С eNB общего пользования для всех eNB LTE для аутентификации между-eNB. В ответе 420 с параметром E-UTRAN, eNB, осуществляющие самоконфигурирование, получают параметры через канал S1 из сети после аутентификации сети узлов eNB. LTE также стандартизирует алгоритмы аутентификации Ех и Fy, описанные ниже.

На этапе 400 eNB, осуществляющий самоконфигурирование, использует ключ К и алгоритм защиты Fx для шифрования мандата С. Результирующий шифрованный мандат С' передают в сигнале 410 AUTH-Req в соседний eNB и соседний eNB использует его для аутентификации eNB, осуществляющего самоконфигурирование. ENB, осуществляющий самоконфигурирование, также выбирает случайное число (RAND) (этап 400) и использует алгоритм Fx для вычисления шифрованного значения аутентификации X-RES из RAND. С' и RAND передают в соседний(ие) eNB (этап 410).

Затем приемный(ые) соседний(ие) eNB использует секретный ключ К общего пользования и Fx для декодирования С' и сравнивает результат с универсальным мандатом С eNB (этап 430), который он содержит в памяти. Он также использует принятое RAND для вычисления расшифрованного значения аутентификации RES с использованием функции Fy. Затем RES передают обратно в сигнале 440 AUTH-Resp в eNB, осуществляющий самоконфигурирование для аутентификации им соседнего(их) eNB (этап 450).

При этой упрощенной поверхностной аутентификации Между-eNB избегают длинных вычислений SQN, AK7 AMF и MAC в текущей процедуре аутентификации UMTS UE до LTE для уменьшения вычислительной нагрузки защиты, а также для уменьшения размера сообщения сигнализации через Х2С.

Возвращаясь к фиг.7, также может быть осуществлена ассоциация 630 ключей защиты eNB через Х2С.При предположении, что IPsec должно быть развернуто для соединений Х2 LTE, раскрыто использование IPsec и относящегося к нему IKE-v2 в "Ручном" режиме с eNB LTE, снабженным ключом защиты, только при шифровании, выполняемом IPsec. Это обеспечивает управление защитой Х2С и ключами LTE через eNB, обеспечивая высокий порог защиты.

Для управляемой eNB LTE ассоциации ключей защиты (для защиты целостности и шифрования) предложены следующие параметры:

Во-первых, LTE может стандартизировать алгоритм защиты Х2С Fa по всем eNB LTE. Алгоритмом Fa может быть используемый в текущее время алгоритм, такой как f8 UMTS, или новый алгоритм, который обеспечивает возможность шифрования и расшифровки информации с использованием ключа защиты общего пользования, например Х2С-ключа.

Во-вторых, LTE может стандартизировать универсальную совокупность ключей защиты (выбор которых может быть осуществлен для лучших результатов защиты Fa) для приложений защиты (защиты целостности и шифрования) по узлам eNB через интерфейс Х2С, то есть может быть определен индексированный набор ключей N, известных всем узлам eNB LTE.

В-третьих, эта универсальная совокупность ключей для операций защиты Х2С LTE может быть загружена из обслуживающих aGW в eNB, осуществляющий самоконфигурирование, после процедур аутентификации сети, например, при обмене сигнализацией "Ответа с Параметром E-UTRAN" 350. Загрузка совокупности ключей защиты в каждый ENB LTE может происходить на этапе самоконфигурирования eNB, когда eNB находится в пред-рабочем режиме и соответственно обеспечен возможностью осуществлять обработку загрузки сигнализации. Существующие действующие eNB уже содержат сохраненную совокупность ключей.

В-четвертых, ключ или ключи защиты, если существуют один для защиты целостности и другой для расшифровки, могут быть выбраны отдельно или ассоциированы между любыми парами из двух eNB через интерфейс Х2С, на этапе самоконфигурирования, этапе ассоциирования или на более позднем рабочем этапе для повторного ассоциирования. На этапе ассоциирования требуется только взаимное определение индекса ключа для обеспечения возможности использования согласованного единого ключа защиты. Этот подход выигрышен в отношении повышенного порога защиты посредством того, что не передают основные значения ключей защиты при обмене сообщениями, как в известных технологиях, при этом уменьшая вычислительную нагрузку, непосредственно получая ключи защиты, и уменьшая объем сигнализации при обмене сообщениями при согласовании ключей.

В-пятых, на этапе согласования ключей, для идентичной совокупности из количества N Х2С-ключей, может быть использован способ индексации ключей Диффи-Хелмана для взаимного получения идентичного индекса I ключа, так чтобы ключ защиты Х2С-ключ [i] использовался для предназначенной защиты целостности и/или для операции шифрования. Это изображено на фиг.5.

В-шестых, полученный ключ защиты может быть использован и для защиты целостности, и для шифрования. В виде варианта, может быть предпочтительным различный ключ защиты для каждой операции. В этом случае одна возможность состоит в выполнении идентичной процедуры обмена индексом ключа по-отдельности, последовательно или параллельно, для другого ключа. Альтернативная возможность состоит в том, чтобы добавлять число смещения к уже полученному индексу ключа и затем вновь производить операцию по модулю N для получения нового индекса [0, N-1]. Смещение может быть получено посредством использования числа, известного только этим двум узлам, например номера идентификатора, такого как Id-eNB, осуществляющего самоконфигурирование.

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

Аутентификация между-eNB и ассоциация ключей защиты между eNB, осуществляющим самоконфигурирование, и соседним(и) с ним eNB могут быть объединены совместно для достижения аутентификации между-eNB и ассоциации защиты при одном обмене, как изображено на фиг.7, который иллюстрирует все операции eNB, осуществляющего самоконфигурирование, через Х2С в отношении подсоединенных соседних eNB.

Операции между-eNB на фиг.7 напоминают функционирование двухточечной линии связи, но с точки зрения eNB это функционирование многоточечной линии связи. Следовательно, eNB, осуществляющим самоконфигурирование, может быть использована многоадресная передача, если базовый уровень IP поддерживает такое функционирование. Но каждый соседний eNB должен отвечать eNB, осуществляющему самоконфигурирование, отдельно.

Следует отметить, что согласно фиг.7 возможен обмен 620 с квитированием Х2С, описанный выше, согласно фиг.3. Также идентичны описанным выше Alt-1 в аутентификации между-eNB и согласование 600 ключей защиты, где первые два сообщения IPsec_Init_SA являются сообщениями с защитой целостности. Затем может быть выполнена остальная часть этапов Ipsec, как нормально требуется в соответствии с IPsec.

Если аутентификация или обмен ключами неуспешны, с решением о неудаче, основанном на нескольких последовательных неудавшихся попытках, то eNB, осуществляющая самоконфигурирование, должна считать интерфейс Х2С недействительным и информировать сеть.

Из операции 610 обмена параметрами с соседней eNB могут быть получены следующие параметры E-UTRAN (eNB): информация местоположения GPS; количество ячеек, используемых eNB, и идентификатор(ы) ячейки; идентификатор обслуживающего оператора или домашний Id PLMN; информация измерения eNB или группы/ассоциации измерений; параметры беспроводной связи для Ячейки(ек), такие как полоса частот и средняя частота, значение ширины полосы частот передачи ячейки, информация управления мощностью, базовые конфигурации общего канала ячейки, информация направленной антенны и MIMO, информация SFN MBMS, и информация ресурса MBMS; и параметры обслуживания для Ячейки(ек), такие как информация MBMS, информация LCS, и общая информация SI, совместно используемая среди eNB.

Варианты осуществления

1. Способ самоконфигурирования беспроводной базовой станции, содержащий обеспечение возможности взаимодействия между базовой станцией и другой соседней базовой станцией.

2. Способ по варианту осуществления 1, содержащий аутентификацию базовой станции и соседней базовой станции.

3. Способ по варианту осуществления 2, в котором аутентификация содержит:

передачу базовой станцией сигнала с запросом параметров в шлюз доступа и прием сигнала с ответом с параметрами,

кодирование первого мандата с использованием ключа для формирования второго мандата,

генерацию случайного числа,

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

4. Способ по варианту осуществления 3, дополнительно содержащий:

передачу запроса на авторизацию в соседнюю базовую станцию,

прием ответа с авторизацией из соседней базовой станции, имеющий расшифрованное значение аутентификации, и

сравнение шифрованного и расшифрованного значений аутентификации.

5. Способ по варианту осуществления 3 или 4, в котором сигнал с запросом параметров содержит информацию, имеющую отношение к соседней базовой станции.

6. Способ по любому из вариантов осуществления 3-5, в котором сигнал с ответом с параметрами содержит первый мандат, ключ и информацию кодирования.

7. Способ по любому из вариантов осуществления 4-6, в котором сигнал с запросом на авторизацию содержит второй мандат и случайное число.

8. Способ по любому из вариантов осуществления 4-7, дополнительно содержащий осуществление первой базовой станцией:

приема IP-адреса из шлюза доступа,

выполнения аутентификации сети посредством шлюза доступа,

включения и инициации интерфейса между станциями, и

приема информации идентификации из соседней базовой станции.

9. Способ по любому из вариантов осуществления 4-8, дополнительно содержащий:

передачу и прием базовой станцией сообщений, согласованных с

процедурами защиты Интернет-Протокола (IPsec).

10. Способ по любому из вариантов осуществления 6-9, в котором ключом является совместно используемый ключ, используемый всей системой беспроводной связи в целом.

11. Способ по любому из вариантов осуществления 6-10, в котором первым мандатом является универсальный мандат, используемый по всей системе беспроводной связи.

12. Способ по любому из вариантов осуществления 9-11, дополнительно содержащий установку ассоциации защиты (SА) в IPsec.

13. Способ по варианту осуществления 12, в котором SА содержит определение алгоритмов защиты, IP адрес абонента-получателя и идентификатор для заголовка аутентификации (АН) или полезную нагрузку защиты инкапсуляции (ESP).

14. Способ по варианту осуществления 13, в котором АН или ESP содержит случайные данные для защиты целостности данных.

15. Способ по любому из вариантов осуществления 4-14, содержащий формирование первого ключа защиты для аутентификации и второго ключа защиты для шифрования с использованием алгоритма Диффи-Хелмана.

16. Способ по любому из вариантов осуществления 4-15, дополнительно содержащий подготовку сетью универсального секретного ключа общего пользования и универсального мандата базовой станции общего пользования для всех базовых станций для межстанционной аутентификации, в котором первая станция получает параметры из соседних станций после аутентификации сети соседних станций.

17. Способ по варианту осуществления 16, в котором мандат шифруют посредством базовой станции и передают в соседнюю базовую станцию для аутентификации первой базовой станции.

18. Способ по варианту осуществления 17, дополнительно содержащий декодирование соседней базовой станцией мандата и сравнение его с универсальным мандатом станции.

19. Способ по любому из вариантов осуществления 4-18, в котором базовая станция использует сигнал многоадресной передачи для осуществления связи с соседней базовой станцией.

20. Базовая станция, сконфигурированная для выполнения способа по любому из вариантов осуществления 1-19.

21. Способ аутентификации связи между первой беспроводной базовой станцией и соседней базовой станцией, содержащий:

прием нескольких ключей из шлюза доступа,

выбор первого из нескольких ключей,

вычисление первого значения с использованием первого из нескольких ключей,

передачу первого значения в соседнюю базовую станцию,

вычисление второй базовой станцией первого индекса ключа с использованием первого значения и второго значения,

прием ответа с ассоциацией ключа из соседней базовой станции, ответ с ассоциацией ключа содержит первый индекс ключа, основанный на первом значении, и второй ключ, и

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

22. Базовая станция для беспроводной связи, содержащая:

передатчик для передачи сигнала с запросом параметров в шлюз доступа и для передачи запроса на авторизацию во вторую базовую станцию,

приемник для приема сигнала с ответом с параметрами из шлюза доступа и ответа с авторизацией из второй базовой станции,

кодирующее устройство для использования ключа для кодирования мандата,

генератор случайных чисел для генерирования случайного числа, и

компаратор для сравнения расшифрованного значения аутентификации с шифрованным значением аутентификации.

23. Базовая станция по варианту осуществления 22, сконфигурированная для использования случайного числа для формирования шифрованного значения аутентификации.

24. Базовая станция по варианту осуществления 23 или 24, в которой запрос на авторизацию содержит кодированный мандат и случайное число.

25. Первая базовая станция по любому из вариантов осуществления 22-24, в которой ответ с авторизацией содержит расшифрованное значение аутентификации.

26. Вторая базовая станция по любому из вариантов осуществления 22-25, дополнительно содержащая:

декодер для использования ключа для декодирования кодированного мандата,

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

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

Хотя раскрытые признаки и элементы описаны в вариантах осуществления в определенных комбинациях, каждый признак или элемент может использоваться отдельно, без других признаков и элементов вариантов осуществления, или в различных комбинациях с другими признаками и элементами настоящего раскрытия или без них. Обеспеченные способы или блок-схемы могут быть реализованы в компьютерной программе, программном обеспечении или программируемом оборудовании, реально воплощенном на носителе информации, считываемом компьютером, для выполнения универсальным компьютером или процессором. Возможные варианты носителей информации, считываемых компьютером, включают в себя постоянное запоминающее устройство (ROM), оперативное запоминающее устройство (RAM), регистр, кэш-память, полупроводников