СПОСОБ ПЕРЕДАЧИ СООБЩЕНИЙ МЕЖДУ УЗЛАМИ ОДНОЧАСТОТНОЙ СЕТИ СВЯЗИ
METHOD OF TRANSMITTING MESSAGES BETWEEN NODES OF A SINGLE-FREQUENCY COMMUNICATION NETWORK

Связь с ранними заявками
Настоящее изобретение представляет собой дальнейшее развитие технического решения, описанного в европейской заявке на патент №15154705.6 Method and Device for Configuring a Single Frequency Network (Способ и устройство для конфигурирования одночастотной сети), поданной 1 февраля 2015 г., содержимое которой включено в данный документ посредством ссылки для любых целей.
Область техники
Настоящее изобретение относится к работе одночастотной сети или сетевого кластера, в котором несколько базовых станций, каждая из которых обеспечивает одну или несколько сот радиосвязи, работают таким согласованным образом, чтобы не требовался хэндовер, когда пользовательское оборудование пересекает несколько сот.
Уровень техники
В патентном документе ЕР 15154705.6 описан способ работы одночастотной сети (SFN, Single Frequency Network), основанный на информации о положении и/или траектории мобильных терминалов. Вкратце, при этом определена функция блока управления ресурсами (RCU, Resource Control Unit), которая может быть либо локализована в некотором центре, либо распределена по различным элементам системы связи. Согласно одному из вариантов предложен пул ресурсов с локальным планированием, чтобы назначать первую функцию подавления помех (для подавления помех между SFN-кластерами) для центрального элемента RCU и вторую функцию подавления помех (для подавления помех внутри SFN-кластера) для локального (или предназначенного для определенного кластера) элемента RCU. Локальный блок RCU может включать в себя функциональные средства планирования МАС-уровня радиоинтерфейса системы беспроводной связи или может управлять ими. Согласно описанной концепции локальный блок RCU должен оповещать все задействованные точки передачи (станции eNB или блоки RRH) в своем SFN-кластере о том, когда и какую часть данных отправлять в синхронизированном режиме.
В патентом документе US 20090264125 A1 описана система связи, содержащая портативные блоки для обеспечения работы фемтосот. Портативный блок обеспечивает множество радиоинтерфейсов с пользовательским оборудованием. Фемтосота работает аналогично традиционной сотовой базовой станции. Если в данной зоне действует несколько портативных блоков, функции точки доступа фемтосоты могут перераспределяться между ними.
В соответствии с документом 3GPP TS 36.321, основные службы и функции уровня протокола MAC (Medium Access Control) для LTE включают в себя:
а) сопоставление логических и транспортных каналов;
б) мультиплексирование или демультиплексирование принадлежащих одному или различным физическим каналам блоков служебных данных (SDU, Service Data Unit) протокола MAC в транспортные блоки (ТВ, Transport Blocks) или из транспортных блоков, доставляемых на физический уровень или с физического уровня по транспортным каналам;
в) сообщение информации о планировании;
г) обработку приоритетов логических каналов одного устройства UE;
д) обработку приоритетов устройств UE посредством динамического планирования;
е) выбор транспортного формата;
ж) заполнение и другие функции.
Для этого изобретения особенно важны аспекты (в) и (д) для планирования функций протокола MAC, поскольку они крайне необходимы для подавления помех внутри SFN-кластера.
M
N
Соответствующая современному уровню техники общая архитектура сети сотовой связи представлена фиг. 1, 2, 3А и 3Б. На фиг. 1 представлен пример архитектуры системы 10 связи LTE, где точки 20 передачи сгруппированы в кластеры (показаны два кластера: кластер М 22 и кластер N 24). Каждым кластером управляет соответствующий блок управления ресурсами (Resource Control Unit - RCU 26 и RCU 28). Блоками RCU управляет блок 30 управления кластерами. На фиг. 1 показан интерфейс 32 сетевой инфраструктуры (интерфейс S1 в случае системы LTE) между блоком 30 управления кластерами и узлом 34 управления мобильностью (ММЕ, Mobile Management Entity), входящим в состав базовой сети.
Как показано на фиг. 2, фактическая точка 20 передачи (антенны или антенные решетки) на сетевой стороне находится в базовой станции 40. На фиг. 2 показан интерфейс 32 сетевой инфраструктуры и радиоинтерфейс 36 (базовая точка Uu в случае системы LTE). Также показан стек 38 протоколов радиоинтерфейса для каждой базовой станции 40 и мобильного терминала 42. Оконечные точки различных уровней протоколов LTE находятся в базовой станции (eNB) и в мобильном терминале (UE). На фиг. 3А представлен пример архитектуры сети системы связи LTE с выносным радиоблоком (RRH, Remote Radio Head) 44, выполняющим функции точки передачи. Блок RRH 44 соединен с базовой станцией (eNB) 46, например, посредством прямого проводного или волоконно-оптического соединения. На фиг. 3Б представлен пример архитектуры сети системы связи LTE с блоком RRH 48, соединенным с пулом 50 виртуальных базовых станций (eNB). На фиг. 3А и 3Б фактические точки передачи (антенны или антенные решетки) на сетевой стороне представлены блоками RRH, соединенными с базовой станцией (или с пулом вычислительных ресурсов базовых станций) посредством интерфейса INTERFACE 1, который может представлять собой беспроводной, проводной или оптический интерфейс. В интерфейсе INTERFACE 1 могут, например, использоваться протоколы CPRI (Common Public Radio Interface, радиоинтерфейс общего пользования). Блоки RRH представляют собой одну из наиболее важных подсистем новых распределенных базовых станций. Блок RRH содержит радиочастотные цепи базовой станции, аналого-цифровые и цифро-аналоговые преобразователи (АЦП и ЦАП), повышающие или понижающие преобразователи и антенны. В блоках RRH также предусмотрены средства обработки данных для обеспечения функционирования и управления, а также стандартизированный интерфейс для соединения с остальными компонентами базовой станции. Блоки RRH значительно упрощают работу в режиме MIMO по сравнению с базовыми станциями, содержащими радиочастотные цепи, преобразователи АЦП и т.д., и соединяются с антеннами через аналоговый интерфейс. Блоки RRH также повышают эффективность базовой станции и упрощают физическое размещение для устранения разрывов покрытия в зоне действия сети.
На фиг. 3А и 3Б также показаны стеки 60, 62 и 64 протоколов для радиоинтерфейса. Оконечные точки различных уровней протоколов LTE, за исключением физического уровня LTE (PHY), находятся и в базовой станции (eNB), и в мобильном терминале (UE). В отличие от представленной на фиг. 2 архитектуры, уровень LTE PHY по меньшей мере частично оканчивается в блоке RRH. С точки зрения устройства UE, сопряженная часть уровня PHY находится в блоке RRH, а сопряженные части уровней, более высоких по отношению к уровню PHY, находятся в станции eNB. Интерфейс INTERFACE 1 предназначен для обмена узкополосными сигналами, а интерфейс INTERFACE 2 представляет собой фактический радиоинтерфейс (антенна-антенна), использующий сетку ресурсов (как описано в предыдущем изобретении), а также схемы модуляции и кодирования физического уровня LTE.
Как показано на фиг. 3А, блок RRH соединен с реальной физической базовой станцией. На фиг. 3Б показано подключение блока RRH к пулу вычислительных ресурсов базовых станций (также известному как Cloud RAN (облачная сеть радиодоступа)).
Следует отметить, что эффективность размещения локального блока RCU в системе беспроводной связи в значительной степени зависит от фактического сценария реализации. Точнее, оно зависит от топологической структуры сети и от использования в качестве точек передачи (TP, Transmission Point) блоков RRH или станций eNB. Кроме того, оно зависит от того, используются при этом реальные физические станции eNB (см. фиг. 3А) или виртуальные станции eNB (например, из пула вычислительных ресурсов eNB, см. фиг. 3Б).
Также следует отметить, что в контексте настоящего изобретения станция eNB может быть реальной (физическая станция eNB) или виртуальной (экземпляр вычислительного ресурса eNB из пула вычислительных ресурсов). Точка передачи (TP) может представлять собой блок RRH или полнофункциональную базовую станцию.
Для лучшего понимания настоящего изобретения на фиг. 4А-4В представлены примеры различных известных топологий сети, подходящих для реализации изобретения. Термину точка передачи (TP) (антенна или антенная решетка) может соответствовать блок RRH или реальная физическая станция eNB. На фиг. 4А представлен пример топологической структуры сети типа «шина», на фиг. 4Б - структуры сети типа «звезда», на фиг. 4В - смешанной структуры сети типа «шина» и «звезда».
Раскрытие изобретения
В настоящем изобретении реализован способ передачи функций оперативного управления блока управления ресурсами в одночастотной сети от первого узла ко второму узлу согласно п. 1 формулы изобретения.
Цель способа согласно изобретению заключается в обеспечении бесшовной передачи функций блока RCU или информации контекста блока RCU (включая аспекты планирования протокола MAC для подавления помех внутри SFN-кластера) от одного элемента к другому элементу, когда соответствующий SFN-кластер перемещается, расширяется или сужается.
Процесс передачи функций блока RCU может включать в себя один или несколько из следующих шагов: выбор по меньшей мере одного узла-кандидата; активация по меньшей мере одного узла-кандидата; запрос информации от по меньшей мере одного узла-кандидата; прием набора информации от по меньшей мере одного узла-кандидата; оценка набора информации, принятого от по меньшей мере одного узла-кандидата; оценка другого набора информации, полученного первым узлом; определение одного узла-кандидата в качестве второго узла; инициирование передачи информации контекста блока RCU от первого узла ко второму узлу (к целевому узлу); полная или частичная передача информации контекста блока RCU от первого узла ко второму узлу (к целевому узлу); деактивация первого узла. Последовательность выполнения описанных здесь шагов выбрана произвольным образом, т.е. в реальных условиях они могут выполняться в другом порядке согласно соответствующему сценарию. Кроме того, не все описанные здесь шаги процесса могут потребоваться для передачи функций RCU между элементами. В одном из вариантов осуществления изобретения передача функций блока RCU может включать в себя передачу информации контекста блока RCU. В другом варианте осуществления изобретения передача информации контекста блока RCU может включать в себя передачу функций блока RCU. Другие аспекты изобретения представлены в зависимых пунктах формулы изобретения.
Краткое описание чертежей
Далее варианты осуществления изобретения описаны только в качестве примеров со ссылками на следующие чертежи.
На фиг. 1 представлена схема одночастотной сети, разделенной на кластеры.
На фиг. 2 представлен пример архитектуры сети системы связи LTE.
На фиг. 3А представлен пример архитектуры сети системы связи LTE с выносным радиоблоком.
На фиг. 3Б представлен другой пример архитектуры сети системы связи LTE с выносным радиоблоком.
На фиг. 4А представлена структура сети типа «шина».
На фиг. 4Б представлена структура сети типа «звезда».
На фиг. 4В представлена смешанная структура сети «шина» и «звезда».
На фиг. 5А представлен вариант осуществления изобретения в кластере с шинной топологией.
На фиг. 5Б представлен вариант осуществления изобретения в кластере со звездообразной топологией.
На фиг. 6А показана передача функций блока RCU между локальными блоками RCU при шинной топологии.
На фиг. 6Б показана передача функций блока RCU между локальными блоками RCU при звездообразной топологии.
На фиг. 7А представлен SFN-кластер с шинной топологией.
На фиг. 7Б представлен SFN-кластер со звездообразной топологией.
На фиг. 8 показана передача от первой станции eNB ко второй станции eNB.
На фиг. 9 представлена первая схема последовательности сообщений.
На фиг. 10 представлена вторая схема последовательности сообщений.
Осуществление изобретения
m
m+2
На фиг. 5А показана передача функций блока RCU в SFN-кластере М с шинной топологией от первой станции eNB (eNB) ко второй станции eNB (eNB). При передаче от одной станции eNB к другой также переходят функции локального блока RCU.
M
M
Локальный блок RCU соответствует блоку RCU до передачи, локальный блок RCU* соответствует блоку RCU после передачи. До передачи используется интерфейс S1 инфраструктуры между сетями RAN (Radio Access Network) и CN (Core Network), а после передачи - интерфейс S1*.
n
n+2
n+2
n
n+1
n+2
n+1
Согласно фиг. 5А, функции блока RCU могут передаваться через две базовые точки интерфейса S1 или по шине, соединяющей станции eNB в SFN-кластере М. Согласно фиг. 5Б, функции блока RCU могут передаваться через две базовые точки интерфейса S1 или с использованием прямого соединения между станциями eNB и eNB в SFN-кластере N. В случае архитектуры, представленной на фиг. 5Б, звездообразную топологию следует сформировать по-иному после успешной передачи функций блока RCU (когда станция eNB поддерживает функции блока RCU для SFN-кластера N, прямое соединение между станциями eNB и eNB может быть сброшено, а прямое соединение между станциями eNB и eNB должно быть установлено). Это зависит от фактического сценария реализации и может оказаться возможным не во всех случаях.
1
m
n
o
L
N
M
O
L
N
M
O
В настоящем изобретении также реализована передача функций локального блока RCU от первой станции eNB первого SFN-кластера ко второй станции eNB второго SFN-кластера (например, от станции eNB к станции eNB, как показано на фиг. 6А, или от станции eNB к станции eNB, как показано на фиг. 6Б). Локальный блок RCU или RCU соответствует блоку RCU до передачи, локальный блок RCU или RCU соответствует блоку RCU после передачи. До передачи используется интерфейс S1или S1 инфраструктуры между сетями RAN и CN, а после передачи - интерфейс S1 или S1.
Согласно фиг. 6А, функции блока RCU могут передаваться через две базовые точки интерфейса S1 или по шине, соединяющей SFN-кластер L и SFN-кластер М. Согласно фиг. 6Б, функции блока RCU могут передаваться только через две базовые точки интерфейса S1. В отличие от представленного выше примера, здесь отсутствует прямое соединение между различными SFN-кластерами вследствие данной звездообразной топологии. Как видно из фиг. 7А и 7Б, передача от первой станции eNB ко второй станции eNB одного SFN-кластера не требуется в силу принципа реализации блоков RRH.
Возможности и/или пригодность станции eNB для выполнения функций локального блока RCU в любом конкретном SFN-кластере должна быть известна до инициирования передачи функций RCU. В некоторых сценариях реализации в дополнение к этой информации или вместо нее необходима информация о распределении ресурсов (например, в радиоинтерфейсе станции eNB), и/или о связанной с обработкой данных нагрузке (например, в аппаратных средствах станции eNB), и/или данные о текущей конфигурации (например, конфигурация полосы пропускания станции eNB), и/или местное состояние активности (например, относящееся к режимам энергосбережения в станциях eNB).
Поэтому различная информация, описывающая возможности и/или пригодность станции eNB, в целом называемая информацией управления ресурсами, сообщается элементу, инициирующему передачу функций RCU, до первой передачи. Эти данные могут запрашиваться либо определяться, например, первым узлом (т.е. станцией eNB, которая в данный момент обеспечивает функции локального блока RCU для конкретного кластера) или центральным блоком управления (таким как блок управления кластерами сети SFN).
M
N
M
M
N
N
Согласно другому аспекту настоящего изобретения, выполняется передача функций локального блока RCU от первой виртуальной станции eNB, управляющей первым SFN-кластером, ко второй виртуальной станции eNB, управляющей вторым SFN-кластером (например, от станции eNB к станции eNB, как показано на фиг. 8). Локальный блок RCU соответствует блоку RCU, выделенному для станции eNB до передачи, а локальный блок RCU соответствует блоку RCU, выделенному для станции eNB после передачи. В этом сценарии передача функций локального блока RCU от одной виртуальной станции eNB к другой виртуальной станции eNB представляет собой внутреннюю операцию пула станций eNB и поэтому не требует внешних интерфейсов для передачи информации контекста.
На фиг. 8 представлен пример топологии реализации с SFN-кластером М с шинной топологией и SFN-кластером N со звездообразной топологией. Этот пример не имеет ограничительного характера. В других сценариях оба SFN-кластера могут иметь шинную топологию или звездообразную топологию. Кроме того, очевидно, что передача информации контекста блока RCU между пулом станций eNB, состоящим из нескольких виртуальных станций eNB, и подсистемой, состоящей из нескольких физических станций eNB, входит в объем настоящего изобретения. Последнее не представлено в данном документе для краткости.
Как показано на фиг. 1, любым локальным блоком RCU, обслуживающим определенный кластер, управляет блок управления кластерами SFN. Этот блок управления определяет по меньшей мере один SFN- кластер в пределах сети, обслуживаемый локальным блоком RCU, а также пользователей или устройства, подключенных к определенному SFN-кластеру.
Концепция SFN-кластеров и устройств, обслуживаемых SFN-кластерами, учитывает географическое местоположение, фактические перемещения устройств UE и/или предполагаемые траектории устройств UE, а также другие аспекты, включая следующие:
доступность и потребность в ресурсах в локальных блоках RCU;
необходимые издержки синхронизации, т.е. затраты ресурсов вследствие использования SFN;
предполагаемое время существования кластера, т.е. предполагаемые затраты на его поддержание.
Сформированный SFN-кластер представляет собой динамическую конструкцию, следующие параметры которой изменяются в соответствии с локальными и глобальными потребностями:
количество устройств UE, обслуживаемых SFN-кластером;
точки TP (блоки RRH и/или станции eNB), образующие SFN-кластер;
ресурсы, которыми управляет (центральный) блок RCU для обслуживания SFN-кластера;
элемент, выполняющий функции локального блока RCU для определенного SFN-кластера.
В отличие от представленных в этом перечне параметров, местное управление некоторыми параметрами осуществляет локальный блок RCU без взаимодействия с централизованными функциями управления. В качестве примера можно привести локальное управление централизованно выделяемыми ресурсами и локальное включение и выключение питания точек TP (блоков RRH, станций eNB) для повышения энергоэффективности кластера.
Решение относительно элемента, который должен выполнять функции местного блока RCU, принимается центральным блоком RCU в блоке управления кластерами сети SFN. Во-первых, это решение основывается на возможностях доступных элементов, поскольку не все элементы способны или подходят для выполнения необходимых функций с обеспечением требуемых характеристик. Во-вторых, должен выбираться локальный блок RCU с надлежащими соединениями со всеми точками TP в кластере, которые должны иметь достаточно малую задержку передачи, чтобы обеспечить синхронизированную работу SFN-кластера, и достаточную полосу пропускания для обработки всех соответствующих запросов устройства UE. В-третьих, в зависимости от сценария реализации, также могут учитываться другие критерии, такие как распределение ресурсов, нагрузка, связанная с обработкой данных, конфигурация полосы пропускания и/или состояние активности конкретного узла.
Логичным, но необязательным решением является наделение функциями локального блока RCU одной из станций eNB с соответствующими возможностями в пределах SFN-кластера. Тем не менее, вследствие динамических свойств, по определению присущих кластеру, элемент, выполняющий функции локального блока RCU, может оказаться неоптимальным выбором по истечении некоторого периода времени и, наконец, он может быть неспособен или не подходить для выполнения этих функций, например, вследствие потери соединения или ухудшения качества соединения. Элемент также может иметь недостаточные вычислительные ресурсы или может представлять собой оптимальный вариант для обслуживания другого кластера и поэтому должен прекратить обслуживание своего текущего кластера. В другом варианте осуществления изобретения для питания определенного узла могут использоваться солнечные батареи. В этом случае узел может оказаться непригодным для выполнения функций локального блока RCU, когда он принудительно переводится в состояние неактивности, например, в ночное время.
В другом варианте осуществления изобретения только часть (или подмножество) функций локального блока RCU передается от одного элемента (от первого узла) к другому элементу (ко второму узлу) в зависимости от информации, принятой от вторых узлов (узлов-кандидатов) и/или информации, самостоятельно полученной первым узлом.
Представленные выше соображения указывают на необходимость передачи функций от текущего элемента вновь определенному (целевому) элементу. Окончательное решение о передаче принимается блоком управления кластерами сети SFN, тем не менее, инициирующее сообщение для передачи может поступать как от центрального, так и от локального блока RCU.
Хорошо известные из существующих сотовых сетей измерения, выполняемые в устройстве, например, межсотовые измерения (в данном контексте их лучше называть измерениями вне сети SFN), могут позволять блокам RCU получать информацию о доступности точек TP для добавления их в SFN-кластер и/или для наделения их функциями локального блока RCU.
На фиг. 9 представлена схема последовательности сообщений, в верхней части которой показаны процедуры с необязательным запросом от локального блока RCU на передачу функций (штриховая линия), предшествующие передаче. Это сообщение может запрашивать передачу в конкретный элемент, например, в станцию eNB, который достаточное количество устройств UE определило посредством измерений как обеспечивающий очень хороший прием. Передача также может запрашиваться без указания целевого элемента, например, чтобы указать на ухудшение качества соединения между блоком RCU и одной или несколькими точками ТР. Запрос может включать в себя результаты измерений, принятые от устройств UE в кластере или результаты измерений, выполненных локальным блоком RCU самостоятельно. Он может включать в себя результаты отдельных измерений или сводную информацию, полученную в результате непрерывных измерений и наблюдений.
Альтернативный вариант показан на фиг. 9 пунктирными линиями. Текущий локальный блок RCU может напрямую отправить запрос в один или несколько элементов-кандидатов, например, в находящиеся поблизости станции eNB, которые в данный момент входят в состав данного кластера (как показано на фиг. 9), а также в находящиеся поблизости станции eNB, которые в данный момент не входят в состав данного кластера, чтобы измерить сигналы восходящего канала (UL), передаваемые устройствами UE в кластере. Ответ на этот запрос, поступивший от других элементов, может содержать результаты измерений и информацию о текущих возможностях, указывающую, можно ли передать этому элементу функции блока RCU кластера, с возможными ограничениями по предельному количеству устройств UE, максимальной полосе пропускания и т.п. Дополнительная информация, например, о распределении ресурсов и/или о показателях нагрузки, также может входить в состав ответов, которые принимаются от различных находящихся поблизости станций eNB, чтобы определить, подходят ли они для выполнения функций блока RCU.
Например, решение о передаче функций блока RCU от одного узла другому узлу может основываться на следующих характеристиках:
- результаты измерений в восходящих каналах (например, выполненных в восходящих каналах базовыми станциями);
- результаты измерений в нисходящих каналах (например, выполненных в нисходящих каналах мобильными устройствами и затем переданные в отчетах);
- возможности узла;
- сведения о конфигурации узла;
- состояние активности;
- использование радиоресурса;
- нагрузка, связанная с обработкой.
В качестве альтернативы очень похожий запрос может быть отправлен из блока управления кластерами сети SFN (центрального блока управления) после приема запроса на передачу функций блока RCU, поступившего от текущего локального блока RCU. В этом альтернативном примере, представленном на фиг. 9, предполагается, что блок управления кластерами сети SFN обладает информацией о возможностях различных находящихся поблизости станций eNB. Поэтому нет необходимости показывать передачу информации о возможностях из различных находящихся поблизости узлов-кандидатов в блок управления кластерами сети SFN (центральный блок управления). На основе запросов, ответов и принятых сообщений обратной связи (таких как результаты измерений и/или информация о местоположении и т.п.) блок управления кластерами сети SFN (центральный блок управления) начинает передачу функций путем указаний исходному и целевому элементам относительно передачи функции локального блока RCU.
Эта передача функций не требует обязательного изменения точек TP, входящих в состав кластера: если исходный блок RCU представляет собой, например, станцию eNB, которая также работает как точка TP, функции точки TP могут оставаться без изменений, чтобы не терять информацию, переданную из устройств UE или в обратном направлении. Эти точки обозначены на фиг. 9 как «(TP)».
Локальный блок RCU кластера может выполнять несколько функций, например, следующие.
Функция А. Распределение данных нисходящего канала (DL) по точкам TP для синхронизированной передачи, т.е. посредством синхронизированной транспортировки или распределения в сочетании с информацией синхронизации, например, с использованием точной синхронизации передачи.
Функция Б. Объединение и/или выбор данных канала UL, принятых различными точками TP, т.е. выбор соответствующего принимающего узла (из всех точек TP кластера), объединение данных из одного устройства UE, которые с избыточностью приняты несколькими точками TP, и пересылка их в сеть.
Функция В. Управление ресурсами, т.е. распределение доступных ресурсов, выделенных для кластера блоком управления кластерами сети SFN (центральным блоком управления), между различными устройствами UE, обслуживаемыми в кластере (в зависимости от запросов устройств UE).
Функция Г. Локальное управление точками TP, т.е. активация и деактивация точек TP для повышения энергоэффективности, и управление мощностью передачи точек TP, т.е. объединение данных управления мощностью, принятых в канале UL, с целью получения значений требуемых мощностей в канале DL для различных точек ТР.
Передача функций локального блока RCU означает передачу описанных выше функций от исходного узла к целевому узлу без прерывания или почти без прерывания обслуживания.
Функция А
Чтобы обеспечить успешное распределение данных во время передачи и после нее, сеть оповещается о маршрутизации трафика через новый локальный блок RCU. Весь трафик, который все еще принимается по старому маршруту (посредством прежнего локального блока RCU), может распределяться в точки TP так же, как и до передачи или может перенаправляться в целевой локальный блок RCU. Трафик через целевой локальный блок RCU предпочтительно распределяется в точки TP только после отправки всего оставшегося трафика исходным локальным блоком RCU. В известных решениях (таких как хэндовер между станциями eNB в системе LTE или подобное изменение узла сети для маршрута данных отдельного устройства UE) исходный узел перенаправляет трафик в целевой узел для передачи в устройство UE. Последний перенаправленный пакет может содержать концевой маркер, указывающий на конец перенаправленных (старых) данных и, таким образом, запускающий распределение новых данных целевым узлом. Особое требование для текущего решения для SFN-кластера заключается в синхронизированном распределении пакетов данных.
Если распределение данных из блоков RCU в точки TP выполняется синхронизированно, т.е. распределение пакетов данных привязано по времени к передаче данных точками TP через радиоинтерфейс, то переключение функции распределения должно быть точно синхронизировано. Для этого необходимо, чтобы исходный блок RCU и целевой блок RCU определили единый момент времени (на основе общего времени) для прекращения распределения данных исходным блоком и начала распределения данных целевым блоком, а также подготовительный этап, чтобы целевой блок мог начать распределение данных в этот момент времени.
Если распределение данных из блоков RCU в точки TP выполняется не синхронизированно, т.е. распределение пакетов данных включает в себя информацию точной синхронизации для каждого пакета, который должен передаваться точками TP, то момент времени переключения может быть согласован между исходным блоком RCU и целевым блоком RCU и оба блока могут начать распределение без синхронизации. В этом случае целевой блок распределяет пакеты для передачи точками TP только после момента переключения, а исходный блок RCU распределяет пакеты только до момента переключения.
Обе эти функции не зависят от того, использовано перенаправление данных или нет, т.е. перенаправление данных из исходного в целевой блок RCU может происходить и после переключения функции распределения.
Функция Б
Чтобы обеспечить успешную передачу функции объединения данных канала UL и выбора точки TP, точки TP кластера должны быть оповещены об изменении локального блока RCU. Требования относительно переключения маршрута в точке TP с исходного блока RCU на целевой блок RCU не являются жесткими, поскольку исходный блок может продолжать выполнять свои функции в канале UL, пока имеются распределяемые данные. Должна предотвращаться только такая ситуация, когда одна точка TP отправляет свои данные восходящего канала в исходный блок RCU, а другая точка отправляет такие же данные в целевой блок RCU. Это может привести к дублированию данных в потоке данных канала UL, направляемом в сеть. Проблему можно решить так же, как и для канала DL: путем синхронизированного переключения или перенаправления данных (чтобы снизить требования к синхронизации в точках TP), например, из исходного блока RCU в целевой блок RCU, и объединения данных только в одном из блоков RCU.
Функция В
Для успешной передачи функции распределения ресурсов целевому блоку RCU должен быть предоставлен пул ресурсов, выделенных SFN-кластеру. Наиболее вероятное решение в этом случае заключается в предоставлении ресурсов из центрального блока управления SFN-кластерами, поскольку он отвечает за общее распределение пула ресурсов (включая аспекты помех между SFN-кластерами). Также возможно перенаправление текущего распределения из исходного локального блока RCU. Чтобы обеспечить оптимальное распределение локальных ресурсов целевым локальным блоком RCU, также должна передаваться вся соответствующая информация контекста, т.е. контекст для конкретных устройств UE, касающийся требуемых ресурсов, подписок на услуги, возможностей, качества канала связи и т.п.
Чтобы целевой локальный блок RCU мог выбрать подходящий ресурс из выделенных ему ресурсов канала DL, текущее распределение ресурсов канала DL должно быть сообщено задолго до фактического распределения данных целевым локальным блоком RCU с использованием этих ресурсов. Чтобы направлять принятые данные надлежащему исходному устройству UE, целевой локальный блок RCU также должен иметь информацию о распределении ресурсов канала UL. Впоследствии целевой локальный блок RCU может в любое время распределять ресурсы канала UL из пула ресурсов в соответствии со своей собственной стратегией распределения.
Функция Г
Для передачи управления локальными точками TP (и некоторых вышеупомянутых функций) прежде всего необходима вся информация о точках TP, входящих в состав кластера. Целевому блоку RCU, помимо данной информации, необходимо знать текущее состояние точек TP (включена или выключена) и, возможно, взаимосвязь точки TP с определенным устройством UE, т.е. сведения о том, требуется ли обычно включенная точка TP, чтобы передавать и принимать данные определенного устройства UE. Некоторые точки TP из кластера могут переходить в «режим молчания» при распределении данных в устройства UE, осуществляющие прием данных с достаточным качеством из других точек TP, и, соответственно, при передаче в канале UL из устройств UE. Эта информация должна передаваться из исходного локального блока RCU или из центрального блока RCU (или из обоих блоков, когда передача информации в целевой локальный блок RCU разделена между этими двумя блоками). В случае передачи функции управления между точками TP обычно предъявляются менее жесткие требования ко времени и синхронизации по сравнению с передачей функций А, Б, В.
На фиг. 10 представлена схема последовательности сообщений для описанного выше обмена информацией между различными элементами с использованием иллюстративных сообщений. Тем не менее, обмен сообщениями может происходить в другой последовательности. При этом может использоваться большее или меньшее количество сообщений.
Y
X
Как показано на фиг. 10, целевой локальный блок RCU (RCU) оповещается исходным локальным блоком RCU (RCU) о передаче функций. Альтернативный вариант представлен на фиг. 9, где и исходный, и целевой локальные блоки RCU оповещаются блоком управления кластерами сети SFN (центральным блоком управления). В представленном примере информация маршрутизации обновляется центральным блоком управления в точках TP (показана только одна точка) и в сети практически одновременно. При передаче функций радиоинтерфейс между устройствами UE и точками TP не изменяется, но трафик канала UL, поступающий в исходный локальный блок RCU, перенаправляется в целевой локальный блок RCU до обновления маршрутизации, чтобы предотвратить дублирование данных. Концевой маркер указывает на прекращение перенаправления данных, чтобы целевой локальный блок RCU мог начать передачу данных канала DL в точки ТР. Возможны другие примеры с другими временными взаимосвязями между сообщениями, т.е. на фиг. 10 представлен только один из множества возможных примеров.
В таблице 1 приведены информационные элементы, которые могут быть включены в содержимое сообщения «Контекст передачи» (см. фиг. 10), а также указаны обязательные (ОБ) и необязательные (НОБ) элементы.
Специалисту в данной области должно быть очевидно, что возможны и другие информационные элементы.
После завершения передачи функций в исходном локальном блоке RCU может быть удален весь контекст, касающийся соответствующего SFN-кластера. Целевой локальный блок RCU может начать управлять SFN-кластером путем распределения ресурсов и т.д.
Целевой локальный блок RCU может сохранить исходный локальный блок RCU в списке последних локальных блоков RCU для данного SFN-кластера, чтобы предотвратить переключение обратно на тот же локальный блок RCU по результатам измерений от устройств UE. Чтобы гарантировать эффективность системы, важно предотвращать возникновение так называемого эффекта «пинг-понг» при передаче функций локального блока RCU.