Продукты и услуги Информационно-правовое обеспечение ПРАЙМ Документы ленты ПРАЙМ Доработанный текст проекта Приказа Министерства связи и массовых коммуникаций РФ "О внесении изменений в Правила применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.09.2010 N 124 и Правила применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 06.06.2011 N 130" (подготовлен Минкомсвязью России 13.06.2017)

Доработанный текст проекта Приказа Министерства связи и массовых коммуникаций РФ "О внесении изменений в Правила применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.09.2010 N 124 и Правила применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 06.06.2011 N 130" (подготовлен Минкомсвязью России 13.06.2017)

28 июля 2017

Досье на проект

В соответствии со статьей 41 Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст. 2895; N 52, ст. 5038; 2004, N 35, ст. 3607; N 45, ст. 4377; 2005, N 19, ст. 1752; 2006, N 6, ст. 636; N 10, ст. 1069; N 31, ст. 3431, ст. 3452; 2007, N 1, ст. 8; N 7, ст. 835; 2008, N 18, ст. 1941; 2009, N 29, ст. 3625; 2010, N 7, ст. 705; N 15, ст. 1737; N 27, ст. 3408; N 31, ст. 4190; 2011, N 7, ст. 901; N 9, ст. 1205; N 25, ст. 3535; N 27, ст. 3873, ст. 3880; N 29, ст. 4284, ст. 4291; N 30, ст. 4590; N 45, ст. 6333; N 49, ст. 7061; N 50, ст. 7351, ст. 7366; 2012, N 31, ст. 4322, ст. 4328; N 53, ст. 7578; 2013, N 19, ст. 2326; N 27, ст. 3450; N 30, ст. 4062; N 43, ст. 5451; N 44, ст. 5643; N 48, ст. 6162; N 49, ст. 6339, ст. 6347; N 52, ст. 6961; 2014, N 6, ст. 560; N 14, ст. 1552; N 19, ст. 2302; N 26, ст. 3366, ст. 3377; N 30, ст. 4229, ст. 4273; N 49, ст. 6928; 2015, N 29, ст. 4342, ст. 4383, ст. 4389; 2016, N 10, ст. 1316, ст. 1318; N 15, ст. 2066; N 18, ст. 2498; N 26, ст. 3873; N 27, ст. 4213, ст. 4221; N 28, ст. 4558) и пунктом 4 Правил организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденных постановлением Правительства Российской Федерации от 13 апреля 2005 г. N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст. 1463; 2008, N 42, ст. 4832; 2012, N 6, ст. 687),

ПРИКАЗЫВАЮ:

1. Утвердить прилагаемые изменения, которые вносятся в некоторые приказы Министерства связи и массовых коммуникаций Российской Федерации.

2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.

Министр

Н.А. Никифоров

УТВЕРЖДЕНЫ
приказом Министерства связи и массовых
коммуникаций Российской Федерации
от ____________________ N______

Изменения,которые вносятся в некоторые приказы Министерства связи и массовых коммуникаций Российской Федерации (в части реализации технологии WiFiCalling)

1. В Правила применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.09.2010 N 124 (зарегистрирован в Министерстве юстиции Российской Федерации 12 октября 2010 г., регистрационный N 18695) с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 23.04.2013 N 93 (зарегистрирован в Министерстве юстиции Российской Федерации 14 июня 2013 г., регистрационный N 28788) и от 22.04.2015 N 129 (зарегистрирован в Министерстве юстиции Российской Федерации 14 мая 2015 г., регистрационный N 37274) внести следующие изменения:

1) пункт 23 дополнить подпунктами 8-13 следующего содержания:

"8) протокола MIPv4, используемого при взаимодействии оборудования доверенного радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц (далее ? TWAN) с обслуживающим шлюзом (далее ? S-GW) или шлюзом взаимодействия с сетями, использующими технологию с коммутацией пакетов (далее ? P-GW) оборудования коммутации стандарта LTE (интерфейс S2а), в случае реализации согласно приложению N 19 к Правилам;

9) протокола PMIPv6, используемого на интерфейсе S2а, в случае реализации согласно приложению N 8.1 к Правилам применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 06.06.2011 N 130 (зарегистрирован в Министерстве юстиции Российской Федерации 28 июня 2011 г., регистрационный N 21216), с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 06.12.2012 N 284 (зарегистрирован в Министерстве юстиции Российской Федерации 18 января 2013 г., регистрационный N 26585) и от 14.12.2015 N 543 (зарегистрирован в Министерстве юстиции Российской Федерации 18 января 2016 г., регистрационный N 40606)), (далее ? Правила N 130-11);

10) протокола GTP, используемого на интерфейсе S2а, в случае реализации согласно приложению N 7 к Правилам N 130-11;

11) протокола Diameter, используемого между TWAN и функцией реализации правил политики и тарификации (далее ? PCRF) оборудования коммутации стандарта LTE на интерфейсе Gxх (Gxa,Gxc), согласно пункту 5 приложения N 5 к Правилам N 130-11;

12) протокола Diameter между TWAN и 3GPP ААА сервер/прокси на интерфейсе STa, между оборудованием ненадежного радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц (далее ? UTWAN) и 3GPP ААА сервер/прокси на интерфейсе SWa, согласно приложению N 20 к Правилам;

13) протокола EAP-AKA, EAP-AKA′ на интерфейсах STa, SWa согласно приложению N 21 к Правилам.".

2) приложение N 19 считать Приложением N 22.

3) дополнить пунктом 24 следующего содержания:

"24. Список используемых сокращений приведен в приложении N 22 к Правилам (справочно).".

4) приложение N 19 изложить в следующей редакции:

"Приложение N 19
к Правилам применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц

Требования к параметрам протокола MIPv4

1. Дополнения и расширения протоколов, необходимые для поддержки мобильности пользователя в сети, использующей IPv4.

1.1. Дополнительные сообщения, поддерживающие управление мобильностью пользователя и отправляемые с порта UDP/TCP 434:

"Запрос регистрации" (Registration Request),

"Результат регистрации" (Registration Reply).

1.2. Формат сообщения "Запрос регистрации" приведен на рисунке 1.

Тип	S	B	D	M	G	r	T	X	Длительность регистрации
Домашний адрес
Адрес домашнего агента
СoA
Идентификация
Расширения

Рисунок 1. Формат сообщения "Запрос регистрации"

Поле "Тип" (1 байт) устанавливается в "1".

Поле "S" (1 бит) устанавливается в "1", если мобильный узел запрашивает сохранение нескольких предыдущих адресов привязки.

Поле "B" (1 бит) устанавливается в "1", если мобильный узел запрашивает у домашнего агента доставку широковещательных дейтаграмм.

Поле "D" (1 бит) устанавливается в "1", если мобильный узел сам декапсулирует дейтаграммы, направленные по адресу CoA.

Поле "M" (1 бит) устанавливается в "1", если мобильный узел запрашивает у домашнего агента режим минимальной инкапсуляции данных.

Поле "G" (1 бит) устанавливается в "1", если мобильный узел запрашивает у домашнего агента режим инкапсуляции GRE.

Поля "r" и "Х" (по 1 биту) устанавливаются в "0" и игнорируются при приеме.

Поле "T" (1 бит) указывает, что запрошено обратное туннелирование.

Поле "Длительность регистрации" (2 байта) указывает длительность регистрации в секундах. Значение "0" указывает на запрос отмены регистрации. Значение "0xffff" указывает бесконечность.

Поле "Домашний адрес" (4 байта) указывает IP адрес мобильного узла в домашней сети.

Поле "Адрес домашнего агента" (4 байта) указывает IP адрес домашнего агента.

Поле "СoA" (4 байта) указывает временный IP адрес мобильного узла в визитной сети.

Поле "Идентификация" содержит сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса регистрации и ответа.

1.3. Формат сообщения "Результат регистрации" приведен на рисунке 2.

Тип	Код	Длительность регистрации
Домашний адрес
Адрес домашнего агента
Идентификатор
Расширения

Рисунок 2. Формат сообщения "Результат регистрации"

Поле "Тип" (1 байт) устанавливается в "3".

Поле "Код" (1 байт) указывает результат регистрации.

Поле "Длительность регистрации" (2 байта) указывает длительность регистрации в секундах. Значение "0" указывает на отмену регистрации. Значение "0xffff" указывает бесконечность.

Поле "Домашний адрес" (4 байта) указывает IP адрес мобильного узла в домашней сети.

Поле "Адрес домашнего агента" (4 байта) указывает IP адрес домашнего агента.

Поле "Идентификатор" ? сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса регистрации и ответа.

1.4. Расширения для сообщений "Запрос регистрации", "Результат регистрации".

Хотя бы одно расширение из указанных ниже, должно присутствовать в сообщениях регистрации.

Структура расширений "аутентификация в домашней сети" (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.5. Сообщения протокола ICMPv4, поддерживающие управление мобильностью пользователя:

"Объявление маршрутизатора" (Router Advertisement),

"Запрос доступности маршрутизатора" (Router Solicitation).

1.6. Значения расширений, используемые для этих сообщений:

0 ? один байт заполнения, последнее расширение сообщения ICMP используется для дополнения длины сообщения до четного количества байт;

16 ? объявление мобильного агента (Mobility Agent Advertisement);

19 ? длина префикса.

1.7. Форматы расширений для сообщения "Объявление маршрутизатора":

Формат расширения "Объявление мобильного агента" (Mobility Agent Advertisement) приведен на рисунке 4.

Тип расширения	Длина	Порядковый номер
Длительность регистрации	R	B	H	F	M	G	r	T	Резерв
Адрес(а) CoA

Рисунок 4. Формат расширения "Объявление мобильного агента"

Полю "Тип расширения" (1 байт) присваивается значение "16".

Поле "Порядковый номер" (2 байта) указывает номер сообщения с расширением Agent Advertisement.

Поле "R" (1 бит) указывает, что, не смотря на наличие у мобильного узла адреса CoA, требуется регистрация в визитном агенте (FA).

Поле "B" (1 бит) указывает, что FA не осуществляет регистрацию мобильных узлов.

Поле "H" (1 бит) (домашний агент, HA) указывает, что агент предлагает услугу домашнего агента.

Поле "F" (1 бит) (визитный агент) указывает, что агент предлагает услугу визитного агента.

Поле "M" (1 бит) (минимальная инкапсуляция) указывает, что агент реализует прием туннелируемых дейтаграмм, которые используют минимальную инкапсуляцию.

Поле "G" (1 бит) (GRE инкапсуляция) указывает, что агент реализует прием туннелируемых дейтаграмм, которые используют GRE инкапсуляцию.

Поле "r" (1 бит) ? резерв, устанавливается в "0".

Поле "T" (1 бит) указывает, что FA поддерживает обратное туннелирование.

Поле "Резерв" (8 бит) устанавливается в "0".

В поле "Адрес(а) CoA" указывается один или более адресов CoA, в случае если установлен бит F. Количество адресов, присутствующих в поле, определяется указателем длины.

1.8. Формат расширения " Длина префикса" (19) приведен на рисунке 5.

Расширение "Длина префикса" может следовать за расширением "Объявление мобильного агента" и указывает количество бит префикса сети, который применяется к каждому адресу маршрутизатора, указанному в сообщении ICMP "Router Advertisement".

Тип расширения	Длина	Длина префикса

Рисунок 5. Формат расширения "Длина префикса"

Полю "Тип расширения" (1 байт) присваивается значение "19".

Поле "Длина префикса" (8 бит) определяет число начальных битов, определяющих номер сети в адресе маршрутизатора, указанного в сообщении ICMP "Router Advertisement". Для каждого адреса указывается своя длина префикса.".

5) дополнить приложением N 20 следующего содержания:

"Приложение N 20

К Правилам применения оборудования радиодоступа. Часть I. Правила применения оборудования радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц

Требования к параметрам протокола Diameter на интерфейсах STa/SWa

1. Сообщения протокола Diameter, передаваемые на интерфейсе STa, определены Auth-Application-Id равным "16777250" и приведены в таблице N 1.

Таблица N 1. Сообщения протокола Diameter на интерфейсе STa

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к TWAN
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к TWAN
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от TWAN к 3GPP AAA серверу/прокси
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к TWAN
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к TWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от TWAN к 3GPP AAA серверу/прокси
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к TWAN

2. Сообщения протокола Diameter, передаваемые на интерфейсе SWa, определены Auth-Application-Id равным "16777250" и приведены в таблице N 2.

Таблица N 2. Сообщения протокола Diameter на интерфейсе SWa

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к UTWAN
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к UTWAN
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к UTWAN

6) дополнить приложением N 21 следующего содержания:

"Приложение N 21

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

Требования к протоколам EAP-AKA, EAP-AKA′

1. Протокол EAP-AKA ? расширяемый протокол аутентификации для аутентификации и согласования ключей пользователей UMTS при помощи универсального модуля идентификации абонента (USIM).

Протокол EAP-AKA′ применяется для доступа к оборудованию коммутации стандартов GSM 900/1800, UMTS, LTE с использованием TWAN или UTWAN доступа.

Протоколы пользуются услугами протоколов канального уровня.

2. Требования к протоколу EAP-AKA:

2.1. Формат пакетов EAP-AKA.

На рисунке 1 приведен формат пакетов EAP.

Код	Идентификатор	Длина
Данные

Рисунок 1. Формат пакетов EAP

Поле "Код" (1 октет) показывает тип пакета EAP и может принимать значения:

1 - запрос (Request);

2 - ответ (Response);

3 - подтверждение (Success);

4 - отказ (Failure).

Пакеты EAP с другими значениями кода отбрасываются обеими сторонами без уведомления.

Поле "Идентификатор" (1 октет) обеспечивает соответствие вопросов и ответов на них.

Поле "Длина" (2 октета) содержит размер (в октетах) пакета EAP с учетом полей "Код", "Идентификатор", "Длина" и "Данные". Октеты, выходящие за пределы указанного размера, следует трактовать, как заполнение канального уровня ? на приеме эти данные должны игнорироваться. Сообщения, в которых значение поля "Длина" превышает размер полученного пакета, должны отбрасываться без уведомления.

Поле "Данные" имеет размер ноль или более октетов. Формат поля зависит от типа пакета (значения поля "Код").

