О внесении изменений в Правила применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.09.2010 № 124

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ ПРИКАЗ Москва 13 июня 2018 г. № 281 О внесении изменений в Правила применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.09.2010 № 124 Зарегистрирован Минюстом России 26 июля 2018 г. Регистрационный № 51696 В соответствии со статьей 41 Федерального закона от 7 июля 2003 г. № 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, № 28, ст. 2895; 2018, № 17, ст. 2419) и пунктом 4 Правил организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденных постановлением Правительства Российской Федерации от 13 апреля 2005 г. № 214 (Собрание законодательства Российской Федерации, 2005, № 16, ст. 1463; 2012, № 6, ст. 687), ПРИКАЗ Ы В А Ю: 1. Утвердить прилагаемые изменения, которые вносятся в Правила применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.09.2010 № 124, с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 23.04.2013 № 93 (зарегистрирован Министерством юстиции Российской Федерации 14 июня 2013 г., регистрационный № 28788) и от 22.04.2015 № 129 (зарегистрирован Министерством юстиции Российской Федерации 14 мая 2015 г., регистрационный № 37274). 2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации. Министр К.Ю.Носков _____________ Зарегистрирован Министерством юстиции Российской Федерации 12 октября 2010 г., регистрационный № 18695 _____________ УТВЕРЖДЕНЫ приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 13 июня 2018 г. № 281 Изменения, которые вносятся в Правила применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.09.2010 № 124 1. Пункт 23 дополнить подпунктами 8 - 13 следующего содержания: "8) протокола MIPv4, используемого при взаимодействии оборудования доверенного радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц (далее - TWAN) с обслуживающим шлюзом (далее - S-GW) или шлюзом взаимодействия с сетями, использующими технологию с коммутацией пакетов (далее - P-GW) оборудования коммутации стандарта LTE (интерфейс S2a) при реализации согласно приложению № 19 к Правилам; 9) протокола PMIPv6, используемого на интерфейсе S2a, в случае реализации согласно приложению № 8.1 к Правилам применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденным приказом Министерства связи и массовых коммуникаций Российской Федерации от 06.06.2011 № 130 (зарегистрирован Министерством юстиции Российской Федерации 28 июня 2011 г., регистрационный № 21216), с изменениями, внесенными приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.12.2015 № 543 (зарегистрирован Министерством юстиции Российской Федерации 18 января 2016 г., регистрационный № 40606) (далее - Правила № 130-11); 10) протокола GTP, используемого на интерфейсе S2a, в случае реализации согласно приложению № 7 к Правилам № 130-11; 11) протокола Diameter, используемого между TWAN и функцией реализации правил политики и тарификации (далее - PCRF) оборудования коммутации стандарта LTE на интерфейсе Gxx (Gxa, Gxc), согласно пункту 5 приложения № 5 к Правилам № 130-11; 12) протокола Diameter между TWAN и 3GPP ААА сервер/прокси на интерфейсе STa, между оборудованием ненадежного радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц (далее - UTWAN) и 3GPP ААА сервер/прокси на интерфейсе SWa, согласно приложению № 20 к Правилам; 13) протокола ЕАР-АKА, ЕАР-АKА' на интерфейсах STa, SWa согласно приложению № 21 к Правилам.". 2. Приложение № 19 изложить в следующей редакции: "Приложение № 19 к Правилам применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц Требования к параметрам протокола MIPv4 1. Требования к дополнениям и расширениям протоколов, необходимым для поддержки мобильности пользователя в сети, использующей IPv4: 1.1. дополнительные сообщения, поддерживающие управление мобильностью пользователя и отправляемые с порта UDP/TCP 434 ("Запрос регистрации" (Registration Request) и "Результат регистрации" (Registration Reply): а) формат сообщения "Запрос регистрации" (рисунок 1). |-----|---|---|---|---|---|---|---|---|---------------------------| |Тип | S | B | D | M | G | r | T | X |Длительность регистрации | |-----|---|---|---|---|---|---|---|---|---------------------------| |Домашний адрес | |-----------------------------------------------------------------| |Адрес домашнего агента | |-----------------------------------------------------------------| |СоА | |-----------------------------------------------------------------| |Идентификация | |-----------------------------------------------------------------| |Расширения | |-----------------------------------------------------------------| Рисунок 1. Примечание: поле "Тип" (1 байт) должно быть равно "1"; поле "S" (1 бит) должно быть равно "1", если мобильный узел запрашивает сохранение нескольких предыдущих адресов привязки; поле "В" (1 бит) должно быть равно "1", если мобильный узел запрашивает у домашнего агента доставку широковещательных дейтаграмм; поле "D" (1 бит) должно быть равно "1", если мобильный узел сам декапсулирует дейтаграммы, направленные по адресу СоА; поле "М" (1 бит) должно быть равно "1", если мобильный узел запрашивает у домашнего агента режим минимальной инкапсуляции данных; поле "G" (1 бит) должно быть равно "1", если мобильный узел запрашивает у домашнего агента режим инкапсуляции GRE; поля "r" и "X" (по 1 биту) должны быть равны "0" и игнорироваться при приеме; поле "Т" (1 бит) должно содержать информацию о запросе обратного туннелирования; поле "Длительность регистрации" (2 байта) должно содержать значение длительности регистрации в секундах и при установлении в значение "0" сообщает о запросе отмены регистрации, а в значение "0xffff" - бесконечность; поле "Домашний адрес" (4 байта) должно содержать IP адрес мобильного узла в домашней сети; поле "Адрес домашнего агента" (4 байта) должно содержать IP адрес домашнего агента; поле "СоА" (4 байта) должно содержать временный IP адрес мобильного узла в визитной сети; поле "Идентификация" должно содержать сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса регистрации и ответа; б) формат сообщения "Результат регистрации" (рисунок 2). |--------------|------------------|-------------------------------| |Тип |Код |Длительность регистрации | |--------------|------------------|-------------------------------| |Домашний адрес | |-----------------------------------------------------------------| |Адрес домашнего агента | |-----------------------------------------------------------------| |Идентификатор | |-----------------------------------------------------------------| |Расширения | |-----------------------------------------------------------------| Рисунок 2. Примечание: поле "Тип" (1 байт) должно быть равно "3"; поле "Код" (1 байт) должно содержать информацию о результате регистрации; поле "Длительность регистрации" (2 байта) должно содержать значение длительности регистрации в секундах и при значении "0" сообщать о запросе отмены регистрации, а при значении "0xffff" - бесконечность; поле "Домашний адрес" (4 байта) должно содержать IP адрес мобильного узла в домашней сети; поле "Адрес домашнего агента" (4 байта) должно содержать IP адрес домашнего агента; поле "Идентификатор" должно содержать сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса регистрации и ответа; в) сообщения "Запрос регистрации", "Результат регистрации" должны содержать одно или несколько следующих расширений: "аутентификация в домашней сети" (Mobile-Home Authentication) (тип расширения - 32), "аутентификация в визитной сети" (Mobile-Foreign Authentication) (тип расширения - 33), "аутентификация между домашней и визитной сетями" (Foreign-Home Authentication) (тип расширения - 34). Требования к структуре расширений сообщений регистрации приведены на рисунке 3. |-----------------|------------------|----------------------------| |Тип расширения |Длина |SPI | |-----------------|------------------|----------------------------| |SPI |Аутентификатор | |------------------------------------|----------------------------| Рисунок 3. Примечание: поле "Длина" должно содержать информацию о размере аутентификатора плюс 4 байта; поле "SPI" (Security Parameter Index) должно содержать Идентификатор параметров защиты, используемый для вычисления аутентификатора. Алгоритм аутентификации HMAC-MD5 устанавливается по умолчанию; поле "Аутентификатор" должно быть переменной длины, вычисляться для каждого сообщения регистрации и использовать следующие поля сообщений регистрации: поля сообщения регистрации, поступившего с порта 434 UDP; все присутствующие расширения; поля "Тип", "Длина" и "SPI" указанного расширения; 1.2. сообщения протокола ICMPv4, поддерживающие управление мобильностью пользователя ("Объявление маршрутизатора" (Router Advertisement), "Запрос доступности маршрутизатора" (Router Solicitation): а) расширения указанных сообщений должны принимать следующие значения: "0" - один байт заполнения, последнее расширение сообщения ICMP должно использоваться для дополнения длины сообщения до четного количества байт; "16" - объявление мобильного агента (Mobility Agent Advertisement); "19" - длина префикса; б) формат расширения "Объявление мобильного агента" (Mobility Agent Advertisement) (рисунок 4). |-----------------|--------|--------------------------------------| |Тип расширения |Длина |Порядковый номер | |-----------------|--------|---|---|---|---|---|---|---|--|-------| |Длительность регистрации | R | В | Н | F | M | G | r |Т |Резерв | |--------------------------|---|---|---|---|---|---|---|--|-------| |Адрес(а) СоА | |-----------------------------------------------------------------| Рисунок 4. Примечание: поле "Тип расширения" (1 байт) должно быть равно "16"; поле "Порядковый номер" (2 байта) должно содержать номер сообщения с расширением Agent Advertisement; поле "Длительность регистрации" (2 байта) должно содержать значение длительности регистрации в секундах и при значении "0" сообщать о запросе отмены регистрации, а при значении "0xffff" - бесконечность; поле "R" (1 бит) должно содержать информацию о необходимости регистрации в визитном агенте (FA), несмотря на наличие у мобильного узла адреса СоА; поле "В" (1 бит) должно содержать информацию о том, что FA не осуществляет регистрацию мобильных узлов; поле "Н" (1 бит) (домашний агент, НА) должно содержать информацию о том, что агент предлагает услугу домашнего агента; поле "F" (1 бит) (визитный агент) должно содержать информацию о том, что агент предлагает услугу визитного агента; поле "М" (1 бит) (минимальная инкапсуляция) должно содержать информацию о том, что агент реализует прием туннелируемых дейтаграмм, использующих минимальную инкапсуляцию; поле "G" (1 бит) (GRE инкапсуляция) должно содержать информацию о том, что агент реализует прием туннелируемых дейтаграмм, использующих GRE инкапсуляцию; поле "r" (1 бит) резервное и должно быть равно "0"; поле "Т" (1 бит) должно содержать информацию о том, что FA поддерживает обратное туннелирование; поле "Резерв" (8 бит) должно быть равно "0"; поле "Адрес(а) СоА" должно содержать один или несколько адресов СоА при установлении бита F (количество адресов, присутствующих в поле, должно определяться указателем длины); в) формат расширения "Длина префикса" (рисунок 5). Расширение "Длина префикса" может следовать за расширением "Объявление мобильного агента" и должно содержать информацию о количестве бит префикса сети, который применяется к каждому адресу маршрутизатора, указанному в сообщении ICMP "Router Advertisement". |------------------|---------------------------|------------------| | Тип расширения | Длина | Длина префикса | |------------------|---------------------------|------------------| Рисунок 5. Примечание: поле "Тип расширения" (1 байт) должно быть равно "19"; поле "Длина префикса" (8 бит) должно содержать число начальных битов, определяющих номер сети в адресе маршрутизатора, указанного в сообщении ICMP "Router Advertisement". Для каждого адреса должна быть своя длина префикса.". 3. Дополнить приложениями № 20 - 22 следующего содержания: "Приложение № 20 к Правилам применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц Требования к параметрам протокола Diameter на интерфейсах STa/SWa Таблица № 1. Сообщения протокола Diameter, передаваемые на интерфейсе STa и определеные Auth-Application-Id равным "16777250" |---------------------------|-----------------------|----------------------------| | Сообщение | Код сообщения | Направление передачи | |---------------------------|-----------------------|----------------------------| |Diameter-EAP-Request (DER) | 268, бит R в поле |от TWAN к 3GPP AAA серверу | | | команды "Флаг" | | | | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Diameter-EAP-Answer (DEA) | 268, бит R в поле |от 3GPP ААА сервера к TWAN | | | команды "Флаг" очищен | | |---------------------------|-----------------------|----------------------------| |Аварийное прекращение | 274, бит R в поле |от 3GPP ААА сервера/прокси к| |сессии. Запрос (Abort- | команды "Флаг" |TWAN | |Session-Request (ASR)) | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Аварийное прекращение | 274, бит R в поле |от TWAN к 3GPP ААА | |сессии. Ответ | команды "Флаг" очищен |серверу/прокси | |(Abort-Session-Answer | | | |(ASA)) | | | |---------------------------|-----------------------|----------------------------| |Окончание сессии. Запрос | 275, бит R в поле |от TWAN к 3GPP ААА | |(Session-Termination- | команды "Флаг" |серверу/прокси | |Request (STR)) | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Окончание сессии. Ответ | 275, бит R в поле |от 3GPP ААА сервера/прокси к| |(Session-Termination-Answer| команды "Флаг" очищен |TWAN | |(STA)) | | | |---------------------------|-----------------------|----------------------------| |Обновление данных | 258, бит R в поле |от 3GPP ААА сервера/прокси к| |авторизации. Запрос | команды "Флаг" |TWAN | |(Re-Auth-Request (RAR)) | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Обновление данных | 258, бит R в поле |от TWAN к 3GPP ААА | |авторизации. Ответ | команды "Флаг" очищен |серверу/прокси | |(Re-Auth-Answer (RAA)) | | | |---------------------------|-----------------------|----------------------------| |Информация о сессии. Запрос| 265, бит R в поле |от TWAN к 3GPP ААА | |(AA-Request (AAR)) | команды "Флаг" |серверу/прокси | | | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Информация о сессии. Ответ | 265, бит R в поле |от 3GPP ААА сервера/прокси к| |(АА-Answer (ААА)) | команды "Флаг" очищен |TWAN | |---------------------------|-----------------------|----------------------------| Таблица № 2. Сообщения протокола Diameter, передаваемые на интерфейсе SWa и определеные Auth-Application-Id равным "16777250" |---------------------------|-----------------------|----------------------------| | Сообщение | Код сообщения | Направление передачи | |---------------------------|-----------------------|----------------------------| |Diameter-EAP-Request (DER) | 268, бит R в поле |от UTWAN к 3GPP ААА серверу | | | команды "Флаг" | | | | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Diameter-EAP-Answer (DEA) | 268, бит R в поле |от 3GPP ААА сервера к UTWAN | | | команды "Флаг" очищен | | |---------------------------|-----------------------|----------------------------| |Аварийное прекращение | 274, бит R в поле |от 3GPP ААА сервера/прокси к| |сессии. Запрос | команды "Флаг" |UTWAN | |(Abort-Session-Request | установлен в "1" | | |(ASR)) | | | |---------------------------|-----------------------|----------------------------| |Аварийное прекращение | 274, бит R в поле |от UTWAN к 3GPP ААА | |сессии. Ответ | команды "Флаг" очищен |серверу/прокси | |(Abort-Session-Answer | | | |(ASA)) | | | |---------------------------|-----------------------|----------------------------| |Окончание сессии. Запрос | 275, бит R в поле |от UTWAN к 3GPP ААА | |(Session-Termination- | команды "Флаг" |серверу/прокси | |Request (STR)) | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Окончание сессии. Ответ | 275, бит R в поле |от 3GPP ААА сервера/прокси к| |(Session-Termination-Answer| команды "Флаг" очищен |UTWAN | |(STA)) | | | |---------------------------|-----------------------|----------------------------| |Обновление данных | 258, бит R в поле |от 3GPP ААА сервера/прокси к| |авторизации. Запрос | команды "Флаг" |UTWAN | |(Re-Auth-Request (RAR)) | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Обновление данных |258, 6HTRB поле команды|от UTWAN к 3GPP ААА | |авторизации. Ответ (Re- | "Флаг" |серверу/прокси | |Auth-Answer (RAA)) | очищен | | |---------------------------|-----------------------|----------------------------| |Информация о сессии. Запрос| 265, бит R в поле |от UTWAN к 3GPP ААА | |(AA-Request (AAR)) | команды "Флаг" |серверу/прокси | | | установлен в "1" | | |---------------------------|-----------------------|----------------------------| |Информация о сессии. Ответ | 265, бит R в поле |от 3GPP ААА сервера/прокси к| |(АА-Answer (ААА)) | команды "Флаг" очищен |UTWAN | |---------------------------|-----------------------|----------------------------| _____________ Приложение № 21 к Правилам применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц Требования к параметрам протокола ЕАР-АKА, ЕАР-АKА' 1. Расширяемый протокол аутентификации ЕАР-АKА должен применяться для аутентификации и согласования ключей пользователей UMTS при помощи универсального модуля идентификации абонента (USIM). Протокол ЕАР-АKА' должен применяться для доступа к оборудованию коммутации стандартов GSM 900/1800, UMTS, LTE с использованием TWAN или UTWAN доступа. Протоколы должны пользоваться услугами протоколов канального уровня. 2. Требования к параметрам протокола ЕАР-АKА: 2.1. формат пакетов ЕАР (рисунок 1). |------------------|---------------------------|------------------| | Код | Идентификатор | Длина | |------------------|---------------------------|------------------| | Данные | |-----------------------------------------------------------------| Рисунок 1. Примечание: поле "Код" (1 октет) должно содержать информацию о типе пакета ЕАР и принимать следующие значения: "1" - запрос (Request); "2" - ответ (Response); "3" - подтверждение (Success); "4" - отказ (Failure). Пакеты ЕАР с другими значениями кода должны отбрасываться обеими сторонами без уведомления; поле "Идентификатор" (1 октет) должно обеспечивать соответствие вопросов и ответов на них. поле "Длина" (2 октета) должно содержать информацию о размере (в октетах) пакета ЕАР с учетом полей "Код", "Идентификатор", "Длина" и "Данные". Октеты, выходящие за пределы указанного размера, следует рассматривать как заполнение канального уровня и на приеме эти данные должны игнорироваться. Сообщения, в которых значение поля "Длина" превышает размер полученного пакета, должны отбрасываться без уведомления; поле "Данные" должно иметь размер ноль или более октетов. Формат поля должен зависеть от типа пакета (значения поля "Код"). 2.2. формат пакетов ЕАР Request, Response для аутентификации и согласования ключей с помощью USIM (далее - АKА) (рисунок 2). |----------------|------------------|-----------------------------| | Код | Идентификатор | Длина | |----------------|------------------|-----------------------------| | Тип (23) | Подтип | Резерв | |----------------|------------------|-----------------------------| | Тип атрибута | Длина атрибута | Значение (2 и более байтов) | |----------------|------------------|-----------------------------| Рисунок 2. Примечание: поле "Данные" Для пакетов Request и Response должно начинаться с поля "Тип" (1 октет), содержащее тип запрашиваемой информации. Пакеты Request должны передаваться, пока не будет получен корректный отклик, не завершится отсчет числа попыток или нижележащий уровень не сообщит об отказе. Повторные запросы должны передаваться с тем же значением поля "Идентификатор", чтобы их можно было отличить от новых запросов. Содержимое поля "Данные" должно зависеть от "Типа" запроса. Пакеты Response должны передаваться в ответ на корректный запрос; поле "Тип" для пакетов ЕАР-АKА должно быть равно "23"; поле "Данные" должно содержать поле "Подтип" (1 октет) и поле "Резерв" (2 октета). Поле "Подтип" должно содержать информацию о типе запроса/ответа для ЕАР-АKА. За полем "Резерв" должны следовать "Атрибуты" в формате: тип-длина-значение. 2.3. пакет EAP-Request/AKA-Identity (подтип-5) должен содержать запрос идентификационной информации. Для пользователя сети стандартов GSM 900/1800, UMTS, LTE и Интернет идентификационной информацией являются IMSI (TMSI) и NAI (имя пользователя@оператор). Запрос должен содержать один из трех атрибутов, указывающий тип запрашиваемого идентификатора: AT_PERMANENT_ID_REQ; AT_FULLAUTH_ID_REQ; AT_ANY_ID_REQ; 2.4. пакет EAP-Response/AKA-Identity должен содержать ответ с запрашиваемой идентификационной информацией. Ответ должен содержать атрибут AT_IDENTITY. 2.5. пакет EAP-Request/AKA-Challenge (подтип-1) должен содержать данные для полной аутентификации пользователя и включать атрибуты AT_RAND и АТ_МАС, AT_AUTN; 2.6. пакет EAP-Response/AKA-Challenge должен содержать отклик пользователя и включать атрибуты АТМАС и AT_RES; 2.7. пакет EAP-Response/AKA-Authentication-Reject (подтип-2) должен передаваться, если пользователь не принимает параметр аутентификации сети AUTN; 2.8. пакет EAP-Response/AKA-Synchronization-Failure (подтип-4) должен передаваться при ошибке в порядковом номере AUTN и включать атрибут AT_AUTS; 2.9. пакет EAP-Request/AKA-Reauthentication (подтип-13) должен передаваться при запросе сервером повторной быстрой аутентификации пользователя после получения EAP-Response/Identity или EAP-Response/AKA-Identity, и включать атрибут АТ_МАС. 2.10. пакет EAP-Response/AKA-Reauthentication должен передаваться в ответ на запрос AKA-Reauthentication и включать атрибуты АТ_МАС, AT_IV и AT_ENCR_DATA; 2.11. пакет EAP-Response/AKA-Client-Error (подтип-14) должен передаваться при обнаружении пользователем ошибки в пакете ЕАР/АKА, и содержать атрибут AT_CLIENT_ERROR_CODE; 2.12. пакет EAP-Request/AKA-Notification (подтип-12) должен передаваться для передачи пользователю уведомления от идентифицирующей стороны и содержать атрибут AT_NOTIFICATION АT_MАС; 2.13. пакет EAP-Response/AKA-Notification должен передаваться в ответ на EAP-Request/AKA-Notification и включать атрибуты AT_ENCR_DATA и AT_IV; 2.14. генерация ключа должна осуществляться с использованием функции SHA-1. 3. Требования к параметрам протокола ЕАР-АKА должны соответствовать требованиям к параметрам протокола ЕАР-АKА, установленным в пункте 2 Приложения № 21 к Правилам, за исключением: 3.1. поле "Тип" для пакетов ЕАР-АKА' должно быть равно "50"; 3.2. генерация ключа должна осуществляться с использованием функции SHA-256. В протоколе ЕАР-АKА' должны использоваться дополнительные атрибуты: AT_KDF, AT_KDF_INPUT. _____________ Приложение № 22 к Правилам применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц Справочно Список используемых сокращений 1. ГЛОНАСС - ГЛОбальная Навигационная Спутниковая Система. 2. ПЧ - Промежуточная частота. 3. ЭИИМ - Эквивалентная изотропно-излучаемая мощность. 4. 3GPP - 3rd Generation Partnership Project (консорциум, разрабатывающий спецификации для сетей радиотелефонной связи). 5. 8PSK - 8 Phase Shift Keying (8-позиционная фазовая манипуляция). 6. 12QAM - 12 Quadrature Amplitude Modulation (12-позиционная квадратурная амплитудно-фазовая модуляция). 7. 16QAM - 16 Quadrature Amplitude Modulation (16-позиционная квадратурная амплитудно-фазовая модуляция). 8. 16PSK - 16 Phase Shift Keying (16-позиционная фазовая манипуляция). 9. 64QAM - 64 Quadrature Amplitude Modulation (64-позиционная квадратурная амплитудно-фазовая модуляция). 10. 256-QAM - 256 Quadrature Amplitude Modulation (256-позиционная квадратурная амплитудно-фазовая модуляция). 11. ААА - Authentication, Authorization, Accounting (аутентификация, проверка полномочий, учет). 12. АР - Access point (точка доступа). 13. AUTN - Authentication Token (символ аутентификации сети). 14. ВСС - Binary Convolutional Code (двоичный сверточный код). 15. Beam refinement - улучшение конфигурации диаграммы направленности антенны. 16. Beamforming - формирование диаграммы направленности антенны. 17. BF training - Beamforming training (предварительное формирование диаграммы направленности антенны). 18. BPSK - Binary Phase Shift Keying (двоичная фазовая манипуляция). 19. BRP - Beam refinement Packets (пакеты, предназначенные для улучшения конфигурации диаграммы направленности). 20. ССK - Complementary Code Keying (манипуляция дополнительным кодом). 21.СоА - Care-of Address (адрес, назначаемый при регистрации пользователя в сети). 22. CPHY - Control Physical Layer (физический уровень управления). 23. С/I - Carrier/Interference ratio (отношение несущая/интерференционная помеха). 24. DBPSK - Differential Phase Shift Keying (относительная фазовая манипуляция). 25. DC - Direct Current (Постоянный ток). 26. DL-MU-MIMO - Downlink Multiple User Multiple Input/Multiple Output (применение технологии множественного ввода и вывода для нескольких пользователей на нисходящей линии). 27. DMG - Directional Multi-Gigabit (направленная передача со скоростью несколько гигабит в секунду). 28. DQPSK - Differential Quadrature Shift Keying (относительная квадратурная фазовая манипуляция). 29. DSSS - Direct Sequence Spread Spectrum (прямая последовательность перестройки частоты). 30. ЕАР-АKА - Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement (расширяемый протокол Аутентификации для аутентификации и согласования ключей пользователей UMTS). 31. EQM - использование в каждом потоке одинаковой схемы мультиплексирования. 32. FA - Foreign Agent (агент визитной сети). 33. FACoA - Foreign Agent Care-of Address (адрес агента визитной сети). 34. FHSS - Frequency Hopping Spread Spectrum (скачкообразная псевдослучайная перестройка частоты). 35. GFSK - Gaussian Frequency Shift Keying (частотная манипуляция с Гауссовым фильтром). 36. GMSK - Gaussian Filtered Minimum Shift Keying (Гауссовская частотная манипуляция с минимальным сдвигом). 37. GPS - Global Positioning System (система глобального позиционирования). 38. GRE - Generic Routing Encapsulation (общая инкапсуляция маршрутов). 39. GSM - Global System for Mobility (глобальная система мобильной связи). 40. GTP - GPRS Tunnelling Protocol (протокол туннелирования GPRS). 41. НА - Home Agent (агент домашней сети сети). 42. НМАС - hash-based message authentication code (код аутентификации сообщений, использующий хеш-функции). 43. IMSI - International Mobile Subscriber Identity (международный номер абонентской станции). 44. LDPC Coding - Low-Density Parity-Check Coding (кодирование с контролем по четности малой плотности). 45. LTE - Long-Term Evolution (эволюция на длительный период). 46. MAG - Mobile Access Gateway (шлюз мобильного доступа). 47. MD5 - Message Digest 5 (128-битный алгоритм хеширования). 48. MIMO - Multiple Input/Multiple Output (множественный ввод и вывод). 49. MIPv4 - Mobile IP version 4 (расширение функциональности протокола IPv4 по обеспечению мобильности). 50. MSC - Modulation and Coding Scheme (схема модуляции и кодирования). 51. MSK - Minimum Shift Keying (частотная манипуляция с минимальным сдвигом). 52. MU - Multiple User (режим передачи информации от базовой станции многим пользователям). 53. NAI - Network Access Identifier (идентификатор доступа к сети). 54. NSTS - Number of Space-Time Streams (число пространственно-временных потоков). 55. Number of Spatial Streams (число пространственных потоков). 56. OFDM - Orthogonal Frequency Division Multiplexing (мультиплексирование с разделением по ортогональным частотам). 57. OFDMA - Orthogonal Frequency Division Multiple Access (ортогональный частотный множественный доступ). 58. OFDM PHY - Orthogonal Frequency Division Multiplexing Physical Layer (физический уровень мультиплексирования с разделением по ортогональным частотам). 59. P-GW - Packet Data Networks Gateway (шлюз взаимодействия с сетями, использующими технологию с коммутацией пакетов). 60. РВСС - Packet Binary Convolutional Coding (двоичное сверточное кодирование пакетов). 61. PCRF - The Policy and Charging Rules Function (функция правил политики и тарификации). 62. PHY - Physical layer (физический уровень). 63. PMIPv6 - Proxy Mobile IP version 6 (расширение функциональности протокола IPv6 по обеспечению мобильности). 64. QPSK - Quadrature Phase Shift Keying (квадратурная фазовая манипуляция). 65. RS coding - Read Solomon coding (кодирование Рида-Соломона). 66. S-GW - Serving Gateway (обслуживающий шлюз). 67. SC - Single Carrier (одна несущая). 68. SC PHY - Single Carrier Physical Layer (физический уровень для одной несущей). 69. SHA - Secure Hash Algorithm (алгоритм криптографического хеширования). 70. SOFDMA - Scalable Orthogonal Frequency Division Multiple Access (масштабируемый ортогональный частотный множественный доступ). 71. SPC coding - Single Parity Check coding (одиночное кодирование с контролем по четности). 72. SQPSK - Spread Quadrature Phase Shift Keying (расширенная квадратурная фазовая манипуляция). 73. STBC - Space-Time Block Coding (пространственно-временное блочное кодирование). 74. STC - Space-Time Coding (пространственно-временное кодирование). 75. SU - Single User (режим передачи информации от базовой станции одному пользователю). 76. SU-MIMO - Single User Multiple Input/Multiple Output (применение технологии множественного ввода и вывода для одного пользователя). 77. TMSI - Temporary Mobile Subscriber Identity (временный идентификатор мобильного абонента). 78. ТРС - Transmit Power Control (регулирование мощности передачи). 79. TWAN - trusted WLAN (доверенный беспроводный доступ). 80. UEQM - UnEQual Modulation on the spatial streams (использование в каждом потоке разной схемы мультиплексирования). 81. UMTS - Universal Mobile Telecommunications System (универсальная система мобильной связи). 82. USIM - Universal Subscriber Identity Module (карта мобильного пользователя для работы в сети UMTS). 83. UTWAN - Untrusted WLAN (ненадежный беспроводный доступ). 84. VHT - Very High Throughput (очень высокая пропускная способность). 85. XOR - Условное обозначение логической операции, исключающее ИЛИ. 86. /2-BPSK - /2-Binary Phase Shift Keying (/2 двоичная фазовая манипуляция). 87. /2-QPSK - /2-Quadrature Phase Shift Keying (/2 квадратурная фазовая манипуляция). 88. /2-16QAM - /2-16 Quadrature Amplitude Modulation (/2-16-позиционная квадратурная амплитудно-фазовая манипуляция).". _____________