Технология xRAN

Введение

В настоящее время архитектура построения распределенных базовых станций стандарта LTE (и предыдущих стандартов связи) одинакова для всех вендоров и при этом вендорозависима. Распределенная базовая станция состоит из базового блока обработки (BBU, base band unit) и вынесенных радиомодулей (RRU, remote radio unit), связанных с базовым блоком по протоколу CPRI (common public radio interface). Описание интерфейса CPRI/eCPRI представлено здесь - https://itechinfo.ru/content/ecpri_interface. Подключение радиомодулей одного вендора к базовому блоку другого вендора невозможно по причине проприетарности решений.
От данной схемы построения сетей в определенном выигрыше остаются только крупные производители оборудования базовых станций, такие как Huawei, Ericsson и т.д., поскольку данная схема не позволяет менять производителя оборудования по усмотрению оператора при изменении финансовой политики установленного на сети вендрора, либо ухудшении качества предоставляемого решения, кроме как проводить глобальную замену оборудования одного вендора на оборудование иного вендора в целых регионах, что является процессом длительным, дорогостоящим и снижающим качество связи на период проведения замены (от года работы, в зависимости от региона). Но это же и мешает вендорам, поскольку не позволяет конкурировать на уже сформированных сетях по тем же самым причинам.
В проигравших также находятся все остальные участники рынка - операторы, которые не могут гибко строить свою сеть, и менее крупные производители оборудования, которые не имеют возможность разработать полный комплекс оборудования и программного обеспечения базовой станции, но готовы разрабатывать либо программное обеспечение, либо, например, отдельно элементы СВЧ-инфраструктуры.
Это явилось предпосылкой идеи разработки стандарта, который бы стандартизовал процедуру взаимодействия между элементами базовой станции. В рамках решения данной задачи существуют несколько групп - xRAN Forum, Telecom Infra Project’s OpenRAN Group и Cisco’s Open vRAN initiative. Хотя все эти группы и заявляют, что они работают над одним и тем же, что позволит сделать архитектуру RAN более открытой с использованием стандартизованных интерфейсов и сетевых элементов, при ближайшем рассмотрении деятельности данных групп существуют определённые отличия.
По словам Джона Бейкера (John Baker), SVP of business development в компании Mavenir, являущейся членом всех трех групп, между группами нет противоборства, потому что каждая группа сфокусирована на своем направлении.
• xRAN Forum
Форум xRAN был сформирован в 2016 году с целью стандартизации открытой альтернативы традиционному аппаратно-ориентированному RAN. Группа фокусируется на трех областях: отделение Control Plane RAN от User Plane, создание программного стека модульной eNobeB (modular eNodeB software stack), использующей аппаратное обеспечение COTS и публикация открытых северного и южного интерфейсов.
Группа подразумевает членство, ориентированное в первую очередь на операторов связи, включая AT&T, Verizon, Deutsche Telekom, KDDI, NTT Docomo, SK Telecom, Telstra и Verizon. По словам Сачина Катти (Sachin Katti), профессора Стэнфордского университета и директора xRAN Forum, группа сосредоточена на архитектуре сети и разработке спецификаций.
Группа xRAN выпустила свою первую спецификацию, посвященную виртуализации части сети Fronthaul. Fronthaul - это интерфейс, передающий трафик от блоков BBU до удаленных радиомодулей RRU. Спецификация предназначена для обеспечения совместимости между BBU и RRU, даже от разных производителей.
• Cisco’s Open vRAN
На февральской конференции Mobile World Congress 2018 Cisco объявила о новой инициативе открытой виртуальной сети радиодоступа (vRAN), названной Open vRAN. Цель Open vRAN - собрать открытую и модульную архитектуру RAN, основанную на платформах обработки общего назначения (general purpose processing platforms, GPPP) и дезагрегированном программном обеспечении, которые будут поддерживать различные варианты использования.
По словам Бейкера, современные мобильные сети используют много волоконных соединений точка-точка для fronthaul. Но с выпуском xRAN Group спецификации для fronthaul становятся возможны новые типы маршрутизации и IP-подключений. Группа Open vRAN была создана для поддержки этих новых типов построения архитектуры. «Open vRAN Cisco создан для того, чтобы показать, как разворачивать и структурировать IP-сети в сетях оператора связи для построения сетей fronthaul», - сказал Бейкер.
• TIP’s OpenRAN
Telecom Infra Project был основан в 2016 году компанией Facebook, совместно с Intel, Nokia, Deutsche Telekom и SK Telecom. Его задача - разделение программного и аппаратного обеспечения, а членами данного проекта являются более 500 интернет-компаний, операторов, поставщиков и системных интеграторов.
В ноябре 2017 года оператор Vodafone передала в TIP свой проект программно-определяемых RAN и создал OpenRAN Group. Целью группы является разработка технологий RAN на основе 3GPP и дезагрегированного программного обеспечения.
Директор xRAN Forum Sachin Katti говорит, что OpenRAN Group сфокусирована на внедрении и описании того, каким образом создавать программное и аппаратное обеспечение, в то время как xRAN Group более ориентирована на разработку спецификаций. Тем не менее, обе группы взаимодействуют друг с другом, и многие члены данных групп участвуют в обоих проектах. «Мы следим за тем, чтобы наши усилия в разработке дополняли друг друга. Мы не хотим дважды делать одну и ту же работу» - поясняет Sachin Katti.
John Baker согласен с этим, отмечая, что TIP’s OpenRAN ориентирован на конкретные use cases и построение сети с использованием алгоритмов fronthaul, а не на разработку спецификаций. Также John Baker обращает внимание, что многие компании, являющиеся членами TIP, выступают только в роли наблюдателей и не играют активной роли в развитии проекта.
(https://www.sdxcentral.com/articles/news/xran-open-vran-and-openran-whats-the-difference/2018/04/)

В данном обзоре будут рассмотрены основные аспекты спецификаций для fronthaul (XRAN-FH.CUS.0-v02.00, XRAN-FH.MP.0-v01.00), разработанной рабочей группой xRAN Fronthaul Working Group.

Архитектура построения базовой станции

На рисунке 1 показана архитектура базовых станций eNb и gNb разделенная на два типа узлов lls-CU (Lower Layer Split Central Unit) и RU. Представленные интерфейсы LLS-C (Low-Layer Split Control-Plane) и LLS-U (Low-Layer Split User-Plane) отвечают за передачу сообщений уровня управления (C-plane) и уровня данных (U-plane) в интерфейсе LLS.
В такой архитектуре узлы lls-CU и RU могут быть определены следующим образом:
• Lower Layer Split Central Unit - логический узел, включающий в себя функции eNb/gNb, до точки разделения Split point 7-2x, за исключением функций, выделенных исключительно в RU. lls-CU управляет работой радиомодулей.
• Радиомодуль (RU) – логический узел, который включает в себя подмножество функций eNb/gNb, после точки разделения Split point 7-2x.
Интерфейс fronthaul – это интерфейс между узлами lls-CU и RU.

Рисунок 1. Архитектура базовых станций eNb/gNb с разделением на lls-CU и RU

Функциональное разделение интерфейса fronthaul

Варианты функционального разделения интерфейса между CU и RU представлено на рисунках 2 и 3.

Рисунок 2. Опции разделения для LTE eNb

Рисунок 3. Опции разделения для 5G gNb

При анализе вариантов функционального разделения интерфейса fronthaul, возникают два противоположных момента:
1. С одной стороны, ставится задача максимально упростить RU, потому что размер, вес и мощность являются важными параметрами радиомодулей, и чем сложнее RU, тем больше, тяжелее и энергозатратнее получается RU;
2. С другой стороны, организация интерфейса с RU на более высоком транспортном уровне снижает требования к пропускной способности интерфейса, но чем выше уровень интерфейса обмена между lls-CU и RU, тем более сложным является блок RU.
Существующая спецификация xRAN fronthaul соответствует функциональному разделению нижнего уровня, показанному на рисунке 4. Разделение нижнего уровня в плоскости управления (LLS-M, Low-Layer Split Management-Plane) облегчает инициализацию, настройку и управление RU.

Рисунок 4. xRAN FH functional split

В рамках поиска альтернативы для обеих задач, группа xRAN выбрала одну точку разделения (split point) – «Split point 7-2x», но допускает вариации, при которых функция предварительного кодирования должна располагаться либо «выше» интерфейса fronthaul в узле lls-CU, либо «ниже» интерфейса fronthaul в узле RU. Радиомодули, в которых предварительное кодирование не выполняется (более простые радиомодули), называются радиомодули «Категории А». Радиомодули, в которых предварительное кодирование выполняется, называются радиомодули «Категории В». На рисунке 5 представлена данная двойная концепция радиомодулей.

Рисунок 5. Точка разделения и радиомодули Категории А и В

Включение в стандарт xRAN двух категорий радиомодулей приводит к определенным особенностям разделения функционала БС LTE и NR в каналах DL и UL. В частности, для радиомодулей Категории В, для выполнения функции предварительного кодирования в схемах LTE TM2-TM4 некоторые специальные инструкции плоскости управления должны быть переданы в RU из lls-CU. Для схем кодирования LTE TM5-TM10 и NR, передача дополнительных инструкций не требуется, поскольку функция предварительного кодирования может быть включена в цифровой блок обработки beamforming’а в RU для радиомодулей Категории В (даже в случае аналогового диаграммообразования в RU), тогда как для радиомодулей Категории А предварительное кодирование будет выполняться в lls-CU и любое формирование луча в RU, если оно присутствует, исключает проведение расчета предварительного кодирования.

Описание точки разделения Split 7-2x для канала DL

Функциональное разделение в DL-канале для различных каналов физического уровня показано на рисунках 6..9.
Радиомодуль Категории А, поддерживаемый lls-CU, в обязательном порядке поддерживает 8 потоков предварительного кодирования. Поддержка более 8 потоков радиомодулем опциональна.
Для LTE (например, схемы TM9) и NR PDSCH с опорными сигналами, специфичными для UE, цепочка обработки DL, заданная 3GPP, не включает в себя операцию предварительного кодирования.

Рисунок 6. Lower layer DL split description, LTE, радиомодуль категории А

Рисунок 7. Lower layer DL split description, LTE, радиомодуль категории В

Несмотря на то, что операция RE Mapping явно не показана на рисунке 7, она разделяется на части для поддержки радиомодулем предварительного кодирования для режимов разнесенной передачи и пространственного мультиплексирования в радиомодулях категории В:
1. RE mapping частотных ресурсов выполняется в lls-CU
2. RE mapping антенных портов выполняется в радиомодулях после предварительного кодирования

Рисунок 8. Lower layer DL split description, NR, радиомодуль категории А

Рисунок 9. Lower layer DL split description, NR, радиомодуль категории В

В DL-канале, функции фазовой компенсации OFDM [3GPP TS38.211, глава 5.4], iFFT, добавление циклического префикса и цифрового формирования луча (beamforming) реализуются в радиомодуле, также как и функция предварительного кодирования для радиомодулей Категории В. Остальные функции физического уровня, включая RE Mapping, предварительное кодирование, layer mapping, модуляция, скремблирование, согласование скорости и кодирования реализуются в lls-CU. Предварительное кодирование должно быть реализовано в lls-CU для поддержки радиомодулей Категории А, но это применяется только в том случае, если количество выходных пространственных потоков 8 или меньше, в противном случае предварительное кодирование должно выполняться в радиомодуле (Категория В).
Эта опция не включена в разработку 3GPP TR 38.801 Rel 14.
Преимуществ описанного разделения несколько:
• Простота интерфейса: Передача данных в U-plane основано на Ресурсных элементах / физических ресурсных блоках, что упрощает отображение данных и ограничивает необходимые связанные управляющие сообщения;
• Масштабирование пропускной способности: Более низкие точки разделения (например, split 7-1 и 8) зависят от количества антенн. Напротив, точка разделения 7-2x основывается на количестве «потоков», что позволяет использовать большое количество антенн без увеличения необходимой полосы пропускания на транспортной сети. Кроме того, передача пользовательских данных может быть оптимизирована посылкой только физических ресурсных блоков (PRB), которые содержат пользовательские данные для снижения требуемой полосы пропускания на транспортной сети;
• Поддержка функции beamforming: тот же дизайн интерфейса может поддерживать различные методы формирования диаграммы направленности (цифровые, аналоговые, гибридные), а также различные алгоритмы формирования диаграммы направленности. Использование только аналогового формирования диаграммы направленности реализуемо с этим же дизайном интерфейса;
• Совместимость: в split «7-2x» используется меньше «user specific» параметров (по сравнению с более высокими точками разделения), что упрощает спецификацию;
• Низкая сложность радиомоделей: уменьшение функционала радиомодуля (в сравнении с более высокими точками разделения) позволяет ограничить количество необходимых расчетов в режиме реального времени, а также требуемый объем памяти, особенно для радиомодулей Категории А;
• Гибкость в дальнейшем: Перемещение большинства функций в lls-CU позволит внедрять новые функций с помощью обновления программного обеспечения, без необходимости замены аппаратной части в RU (например, изменения спецификации, связанные с URLLC или новыми схемами модуляции);
• Симметричность интерфейса и функций: если для DL и UL каналов используется один и тот же интерфейс и точка разделения, для разработки спецификации потребуется меньше усилий

Описание точки разделения Split 7-2x для канала UL

Функциональное разделение в UL-канале для различных каналов физического уровня и режимов передачи показано на рисунке 10.

Рисунок 10. Lower layer UL split description for LTE and NR

В UL-канале, функции фазовой компенсации OFDM [3GPP TS38.211, глава 5.4], FFT, удаление циклического префикса и цифрового формирования луча реализуются в радиомодуле.
Остальные функции физического уровня, включая de-mapping ресурсных элементов, выравнивание, демодуляцию, де-скремблирование, rate de-matching и декодирование находятся в lls-CU.
Эта опция не включена в разработку 3GPP TR 38.801 Rel 14.
Преимущества, описанные для DL-канала, также применимы для канала UL.

Общие требования к задержке на fronthaul

Разделение fronthaul на низком физическом уровне вносит жесткие требования к полосе пропускания и задержке. Эти требования подразумевают использование специального профиля «Fronthaul Service Profile», который должен поддерживаться транспортной сетью. Общая концепция модели задержек основана на референсных точках протокола eCPRI (рисунок 11). Однако, данная спецификация предусматривает дополнительные требования по задержке в DL и UL каналах, см. таблицу 1. Набор параметров синхронизации применяется отдельно к каждому RU, присоединенному к lls-CU. Существует несколько подходов, обеспечивающих решение задач синхронизации.
Референсные точки, определенные в стандарте eCPRI:
• llu-CU: R1/R4 – интерфейс приема / передачи в lls-CU
• RU: R2/R3 – интерфейс приема / передачи в RU
• Ra: антенный интерфейс в RU

Рисунок 11. Определение референсных точек для управления задержками

Задержка передачи между lls-CU и RU называется Т12 (DL-канал) и Т34 (UL-канал). Задержка передачи включает в себя только время, от момента, когда бит покидает блок отправителя (точки R1 / R3) до момента, когда он достигнет блок получателя (точки R2 / R4). В транспортной сети данная задержка может быть не постоянной (т.н. PDV – packet delay variation, или джиттер задержки). Для учета этой вариации, задержки на транспортной сети необходимо рассматривать как диапазон с верхними и нижними пределами:
• Задержка на транспортной сети в DL-канале: T12max / T12min;
• Задержка на транспортной сети в UL-канале: T34max / T34min.
При этом, как и прежде, требуется обеспечить постоянную задержку на интерфейсе Ra. Таким образом, интерфейс Ra используется в качестве опорной точки для управления задержкой в модели eCPRI. Передача и прием в референсных точках измеряется относительно Ra, что приводит к следующим параметрам:
Таблица 1. Параметры задержки модели eCPRI lls-CU / RU

		CPRI	Задержка	eCPRI
				Minimum	Maximum
DL	lls-CU	T1a	Измеряется от выходного порта llu-CU (R1) до передающего порта антенны	T1amin	T1amax
	RU	T2a	Измеряется от приемного порта RU (R2) до передающего порта антенны	T2amin	T2amax
UL	lls-CU	Ta4	Измеряется от приемного порта антенны до приемного порта lls-CU (R4)	Ta4min	Ta4max
	RU	Ta3	Измеряется от приемного порта антенны до выходного порта RU (R3)	Ta3min	Ta3max

Взаимосвязь временных параметров

Чтобы обеспечить своевременный прием пакетов данных в приемнике, существует несколько взаимосвязей между указанными выше параметрами, которые должны быть выполнены.
В любом направлении (DL/UL) требуется, чтобы отправитель отправлял пакеты в транспортную сеть сразу по факту их получения. Однако, количество данных для любого интервала (например, символа) может меняться, что приводит к различной длительности передачи. На это время передачи могут влиять несколько факторов, включая (но не ограничиваясь этим) скорость передачи транспортной сети, полосу пропускания радиоинтерфейса и возможность сжатия передаваемых данных. Максимальное временное окно для отправки передатчиком всех данных за один интервал передачи (Transmission Window), определяется как T1amax - T1amin. Важно отметить, что это допустимое время, основанное на характеристиках используемой транспортной сети и RU.
Для учета девиаций времени передачи на транспортной сети и времени передачи сообщения приемник использует окно приема (Reception Window). Это позволяет пакетам, содержащим выборки для конкретного символа, полученным в пределах окна быть переданы в антенный интерфейс Ra в требуемый временной период. Размер приемного окна должен учитывать, как максимальную длительность передачи отправителем, так и вариацию времени передачи транспортной fronthaul-сети. Размер приемного окна является первым требованием к задержке, которое должно быть выполнено для определения допустимой задержки:

Reception Window ≥ Transmission Window – Transport Variation

Таблица 2. Окна задержки протокола eCPRI

	Reception Window	Transmission Window	Transport Variation
DL	T2amax – T2amin	T1amax – T1amin	T12max – T12min
UL	Ta4max – Ta4min	Ta3max – Ta3min	T34max – T34min

Положение (по времени) приемного окна / окна передачи в RU является фиксированным по отношению к радиоинтерфейсу. Однако положение соответствующих окон в lls-CU зависит от параметров RU и транспортной сети. Для гарантированного приема пакетов, отправленных из lls-CU в RU в окне приема RU, должны выполняться следующие условия:

Таблица 3. Положение (во времени) окна приема и передачи lls-CU

lls-CU Timing		Parameter	lls-CU Transmit Boundary Relationships
DL (Transmit)	Не ранее, чем	T1amax	T1amax ≤ T2amax + T12min
	Не позже, чем	T1amin	T1amin ≥ T2amin + T12max
UL (Transmit)	Не ранее, чем	Ta4min	Ta4min ≤ Ta3min + T34min
	Не позже, чем	Ta4max	Ta4max ≥ Ta3max + T34max

Окно передачи lls-CU (T1amax – T1amin) определяется соотношениями, указанными выше, на основе окна приема RU и максимальной вариации задержки на транспортной сети. Оно не определяет точное время передачи от lls-CU. Окно передачи определяет границы, в рамках которых возможна передача данных от lls-CU.Окно просто представляет математические ограничения, налагаемые на lls-CU из-за параметров RU и вариации задержки на транспортной сети. Можно определить временные ограничения для любого из элементов: lls-CU, RU или транспортной сети, на основании двух других параметров. При этом, обычно параметры RU определены производителем, а транспорт является общей частью для всей сети.
Окно передачи lls-CU должно быть больше или равно максимальному времени, требуемому lls-CU для передачи всех данных символа (TXmaxlls-CU). То есть, окно должно быть не меньше, чем максимальная длительность передачи lls-CU при худшей суммарной задержке. В каком месте в пределах окна передачи lls-CU будет передавать данные (например, в начале окна, середине или в конце) и сколько времени займет передача lls-CU в данном окне, является вопросом разработчика lls-CU.
Следующий пример иллюстрирует описанную концепцию:
• Параметры RU: T2min = 100 мкс, T2max = 260 мкс
• Параметры транспортной сети (прямое волокно известной длины): T12min = 50 мкс, T12max = 51 мкс
В результате, параметры для расчета окна передачи lls-CU будут следующими:
• T1amax ≤ 260 + 50
• T1amin ≥ 100 + 51
Данные параметры обеспечивают очень большое окно передачи для lls-CU (159 мкс). Например, если TXmaxlls-CU = 30 мкс, то lls-CU может решать, где в окне начать передачу, при условии, что передача завершится до момента времени T1amin.
Однако, если этот же блок lls-CU соединен с RU с меньшим окном приема (например, T2amin = 100 мксб T2amax = 150 мкс), с использованием той же транспортной сети с тем же значением параметра T12min, но с параметром PDV = 15 мкс, (T12max = 65 мкс), то в результате мы получим:
• T1amax ≤ 150 + 50
• T1amin ≥ 100 + 65
Параметры передачи сообщения для данной сети еще подходят (200 – 165 ≥ 30), но с гораздо меньшим запасом и меньшей гибкостью определения начала передачи сообщения lls-CU в окне.

Транспортная архитектура и описание протокола

Варианты инкапсуляции транспорта

Транспортная архитектура и описание протоколаВозможны следующие виды инкапсуляции U-plane и C-plane в транспортную сеть:
• Инкапсуляция в пакеты Ethernet. Ethernet может быть использован в качестве транспортного механизма для передачи как U-plane, так и C-plane. В этом случае сообщения передаются через стандартные кадры Ethernet (рисунок 12). Заголовок eCPRI и полезная нагрузка содержатся в поле данных Etnernet (Ethernet data field). Для этой инкапсуляции используется значение поля Ethertype eCPRI, либо IEEE 1914.3.
• Инкапсуляция в пакеты IP/UDP. IP/UDP может быть использован в качестве транспортного механизма для передачи как U-plane, так и C-plane. В данном примере сообщения передаются поверх стандартных IP-пакетов и механизм инкапсуляции идентифицируется в поле Ethertype как IP или Jumbo, рисунки 13, 14.
Схемы на рисунках 12..14 подразумевают передачу Ethernet-пакетов как стандартной длины, так и использование Jumbo-фреймов (более 9000 байт).

Рисунок 12. Ethernet-кадр с VLAN

Рисунок 13. Пакет IPv4 с VLAN

Рисунок 14. Пакет IPv6 с VLAN

Транспортный сетевой уровень M-plane построен на IP, TCP/SSH используется для переноса сообщений M-plane между CU/NMS и RU.

Заголовки

xRAN позволяет использовать несколько различных транспортных заголовков в полезной нагрузке Ethernet, чтобы дополнительно описать, каким образом данные приложения должны быть обработаны в C-плоскости и U-плоскости. В каждом случае транспортный заголовок составляет 8 байт и обеспечивает основные возможности маршрутизации данных, включая описание типа потока данных, идентификаторы портов отправки и приема, возможность поддержки объединения нескольких сообщений приложения в одном пакете Ethernet и нумерацию последовательностей.

Архитектура протокола

C-plane / U-plane

На рисунке 15 показан стек протокола для C-plane и U-plane. Опционально, данные могут быть переданы поверх IP, если это поддерживается приемным и передающим узлами.

Рисунок 15. Стек протоколов C-plane / U-plane

S-plane

S-plane (Synchronization Plane) - плоскость синхронизации, описывает трафик между RU или lls-CU и узлом синхронизации, которым обычно является IEEE 1588 Grand Master. Функциональность Grand Master также может быть встроена в узел lls-CU. Для передачи частотной и временной синхронизации между lls-CU и RU используется SyncE или PTP.
В текущей версии спецификации предполагается передача PTP напрямую через Ethernet L2 (ITU-T G.8275.1). Передача PTP через UDP/IP (ITU-T G.8275.2) допустима, но с ухудшением стабильности синхронизации. Механизмы безопасности для уровня S-plane не применяются. Стек протоколов для PTP и SyncE поверх L2 Ethernet изображен на рисунке 16.

Рисунок 16. Стек протоколов S-plane

M-plane

Интерфейс M-plane описывает трафик между узлами lls-CU/NMS и RU. Данная плоскость управления относится к операциям управления не в реальном времени между lls-CU и RU. Стек протоколов интерфейса M-plane показан на рисунке 17.

Рисунок 17. Стек протоколов M-plane

QoS интерфейса LLS

Для интерфейса LLS требуется поддержка способности различать потоки данных с различными требованиями QoS. Настраиваемые уровни приоритета для приоритезации трафика должны поддерживаться на каждом узле сети. Значения по умолчанию для соответствующих уровней xRAN показаны в таблице 4.

Таблица 4. Классы обслуживания

Уровень	L2 QoS Priority (диапазон 0-7)	L3 DSCP Code	Вытеснение (Preemption) (2)
S-plane	Default: 7 (1)	Не применяется	Не вытесняемые
U-plane	Default: 7	EE (Expedited Forwarding)	Не вытесняемые
C-plane	Default: 7	EF (Expedited Forwarding)	Не вытесняемые
M-plane	Default: 2	AF2x (Assured Forwarding)	Вытесняемые
Другой трафик	Default: 1	BE (Best Effort)	Вытесняемые

⁽¹⁾ – Применимо, если использование VLAN возможно в будущем.
⁽²⁾ – Не все транспортные сети поддерживают вытеснение, применяется только для сетей, поддерживающих вытеснение

Разделение потоков данных

Разделение данных между U/C-Plane и уровнем управления (M-plane) может быть реализовано следующим образом:
• Разделение потоков данных, основанное на TCP/UDP (применимо, когда для передачи C/U-plane используется Layer 3);
• Разделение потоков данных, основанное на VLAN (применимо, когда для передачи C/U-plane используется Layer 2 или Layer 3). Примечание – предполагается, что механизм назначения VLAN ID U/C-plane производится через M-plane;
• Разделение потоков данных, основанное на различных MAC адресах (применимо, когда для передачи C/U-plane используется Layer 2). Например, отдельный МАС-адрес используется для M-plane и U-plane, или для распределения нагрузки в основной полосе;
• Разделение потоков данных, основанное на значениях поля EtherType (применимо, когда для передачи C/U-plane используется Layer 2).

Фрагментация

Фрагментация применяется в тех случаях, когда данные (пользовательские или управления) с заголовком Ethernet превышают значение MTU (maximum transmission unit), установленный на сети. Текущая спецификация предполагает два метода фрагментации – фрагментация на уровне приложения и фрагментация на транспортном уровне.
При фрагментации на уровне приложения, приложение создает сообщения уровней С-plane и U-plane, которые не превышают вместе с заголовком значение MTU, установленный на сети (т.е. приложение гарантирует, что фрагментация сообщений происходить не будет)
При фрагментации на транспортном уровне, приложение может создавать сообщения уровней С-plane и U-plane, которые превышают вместе с заголовком значения MTU, установленный на сети (приложение не гарантирует, что фрагментация происходить не будет). Транспортный уровень (eCPRI или IEEE 1914.3) разделяет сообщения на части таким образом, чтобы фрагменты сообщений с заголовками соответствовали требованиям MTU сети передачи.
Фрагментация уровня приложения должна проводиться таким образом, чтобы имелась возможность использовать максимальные размеры кадров Ethernet, описанных в IEEE 802.3:
• В случае использования только L2 решения, максимальный размер блока передачи на уровне приложения определяется как максимальный размер кадра Ethernet, определенный стандартом IEEE 802.3 (1500 байт) за вычетом транспортного заголовка (8 байт) = 1492 байта.
• В случае применения Jumbo-фреймов Ethernet в L2-реализациях, максимальный размер блока передачи на уровне приложения рассчитывается как 9000 байт минус транспортный заголовок (8 байт) = 8992 байт.

Безопасность

Требования по безопасности каждой плоскости данных приведены в таблице 5.

Таблица 5. Требования безопасности

Уровень	Целостность (защита от модификаций)	Конфиденциальность (защита от декодирования)	Доступность (защита от вставки пакета)	Примечание
U-plane	Нет требований	Нет требований	Нет требований	Данные пользователя защищены на всем участке (end to end) с использованием протокола PDCP
C-plane	Нет требований	Нет требований	Нет требований
S-plane	Нет требований	Нет требований	Нет требований	Необязательно в IEEE 1588 (PTP). Однако это не реализуется по разумной цене.
M-plane	Да	Да	Да	Using the SSHv2 layer used for NETCONF transport

Протоколы C/U-plane

В качестве механизма инкапсуляции для C-plane и U-plane сообщений используется EtherType eCPRI или IEEE 1914.3. Из-за особенностей этих сообщений (очень строгих ограничений задержки), считается, что подтверждение приема сообщения невозможно. Кроме того, предполагается, что для C-plane и U-plane должны использоваться различные потоки данных. Кроме того, сообщения C-Plane не сцепляются с сообщениями U-плоскости в пределах одного и того же кадра Ethernet.
IQ данные U-Plane, (как DL и UL) в том числе пользовательские данные, PRACH и каналов управления, может быть переданы в сжатом формате. Существует несколько предполагаемых методов сжатия, включая «несжатый» формат. Методы сжатия блока выполняется на основе физических ресурсных блоков (PRB, Physical Resource Block).
Опционально, существует возможность конфигурирования статического формата IQ и метода сжатия. M-Plane определяет статический формат IQ (битовую ширину) и метод сжатия.

Протокол S-plane

Временная и частотная синхронизация смогут быть переданы на узлы lls-CU и RU разными способами. Существенное влияние на точность синхронизации оказывает реализация. Для Ethernet доступны следующие варианты синхронизации:
• Частотная синхронизация;
• Фазовая синхронизация;
• Временная синхронизация.
Вместе вышеперечисленные параметры определяют профиль транспортной сети, требующий определенного набора функций и опций для работы транспортных узлов и базовых станций. Кроме того, профиль также устанавливает требования соответствия для дополнительного оборудования и пользовательских приложений.
Существующая редакция стандарта подразумевает синхронизацию частоты, фазы и времени всех элементов сети (lls-CU, промежуточные коммутаторы и RU). Обеспечение только частотной синхронизации (например, для LTE FDD или 5G FDD) будет рассматриваться в следующих версиях стандарта.
Для решения различных задач требуются различные варианты организации синхронизации узлов. В спецификации xRAN определены 4 конфигурации синхронизации:
• Конфигурация С1: обеспечивается синхронизация от lls-CU к RU по топологии точка-точка между центральным и удаленным сайтами напрямую;
• Конфигурация С2: обеспечивается синхронизация от lls-CU к RU между центральным и удаленным сайтами. На сети fronthaul располагаются Ethernet-коммутаторы.
• Конфигурация С3: обеспечивается синхронизация от PRTC/T-GM как lls-CU, так и RU. На сети fronthaul располагаются Ethernet-коммутаторы.
• Конфигурация С4: Синхронизация RU осуществляется от внутреннего источника синхронизации, синхронизируемого от PRTC (обычно GNSS-приемник).
Стандарт xRAN в качестве предпочтительного подхода рассматривает организацию синхронизации всей сети fronthaul, однако, данный подход в ряде случаев не может быть реализован (например, используется оборудование, не поддерживающее PTP). Для того, чтобы обеспечить синхронизацию RU в данном случае, стандарт позволяет использовать локальный источник синхронизации (обычно GNSS) для синхронизации RU (Конфигурация 4).
Следует заметить, что данный вариант синхронизации требует дополнительного интерфейса синхронизации или встроенного источника синхронизации (GNSS) в RU.
Указанные виды синхронизации представлены на рисунках 18..20.

Рисунок 18. Конфигурации С1 и С2

Рисунок 19. Конфигурация С3

Рисунок 20. Конфигурация С4

Протокол M-plane

M-Plane на базе NETCONF / YANG используется для поддержки функций управления. Архитектура M-Plane поддерживает две модели:
1. Иерархическая модель. Как показано на левой стороне рисунка 21, RU полностью управляется одним или несколькими lls-CU с использованием интерфейса M-Plane на основе NETCONF. Схема, в которой RU управляется несколькими lls-CU, обычно используется для увеличения надежности путем введения избыточности lls-CU и/или транспорта.
2. Гибридная модель. Гибридная архитектура обеспечивает один или несколько прямых логических интерфейсов между системой управления и RU в дополнение к логическому интерфейсу между lls-CU и RU. Следует отметить, что клиенты NETCONF, подключающиеся к RU, могут быть разных типов (lls-CU и NMS). Например, такие функции, как управление программным обеспечением RU, управление производительностью, управление конфигурацией и управление отказами, могут управляться непосредственно системой (-ми) управления.

Рисунок 21. Архитектура M-plane

В гибридной модели RU имеет сквозное IP-соединение с NMS. С точки зрения физической сети это подключение может осуществляться через lls-CU, где lls-CU выступает в качестве узла пересылки пакетов IP/Ethernet между RU и NMS.
В стандарте отсутствует явный признак, указывающий на то, в какой конфигурации работает RU – иерархической или гибридной. Все серверы NETCONF, поддерживающие спецификацию M-Plane xRAN, должны поддерживать несколько сеансов NETCONF, и, следовательно, все совместимые RU должны поддерживать как иерархическое, так и гибридное развертывание.
NETCONF / YANG используется в качестве протокола управления сетевыми элементами и языка моделирования данных. Использование такой стандартизированной структуры и общего языка моделирования упрощает интеграцию между lls-CU и RU, а также интеграцию сети. NETCONF также изначально поддерживает гибридную архитектуру, которая позволяет нескольким клиентам присоединяться и получать информацию, поступающую с сервера NETCONF в RU.
На основе транспортной топологии возможны различные режимы сетевого соединения между RU, lls-CU и NMS. Основным требованием для M-Plane является наличие сквозного IP-соединения между RU и элементами, управляющими им (lls-CU, NMS или так называемые «контроллеры RU»). IPv4 поддерживаться в качестве обязательного транспортного протокола для M-Plane, поддержка IPv6 рассматривается как опциональная. Для M-Plane не может использоваться NAT для подключения RU к lls-CU / NMS.

Счетчики и KPI

В таблице 6 приведены счетчиков, определенные стандартом. В будущих версиях спецификации будет добавлены дополнительные счетчики производительности, связанные с интерфейсом fronthaul.

Таблица 6. Поддерживаемые счетчики для DL и UL

#	Наименование счетчика	Описание счетчика
1	Rx on time	Данные были приняты вовремя (применяется для приемного окна пользовательских данных)
2	Rx early	Данные были приняты слишком рано (применяется для приемного окна пользовательских данных)
3	Rx late	Данные были приняты слишком поздно (применяется для приемного окна пользовательских данных)
4	Rx corrupt	Испорченный/некорректный заголовок пакета
5	Rx pkt dupl	Дубль пакета
6	Total msgs rcvd	Общее количество принятых сообщений (по всем каналам)

Обязательные и опциональные требования стандарта

Информация о требованиях спецификации xRAN, являющихся как обязательными, так и необязательными, приведена в таблице 7. Данный перечень будет различным для узлов lls-CU и RU, т.к. во многих случаях для узлов lls-CU необходимо реализовать несколько вариантов в качестве обязательных для обеспечения совместимости с радиомодулями, которые имеют различные возможности. Например, возможность поддерживать несколько методов сжатия данных может быть обязательной для узла lls-CU, при этом в радиомодулях может быть обязательным только один метод сжатия для обеспечения простоты разработки RU.

Таблица 7. Поддерживаемые спецификацией xRAN каналы LTE and NR

Поддерживаемые физические каналы
LTE DL Channels	PDSCH, PBCH, PCFICH, PDCCH, ePDCCH, MPDCCH, PHICH, CRS, MBSFN RS, UE-RS, DMRS for ePDCCH/MPDCCH, PRS, CSI-RS, PSS, SSS, Discovery RS
LTE UL Channels	PUSCH, PUCCH, DMRS-PUSCH, DMRS-PUCCH, SRS, PRACH (incl. eMTC)
Narrow band IoT DL Channels	NB-DMRS, NB-PDSCH, NB-PBCH, NB-PDCCH, NB-RS, NB-PRS, NB-PSS, NB-SSS
Narrow band IoT UL Channels	NB-PUSCH, NB-PRACH
NR DL Channels	PDSCH, PDCCH, DMRS-PDSCH, PTRS-PDSCH, DMRS-PDCCH, DRMS-PBCH, CSI-RS, PSS, SSS, SS Block/PBCH
NR UL Channels	PUSCH, PUCCH, PRACH, DMRS-PUSCH, PTRS-PUSCH, DMRS-PUCCH, SRS
Поддерживаемый функционал
Technologies	LTE TDD, FDD (normal and extended CP) NR TDD, FDD
Channel Bandwidth	LTE: 1.4, 3, 5, 10, 15, 20 MHz
	NR: up to 400MHz
Subcarrier Spacing	LTE: 15kHz, 7.5kHz, 1.25kHz LTE PRACH: 1.25kHz, 7.5kHz NB-IoT PRACH: 3.75kHz
	NR: 15, 30, 60, 120, 240 kHz
	NR Multi Numerology
	NR PRACH: 1.25, 5, 15, 30, 60, 120 kHz
LTE Specific Features	DL Transmission Modes : TM1 - TM10
	UL Transmission Modes : TM1, TM2
	Carrier Aggregation
	eMBMS
	TTI-Bundling
	Semi-Persistent Scheduling (SPS)
	MIMO (SU/MU-MIMO)
	UE TAS (Tx Antenna Selection)
	FeICIC (ABS)
	CoMP (DL/UL), JT
	Short TTI
	eMTC
	NB-IOT (in band/gurad band/standalone)
	License Assisted Access (LAA)
	Sidelink (Proximity Services)
	Dynamic TDD (eIMTA)
	Mission Critical PS-LTE Features (MCPTT, ..)
	Positioning (PRS, OTDOA etc)
	V2X
	Distributed Antenna Sysstem Support
	CBRS Support
NR Specific Features	EN-DC
	SSBlock
	BW Part
	Supplimentary UL
	Mini-slot
	LTE-NR Co-existence
Beamforming	Analog Beamforming
	Digital Beamforming
	Hybrid Beamforming
	RU Support for 2 - 256 TRXU
Transport	L2 : Ethernet
	L3 : IPv4, IPv6
	QoS over Fronthaul

Таблица 8. Обязательные и опциональный возможности стандарта xRAN

Category	Feature	lls-CU Support	RU Support	Note
RU Category Support	Support for CAT-A RU (up to 8 spatial streams)	Mandatory	NA
	Support for CAT-A RU (> 8 spatial streams)	Optional	NA
	Support for CAT-B RU (precoding in RU)	Mandatory	NA
Beamforming	Beam Index based	Mandatory	Mandatory	Applies to UE specific BF for all RUs
	Real-time BF Weights	Mandatory	Mandatory	Applies to RUs capable of BF using RT Weights
	Real-Time Beamforming Attributes	Optional	Optional
	UE Channel Info	Optional	Optional
Bandwidth Saving	Programmable static-bit-width Fixed Point IQ	Mandatory	Mandatory
	Real-time variable-bit-width	Optional	Optional
	Compressed IQ
	- Block floating point compression	Optional	Optional
	- Block scaling compression	Optional	Optional
	- u-law compression	Optional	Optional
	- modulation compression	Optional	Optional
	- beamspace compression	Optional	Optional
	Variable Bit Width per Channel (per data section)	Optional	Optional
	Static configuration of U-Plane IQ format and compression header	Optional	Optional
	Use of “symInc” flag to allow multiple symbols in a C-Plane section	Optional	Optional
Energy Savings	Transmission blanking	Optional	Optional
lls-CU - RU Timing	Pre-configured Transport Delay Method	Mandatory	Mandatory
	Measured Transport Method (eCPRI Msg 5)	Optional	Optional
Synchronization	G.8275.1	NA	Mandatory
	G.8275.2	NA	Optional
	GNSS based sync	NA	Optional
	SyncE	NA	Optional
Transport Features	L2 : Ethernet	Mandatory	Mandatory
	L3 : IPv4, IPv6 (CUS Plane)	Optional	Optional
	QoS over Fronthaul	Mandatory	Mandatory
	Prioritization of different U-Plane traffic types	Optional	Optional
	Support of Jumbo Ethernet frames	Optional	Optional
	eCPRI	Mandatory	Mandatory
	support of eCPRI concatenation	Optional	Optional
	IEEE 1914.3	Optional	Optional
Other features	LAA LBT lls-CU Congestion Window mgmt	Mandatory	Mandatory
	LAA LBT RU Congestion Window mgmt	Optional	Optional