2.2. Пакеты EAP Request, Response для аутентификации и согласования ключей с помощью USIM (далее - AKA) приведены на рисунке 2.

Код	Идентификатор	Длина
Тип (23)	Подтип	Резерв
Тип атрибута	Длина атрибута	Значение (2 и более байтов)

Рисунок 2. Формат пакетов EAP Request, Response для AKA

Для пакетов Request и Response поле "Данные" начинается с поля "Тип" (1 октет), которое содержит тип запрашиваемой информации. Пакеты Request должны передаваться пока не будет получен корректный отклик, не завершится отсчет числа попыток или нижележащий уровень не сообщит об отказе. Повторные запросы должны передаваться с тем же значением поля "Идентификатор", чтобы их можно было отличить от новых запросов. Содержимое поля "Данные" зависит от "Типа" запроса. Пакеты Response передаются в ответ на корректный запрос.

Для пакетов EAP-AKA поле "Тип" устанавливается равным "23".

Далее поле "Данные" включает поле "Подтип" (1 октет) и поле "Резерв" (2 октета). Поле "Подтип" указывает тип запроса/ответа для EAP-AKA.

За полем "Резерв" в поле "Данные" следуют "Атрибуты" в формате: тип-длина-значение.

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_MAC, AT_AUTN.

2.6. Пакет EAP-Response/AKA-Challenge содержит отклик пользователя и включает атрибуты AT_MAC и 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, и включает атрибут AT_MAC.

2.10. Пакет EAP-Response/AKA-Reauthentication передается в ответ на запрос AKA-Reauthentication и включает атрибуты AT_MAC, AT_IV и AT_ENCR_DATA.

2.11. Пакет EAP-Response/AKA-Client-Error (подтип-14) передается, когда пользователь обнаруживает ошибку в пакете EAP/AKA, и содержит атрибут AT_CLIENT_ERROR_CODE.

2.12. Пакет EAP-Request/AKA-Notification (подтип-12) включает атрибут AT_NOTIFICATION AT_MAC и передается для передачи пользователю уведомления от идентифицирующей стороны.

2.13. Пакет EAP-Response/AKA-Notification передается в ответ на EAP-Request/AKA-Notification и включает атрибуты AT_ENCR_DATA и AT_IV.

2.14. Генерация ключа осуществляется с использованием функции SHA-1.

3. Требования к протоколу EAP-AKA′ соответствуют требованиям к EAP-AKA за исключением:

3.1. Для пакетов EAP-AKA′ поле "Тип" устанавливается равным "50".

3.2. Используются новые атрибуты AT_KDF, AT_KDF_INPUT.

3.3. Генерация ключа осуществляется с использованием функции SHA-256.".

7) приложение N 22 дополнить пунктами 28-55 следующего содержания:

"28. 3GPP ? 3rd Generation Partnership Project (консорциум, разрабатывающий спецификации для сетей радиотелефонной связи).

29. AAA ? Authentication, Authorization, Accounting (аутентификация, проверка полномочий, учет).

30. AUTN ? Authentication Token (символ аутентификации сети).

31. CoA ? Care-of Аddress (адрес, назначаемый при регистрации пользователя в сети).

32. EAP-AKA ? Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement (расширяемый протокол Аутентификации для аутентификации и согласования ключей пользователей UMTS).

33. FA ? Foreign Agent (агент визитной сети).

34. FACoA ? Foreign Agent Care-of Address (адрес агента визитной сети).

35. GRE ? Generic Routing Encapsulation (общая инкапсуляция маршрутов).

36. GSM ? Global System for Mobility (глобальная система мобильной связи).

37. GTP ? GPRS Tunnelling Protocol (протокол туннелирования GPRS).

38. HA ? Home Agent (агент домашней сети сети).

39. HMAC ? hash-based message authentication code (код аутентификации сообщений, использующий хеш-функции).

40. IMSI ? International Mobile Subscriber Identity (международный номер абонентской станции).

41. LTE ? Long-Term Evolution (эволюция на длительный период).

42. MAG ? Mobile Access Gateway (шлюз мобильного доступа).

43. MD5 ? Message Digest 5 (128-битный алгоритм хеширования).

44. MIPv4 ? Mobile IP version 4 (расширение функциональности протокола IPv4 по обеспечению мобильности).

45. NAI ? Network Access Identifier (идентификатор доступа к сети).

46. P-GW ? Packet Data Networks Gateway (шлюз взаимодействия с сетями, использующими технологию с коммутацией пакетов).

47. PCRF ? The Policy and Charging Rules Function (функция правил политики и тарификации).

48. PMIPv6 ? Proxy Mobile IP version 6 (расширение функциональности протокола IPv6 по обеспечению мобильности).

49. S-GW ? Serving Gateway (обслуживающий шлюз).

50. SHA ? Secure Hash Algorithm (алгоритм криптографического хеширования).

51. TMSI ? Temporary Mobile Subscriber Identity (временный идентификатор мобильного абонента).

52. TWAN ? trusted WLAN (доверенный беспроводный доступ).

53. UMTS ? Universal Mobile Telecommunications System (универсальная система мобильной связи)

54. USIM ? Universal Subscriber Identity Module (карта мобильного пользователя для работы в сети UMTS).

55. UTWAN ? Untrusted WLAN (ненадежный беспроводный доступ)."

2. В Правила применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденные приказом Министерства связи и массовых коммуникаций Российской Федерации от 06.06.2011 N 130 (зарегистрирован в Министерстве юстиции Российской Федерации 28 июня 2011 г., регистрационный N 21216) с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 06.12.2012 N 284 (зарегистрирован в Министерстве юстиции Российской Федерации 18 января 2013 г., регистрационный N 26585) и от 14.12.2015 N 543 (зарегистрирован в Министерстве юстиции Российской Федерации 18 января 2016 г., регистрационный N 40606) внести следующие изменения:

1) пункт 2 изложить в следующей редакции:

"2. Правила устанавливают обязательные требования к параметрам оборудования коммутации стандартов LTE и (или) LTE-Advanced (далее ? стандарта LTE), включая оборудование коммутации IMS, при оказании услуг передачи данных и телефонного соединения, в том числе требования к параметрам, обеспечивающим взаимодействие с узлами связи стандартов GSM 900/1800 и UMTS, а так же к параметрам оборудования коммутации стандарта LTE для взаимодействия с беспроводным доступом, отличным от стандартов GSM 900/1800, UMTS, LTE (далее - non-3GPP), и принадлежащим домашнему или визитному оператору СПРС (далее ? доверенный беспроводный доступ TWAN) или принадлежащим другой сети связи общего пользования (далее ? ненадежный беспроводный доступ UTWAN).".

2) пункт 4 дополнить подпунктами 11 и 12 следующего содержания:

"11) оборудование 3GPP AAA сервер/прокси;

12) оборудование, реализующее функции доступа к оборудованию коммутации стандарта LTE из сети Интернет при использовании доступа UTWAN (далее ? ePDG).".

3) пункт 5 изложить в следующей редакции:

"5. Процедуру обязательной сертификации проходит как оборудование коммутации сетей подвижной радиотелефонной связи в составе входящего в него оборудования коммутации стандарта LTE, так и оборудование, приведенное в подпунктах 1 - 7, 9, 10 пункта 4 Правил, в качестве самостоятельных средств связи, включая оборудование средств связи, в том числе программное обеспечение, обеспечивающее выполнение установленных действий при проведении оперативно-розыскных мероприятий.

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

При использовании оборудования коммутации стандарта LTE несколькими операторами сети подвижной радиотелефонной связи каждый оператор несет ответственность за обеспечение возможности проведения ОРМ в принадлежащем ему трафике.".

4) пункт 11 дополнить подпунктами 11 и 12 следующего содержания:

"11) к функциям MME при реализации non-3GPP доступа:

пересылка ключа протокола GRE к целевому S-GW по интерфейсам S10/S11 для передачи данных по восходящей линии связи в случае перемещения UE из узла CN;

12) к данным MME при реализации non-3GPP доступа согласно приложению N 21 к Правилам.".

5) подпункт 6 пункта 12 изложить в следующей редакции:

"6) к параметрам протокола PMIPv6 согласно приложению N 8.1 к Правилам при реализации в оборудовании коммутации стандарта LTE;".

6) пункт 12 дополнить подпунктами 8-10 следующего содержания:

"8) к функциям S-GW при реализации non-3GPP доступа:

а) при взаимодействии с TWAN с использованием протокола PMIPv6 на интерфейсе S2a реализует функции локального узла управления мобильностью (далее - LMA) визитной (гостевой) сети подвижной радиотелефонной связи (далее ? VPLMN) с TWAN, когда UE находится в роуминге;

б) информирует PCRF о происходящих изменениях при переходе UE на новую технологию радиодоступа;

в) организует взаимодействие восходящих и нисходящих каналов относительно доступа стандартов GSM 900/1800, UMTS, LTE;

г) осуществляет контроль трафика от UE;

д) при взаимодействии с P-GW с использованием протокола PMIPv6 на интерфейсах S5 и S8 реализует функции MAG;

е) принимает решение о маршрутизации пакетов по восходящей линии к P-GW, по нисходящей линии к UE, или определение пакетов, предназначенных для S-GW;

ж) реализует функции агента протокола DHCPv4, либо DHCPv6 в случае использования протокола PMIPv6 на интерфейсах S5 или S8;

з) осуществляет обмен сообщениями "Запрос доступности маршрутизатора" (Router Solicitation) (далее ? RS) и "Ответ маршрутизатора" (Router Advertisement) (далее ? RA) протокола NDP в случае использования протокола PMIPv6 на интерфейсах S5 и S8;

и) осуществляет обмен сообщениями "Запрос доступных соседей" (Neighbour Solicitation) и "Ответ соседа" (Neighbor Advertisement) протокола NDP в случае использования протокола PMIPv6 на интерфейсах S5 и S8;

й) осуществляет генерацию и распределение ключей протокола GRE для каждого соединения передачи данных по нисходящей линии от P-GW к S-GW в случае использования протокола PMIPv6 на интерфейсах S5 и S8;

к) реализует функции LMA в отношении функции MAG протокола PMIPv6, реализованной в TWAN либо в ePDG;

л) осуществляет генерацию и распределение ключей протокола GRE для инкапсуляции пакетов данных в туннель для каждого соединения передачи данных по восходящей линии от S-GW в случае использования протокола PMIPv6 на интерфейсах S2a/S2b;

м) реализует функции взаимодействия протокола PMIPv6 в направлении P-GW и в направлении функции MAG, реализованной в TWAN (S8 и S2a) либо в ePDG (S8 и S2b). При этом S-GW реализует функции MAG по отношению к P-GW;

н) реализует функции соединения плоскости пользователя туннеля PMIPv6 в направлении P-GW и плоскости пользователя туннеля PMIPv6 в направлении функции MAG, реализованной в TWAN либо в ePDG;

9) к параметрам протокола MIPv4, используемого при взаимодействии S-GW с TWAN (интерфейс S2а), согласно приложению N 16 к Правилам при реализации в оборудовании коммутации стандарта LTE;

10) к данным S-GW при реализации non-3GPP доступа согласно приложению N 21 к Правилам.".

7) подпункт 7 пункта 13 изложить в следующей редакции:

"7) к параметрам протокола PMIPv6 согласно приложению N 8.1 к Правилам при реализации в оборудовании коммутации стандарта LTE;".

8) пункт 13 дополнить подпунктами 10-16 следующего содержания:

"10) требования к функциям P-GW при реализации non-3GPP доступа:

а) реализует функции точки взаимодействия для плоскости пользователя при передвижении пользователя между сетями доступа стандартов GSM 900/1800, UMTS, LTE и non-3GPP;

б) реализует функции узла LMA при использовании протокола PMIPv6 на интерфейсах S5 и S8, или на S2a, или на S2b;

в) реализует функции домашнего агента (далее ? HA) протокола DSMIPv6 при использовании интерфейса S2c между P-GW и UE. DSMIPv6 на интерфейсе S2c создает туннель между UE и P-GW, который используется для пересылки пользовательского и сигнального трафика между UE и P-GW. P-GW обеспечивает назначение IP-адресов для создания туннеля;

г) осуществляет генерацию и распределение ключей протокола GRE, используемых для инкапсуляции пользовательских данных, передаваемых по восходящей линии при реализации протокола PMIPv6 на интерфейсах S5 и S8 или на S2a, или на S2b;

д) реализует функции домашнего агента при использовании протокола MIPv4 на интерфейсе S2a, в процессе регистрации осуществляет назначение UE временного IP-адреса с помощью протокола MIPv4. При этом временный IP-адрес является адресом агента визитной сети (далее ? FACoA);

е) реализация протокола GTP для плоскости управления (GTPv2-С) и плоскости пользователя (GTPv1-U), чтобы обеспечить соединение PDN c UE, используя non-3GPP доступ, если на интерфейсе S2a или S2b реализуется протокол GTP;

ж) взаимодействие с ААА сервером внешней сети передачи данных по интерфейсу SGi с использованием протоколов RADIUS или Diameter;

з) взаимодействие с 3GPP ААА сервер/прокси c использованием интерфейса S6b по протоколу Diameter;

11) к параметрам протокола MIPv4, используемого при взаимодействии P-GW с TWAN (интерфейс S2a), согласно приложению N 16 к Правилам при реализации в оборудовании коммутации стандарта LTE;

12) к параметрам протокола DSMIPv6, используемого при взаимодействии P-GW с UE (интерфейс S2c) согласно приложению N 17 к Правилам при реализации в оборудовании коммутации стандарта LTE;

13) к параметрам протокола IKEv2, используемого при взаимодействии P-GW с UE (интерфейс S2c), согласно приложению N 18 к Правилам при реализации в оборудовании коммутации стандарта LTE;

14) к параметрам протокола IPSec, используемого при взаимодействии P-GW с UE (интерфейс S2c), согласно приложению N 19 к Правилам;

15) к параметрам протокола Diameter на интерфейсе S6b согласно приложению N 20 к Правилам;

16) к данным P-GW при реализации non-3GPP доступа согласно приложению N 21 к Правилам.".

9) пункт 16 дополнить подпунктами 4-6 следующего содержания:

