В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения )
|
Протокол управления пересылкой пакетов ( PFCP ) — это протокол 3GPP , используемый на интерфейсе Sx/N4 между плоскостью управления и функцией плоскости пользователя, указанный в TS 29.244. [1] Это один из основных протоколов, представленных в базовой мобильной сети 5G следующего поколения (также известной как 5GC [2] ), но также используемый в EPC 4G/LTE для реализации разделения плоскости управления и плоскости пользователя (CUPS). [3] PFCP и связанные с ним интерфейсы стремятся формализовать взаимодействия между различными типами функциональных элементов, используемых в базовых мобильных сетях, которые развернуты большинством операторов, предоставляющих услуги 4G, а также 5G мобильным абонентам. Этими двумя типами компонентов являются:
Область применения PFCP аналогична области применения OpenFlow , однако он был разработан для обслуживания конкретного варианта использования мобильных базовых сетей .
PFCP также используется в интерфейсе между функциями плоскости управления и плоскости пользователя дезагрегированного BNG , как определено форумом BroadBand в TR-459.
Хотя PFCP похож на GTP по концепциям и реализации, он дополняет его. Он предоставляет средства управления для сигнального компонента Control-Plane для управления обработкой и пересылкой пакетов, выполняемых компонентом User-Plane. Типичные шлюзы EPC или 5G Packet Gateways разделены протоколом на две функциональные части, что обеспечивает более естественную эволюцию и масштабируемость.
Протокол PFCP используется на следующих основных мобильных интерфейсах 3GPP :
Примечание: Sxa и Sxb можно объединить в случае реализации объединенного SGW/PGW.
Функциональный элемент Control-Plane (например, PGW-C, SMF) управляет обработкой и пересылкой пакетов в функциональных элементах User-Plane (например, PGW-U, UPF) путем установления, изменения или удаления сеансов PFCP.
Пакеты плоскости пользователя должны пересылаться между функциями CP и UP путем инкапсуляции пакетов плоскости пользователя с использованием инкапсуляции GTP-U (см. 3GPP TS 29.281 [3]). Для пересылки данных из функции UP в функцию CP функция CP должна предоставить правила обнаружения пакетов (PDR) для каждого контекста сеанса PFCP с информацией об обнаружении пакетов (PDI), идентифицирующей трафик плоскости пользователя для пересылки в функцию CP, и с правилом действия пересылки (FAR), установленным с интерфейсом назначения "сторона функции CP" и настроенным на выполнение инкапсуляции GTP-U и пересылку пакетов в F-TEID GTP-u, уникально назначенный в функции CP для каждого сеанса PFCP и PDR. Затем функция CP должна идентифицировать соединение PDN и носитель, к которому относятся пересылаемые данные, с помощью полностью определенного TEID (F-TEID) в заголовке инкапсулирующего пакета GTP-U. Для пересылки данных из функции CP в функцию UP функция CP должна предоставить один или несколько PDR на контекст сеанса PFCP с PDI, установленным с исходным интерфейсом "сторона функции CP" и идентифицирующим GTP-u F-TEID, уникально назначенным в функции UP для каждого PDR, и с FAR, установленным для выполнения декапсуляции GTP-U и пересылки пакетов в предполагаемое место назначения. URR и QER также могут быть настроены.
За один сеанс отправляется несколько PDR, FAR, правил обеспечения качества обслуживания (QER), правил отчетности об использовании (URR) и/или правил действий буферизации (BAR).
Вот основные используемые концепции, организованные в логическую ассоциативную модель:
Смещение бит/байт | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Байты 0..3 | Версия (1) | (запасные нули) | ФО | МП | С | Тип сообщения | Длина сообщения (в байтах, не включая первые 4) | |||||||||||||||||||||||||
Байты 4..11 | если (установлен флаг S), то SEID; в противном случае эти байты отсутствуют | |||||||||||||||||||||||||||||||
Байты 8..11 | ||||||||||||||||||||||||||||||||
Байты 4..7 или 12..15 | Порядковый номер | если (установлен флаг MP) то Сообщение Приоритет; иначе (запасные нули) | (запасные нули) | |||||||||||||||||||||||||||||
Байты 8..(MsgLen+4) или 16..(MsgLen+4) | Ноль или более информационных элементов |
Смещение бит/байт | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Байты 0..3 | Тип | Длина IE (в байтах, не включая первые 4) | ||||||||||||||||||||||||||||||
Байты 4..IELen+4 | если (Тип >= 32768), то Enterprise-ID; в противном случае это часть полезной нагрузки | Полезная нагрузка (продолжение) ... | ||||||||||||||||||||||||||||||
Полезная нагрузка продолжается... |
IE определяются либо как имеющие собственную кодировку, либо как сгруппированные. Сгруппированные IE — это просто список других IE, закодированных один за другим, как в полезной нагрузке сообщения PFCP.
Типы IE 0..32767 являются специфическими для 3GPP и не имеют набора Enterprise-ID. Типы IE 32768..65535 могут использоваться пользовательской реализацией, а Enterprise-ID должен быть установлен на частные корпоративные коды IANA SMI Network Management [4] стороны-эмитента.
Тип сообщения | Сообщение | Применимость интерфейса | Направление | Цель | |||||
---|---|---|---|---|---|---|---|---|---|
Запрос | Ответ | Скса | Sxb | Sxc | Н4 | Запрос | Ответ | ||
0 | (Сдержанный) | ||||||||
(1..49) | Сообщения, связанные с узлом | ||||||||
1 | 2 | Сердцебиение | Х | Х | Х | Х | КП ↔ ВВЕРХ | Может быть опционально использован между пирами связи, которые имеют установленную ассоциацию, чтобы проверить, жив ли другой узел. Метка времени восстановления используется для определения того, был ли перезапущен другой пир. | |
3 | 4 | Управление ПФД | - | Х | Х | Х | КП → ВВЕРХ | ВВЕРХ → КП | Дополнительная функция для предоставления PFD по идентификатору приложения вне обычных сеансов PFCP. |
5 | 6 | Создание ассоциации | Х | Х | Х | Х | КП ↔ ВВЕРХ | Настройка и обновление ассоциации между функциональными элементами CP и UP. Включает список дополнительных функций для информирования других элементов о возможностях; также передаются другие элементы конфигурации. Перед этой процедурой не следует обмениваться никакими сообщениями, связанными с сеансом. В то время как Association-Release инициируется только CP, UP может запросить его как часть Association-Update-Request. | |
7 | 8 | Обновление Ассоциации | Х | Х | Х | Х | КП ↔ ВВЕРХ | ||
9 | 10 | Ассоциация Выпуск | Х | Х | Х | Х | КП → ВВЕРХ | ВВЕРХ → КП | |
- | 11 | Версия не поддерживается | Х | Х | Х | Х | КП ↔ ВВЕРХ | Ошибка ответа на все запросы, которые не охватывают реализованные версии (в настоящее время определена только версия 1). | |
12 | 13 | Отчет узла | Х | Х | Х | Х | ВВЕРХ → КП | КП → ВВЕРХ | Отправляется функцией UP для сообщения информации, которая не является частью сеанса, но потенциально носит общий характер (например, сбой пути к плоскости пользователя). |
14 | 15 | Удаление набора сеансов | Х | Х | - | КП → ВВЕРХ | ВВЕРХ → КП | Отправляется функцией CP для указания на частичный сбой с запросом на удаление всех затронутых сеансов. | |
(50..99) | Сообщения, связанные с сеансом | ||||||||
50 | 51 | Установление сессии | Х | Х | Х | Х | КП → ВВЕРХ | ВВЕРХ → КП | Используется CP для настройки, изменения и удаления сессий, состоящих из наборов правил обработки и пересылки UP-трафика. Это основные функциональные сообщения домена приложений PFCP. UP может включить в ответ информацию об отчете об использовании, чтобы избежать дополнительного сообщения об отчете о сеансе. |
52 | 53 | Модификация сеанса | Х | Х | Х | Х | |||
54 | 55 | Удаление сеанса | Х | Х | Х | Х | |||
56 | 57 | Отчет о сеансе | Х | Х | Х | Х | ВВЕРХ → КП | КП → ВВЕРХ | Отчет об использовании UP. Информация в отчете основана на процедурах обработки и пересылки пакетов: данные нисходящего канала (уведомления о новых пакетах в очереди), отчет об использовании (информация об объеме, времени и т. д. для целей тарификации), сообщения об ошибках и/или бездействии. |
(100..255) | Другие сообщения |
Очень похоже на GTP-C , PFCP использует UDP . Порт 8805 зарезервирован. [5]
Для надежности используется стратегия повторной передачи, аналогичная GTP-C , при этом потерянные сообщения отправляются N1 раз с интервалом T1. Транзакции идентифицируются по 3-байтовому порядковому номеру, IP-адресу и порту коммуникационного партнера.
Протокол включает в себя собственную модель Heart-beat Request/Response, которая позволяет отслеживать доступность одноранговых узлов связи и обнаруживать перезапуски (с помощью информационного элемента Recovery-Timestamp).
Для обмена пакетами на уровне пользователя между функциональными элементами управления и уровня пользователя используется GTP-U для интерфейса Sx-u или, в качестве альтернативы, более простая инкапсуляция UDP или Ethernet для интерфейса N4-u (подлежит подтверждению, поскольку стандарты еще не завершены).