"4) требования к функциям HSS при реализации non-3GPP доступа:

взаимодействие с 3GPP ААА сервером по интерфейсу SWx с использованием протокола Diameter;

5) к параметрам протокола Diameter на интерфейсе SWx согласно приложению N 20 к Правилам;

6) к данным HSS при реализации non-3GPP доступа согласно приложению N 21 к Правилам.".

10) пункт 17 дополнить подпунктом 5 следующего содержания:

"5) требования к функциям PCRF при реализации non-3GPP доступа:

а) к PCRF домашней сети (далее - H-PCRF):

взаимодействие с P-GW домашней сети по интерфейсу Gx для обмена информацией управления качеством передачи данных QoS и правил тарификации при маршрутизации трафика через домашнюю сеть с использованием протокола Diameter;

взаимодействие с TWAN по интерфейсу Gxa, с S-GW по интерфейсу Gxc, с ePDG по интерфейсу Gxb, для передачи сообщений управления качеством передачи данных QoS и тарификации с использованием протокола Diameter;

взаимодействие с PCRF визитной сети (далее - V-PCRF) по интерфейсу S9 с использованием протокола Diameter;

б) к PCRF визитной сети:

взаимодействие с TWAN по интерфейсу Gxa, с S-GW по интерфейсу Gxc, с ePDG по интерфейсу Gxb для передачи сообщений управления качеством передачи данных QoS и тарификации с использованием протокола Diameter;

взаимодействие с H-PCRF по интерфейсу S9 с использованием протокола Diameter.".

11) пункт 19 считать пунктом 22.

12) дополнить новыми пунктами 19, 20, 21 следующего содержания:

"19. Для оборудования, выполняющего функции ePDG, устанавливаются следующие обязательные требования:

1) выделение UE временного удаленного IP адреса (далее-CoA), который является локальным для ePDG, при использовании интерфейса S2c;

2) регистрация локального IP адреса UE;

3) возможности для транспортировки удаленного IP-адреса, выделенного в качестве IP-адреса PDN, при использовании S2b;

4) маршрутизация пакетов данных от(к) P-GW, (от(к) S-GW, если S-GW выполняет функции LA в сети VPLMN) к(от) UE, если на S2b используется протокол GTP;

5) маршрутизация пакетов данных к UE по интерфейсу SWu, связанному соединением с PDN;

6) инкапсуляция и деинкапсуляция пакетов данных для туннелей IPSec, для GTP или PMIPv6, если поддержка мобильности осуществляется на базе интерфейса S2b;

7) реализация функций MAG, если на S2b используется PMIPv6;

8) формирование безопасных туннелей IPSec при помощи протокола IKEv2 для передачи данных аутентификации и авторизации;

9) обеспечение функции LMA, в случае реализации расширения протокола IKEv2;

10) генерация и распределение ключей протокола GRE, используемых для инкапсуляции данных PMIPv6, передаваемых EPC в направлении ePDG и далее в сторону интерфейса S2b;

11) организация взаимодействия правил тарификации различных операторов;

12) реализация функции пограничного взаимодействия;

13) к параметрам протоколов IP, UDP, TCP согласно приложению N 8 к Правилам при реализации в оборудовании коммутации стандарта LTE;

14) к интерфейсам взаимодействия и их параметрам согласно приложению N 9 к Правилам;

15) к параметрам протокола PMIPv6 согласно приложению N 8.1 к Правилам при реализации в оборудовании коммутации стандарта LTE;

16) к параметрам протокола SCTP согласно пункту 2 приложения N 14 к Правилам N 58-07 при реализации в оборудовании коммутации стандарта LTE;

17) к параметрам протокола GTP согласно приложению N 7 к Правилам;

18) к параметрам протокола IKEv2 согласно приложению N 18 к Правилам;

19) к параметрам протокола IPSec, к идентификационному заголовку AH, к протоколу ESP согласно приложению N 19 к Правилам;

20) к параметрам протокола Diameter на интерфейсе SWm между ePDG и 3GPP AAA сервер/прокси согласно приложению N 20 к Правилам;

21) к данным ePDG при реализации non-3GPP доступа согласно приложению N 21 к Правилам;

22) к параметрам протокола EAP-AKA, EAP-AKA′ согласно приложению N 22 к Правилам.

20. Для оборудования, выполняющего функции 3GPP AAA сервера, устанавливаются следующие обязательные требования:

1) выполнение функции сервера для метода EAP-AKA, используемого при аутентификации UE;

2) получение от HLR/HSS информации о профилях UE для аутентификации;

3) аутентификация 3GPP пользователя с использованием данных, полученных от HLR/HSS;

4) по просьбе HLR/HSS обновление информации для доступа TWAN;

5) передача информации авторизации пользователя к WLAN, если пользователь находится в визитной сети, то через 3GPP ААА прокси;

6) регистрация своего адреса в HLR/HSS при каждой аутентификации пользователя;

7) удаление данных о подключении из HLR/HSS при отмене регистрации пользователя в 3GPP AAA сервере;

8) сохранение информации о состоянии подключения UE к WLAN;

9) формирование и передача данных для тарификации к системе тарификации в HPLMN при доступе UE через UTWAN;

10) хранение данных о качестве обслуживания для TWAN;

11) взаимодействие с TWAN по интерфейсу STa, с HLR/HSS по интерфейсу SWx, с UTWAN по интерфейсу SWa, с 3GPP AAA прокси по интерфейсу SWd с использованием протокола Diameter;

12) передача к P-GW информации для авторизации;

13) предоставление P-GW временного удаленного IP адреса UE, полученного от HSS, когда используется статический удаленный IP адрес;

14) предоставление 3GPP AAA прокси информации о правилах обслуживания пользователя;

16) к параметрам протоколов IP, UDP, TCP согласно приложению N 8 к Правилам при реализации в оборудовании коммутации стандарта LTE;

17) к интерфейсам взаимодействия и их параметрам согласно приложению N 9 к Правилам;

18) к параметрам протокола SCTP согласно пункту 2 приложения N 14 к Правилам N 58-07 при реализации в оборудовании коммутации стандарта LTE;

19) к параметрам протокола IKEv2 согласно приложению N 18 к Правилам;

20) к параметрам протокола IPSec, к идентификационному заголовку AH, к протоколу ESP согласно приложению N 19 к Правилам;

21) к параметрам протокола Diameter на интерфейсах STa, SWx, SWa, SWd согласно приложению N 20 к Правилам;

22) к данным 3GPP AAA сервера при реализации non-3GPP доступа согласно приложению N 21 к Правилам;

23) к параметрам протокола EAP-AKA, EAP-AKA′ согласно приложению N 22 к Правилам.

21. Для оборудования, выполняющего функции 3GPP AAA прокси, устанавливаются следующие обязательные требования:

1) трансляция информации для аутентификации между WLAN и 3GPP AAA сервером;

2) обеспечение выполнения в визитной сети правил обслуживания пользователя, согласованных операторами 3GPP, оператором WLAN и оператором 3GPP;

3) при использовании доступа WLAN предоставление информации об ограничениях, полученной из домашней сети;

4) формирование и передача данных для тарификации к системе тарификации VPLMN;

5) прекращение обслуживания;

6) обеспечение взаимодействия интерфейсов SWa, STa и SWd в случае использования на них различных протоколов;

7) к параметрам протокола PMIPv6 согласно приложению N 8.1 к Правилам при реализации в оборудовании коммутации стандарта LTE;

8) к параметрам протоколов IP, UDP, TCP согласно приложению N 8 к Правилам при реализации в оборудовании коммутации стандарта LTE;

9) к интерфейсам взаимодействия и их параметрам согласно приложению N 9 к Правилам;

10) к параметрам протокола SCTP согласно пункту 2 приложения N 14 к Правилам N 58-07 при реализации в оборудовании коммутации стандарта LTE;

11) к параметрам протокола IKEv2 согласно приложению N 18 к Правилам;

12) к параметрам протокола IPSec, к идентификационному заголовку AH, требования к протоколу ESP согласно приложению N 19 к Правилам;

13) к параметрам протокола Diameter на интерфейсах STa, SWa, SWd согласно приложению N 20 к Правилам;

14) к данным 3GPP AAA прокси при реализации non-3GPP доступа согласно приложению N 21 к Правилам;

15) к параметрам протокола EAP-AKA, EAP-AKA′ согласно приложению N 22 к Правилам.".

13) пункт 22 изложить в следующей редакции:

"22. Список используемых сокращений приведен в приложении N 23 к Правилам (справочно).".

14) приложение N 1 дополнить пунктом 4 следующего содержания:

"4. Для аутентификации UE при доступе через TWAN используются:

1) идентификатор доступа к сети (далее ? NAI), который имеет структуру:

"1"<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org ? для аутентификации EAP-AKA;

"0"<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org ? для аутентификации EAP-SIM;

2) идентификатор сети доступа (далее ? ANID) при доступе non-3GPP принимает следующие значения:

"WIMAX" - сеть доступа WiMAX;

"WLAN" ? сеть доступа WLAN;

"ETHERNET" ? сеть фиксированного доступа с коммутацией пакетов.".

15) название приложения N 8.1 к Правилам N 130 изложить в следующей редакции: "Требования к параметрам протокола PMIPv6".

16) в приложении N 9 к Правилам N 130 первый абзац пункта 1.3 изложить в следующей редакции:

"1.3. В рамках протокола PMIPv6 для интерфейсов S5, S8, S2a, S2b определены следующие сообщения:".

17) приложение N 9 дополнить пунктом 9 следующего содержания:

"9. Для обслуживания non-3GPP доступа реализуются следующие интерфейсы взаимодействия:

S2a ? интерфейс взаимодействия TWAN (TWAG) и S-GW, либо P-GW в зависимости от архитектуры сети, обеспечивающий передачу данных пользователя и сигнализации. На интерфейсе S2a реализуются протоколы управления мобильностью PMIPv6, MIPv4 (с адресацией FACoA) или GTP плоскости управления и пользователя;

S2b ? интерфейс взаимодействия ePDG и S-GW либо P-GW в зависимости от архитектуры сети, обеспечивающий передачу данных пользователя и сигнализации. Интерфейс S2b реализует протокол управления мобильностью PMIPv6 или GTP;

S2c ? интерфейс взаимодействия UE с P-GW, обеспечивающий передачу данных пользователя и сигнализации. Интерфейс S2c поддерживает протокол управления мобильностью DSMIPv6 и IPSec. Формирование безопасных туннелей IPSec выполняется при помощи протокола IKEv2;

S5 ? интерфейс взаимодействия S-GW и P-GW, обеспечивающий передачу данных пользователя и сигнализации с использованием туннелей, реализует протокол GTP либо PMIPv6;

S8 ? интерфейс взаимодействия S-GW в VPLMN и P-GW в HPLMN необходим при роуминге и в случае маршрутизации пользовательского трафика через HPLMN. Интерфейс реализует протокол GTP либо PMIPv6;

На интерфейсах S5, S8, S2a, S2b реализуется один и тот же протокол либо PMIPv6, либо GTP.

S6a ? интерфейс взаимодействия MME и HSS, используемый в целях аутентификации и авторизации, реализует протокол Diameter.

S6b ? интерфейс взаимодействия P-GW и 3GPP AAA сервера либо 3GPP AAA прокси (при роуминге в случае маршрутизации трафика через визитную сеть) с использованием Diameter.

Gx ? интерфейс обеспечивает передачу сообщений управления качеством передачи данных QoS и правил тарификации от PCRF к P-GW c использованием протокола Diameter.

Gxa ? интерфейс обеспечивает передачу сообщений протокола Diameter для управления качеством передачи данных QoS от PCRF к TWAN.

Gxb ? интерфейс между ePDG и VPCRF, обеспечивающий передачу сообщений протокола Diameter для управления качеством передачи данных QoS от VPCRF к ePDG.

Gxc ? интерфейс обеспечивает передачу сообщений протокола Diameter для управления качеством передачи данных QoS между S-GW и PCRF.

S9 ? интерфейс обеспечивает передачу сообщений протокола Diameter для управления качеством передачи данных QoS в условиях роуминга между НPCRF и VPCRF. В случае маршрутизации пользовательского трафика в PDN из визитной сети по интерфейсу S9 передаются данные о правилах тарификации.

SGi ? интерфейс между P-GW и PDN.

SWa ? интерфейс взаимодействия UTWAN с 3GPP AAA сервером (либо прокси) по протоколу Diameter используется для безопасной передачи информации аутентификации, авторизации и учета (тарификации).

STa ? интерфейс взаимодействия TWAN с 3GPP AAA сервером (либо прокси) по протоколу Diameter используется в целях безопасной передачи информации аутентификации, авторизации и учета (тарификации) с поддержкой протокола EAP-AKA, EAP-AKA′.

SWd ? интерфейс взаимодействия 3GPP AAA прокси и 3GPP AAA сервера по протоколу Diameter с поддержкой протокола EAP-AKA, EAP-AKA′.

SWm ? интерфейс взаимодействия 3GPP AAA сервера (либо прокси) и ePDG для передачи данных сигнализации AAA. Данный интерфейс используется также для передачи данных аутентификации и авторизации протоколов управления мобильности PMIPv6 (MAG-AAA) и MIPv6 (MIPv6 NAS-AAA) с поддержкой протокола EAP-AKA.

SWu ? интерфейс между мобильным терминалом и шлюзом ePDG, обеспечивает безопасную передачу данных в туннеле IPSec. Обмен ключами при формировании туннеля IPSec выполняется при помощи протокола IKEv2.

SWx ? интерфейс взаимодействия 3GPP AAA сервера и базы данных HSS обеспечивает обмен данными для аутентификации и авторизации UE.".

18) приложение N 16 изложить в следующей редакции:

"Приложение N 16

к Правилам применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE

Требования к параметрам протокола MIPv4

"Запрос регистрации" (Registration Request);

"Результат регистрации" (Registration Reply).

1.1.1. Формат сообщения "Запрос регистрации" приведен на рисунке 1.

Тип	S	B	D	M	G	r	T	X	Длительность регистрации
Домашний адрес
Адрес домашнего агента
СoA
Идентификация
Расширения

Рисунок 1. Формат сообщения "Запрос регистрации"

Поле "Тип" (1 байт) устанавливается в "1".

Поле "G" (1 бит) устанавливается в "1", если мобильный узел запрашивает у домашнего агента режим инкапсуляции GRE.

Поля "r" и "Х" (по 1 биту) устанавливаются в "0" и игнорируются при приеме.

Поле "T" (1 бит ) указывает, что запрошено обратное туннелирование.

Поле "Домашний адрес" (4 байта) указывает IP адрес мобильного узла в домашней сети.

Поле "Адрес домашнего агента" (4 байта) указывает IP адрес домашнего агента.

Поле "СoA" (4 байта) указывает временный IP адрес мобильного узла в визитной сети.

1.1.2. Формат сообщения "Результат регистрации" приведен на рисунке 2.

Тип	Код	Длительность регистрации
Домашний адрес
Адрес домашнего агента
Идентификатор
Расширения

Рисунок 2. Формат сообщения "Результат регистрации"

Поле "Тип" (1 байт) устанавливается в 3.

Поле "Код" (1 байт ) указывает результат регистрации.

Поле "Домашний адрес" (4 байта) указывает IP адрес мобильного узла в домашней сети.

Поле "Адрес домашнего агента" (4 байта) указывает IP адрес домашнего агента.

Поле "Идентификатор" содержит сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса регистрации и ответа.

1.1.3. Расширения для сообщений "Запрос регистрации", "Результат регистрации".

Хотя бы одно расширение, из указанных ниже, должно присутствовать в сообщениях регистрации.

Расширения "аутентификация в домашней сети (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).

1.2.1. Значения расширений, используемые для этих сообщений:

16 ? "Объявление мобильного агента" (Mobility Agent Advertisement);

19 ? длина префикса.

1.3. Форматы расширений для сообщения "Объявление маршрутизатора".

1.3.1. Формат расширения "Объявление мобильного агента" приведен на рисунке 4.

Тип расширения	Длина	Порядковый номер
Длительность регистрации	R	B	H	F	M	G	r	T	Резерв
Адрес (а) CoA

Рисунок 4. Формат расширения "Объявление мобильного агента"

Полю "Тип расширения" (1 байт) присваивается значение "16".

Поле "Порядковый номер" (2 байта) указывает номер сообщения с расширением Agent Advertisement.

Поле "B" (1 бит) указывает, что FA не осуществляет регистрацию мобильных узлов.

Поле "H" (1 бит) (домашний агент, HA) указывает, что агент предлагает услугу домашнего агента.

Поле "F" (1 бит) (визитный агент) указывает, что агент предлагает услугу визитного агента.

Поле "r" (1 бит) ? резерв, устанавливается в "0".

Поле "T"(1 бит) указывает, что FA поддерживает обратное туннелирование.

Поле "Резерв" (8 бит) устанавливается в "0".

В поле "Адрес(а) CoA" указывается один или более адресов CoA в случае, если установлен бит F. Количество адресов, присутствующих в поле, определяется указателем длины.

1.3.2. Формат расширения "Длина префикса" (19) приведен на рисунке 5.

Тип расширения	Длина	Длина префикса

Рисунок 5. Формат расширения "Длина префикса"

Полю "Тип расширения" (1 байт) присваивается значение "19".

Поле "Длина префикса" (8 бит) определяет число начальных битов, определяющих номер сети в адресе маршрутизатора, указанного в сообщении ICMP Router Advertisement. Для каждого адреса указывается своя длина префикса.".

19) дополнить приложением N 17 следующего содержания:

"Приложение N 17

Требования к параметрам протоколов MIPv6, DSMIPv6

1. Дополнительный заголовок мобильности протокола IPv6, обеспечивающий мобильность пользователя ? Mobility Header (далее ? MH).

1.1. Заголовок "Mobility Header" обозначается в поле "Next Header" (Следующий заголовок) значением "135" и включает поля, приведенные в таблице N 1.

Таблица N 1. Поля заголовка "Mobility Header"

Поля заголовка
N поля	Название	Длина поля (бит)
1	Payload Proto	8
2	Header Len	8
3	MH Type	8
4	Резерв	8
5	Checksum	16
6	Message Data	0-n

Поле "Payload Proto" идентифицирует тип заголовка, следующего сразу за Mobility Header, используются те же значения, что в заголовке "Следующий заголовок" протокола IPv6.

Поле "Header Len" указывает длину заголовка (за исключением первых 8 октетов) в единицах, равных 8 октетам. Если сообщение не имеет параметров, то значение Header Len устанавливается равным "0".

Поле "MH Type" указывает тип передаваемого сообщения.

Поле "Резерв" устанавливается равным "0".

Поле "Checksum" содержит контрольную сумму заголовка "Mobility Header", начиная с поля "Payload Proto".

Поле "Message Data" - поле переменной длины, содержит данные сообщения, тип которого указан в поле "MH Type".

Для выравнивания границы заголовка по длине, кратной 8 октетам, используется "Поле дополнения до границы заголовка". Свободные позиции заполняются нулями.

1.2. С использованием заголовка "Mobility Header" передаются следующие сообщения:

1.2.1. "Запрос обновления привязки UE" (Binding Refresh Request (BRR)). "MH Type" присваивается значение "0".

BRR включает следующие поля:

"Резерв" (16 бит) для использования в будущем. Отправителем его значение устанавливается в "0" и игнорируется получателем;

"Опции мобильности" (Mobility Options). Поле переменной длины, при этом длина полного заголовка мобильности кратна 8 октетам. Это поле содержит ноль, одну или несколько опций мобильности, закодированных в формате TLV. Получатель игнорирует и пропускает любые опции, которые он не понимает.

1.2.2. "Инициирование проверки домашнего адреса" (Home Test Init (HoTI)). "MH Type" присваивается значение "1".

HoTI включает следующие поля:

"Резерв" (16 бит) для использования в будущем. Отправителем его значение устанавливается в "0" и игнорируется получателем.

"Идентифицирующая цепочка домашнего адреса" (Home Init Cookie) ? 64-битовое поле, которое содержит значение вновь сгенерированного случайного числа, которое возвращается в UE в сообщении Home Test.

"Опции мобильности" (Mobility Options) ? поле переменной длины, при этом длина полного заголовка мобильности кратна 8 октетам. Это поле содержит ноль, одну или несколько опций мобильности, закодированных в формате TLV. Получатель игнорирует и пропускает любые опции, которые он не понимает.

Мобильный узел использует сообщение "Home Test Init" для инициализации процедуры обратной маршрутизации и запроса маркера "Home keygen token" от узла-корреспондента. Это сообщение туннелируется через домашнего агента, когда мобильный узел находится в визитной сети.

1.2.3. "Инициирование проверки временного адреса" (Care-of Test Init). "MH Type" присваивается значение "2".

Сообщение "Care-of Test Init" включает следующие поля:

"Идентифицирующая цепочка временного адреса" (Care-of Init Cookie), 64-битовое поле, которое содержит значение вновь сгенерированного случайного числа, которое возвращается в UE в сообщении "Care-of Test".

Мобильный узел использует сообщение "Care-of Test Init" (CoTI) для инициализации процедуры обратной маршрутизации и запроса маркера "Care-of Keygen Token" от узла-корреспондента.

1.2.4. Идентифицирующая цепочка, посылаемая узлу-корреспонденту в сообщении "Home Test Init" должна быть возвращена UE в сообщении "Проверка домашнего адреса" (Home Test). Полю "MH Type" для сообщения "Home Test" присваивается значение "3".

Сообщение "Home Test" включает следующие поля:

"Одноразовый индекс домашнего номера" (Home Nonce Index). Это 16-битовое поле будет возвращено обратно узлу-корреспонденту мобильным узлом в сообщении "Binding Update".

"Идентифицирующая цепочка домашнего адреса" (Home Init Cookie) ? 64-битовое поле, которое было принято в сообщении "Home Test Init".

"Маркер Home Keygen Token" ? поле содержит 64 бита маркера, используемого в процедуре обратной маршрутизации.

1.2.5. Идентифицирующая цепочка, посылаемая узлу-корреспонденту в сообщении "Care-of Test Init", должна быть возвращена UE в сообщении "Care-of Test". Полю "MH Type" для сообщения "Care-of Test" присваивается значение "4".

Сообщение "Care-of Test" включает следующие поля:

"Одноразовый индекс временного номера" (Care-of Nonce Index). Это 16-битовое поле будет возвращено обратно узлу-корреспонденту мобильным узлом в сообщении "Binding Update".

"Идентифицирующая цепочка временного адреса" (Care-of Init Cookie) ? 64-битовое поле, которое содержит значение принятое в сообщении "Care-of Test Init".

"Маркер Care-of Keygen Token" ? поле содержит 64 бита маркера, используемого в процедуре обратной маршрутизации.

1.2.6. "Информирование об обновлении привязки" (Binding Update (BU)). "MH Type" для сообщения BU присваивается значение "5". Сообщение "Binding Update" используется мобильным узлом для уведомления других узлов о своем новом временном адресе.

Сообщение "Binding Update" включает следующие поля:

"Порядковый номер" (Sequence) ? это 16-битовое поле используется для нумерации сообщений "Binding Update" для сопоставления сообщения "Binding Acknowledgement" с сообщением "Binding Update".

Бит "Подтверждение" (A) (Acknowledge) устанавливается посылающим мобильным узлом для указания, что ожидается сообщение "Подтверждение привязки".

Бит "Регистрация в домашнем агенте" (H) (Home Registration) устанавливается посылающим мобильным узлом для того, чтобы принимающий узел домашней сети служил ему домашним агентом.

Бит "Соответствие линка и локального адреса" (L) (Link-Local Address Compatibility) устанавливается, когда домашний адрес, переданный мобильным узлом, имеет тот же идентификатор интерфейса, что и линк.

Бит "Возможность мобильного управления ключами" (Key Management Mobility Capability) (K). Если этот бит обнуляется, то протокол, используемый для установления контекстов безопасности IPsec между мобильным узлом и домашним агентом, не переносит информацию о перемещении. Этот бит является правомерным только в сообщениях "Binding Update", посылаемых домашнему агенту, и обнуляется в других сообщениях "Binding Update". Узлы-корреспонденты игнорируют этот бит.

Поле "Зарезервировано" (Reserved) (12 бит) не используется. Оно устанавливается в "0" отправителем и игнорируется приемником.

Поле "Время жизни" (Lifetime) (16 бит) указывает на количество единиц времени, оставшихся до того момента, когда привязка UE считается просроченной. Нулевое значение указывает на то, что информация о привязке мобильного узла должна быть удалена. В этом случае указанный временный адрес устанавливается равным домашнему адресу. За единицу времени приняты 4 сек.

"Опции мобильности" (Mobility Options) ? это поле переменной длины, которое имеет такую длину, что длина полного заголовка мобильности кратна 8 октетам. Это поле содержит ноль или несколько опций мобильности, закодированных в формате TLV. Получатель должен игнорировать и пропускать любые опции, которые он не понимает.

В сообщении "Binding Update" допустимы следующие опции мобильности:

опция "Данные авторизации привязки" (Binding Authorization Data) является обязательной в сообщениях "Binding Update", посылаемых узлу-корреспонденту;

опция "Индексы одноразовых номеров" (Nonce Indices);

опция "Альтернативный (запасной) временный адрес" (Alternate Care-of Address).

Если в данном сообщении опции отсутствуют, то необходимы 4 октета заполнителя, и поле заголовка "Mobility Header Header Len" будет установлено в "1".

1.2.7. Подтверждение приема сообщения об обновлении привязки (Binding Acknowledgement (BA)). "MH Type" для сообщения BA присваивается значение "6".

1.2.8. Сообщение об ошибке, связанной с мобильностью (Binding Error (BE)). "MH Type" для сообщения BE присваивается значение "7".

1.3. Дополнительный заголовок протокола IPv6, обеспечивающий дополнительные данные для маршрутизации ? "Type 2 Routing Header".

1.3.1. Заголовок "Type 2 Routing Header" включает поля, приведенные в таблице N 2.

Таблица N 2. Поля заголовка "Type 2 Routing Header"

Поля заголовка
N поля	Название	Длина поля (бит)
1	Next Header	8
2	Hdr Ext Len	8
3	Routing Type	8
4	Segments Left	8
5	Резерв	32
6	Home Address	16

Поле "Next Header" - идентифицирует тип заголовка, следующего за заголовком "Type 2 Routing Header", для идентификации заголовков используются те же значения, что в заголовке "Следующий заголовок" протокола IPv6.

Поле "Hdr Ext Len" указывает длину заголовка (за исключением первых 8 октетов) в единицах, равных 8 октетам. Значение "Hdr Ext Len" устанавливается равным "2".

Поле "Routing Type" указывает тип маршрутизации, устанавливается равным "2".

Поле "Segments Left" устанавливается равным "1".

Поле "Резерв" устанавливается равным "0".

Поле "Home Address" - поле длиной 16 октетов, содержит домашний адрес узла назначения.

1.4. Новые сообщения ICMP IPv6:

Протокол Mobile IPv6 вводит четыре новых типа сообщений для протокола ICMP.

Для определения адреса домашнего агента используются новые сообщения ICMP:

"Запрос определения адреса домашнего агента" (Home Agent Address Discovery Request) используется мобильным терминалом для инициации механизма динамического определения адреса домашнего агента.

"Ответ определения адреса домашнего агента" (Home Agent Address Discovery Reply) используется домашним агентом для ответа мобильному узлу, который использует механизм динамического определения адреса домашнего агента.

Для перенумерования сетей и конфигурирования адресов на мобильном узле используются новые сообщения ICMP:

"Запрос мобильного префикса" (Mobile Prefix Solicitation),

"Объявление мобильного префикса" (Mobile Prefix Advertisement).

1.4.1. Формат сообщения "Запрос определения адреса домашнего агента" (Home Agent Address Discovery Request) приведен на рисунке 1.

Тип	Код	Контрольная сумма
Идентификатор		Резерв

Рисунок 1. Формат сообщения "Запрос определения адреса домашнего агента"

Поле "Тип" (1 байт) устанавливается в "144".

Поле "Код" (1 байт) устанавливается в "0".

Поле "Идентификатор" (2 байта) содержит сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса и ответа.

Поле "Резерв" не используется. Оно устанавливается в ноль отправителем и игнорируется получателем.

1.4.2. Формат сообщения "Ответ определения адреса домашнего агента" (Home Agent Address Discovery Reply) приведен на рисунке 2.

Тип	Код	Контрольная сумма
Идентификатор		Резерв
Адрес домашнего агента

Рисунок 2. Формат сообщения "Ответ определения адреса домашнего агента"

Поле "Тип" (1 байт) устанавливается в "145".

Поле "Код" (1 байт ) устанавливается в "0".

В поле "Идентификатор" (2 байта) помещается число из сообщения "Home Agent Address Discovery Request".

Поле "Резерв" не используется. Оно устанавливается в ноль отправителем и игнорируется получателем.

Поле "Адреса домашнего агента" содержит список адресов домашних агентов мобильного узла в домашней сети.

1.4.3. Формат сообщения "Запрос мобильного префикса" (Mobile Prefix Solicitation) приведен на рисунке 3.

Тип	Код	Контрольная сумма
Идентификатор		Резерв

Рисунок 3. Формат сообщения "Запрос мобильного префикса"

Поле "Тип" (1 байт) устанавливается в "146".

Поле "Код" (1 байт) устанавливается в "0".

Поле "Резерв" не используется, устанавливается в "0" отправителем и игнорируется получателем.

При этом поля пакета протокола IPv6 заполняются следующим образом: в поле "Адрес источника" (Source Address) указывается временный адрес мобильного узла, в поле "Адрес места назначения" (Destination Address) указывается адрес домашнего агента мобильного узла.

1.4.4. Формат сообщения "Объявление мобильного префикса" (Mobile Prefix Advertisement) приведен на рисунке 4.

Тип	Код	Контрольная сумма
Идентификатор	М	О	Резерв
Опции

Рисунок 4. Формат сообщения "Объявление мобильного префикса"

Поле "Тип" (1 байт) устанавливается в "147".

Поле "Код" (1 байт ) устанавливается в "0".

Поле "M" (1 бит) ? флаг управляемого конфигурирования адресов. Если равен "1", указывает, что адреса доступны через DHCPv6.

Поле "O" (1 бит) - флаг другой конфигурации, если равен "1", указывает, что существует другая информация о конфигурации, доступная через DHCPv6.

Поле "Резерв" не используется, устанавливается в ноль отправителем и игнорируется получателем.

В поле "Опции" сообщение содержит одну или несколько опций "Prefix Information". Каждая опция передает префикс, который мобильный узел использует для конфигурирования своего домашнего адреса (домашних адресов).

При этом поля пакета протокола IPv6 заполняются следующим образом: в поле "Адрес источника" (Source Address) указывается адрес домашнего агента, в поле "Адрес места назначения" (Destination Address) указывается значение поля "Source Address" из сообщения "Запрос мобильного префикса".

2. Изменения формата сообщений протокола обнаружения соседних узлов (далее ? NDP).

2.1. Формат сообщения "Объявление маршрутизатора" (Router Advertisement) приведен на рисунке 5.

Тип	Код
Текущий предел шагов	М	О	H	Резерв	Время жизни маршрутизатора
Время достижимости
Время повторной передачи
Опции

Рисунок 5. Формат сообщения Router Advertisement

Поле "Тип" (1 байт) устанавливается в "134".

Поле "Код" (1 байт) устанавливается в "0".

Поле "Текущий предел шагов" содержит значение по умолчанию, которое следует поместить в поле числа шагов IP-заголовка для исходящих пакетов.

Поле "M" (1 бит) - флаг управляемого конфигурирования адресов, если равен "1", указывает, что адреса доступны через DHCPv6.

Поле "H" (1 бит) - флаг домашнего агента, если равен "1", указывает, что маршрутизатор, пославший это сообщение, функционирует как домашний агент.

Поле "Резерв" не используется, устанавливается в "0" отправителем и игнорируется получателем.

Поле "Время жизни маршрутизатора" указывает время функционирования устройства, в качестве маршрутизатора, измеряется в секундах.

Поле "Время достижимости" (4 байта) указывает в миллисекундах, в течение какого времени соседний маршрутизатор считается доступным после получения подтверждения доступности.

Поле "Время повторной передачи" (4 байта) указывает в миллисекундах время между повторно пересылаемыми сообщениями запросов.

3. Требования к протоколу DSMIPv6.

3.1. Для функционирования протокола на интерфейсе S2c на мобильном терминале устанавливается программное обеспечение (далее - ПО) клиента DSMIPv6, на P-GW ? ПО домашнего агента DSMIPv6.

3.2. Расширения для сообщений протокола MIPv6:

3.2.1. Сообщение "Binding Update", передавемое от UE к домашнему агенту или точке привязки мобильности (Mobility Anchor Point (далее ? MAP)), расширяется:

опцией "IPv4 Home Address Option", в которой указывается домашний адрес мобильного узла формата IPv4;

опцией "IPv4 Care-of Address Option", в которой указывается временный адрес мобильного узла формата IPv4, когда он находится в сети, поддерживающей только протокол IPv4;

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

3.2.2. Сообщение "Binding Acknowledgement", передаваемое от домашнего агента или MAP к UE, расширяется:

опцией "IPv4 Acknowledgement Option", в которой указывается, что обновление адреса привязки для мобильного узла осуществилось адресом формата IPv4, так же указывается домашний адрес мобильного узла формата IPv4;

опцией "NAT Detection Option", в которой домашний агент указывает UE на наличие трансляции сетевого адреса (Network Address Translation, далее ? NAT), так же может включать таймер повторной передачи обновления и флага "F", установка которого указывает на необходимость инкапсуляции с помощью протокола UDP.".

20) дополнить приложением N 18 следующего содержания:

"Приложение N 18

Требования к параметрам протокола IKEv2

1. Протокол обмена ключами в Интернет (Internet Key Exchange) версия 2 IKEv2 пользуется услугами протокола UDP через порты 500 и 4500. Передается по одному сообщению IKEv2 в дейтаграмме UDP. Адреса IP и номера портов UDP в заголовках сохраняются и используются для передачи ответных пакетов. При передаче через UDP порт 500 сообщение IKEv2 начинается непосредственно после заголовка UDP. При передаче через порт UDP 4500 перед сообщением IKEv2 помещается четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKEv2 и не учитываются в размерах и контрольных суммах IKEv2.

2. Каждое сообщение IKEv2 начинается с заголовка. После заголовка следует один или множество элементов данных IKEv2, каждый из которых идентифицируется значением поля "Next Payload" предыдущего элемента данных. Элементы данных обрабатываются в порядке их следования в сообщении IKEv2 путем вызова соответствующей процедуры, согласно значению поля "Next Payload" в заголовке IKEv2, потом согласно значению "Next Payload" в первом элементе данных IKEv2 и так далее, пока в поле "Next Payload" не будет обнаружено нулевое значение, показывающее отсутствие следующего элемента данных. Элемент данных типа Encrypted при приеме дешифруется и результат расшифровки разбирается, как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете, включать в зашифрованные элементы другие элементы типа Encrypted недопустимо.

2.1. Формат заголовка IKEv2 приведен на рисунке 1.

Initiator′s SPI
Responder′s SPI
Next Payload	MjVer	MnVer	ExchType	Flags	Message ID
Length

Рисунок 1. Формат заголовка IKEv2

"Initiator′s SPI" (8 октетов) ? значение, выбранное инициатором для уникальной идентификации параметров безопасности (Security Parameter Index, далее -SPI) IKEv2. Нулевое значение недопустимо.

"Responder′s SPI" (8 октетов) ? значение, выбранное ответчиком для уникальной идентификации защищенной связи IKE. Это значение должно быть нулевым в первом сообщении начального обмена IKEv2 (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений нулевое значение недопустимо.

"Next Payload" (1 октет) показывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.

"Mj Ver" (4 бита) задает старшую часть номера версии, используемого протокола IKE. Реализации на основе IKEv2 должны устанавливать Major Version=2. Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим "2".

"Mn Ver" (4 бита) задает младшую часть номера версии IKE. Реализации на основе IKEv2 должны устанавливать Minor Version=0 и игнорировать младшую часть номера в принимаемых сообщениях.

"Exchange Type" (1 октет) указывает тип обмена, который будет использоваться. Тип ограничивает набор элементов данных в каждом сообщении и порядок сообщений в обмене. Типы обмена приведены в таблице N 1.

Таблица N 1. Типы обмена

Тип обмена	Значение
IKE_SA_INIT	34
IKE_AUTH	35
CREATE_CHILD_SA	36
INFORMATIONAL	37
Резерв IANA	38-239
Резерв для частного использования	240-255

"Flags" (1 октет) показывает наличие специфических опций в сообщении. Наличие опции указывается установкой соответствующего бита флага в "1".

"Message ID" (4 октета) ? идентификатор сообщения служит для управления повторной передачей потерянных пакетов и связывания запросов с откликами.

"Length" (4 октета) ? размер всего сообщения (заголовок и элементы данных) в октетах.

2.2. Каждый элемент данных (payload) IKEv2 начинается с базового заголовка, структура которого приведена на рисунке 2.

Идентификатор следующего элемента	С	Резерв	Размер текущего элемента
Элементы данных

Рисунок 2. Формат базового заголовка данных

"Идентификатор следующего элемента" (Next Payload) (1 октет) указывает тип следующего элемента данных в сообщении. Если текущий элемент является последним, это поле имеет значение "0". Элемент типа Encrypted, который всегда должен быть последним в сообщении, является исключением. Он содержит структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле "Next Payload" устанавливается в соответствии с типом первого вложенного элемента (вместо "0"). Значения типа следующего элемента приведены в таблице N 2.

Таблица N 2. Значения идентификаторов следующих элементов сообщения

Идентификатор следующего элемента	Обозначения	Значение
Отсутствует следующий элемент		0
Резерв		1-32
Контекст безопасности	SA	33
Обмен ключами	KE	34
Идентификатор инициатора	IDi	35
Идентификатор отвечающего	IDr	36
Сертификат	CERT	37
Запрос сертификата	CERTREQ	38
Идентификация	AUTH	39
Случайное число	Ni, Nr	40
Уведомление	N	41
Удаление	D	42
Идентификатор реализации	V	43
Селектор трафика - Инициатор	TSi	44
Селектор трафика - Ответчик	TSr	45
Кодирование	E	46
Конфигурация	CP	47
Расширяемая идентификация	EAP	48
Резерв IANA		49-127
Для частного применения		128-255

Поле "C" (1 бит) имеет значение "0", если отправитель хочет, чтобы получатель пропустил этот элемент в случае, если он не понимает код в поле "Next Payload" предыдущего элемента. Если получатель понимает тип элемента, он игнорирует этот флаг. Флаг "C" относится к текущему элементу данных.

Поле "Резерв" (7 битов) имеет значение "0" при передаче и игнорируется на приеме.

Поле "Размер текущего элемента" (Payload Length) (2 октета) ? размер текущего элемента данных в октетах с учетом базового заголовка.

2.3. Элементы данных SA (Предложения).

Данные контекста безопасности (Security Association Payload, далее ? SA) служат для согласования атрибутов защищенной связи. Элемент SA может включать множество предложений. Если предложений больше одного, они должны быть упорядочены в порядке снижения приоритета. Каждое предложение может включать несколько протоколов IPsec (протоколами являются IKEv2, ESP, AH), каждый протокол может включать множество преобразований, а каждое преобразование может включать несколько атрибутов.

Структура "Предложения" SA приведена на рисунке 3.

0 или 2	Резерв	Длина предложения
Номер предложения	Идентификатор протокола	Значение SPI	Число преобразований
SPI передающей стороны
Структура преобразования

Рисунок 3. Структура элемента данных "Предложения" (SA)

Первый октет равный "0" (последнее) или "2" (не последнее) показывает, является ли предложение последним в субструктуре предложений элемента SA.

Поле "Длина предложения" (2 октета) указывает размер данного предложения, включая все входящие в него преобразования и атрибуты.

Поле "Номер предложения" (1 октет) указывает номер предложения. Первое предложение в элементе SA должно иметь номер 1, номера последующих должны совпадать с номером предшественника (И ? пересечение двух предложений) или быть на 1 больше (ИЛИ ? объединение двух предложений). Когда предложение принимается, все номера предложений в элементе SA должны совпадать и соответствовать номеру переданного предложения, которое было принято.

Поле "Идентификатор протокола" (1 октет) задает идентификатор протокола IPsec для текущего согласования.

Поле "Значение SPI" (1 октет) для начального согласования IKE_SA. Это поле должно иметь нулевое значение, значение SPI получается из внешнего заголовка. При последующих согласованиях это поле показывает размер (в октетах) SPI для соответствующего протокола (8 ? для IKEv2, 4 ? для ESP и AH).

Поле "Число преобразований" (1 октет) показывает число преобразований в данном предложении.

Поле "SPI передающей стороны" (переменный размер).

Поле "Структура преобразования" (переменный размер).

2.3.1. Формат поля "Структура преобразования" приведен на рисунке 4.

0 или 3	Резерв	Длина преобразования
Тип преобразования	Резерв	Идентификатор преобразования
Атрибуты преобразования

Рисунок 4. Формат поля "Структура преобразования"

Первый октет показывает, является ли это преобразование последним в предложении:

0 - последнее преобразование;

3 ? не последнее преобразование.

Поле "Резерв" (1 октет) устанавливается в "0" при передаче и игнорируется на приеме.

Поле "Длина преобразования" (2 октета) указывает размер "Структуры преобразования" (в октетах) с учетом заголовка и атрибутов.

Поле "Тип преобразования" (1 октет) содержит тип преобразования, задаваемого этим элементом. Если преобразование является необязательным и инициатор предлагает его пропустить, преобразования этого типа не включаются в предложение. Если инициатор желает отдать решение вопроса об использовании необязательного преобразования ответчику, он включает субструктуру этого преобразования с нулевым идентификатором (Transform ID = 0) в качестве одной из опций. Типы преобразований приведены в таблице N 3.

Таблица N 3. Типы преобразований

Название преобразования	Тип преобразования	Используется
Резерв	0
Encryption Algorithm (ENCR) ? алгоритм шифрования	1	IKE и ESP
Pseudo-random Function (PRF) ? псевдослучайная функция	2	IKE
Integrity Algorithm (INTEG) ? алгоритм защиты целостности	3	IKE, AH, опционально в ESP
Diffie-Hellman Group (D-H) ? группа Diffie-Hellman	4	IKE, опционально в AH и ESP
Extended Sequence Numbers (ESN) ? расширенные порядковые номера	5	AH и ESP
Резерв IANA	6-240
Частное применение	241-255

Поле "Идентификатор преобразования" (2 октета) содержит идентификатор конкретного преобразования указанного типа.

Число и тип преобразований в элементах SA зависит от типа протокола в самой SA. Элемент данных SA, предлагающий организацию SA, имеет обязательные и опциональные типы преобразований, которые приведены в таблице N 4.

Таблица N 4. Обязательные и опциональные типы преобразований

Протокол	Обязательные типы	Опциональные типы
IKE	ENCR, PRF, INTEG, D-H
ESP	ENCR, ESN	INTEG, D-H
AH	INTEG, ESN	D-H

Поле "Атрибуты преобразования". Каждое преобразование элемента данных SA может включать атрибуты. Атрибуты представляют собой пары "тип-значение" и приведены в таблице N 5.

Таблица N 5. Типы и значения атрибутов

Тип атрибута	Значение атрибута	Формат атрибута
Резерв	0-13
Размер ключа шифрования переменного размера (Key Length) (в битах)	14	тип/значение
Резерв	15-17
Резерв IANA	18-16383
Для частного применения	16384-32767

Значение атрибута может иметь фиксированную (2 октета) или переменную длину. В последнем случае для представления атрибута используется формат "тип-размер-значение". Формат поля "Атрибута преобразования" приведен на рисунке 5.

Тип атрибута	Длина атрибута (значение)
Значение атрибута

Рисунок.5 Формат поля "Атрибут преобразования"

Поле "Тип атрибута" (2 октета) содержит идентификатор атрибута. Старший бит этого поля является флагом формата атрибута (AF), при AF=0, для атрибута используется полный формат атрибута (тип/размер/значение), при AF=1 используется сокращенный формат атрибута (тип/значение).

Поле "Длина атрибута (значение)" (2 октета). При AF=1 поле содержит значение атрибута, а при AF=0 в поле указывается размер атрибута, который содержится ниже в поле "Значение атрибута" (переменная длина).

2.4. Элемент данных Обмен ключами (Key Exchange, далее ? KE).

Элемент данных KE служит для обмена открытыми номерами протокола Димффи-Хемллмана (Diffie-Hellman, далее ? DH) при обмене ключами DH.

Элемент данных KE создается путем копирования открытого значения DH в поле "Данные обмена ключами". Размер открытого значения DH должен быть равен размеру первичного модуля, для которого выполняется возведение в степень, дополненного при необходимости нулями в начале.

Поле "Номер группы DH" (2 байта) идентифицирует группу DH, в которой было рассчитано значение поля "Данные обмена ключами". Если выбранное предложение использует другую группу DH, сообщение должно быть отвергнуто с возвратом элемента "Уведомление типа INVALID_KE_PAYLOAD".

Формат элемента данных Обмен ключами приведен на рисунке 6.

Номер группы DH	Резерв
Данные обмена ключами

Рисунок 6. Формат элемента данных Обмен ключами

2.5. Элементы данных Идентификатор инициатора (IDi) и Идентификатор отвечающего (IDr).

Формат элементов данных IDi и IDr приведен на рисунке 7.

Тип идентификации	Резерв
Данные идентификатора

Рисунок 7. Формат элементов данных IDi и IDr

Поле "Тип идентификации" (1 байт) задает тип используемых идентификаторов.

Поле "Данные идентификатора" (переменной длины) содержит идентификатор, тип которого указан в предыдущем поле.

2.6. Элемент данных Сертификат обеспечивает способ передачи сертификатов или другой, связанной с идентификацией информации через IKE. Элемент данных Сертификат следует включать в обмен, если сертификат доступен отправителю до того, как партнер указал возможность получения идентификационной информации иным путем с использованием элемента Уведомление типа HTTP_CERT_LOOKUP_SUPPORTED. Формат элемента данных Сертификат приведен на рисунке 8.

Тип сертификата	Данные сертификата

Рисунок 8. Формат элемента данных Сертификат

Элемент данных Сертификат имеет следующие поля:

Поле "Тип сертификата" (1 октет) указывает способ кодирования сертификата.

Поле "Данные сертификата" (переменный размер).

Значения поля "Тип сертификата" приведены в таблице N 6.

Таблица N 6. Значения поля "Тип сертификата"

Способ кодирования сертификата	Значение Формат атрибута
Резерв	0
Сертификат X.509 с PKCS (Public Key CryptographyStandard ? криптографический стандарт открытого ключа)) N7	1
Сертификат PGP (Pretty Good Privacy)	2
Подписанный ключ DNS (Domain Name System)	3
Сертификат X.509? подпись	4
Маркер Kerberos	6
Список отозванных сертификатов CRL (Certificate Revocation List)	7
ARL	8
Сертификат простой инфраструктуры открытых ключей SPKI (Simple Public Key Infrastructure)I	9
Сертификат X.509 ? атрибут	10
Неразобранный ключ криптографического алгоритма с открытым ключом RSA	11
Хеш и URL сертификата X.509	12
Хеш и URL связки (bundle) X.509	13
Резерв IANA	14-200
Для частного применения	201-255

2.7. Элемент данных Запрос сертификата

Формат элемента данных Запрос сертификата приведен на рисунке 9.

Тип сертификата	Удостоверяющий центр

Рисунок 9. Формат элемента данных Запрос сертификата

Элемент данных Запрос сертификата имеет следующие поля:

Поле "Тип сертификата" (1 октет) указывает способ кодирования сертификата.

Поле "Удостоверяющий центр" (переменный размер).

2.8. Элемент данных Идентификация

Элемент данных Идентификация содержит данные, которые используются для идентификации

Формат элемента представлен на рисунке 10.

Метод идентификации	Резерв
Идентификационные данные

Рисунок 10. Формат элемента данных Идентификация

Элемент данных Идентификация имеет следующие поля:

Поле "Метод идентификации" (1 октет) указывает используемый метод идентификации и может принимать значения:

RSA цифровая подпись (1) ? рассчитывается с использованием приватного ключа RSA и хэш-значения PKCSN1 с заполнением.

Shared Key Message Integrity Code (2) ? рассчитывается с использованием разделяемого ключа, связанного с объектом из элемента Тип идентификации, и согласованной функции prf.

DSS (Digital Signature Standard) цифровая подпись (3) - рассчитывается с использованием закрытого ключа DSS и хэш-значения алгоритма криптографического хеширования SHA-1 (Secure Hash Algorithm).

Значение 0 и 4-200 зарезервированы IANA. Значения 201-255 выделены для частных приложений.

Поле "Идентификационные данные" (переменный размер).

2.9. Элемент данных Случайное число имеет одно поле переменного размера, содержащее случайное значение, созданное передающей стороной.

Размер элемента должен находиться в диапазоне от 16 до 256 октетов, включительно. Недопустимо повторное использование значения Случайного числа.

2.10. Элемент данных Уведомление используется для передачи служебной информации и имеет поля, приведенные на рисунке 11:

Идентификатор протокола	Размер SPI	Тип уведомления
SPI
Данные уведомления

Рисунок 11. Формат элемента данных Уведомление

Поле "Идентификатор протокола" (1 октет). Если уведомление относится к существующей SA, это поле показывает тип данной SA. Для уведомлений IKE_SA это поле должно иметь значение "1". Для уведомлений, касающихся IPsec, это поле должно содержать значение "2" для протокола AH или "3" для протокола ESP. Для уведомлений, не относящихся к существующим SA, это поле должно сбрасываться в "0" при передаче и игнорироваться на приеме. Все остальные значения зарезервированы IANA для использования в будущем.

Поле "Размер SPI" (Security Parameter Index) (1 октет) указывает размер SPI в октетах.

Поле "Тип уведомления" (2 октета) задает тип уведомления.

Поле "SPI" (переменный размер) ? идентификатор параметров защиты.

Поле "Данные уведомления" (переменный размер) ? дополнительная информация к типу уведомления.

2.11. Элемент данных Удаление содержит определяемый протоколом идентификатор защищенной связи, которую отправитель удаляет из базы данных (следовательно, связь перестает быть корректной). Формат элемента данных Удаление приведен на рисунке 12.

Идентификатор протокола	Размер SPI	Количество SPI
Индекс параметров безопасности (SPI)

Рисунок 12. Формат элемента данных Удаление

Поле "Идентификатор протокола" (1 октет) ? значение "1" для IKE_SA, значение "2" для AH, значение "3" для ESP.

Поле "Размер SPI" (1 октет) содержит размер SPI указанного протокола (в октетах).

Поле "Количество SPI" (2 октета) - количество SPI в данном элементе.

Поле "Индекс параметров безопасности" (SPI) (переменный размер) ? идентифицирует удаляемое защищенное соединение.

2.12. Элемент данных Идентификатор реализации имеет одно поле переменного размера, содержащее уникальный идентификатор производителя.

2.13. Элементы данных Селектор трафика - Инициатор, Селектор трафика - Ответчик. Формат элемента Селектор трафика приведен на рисунке 13.

Количество селекторов трафика	Резерв
Селектор(ы) трафика

Рисунок 13. Формат элемента данных Селектор трафика

Поле "Количество селекторов трафика" ? (1 октет).

Поле "Резерв" (3 октета) имеет нулевое значение при передаче и должно игнорироваться на приеме.

Поле "Селектор трафика" (переменный размер) ? один или множество индивидуальных селекторов трафика.

2.14. Элемент данных Кодирование (Encrypted), обозначаемый E, содержит другие элементы в зашифрованном виде. При наличии в сообщении элемента Кодирование он должен быть последним в сообщении. Формат элемента данных Кодирование приведен на рисунке 14.

Initialization Vector
Данные IKE
Padding (0-255 октетов)	Pad Length
Integrity Checksum Data

Рисунок 14. Формат элемента данных Кодирование

Элемент Кодирование включает базовый заголовок IKE (см. рисунок 2) и перечисленные ниже поля:

Поле "Initialization Vecto" ? случайное значение, которое совпадает с размером блока используемого алгоритма шифрования. Получатели должны воспринимать любые значения. Отправителям следует генерировать псевдослучайное значение независимо для каждого сообщения или использовать для выбора значений шифрованный блок предыдущего сообщения.

Поле "Данные IKE" переменной длины, содержит шифрованные элементы IKE. Это поле шифруется с использованием согласованного алгоритма.

Поле "Padding" может содержать любое значение, выбранное отправителем, и должно иметь размер, делающий суммарный размер шифрованных элементов, поля "Padding" и поля "Pad Length" кратным размеру блока шифрования ("Initialization Vecto". Это поле шифруется с использованием согласованного алгоритма.

Поле "Pad Length" (1 октет) указывает размер поля Padding. Отправителю следует устанавливать в поле "Pad Length" минимальное значение, которое делает размер полей шифрованных элементов "Padding" и "Pad Length" кратными размеру блока шифрования, но получатель должен принимать любые значения, обеспечивающие требуемое выравнивание. Это поле шифруется с использованием согласованного алгоритма.

Поле "Integrity Checksum Data" ? криптографическая контрольная сумма всего сообщения, начиная с фиксированного заголовка IKE и заканчивая полем "Pad Length". Контрольная сумма должна рассчитываться для зашифрованного сообщения. Размер поля определяется согласованным алгоритмом защиты целостности.

2.15. Элемент данных Конфигурация (CP) используется для обмена конфигурационными параметрами между партнерами IKE. Формат элемента данных Конфигурация приведен на рисунке 15.

Тип обмена	Резерв
Атрибуты конфигурации

Рисунок 15. Формат элемента данных Конфигурация

Элемент данных Конфигурация включает базовый заголовок IKE и перечисленные ниже поля:

Поле "Тип обмена" (1 октет) указывает тип обмена данными Конфигурации (REQUEST-1, REPLY-2, SET-3, ACK-4).

Поле "Резерв" (3 октета) устанавливается в "0" при передаче и игнорируется на приеме.

Поле "Атрибуты конфигурации" (переменные размер) ? атрибуты конфигурации в формате "тип-размер-значение". В элементе данных Конфигурация может содержаться множество (в том числе, пустое) атрибутов.

2.16. Элемент данных Расширяемая идентификация (EAP) позволяет выполнять идентификацию IKE_SA с использованием протокола EAP. Формат элемент данных EAP приведен на рисунке 16.

Код	Идентификатор	Длина
Тип	Данные

Рисунок 16. Формат Элемент данных EAP

Поле "Код" (1 октет) показывает, является это сообщение запросом (Request - 1), откликом (Response - 2), успешным завершением (Success - 3) или отказом (Failure - 4).

Поле "Идентификатор" (1 октет) используется в протоколе PPP, чтобы отличить повторное использование сообщений от повторной передачи. В откликах этот октет должен устанавливаться равным значению идентификатора в соответствующем запросе. В остальных сообщениях это поле может принимать любое значение.

Поле "Длина" (2 октета) показывает размер сообщения EAP и должно иметь значение в 4 раза меньше значения поля "Размер текущего элемента (Payload Lenqth) базового заголовка" (см. рисунок 2).

Поле "Тип" (1 октет) присутствует только в сообщениях с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должен составлять четыре октета, а поля "Тип" и "Данные" должны отсутствовать. В запросах (1) поле "Тип" указывает запрашиваемые данные, а в откликах (2) поле "Тип" должно быть пустым или соответствовать типу запрошенных данных. Определены следующие значения поля "Тип":

1 ? тождественность;

2 ? уведомление;

3 ? только отклики;

4?MD5 - вызов;

5 ? однократный пароль;

6 ? маркерная карта базового типа.

Поле "Данные" (переменный размер) зависит от типа запроса и связанного с ним отклика.".

21) дополнить приложением N 19 следующего содержания:

"Приложение N 19

Требования к параметрам протокола IPSec

1. Требования к идентификационному заголовку AH.

1.1. Идентификационный заголовок протокола IPSec (AH) используется для обеспечения целостности дейтаграмм IP и идентификации источника данных без организации специальных соединений и защиты против повторного использования пакетов. AH может использоваться в комбинации с ESP или путем вложения. Услуги по защите могут обеспечиваться между парой взаимодействующих элементов сети IP.

1.2. Формат заголовка идентификации AH приведен на рисунке 1.

Следующий заголовок	Длина заголовка	Резерв
Идентификатор параметров защиты (SPI)
Порядковый номер
Аутентификационные данные (Значение контрольной суммы (ICV)) (перемен.)

Рисунок 1.Формат заголовка идентификации AH

Поле "Следующий заголовок" (1 октет) показывает тип информации, расположенной после идентификационного заголовка AH. Значения этого поля выбираются из списка номеров протоколов, предоставленного Администрацией адресного пространства Интернет IANA.

Поле "Длина заголовка" (1 октет) указывает размер заголовка AH в 32-битовых словах (4-байтовых блоках) минус 2.

Поле "Резерв" (2 октета) зарезервировано для использования в будущем. Отправитель должен устанавливать для этого поля нулевое значение, а получателю следует игнорировать значение этого поля. Значение этого поля учитывается при вычислении ICV, но игнорируется получателем.

Поле "Идентификатор параметров защиты" (SPI) представляет собой произвольное 32-битовое значение, используемое получателем для идентификации SA, с которой связан входящий пакет. Для индивидуальных SA значение SPI может само по себе идентифицировать SA или использоваться в комбинации с типом протокола IPsec (в данном случае AH). Поле SPI является обязательным и механизм отображения входящего трафика на индивидуальные SA должен поддерживаться всеми реализациями AH.

Поле "Порядковый номер" (4 октета) содержит значение счетчика пакетов, которое увеличивается на "1" для каждого переданного пакета (счетчик пакетов для SA). Это поле является обязательным и должно присутствовать даже в тех случаях, когда получатель не пользуется услугами по предотвращению повторного использования пакетов для конкретной SA. Отправитель должен передавать это поле, но получатель не обязан принимать его во внимание. Счетчики на стороне отправителя и получателя инициализируются нулевым значением при создании SA (первый пакет, переданный с использованием данной SA будет иметь порядковый номер ? 1). Если предотвращение повторного использования пакетов включено (используется по умолчанию), передаваемые порядковые номера никогда не должны повторяться. Расширенный порядковый номер позволяет использовать для SA 64-битовые порядковые номера. В заголовке AH каждого пакета передаются только младшие 32 бита расширенного порядкового номера, а старшие 32 бита учитываются, как часть порядкового номера, отправителем и получателем и включаются в расчет ICV, но не передаются.

Поле "Аутентификационные данные" содержит значение контрольной суммы ICV для данного пакета. Размер поля должен быть кратным 32 битам как для IPv4, так и для IPv6. Это поле может включать явное заполнение для обеспечения кратности размера заголовка AH в целом 32 (IPv4) или 64 (IPv6) битам. Заполнение должны поддерживать все реализации и размер заполнения должен быть минимально достаточным для выравнивания заголовков в соответствии с требованиями IPv4/IPv6.

1.3. Местонахождение заголовка AH.

AH может работать в двух режимах: транспортном и туннельном.

1.3.1. В транспортном режиме AH помещается между заголовком протокола IP и заголовком протокола транспортного уровня или перед другими заголовками IPsec, если они имеются. Местонахождение заголовка AH в транспортном режиме приведен на рисунке 2.

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

Заголовок исходного IP пакета	Заголовок AH	Заголовок TCP (UDP)	Данные

Рисунок 2. Местонахождение заголовка AH в транспортном режиме

1.3.2. В туннельном режиме заголовок AH защищает исходный IP пакет целиком (включая его заголовок). Местонахождение заголовка AH в туннельном режиме приведено на рисунке 3.

Заголовок внешнего IP пакета	Заголовок AH	Заголовок исходного IP пакета	Заголовок TCP (UDP)	Данные

Рисунок 3. Местонахождение заголовка AH в туннельном режиме

2. Требования к протоколу ESP.

2.1. ESP (IP Encapsulating Security Payload) служит для обеспечения целостности и конфиденциальности данных путем их шифрования. В зависимости от пользовательских требований к безопасности этот механизм может применяться для шифрования пакетов транспортного уровня (например, TCP, UDP, ICMP, IGMP) или дейтаграмм IP полностью. В протоколе ESP функции аутентификации и криптографической защиты могут быть задействованы либо вместе, либо отдельно друг от друга.

2.2. Формат заголовка ESP. ESP может содержаться в любом месте между заголовком IP и конечным протоколом транспортного уровня. Для протокола ESP используется идентификатор IANA 50. Заголовок, расположенный непосредственно перед заголовком ESP, всегда будет содержать значение "50" в поле "Следующий заголовок" для IPv6 или "Протокол" для IPv4. ESP состоит из нешифрованного заголовка, за которым следуют зашифрованные данные. Шифруемые данные включают в себя защищенные поля заголовка ESP и защищаемые пользовательские данные: дейтаграмму IP или пакет протокола вышележащего уровня. Формат заголовка ESP приведен на рисунке 4.

Идентификатор параметров защиты (SPI)
Порядковый номер
Данные (перемен.)
Данные (перемен.)	Заполнитель
Заполнитель	Длина заполнителя	Следующий заголовок
Аутентификационные данные (перемен.)

Рисунок 4. Формат заголовка идентификации ESP

2.3. Местонахождение заголовка ESP. ESP может работать в двух режимах: транспортном и туннельном.

2.3.1. В транспортном режиме зашифрованные данные транспортируются непосредственно между хостами. В транспортном режиме протокола ESP заголовок исходного IP-пакета остается внешним. Заголовок ESP помещается в передаваемый пакет между заголовками протоколов третьего и четвертого уровней.

Шифрованию подвергаются только данные исходного IP-пакета и заключительная часть ESP заголовка. В этом режиме ESP не шифрует заголовок IP-пакета, поля "SPI" и "Порядковый номер".

2.3.2. Функции туннельного режима реализуются в шлюзах безопасности.

В туннельном режиме в качестве внешнего заголовка создается новый заголовок IP. ESP заголовок помещается перед заголовком исходного IP-пакета. Весь исходный IP-пакет и заключительная часть заголовка ESP шифруются. Заголовок внешнего IP-пакета протоколом ESP не защищается.".

22) дополнить приложением N 20 следующего содержания:

"Приложение N 20

Требования к параметрам протокола Diameter на интерфейсах S6b, SWx, SWm, STa, SWd, SWa

1. Сообщения протокола Diameter на интерфейсе S6b определены идентификатором приложения (далее ? Auth-Application-Id) равным "16777272" и приведены в таблице N 1.

Таблица N 1. Сообщения протокола Diameter, передаваемые

на интерфейсе S6b

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от P-GW к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к P-GW
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от P-GW к 3GPP AAA серверу
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к P-GW
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от P-GW к 3GPP AAA серверу или от 3GPP AAA сервера к P-GW
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к P-GW или от P-GW к 3GPP AAA серверу
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера к P-GW
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от P-GW к 3GPP AAA серверу
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к P-GW
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от P-GW к 3GPP AAA серверу/прокси

2. Сообщения протокола Diameter на интерфейсе Wx определены Auth-Application-Id равным "16777265" и приведены в таблице N 2.

Таблица N 2. Сообщения протокола Diameter, передаваемые на интерфейсе SWx

Сообщение	Код сообщения	Направление передачи
Аутентификация при мультимедийной сессии. Запрос. (Multimedia-Authentication-Request (MAR))	303, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера к HSS
Аутентификация при мультимедийной сессии. Ответ (Multimedia-Authentication-Answer (MAA))	303, бит R в поле команды "Флаг" очищен	от HSS к 3GPP AAA серверу
Обновление профилей. Запрос.( Push-Profile-Request (PPR))	305, бит R в поле команды "Флаг" установлен в "1"	от HSS к 3GPP AAA серверу
Обновление профилей. Ответ.( Push-Profile-Answer (PPA))	305, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к HSS
Регистрация сервера сервера. Запрос.(Server-Assignment-Request (SAR))	301, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера к HSS
Регистрация сервера. Ответ. (Server-Assignment-Answer (SAA))	301, бит R в поле команды "Флаг" очищен	от HSS к 3GPP AAA серверу
Окончание регистрации. Запрос. (Registration-Termination-Request (RTR)_	304, бит R в поле команды "Флаг" установлен в "1"	от HSS к 3GPP AAA серверу или от 3GPP AAA сервера к HSS
Окончание регистрации. Ответ (Registration-Termination-Answer (RTA))	304, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к HSS или от HSS к 3GPP AAA серверу

3. Сообщения протокола Diameter на интерфейсе SWm определены Auth-Application-Id равным "16777264" и приведены в таблице N 3.

Таблица N 3. Сообщения протокола Diameter, передаваемые

на интерфейсе SWm

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от ePDG к 3GPP AAA серверу/прокси
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к ePDG
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от ePDG к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к ePDG
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от ePDG к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к ePDG
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к ePDG
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от ePDG к 3GPP AAA серверу/прокси
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к ePDG
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от ePDG к 3GPP AAA серверу/прокси

4. Сообщения протокола Diameter на интерфейсе STa определены Auth-Application-Id равным "16777250" и приведены в таблице N4.

Таблица N 4. Сообщения протокола Diameter, передаваемые на интерфейсе STa

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к TWAN
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к TWAN
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от TWAN к 3GPP AAA серверу/прокси
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к TWAN
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к TWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от TWAN к 3GPP AAA серверу/прокси
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к TWAN

5. Сообщения протокола Diameter на интерфейсе SWa определены Auth-Application-Id равным "16777250" и приведены в таблице N 5.

Таблица N 5. Сообщения протокола Diameter, передаваемые на интерфейсе SWa

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к UTWAN
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к UTWAN
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси

6. На интерфейсе SWd транслируются сообщения протокола Diameter с интерфейсов S6b, SWm, STa, приведенные в таблицах NN1, 3, 4 соответственно.".

23) дополнить приложением N 21 следующего содержания:

"Приложение N 21

Требования к данным, хранящимся в HSS, MME, S-GW, P-GW, ePDG, 3GPP AAA сервере, 3GPP AAA прокси, необходимым при реализации non-3GPP доступа

Данные, хранящиеся в HSS, MME, S-GW, P-GW, ePDG, 3GPP AAA сервере, 3GPP AAA прокси, необходимые для реализации non-3GPP доступа, приведены в таблице.

Таблица. Данные HSS, MME, S-GW, P-GW, ePDG, 3GPP AAA сервере, 3GPP AAA прокси, необходимые для реализации non-3GPP доступа

Параметр	HSS	MME	S-GW	P-GW	ePDG	3GPP AAA сервер	Тип пар.
Международный идентификатор MS (IMSI)	О	У	У	У	У		П
Международный номер MS в сети ISDN (MSISDN)	У	У	У	У	У	У	П
Параметры для аутентификации в сети UMTS (RAND, XRES, CK, IK, AUTN)	О					О	В
Параметры для аутентификации в сети LTE (RAND, XRES, KASME, AUTN)	О					О	В
Режим доступа к сети (Network Access Mode)	У					У	В
Подробное описание трейса 2 (Trace Reference 2)	У			У		У	П
Уровень глубины трейса (Trace depth)	У			У		У	П
Список сетевых элементов, в которых проводится сбор трейсов (List of NE types to trace)	У					У	П
Параметры, указываемые в трейсах (Triggering events)	У			У		У	П
Перечень интерфейсов сетевых элементов для которых формируются трейсы (List of interfaces to trace)	У			У		У	П
IP адреса для которых формируются трейсы (IP address of Trace Collection Entity)	У			У		У	П
Профили имен точек доступа (APN-Configuration-Profile)	О			У	У	У	В
Указанная в подписке общая максимальная скорость передачи для точки доступа (Subscribed APN-AMBR)	О			У	У	У	П
Используемая максимальная скорость передачи для точки доступа (Used APN-AMBR)				У			В
Адрес сети передачи данных (PDN Address)	У		У	У	У	У	П/В
Разрешенный адрес визитной сети радиотелефонной связи (VPLMN Address Allowed)	О	У			У	У	П
Идентификатор PDN GW (PDN GW identity)	О	У			У	У	П
Используемая точка доступа (APN in Use)				У	У		В
Идентификатор EPS (EPS Bearer ID)				У	У		В
Качество обслуживания EPS (EPS Bearer QoS)				У	У		В
Характеристики учета стоимости соединения EPS PDN (EPS PDN Connection Charging Characteristics)	У			У	У	У	П
Тип технологии радиодоступа (RAT type)	У		У	У	У	У	В
Постоянный идентификатор пользователя (Permanent user identity)	О		О	О	О	О	П
Возможности мобильности при доступе не 3GPP (Mobility Capabilities)				O	У	У	В
IP адрес шлюза MAG (MAG IP address)						У	В
Идентификатор визитной сети (Visited Network Identifier)	У			У	У	У	В
Данные для аутентификации EAP (EAP payload)						У	В
Данные об используемом протоколе мобильности (MIP Subscriber profile)	О			О			П
Ключ GRE для восходящего направления интерфейса S5 (Uplink S5 GRE Key)		У	У	У			В
Ключ GRE для нисходящего направления интерфейса S5 (Downlink S5 GRE Key)			У	У			В
Ключ GRE для восходящего направления интерфейса S8 (Uplink S8 GRE Key)		У	У	У			В
Ключ GRE для нисходящего направления интерфейса S8 (Downlink S8 GRE Key)			У	У			В
Ключи GRE интерфейса S2a (S2a GRE Keys)			У	У	У		В
Ключи GRE интерфейса S2b (S2b GRE Keys)			У	У	У		В
Идентификатор мобильного узла (Mobile Node Identifier)			У	У			В
Адрес маршрутизатора по умолчанию формата IPv4 (IPv4 Default Router Address)			У	У			В
Локальный адрес линка (Link-local address)			У	У			В
Данные пользователя не 3GPP (Non 3GPP User Data)	У				У	У	В
Идентификатор 3GPP AAA Сервера (3GPP AAA Server Identity)	У			У	У		В
Выбор режима поддержки мобильности (Selected IP mobility mode)				У	У	У	В
Идентификатор сервера Diameter для HSS (Diameter Server Identity of HSS)		У				У	В
Неаутентифицированный IMSI (Unauthenticated IMSI)			У	У			В
Идентификатор соединения PDN (PDN Connection ID)			У	У	У		В
Идентификатор конечной точки туннеля ePDG F для S2b(плоскость управления) (ePDG F-TEID for S2b (control plane))				У	У		В
Идентификатор конечной точки туннеля ePDG F для S2b(плоскость пользователя) ePDG F-TEID for S2b (user plane)				У	У		В
Идентификатор конечной точки туннеля PGW F для S2b(плоскость управления) (PGW F-TEID for S2b (control plane))				У	У		В
Идентификатор конечной точки туннеля PGW F для S2b(плоскость пользователя) (PGW F-TEID for S2b (user plane))				У	У		В
Параметры тарификации пользователя (Subscribed Charging Characteristics)	О				У	У	П
Мастер ключ сессии) (Master session Key				У	У	У	В
Примечание: В ? временные данные, О ? обязательные данные, У ? данные по условию, П ? постоянные данные.

24) дополнить приложением N 22 следующего содержания:

"Приложение N 22

Требования к протоколам EAP-AKA, EAP-AKA′

Протоколы пользуются услугами протоколов канального уровня.

2. Требования к протоколу EAP-AKA:

2.1. Формат пакетов EAP-AKA.

На рисунке 1 приведен формат пакетов EAP.

Код	Идентификатор	Длина
Данные

Рисунок 1. Формат пакетов EAP

Поле "Код" (1 октет) показывает тип пакета EAP и может принимать значения:

1 - запрос (Request);

2 - ответ (Response);

3 - подтверждение (Success);

4 - отказ (Failure).

Пакеты EAP с другими значениями кода отбрасываются обеими сторонами без уведомления.

Поле "Идентификатор" (1 октет) обеспечивает соответствие вопросов и ответов на них.

Поле "Данные" имеет размер ноль или более октетов. Формат поля зависит от типа пакета (значения поля "Код").

2.2. Пакеты EAP Request, Response для аутентификации и согласования ключей с помощью USIM (далее - AKA) приведены на рисунке 2.

Код	Идентификатор	Длина
Тип (23)	Подтип	Резерв
Тип атрибута	Длина атрибута	Значение (2 и более байтов)

Рисунок 2. Формат пакетов EAP Request, Response для AKA

Для пакетов Request и Response поле "Данные" начинается с поля "Тип" (1 октет), которое содержит тип запрашиваемой информации. Пакеты Request должны передаваться, пока не будет получен корректный отклик, не завершится отсчет числа попыток или нижележащий уровень не сообщит об отказе. Повторные запросы должны передаваться с тем же значением поля "Идентификатор", чтобы их можно было отличить от новых запросов. Содержимое поля "Данные" зависит от "Типа" запроса. Пакеты Response передаются в ответ на корректный запрос.

Для пакетов EAP-AKA поле "Тип" устанавливается равным "23".

За полем "Резерв" в поле "Данные" следуют "Атрибуты" в формате: тип-длина-значение.

2.3. Пакет EAP-Request/AKA-Identity (подтип-5) ? запрос идентификационной информации.

Для пользователя сети стандартов GSM900/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.6. Пакет EAP-Response/AKA-Challenge содержит отклик пользователя и включает атрибуты AT_MAC и AT_RES.

2.8. Пакет EAP-Response/AKA-Synchronization-Failure (подтип-4) передается при ошибке в порядковом номере AUTN и включает атрибут AT_AUTS.

2.10. Пакет EAP-Response/AKA-Reauthentication передается в ответ на запрос AKA-Reauthentication и включает атрибуты AT_MAC, AT_IV и AT_ENCR_DATA.

2.11. Пакет EAP-Response/AKA-Client-Error (подтип-14) передается, когда пользователь обнаруживает ошибку в пакете EAP /AKA, и содержит атрибут AT_CLIENT_ERROR_CODE.

2.13. Пакет EAP-Response/AKA-Notification передается в ответ на EAP-Request/AKA-Notification и включает атрибуты AT_ENCR_DATA и AT_IV.

2.14. Генерация ключа осуществляется с использованием функции SHA-1.

3. Требования к протоколу EAP-AKA′ соответствуют требованиям к EAP-AKA за исключением:

3.1. Для пакетов EAP-AKA′ поле "Тип" устанавливается равным "50".

3.2. Используются новые атрибуты AT_KDF, AT_KDF_INPUT.

3.3. Генерация ключа осуществляется с использованием функции SHA-256.".

25) дополнить приложением N 23 следующего содержания:

"Приложение N 23

Справочно

Список используемых сокращений

1. 3GPP ? 3rd Generation Partnership Project (консорциум, разрабатывающий спецификации для сетей радиотелефонной связи).

2. AAA ? Authentication, Authorization и Accounting (аутентификация, проверка полномочий, учет).

3. AH ? Authentication Header (аутентификационный заголовок для протокола IP).

4. ANID ? Access Network Identity (идентификатор сети доступа).

5. APN ? Access Point Name (идентификатора точки доступа к PDN).

6. ARP ? Allocation and Retention Priority (назначение и сохранение приоритета).

7. AUTN ? Authentication Token (символ аутентификации).

8. CoA ? Care-of Аddress (адрес, назначаемый в момент регистрации пользователя в сети).

9. CN ? Core Network (базовая сеть).

10. DHCP ? Dynamic Host Configuration Protocol ( протокол динамической настройки узла).

11. DSMIP ? Dual-Stack Mobile IPv6 (двух стековый протокол IPv6 по обеспечению мобильности).

12. DPXA ? Diameter Proxy Agents (функция прокси протокола Diameter).

13. DRDA ? Diameter Redirect Agents (функция перенаправления протокола Diameter).

14. DRLA ? Diameter Relay Agents (функция переключения протокола Diameter).

15. EAP-AKA ? Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement (расширяемый протокол Аутентификации для аутентификации и согласования ключей пользователей UMTS).

16. EIR ? Equipment Identity Register (регистр идентификации оборудования).

17. eNodeB ? Evolved NodeB (базовые станции стандарта LTE и LTE-Advanced).

18. ECM ? EPS Connection Management (управление соединением в EPS).

19. ECM-CONNECTED ? EPS Connection Management-CONNECTED (состояние процесса управления соединением для "абонентская радиостанция - соединение").

20. ECM-IDLE ? EPS Connection Management-IDLE (исходное состояние процесса управления соединением для AC в EPS).

21. EMM ? EPS Mobility Management (управление мобильностью в EPS).

22. EMM-DEREGISTERED ? EPS Mobility Management-DEREGISTERED (состояние процесса управления мобильностью для AC в EPS ? не зарегистрирована).

23. ЕРС ? Evolved Packet Core (базовая сеть стандартов LTE и LTE-Advanced).

24. ePDG ? Evolved Packet Data Gateway (оборудование, реализующее функции доступа к оборудованию коммутации стандарта LTE из сети Интернет при использовании доступа UTWAN).

25. EPS ? Evolved Packet System (сеть радиодоступа и базовая сеть стандартов LTE и LTE-Advanced).

26. ESP ? Encapsulating Security Payload (протокол защиты (шифрования) данных).

27. E-UTRAN ? Evolved UTRAN (сеть радиодоступа стандартов LTE и LTE-Advanced).

28. FA ? Foreign Agent (агент визитной сети).

29. FACoA ? Foreign Agent Care-of Address (адрес агента визитной сети).

30. GBR ? Guaranteed Bit Rate (гарантированная скорость передачи данных).

31. GRE ? Generic Routing Encapsulation (общая инкапсуляция маршрутов).

32. GSM ? Global System for Mobility (глобальная система мобильной связи).

33. GTP ? GPRS Tunnelling Protocol (протокол туннелирования GPRS).

34. HA ? Home Agent (агент домашней сети сети).

35. HBM ?Host Based Mobility (управление мобильностью на базе хостов).

36. HLR ? Home Location Register (домашний регистр местонахождения).

37. HMAC ? hash-based message authentication code (код аутентификации сообщений, использующий хеш-функции).

38. HPLMN ? Home Public Land Mobile Network (сеть Оператора мобильной связи, в которой абонент подписан на оказание услуг мобильной связи).

39. HSS ? Home Subscriber Server (сервер абонентских данных).

40. ICMP ? Internet Control Message Protocol (протокол управляющих сообщений в Интернет).

41. IKEv2 ? Internet Key Exchange version 2(Протокол обмена ключами в Интернет версия 2).

42. IMEI ? International Mobile Equipment Identity (международный идентификатор оборудования абонентской радиостанции).

43. IMEISV ? International Mobile Equipment Identity and Software Version (международный идентификатор оборудования и номер версии программного обеспечения оборудования абонентской радиостанции).

44. IMSI ? International Mobile Subscriber Identity (международный номер абонентской станции).

45. IP ? Internet Protocol (протокол Интернет).

46. IPSec ? Internet Protocol Security (протокол Интернет c поддержкой функций безопасности)

47. KDF ? key derivation function (функция формирования ключа).

48. LIPA ? Local IP Access (местный IP доступ).

49. LMA ? Local Mobility Anchor (локальный узел управления мобильностью).

50. LTE ? Long-Term Evolution (эволюция на длительный период).

51. LTE-Advanced ? (развитие стандарта LTE).

52. MAG ? Mobile Access Gateway (шлюз мобильного доступа).

53. MBR ? Maximum Bit Rate (максимальная скорость передачи).

54. MCM ? Multi-connection mode (режим нескольких соединений).

55. MD5 ? Message Digest 5 (128-битный алгоритм хеширования).

56. MIPv4 ? Mobile IP version 4 (расширение функциональности протокола IPv4 по обеспечению мобильности).

57. MME ? Mobility Management Entity (модуль управления мобильностью).

58. MSISDN ? Mobile Subscriber ISDN Number (международный номер AC в сети ISDN).

59. NAI ? Network Access Identifier (идентификатор доступа к сети).

60. NAS protocol ? Non-Access-Stratum protocol (протокол слоя без доступа).

61. NBM ? Network Based Mobility (управление мобильностью на базе сети).

62. NDP ? Neighbor Discovery Protocol (протокол обнаружения соседей).

63. Non-3GPP ? сеть радиодоступа, отличная от стандартов GSM 900/1800, UMTS, LTE, использующая передачу данных в диапазоне от 30 МГц до 66 ГГц

64. P-GW ? Packet Data Networks Gateway (шлюз взаимодействия с сетями, использующими технологию с коммутацией пакетов).

65. PCRF ? The Policy and Charging Rules Function (функция правил политики

66. PDN ? Packet Data Network (сеть передачи данных).

67. PMIPv6 ? Proxy Mobile IP version 6 (расширение функциональности протокола IPv6 по обеспечению сетевой мобильности).

68. PPP ? Point-to-Point Protocol (протокол канала связи с непосредственным соединением).

69. PRF ? PSEUDO_RANDOM_FUNCTION (псевдо случайная функция)

70. QCI ? QoS Class Identifier (идентификатор класса качества обслуживания).

71. QoS ? Quality of Service (качество обслуживания).

72. RADIUS ? Remote Authentication in Dial-In User Service (протокол для аутентификации, авторизации удаленных пользователей).

73. S1-AP ? S1 Application Protocol (прикладной протокол для интерфейса S1).

74. SCM ? Single-connection mode (режим одного соединения).

75. SCTP ? Stream Control Transmission Protocol (протокол передачи с управлением потоками).

76. SGSN ? Serving GPRS Support Node (обслуживающий узел поддержки GPRS).

77. SGsAP ? SGs Application Part (прикладной протокол для интерфейса SGs).

78. S-GW ? Serving Gateway (обслуживающий шлюз).

79. SHA ? Secure Hash Algorithm (алгоритм криптографического хеширования).

80. SIPTO ? Selected IP Traffic Offload (возможность распределения трафика IP).

81. SRVCC ? Single Radio Voice Call Continuity (отдельная непрерывность голосового вызова на радиоинтерфейсе).

82. TCP ? Transmission Control Protocol (протокол управления передачей).

83. TEID ? Tunnel Endpoint Identifier (идентификатор конечной точки туннеля).

84. TLV ? Tag-length-value ("тип-длина-значение", метод записи данных в телекоммуникационных протоколах).

85. ТMAG ? Trusted Mobile Access Gateway (шлюз мобильного доступа).

86. TMSI ? Temporary Mobile Subscriber Identity (временный идентификатор мобильного абонента).

87. TSCM ? Transparent single-connection mode (режим одного прозрачного соединения).

88. TWAG ? TWAN Access Gateway (шлюз сети TWAN).

89. TWAN ? trusted WLAN (доверенный беспроводный доступ).

90. UDP ? User Datagram Protocol (протокол передачи дейтаграмм пользователя).

91. UE ? User Equipment (радиотелефонная станция стандартов GSM900/1800/UMTS/LTE, поддерживающая стандарт беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц).

92. UMTS ? Universal Mobile Telecommunications System (универсальная система мобильной связи)

93. USIM ? Universal Subscriber Identity Module (универсальный модуль идентификации абонента; карта мобильного пользователя для работы в сети UMTS).

94. UTRAN ? Universal Terrestrial Radio Access Network (сеть радиодоступа стандарта UMTS).

95. UTWAN ? Untrusted WLAN (ненадежный беспроводный доступ).

96. VPLMN ? Visited Public Land Mobile Network (гостевая сеть мобильной связи, в которой в настоящий момент обслуживается абонент).

97. WLAN - Wireless Local Area Network (локальная сеть, построенная на основе беспроводных технологий).

98. WLAN AN ? WLAN Access Network (сеть беспроводного абонентского доступа).".

_____________

Обзор документа

Предложены требования к оборудованию радиодоступа для беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц и к оборудованию коммутации стандарта LTE при их использовании на сети связи общего пользования.

Это позволит внедрить на сети связи общего пользования средства связи, работающие по технологии WiFiCalling.

Для просмотра актуального текста документа и получения полной информации о вступлении в силу, изменениях и порядке применения документа, воспользуйтесь поиском в Интернет-версии системы ГАРАНТ:

Перепечатка