РАБОТА С МНОЖЕСТВОМ ПЛАНИРОВЩИКОВ В БЕСПРОВОДНОЙ СИСТЕМЕ Российский патент 2016 года по МПК H04W36/00 

Перекрестная ссылка на родственные заявки

По данной заявке испрашивается приоритет на основании предварительной заявки на патент США № 61/692,548, поданной 23 августа 2012 г.; предварительной заявки на патент США № 61/726,448, поданной 14 ноября 2012 г.; предварительной заявки на патент США № 61/753,323, поданной 16 января 2013 г.; предварительной заявки на патент США № 61/753,334, поданной 16 января 2013 г.; предварительной заявки на патент США № 61/821,071, поданной 8 мая 2013 г.; предварительной заявке на патент США № 61/821,186, поданной 8 мая 2013 г.; и предварительной заявки на патент США № 61/863,311, поданной 7 августа 2013 г., содержание которых настоящим включено путем ссылки в полном объеме.

Уровень техники

Системы беспроводной связи получили широкое распространение для обеспечения различных типов контента связи, например голоса, данных и т.д. Эти системы могут быть системами множественного доступа, способными поддерживать связь с множеством пользователей путем совместного использования доступных системных ресурсов (например, полосы пропускания, мощности передачи и т.д.). Примеры таких систем множественного доступа могут включать в себя системы множественного доступа с кодовым разделением (CDMA), системы широкополосного множественного доступа с кодовым разделением (WCDMA), системы множественного доступа с временным разделением (TDMA), системы множественного доступа с частотным разделением (FDMA), системы проекта долгосрочного развития систем связи (LTE) в рамках проекта партнерства третьего поколения (3GPP), и системы множественного доступа с ортогональным частотным разделением (OFDMA) и т.д.

Эти технологии множественного доступа были приняты для обеспечения общего протокола, который позволяет разным беспроводным устройствам осуществлять связь на муниципальном, национальном, региональном и даже глобальном уровне. Примером перспективного стандарта связи является LTE. LTE это набор улучшений до мобильного стандарта «универсальная система мобильной связи» (UMTS), распространяемого 3GPP. LTE призван лучше поддерживать широкополосный мобильный доступ в интернет за счет повышения спектральной эффективности, снижения затрат, улучшения обслуживания, ввода нового спектра и улучшения интегрирования с другими открытыми стандартами с использованием OFDMA на нисходящей линии связи (DL), SC-FDMA на восходящей линии связи (UL) и антенной технологии с множественном входов и множеством выходов (MIMO).

Раскрытие изобретения

Раскрыты системы и способы работы беспроводного приемопередающего блока (WTRU) в системах беспроводной связи, в которых используется множество планировщиков. Например, в некоторых системах с множеством планировщиков, планировщикам может недоставать интерфейса связи с низкой задержкой для координации работы планировщиков, связанной с одним и тем же WTRU. WTRU может обмениваться данными с сетью по более чем одному тракту данных, таким образом, что каждый тракт данных может использовать радиоинтерфейс, соединенный с отдельным узлом сети, и каждый узел может быть связан с независимым планировщиком. Например, WTRU может устанавливать соединение управления радиоресурсами (RRC) между WTRU и сетью. RRC-соединение может устанавливать первый радиоинтерфейс между WTRU и первым обслуживающим участком сети и второй радиоинтерфейс между WTRU и вторым обслуживающим участком сети. Первый обслуживающий участок может быть eNodeB макросоты (MeNB), и второй обслуживающий участок может быть eNodeB малой соты (SCeNB). Между WTRU и MeNB может устанавливаться RRC-соединение, и между WTRU и SCeNB может устанавливаться функция управления. WTRU может принимать данные из сети по первому радиоинтерфейсу или второму радиоинтерфейсу.

В качестве примера, описаны способы и системы для работы WTRU с использованием множества независимо планируемых уровней. Например, WTRU может устанавливать соединение управления радиоресурсами (RRC) с первым обслуживающим участком. WTRU может принимать сообщение переконфигурирования от первого обслуживающего участка. Сообщение переконфигурирования может включать в себя конфигурацию WTRU для соединения с одной или более сотами, связанными со вторым обслуживающим участком. Сообщение переконфигурирования может указывать по меньшей мере один радиоканал-носитель (RB), подлежащий использованию WTRU на втором обслуживающем участие. WTRU может определять необходимость активации соединения со вторым обслуживающим участком. WTRU может отслеживать канал управления по меньшей мере одной из одной или более сот, связанных со вторым обслуживающим участком на основании определения необходимости активации соединения со вторым обслуживающим участком. Например, сообщение переконфигурирования может быть сообщением переконфигурирования RRC-соединения, и по меньшей мере один RB может быть новым RB, установленным для использования на втором обслуживающем участие. В одном примере, сообщение переконфигурирования может быть сообщением переконфигурирования RRC-соединения, которое включает в себя информационный элемент управления мобильностью, причем по меньшей мере один RB может быть RB, который был ранее отображен в первый обслуживающий участок, и сообщение переконфигурирования RRC-соединения может предписывать WTRU начинать связывание RB, который был ранее отображен в первый обслуживающий участок, со вторым обслуживающим участком.

В одном примере, сообщение переконфигурирования может включать в себя множество конфигураций управления радиоресурсами (RRM) для данной соты, связанной со вторым обслуживающим участком. После активации соединения со вторым обслуживающим участком, WTRU может применять принятую по умолчанию конфигурацию RRM из множества конфигураций RRM. WTRU может принимать одну или более из сигнализации физического уровня и сигнализации уровня 2. Одна или более из сигнализации физического уровня и сигнализации уровня 2 может указывать другую конфигурацию RRM из множества конфигураций RRM, которую WTRU должен применять к данной соте второго обслуживающего участка. Затем WTRU может применять другую конфигурацию RRM при соединении с определенной сотой второго обслуживающего участка. Например, одно или более из сигнализации физического уровня и сигнализации уровня 2 может включать в себя одно или более из передачи физического канала управления нисходящей линии связи (PDCCH) и управляющего элемента (CE) управления доступом к среде (MAC). WTRU может определять, какую из множества конфигураций RRM следует применять на основании индекса, принятого в одной или более из сигнализации физического уровня и сигнализации уровня 2. По меньшей мере одна конфигурация RRM из множества конфигураций RRM может включать в себя одно или более из конфигурации физического уровня, конфигурации выдачи отчета об индикаторе качества канала (CQI) или конфигурации MAC.

В одном примере, плоскость управления может быть распределенной по обслуживающим участкам, скоординированной между обслуживающими участками и/или централизованной на одном из обслуживающих участков. Например, сетевой объект RRC, связанный как с первым обслуживающим участком, так и со вторым обслуживающим участком, может располагаться на втором обслуживающем участие. Один или более радиоканалов-носителей сигнализации, заканчивающихся на объекте RRC на первом обслуживающем участке, могут передаваться на WTRU через второй обслуживающий участок. Например, один или более радиоканалов-носителей сигнализации, заканчивающихся на объекте RRC на первом обслуживающем участке, которые передаются на WTRU через второй обслуживающий участок, может быть связан с информацией управления для управления радиоресурсами между WTRU и вторым обслуживающим участком. WTRU может осуществлять одно или более измерений по меньшей мере одной или одной или более сот, связанных со вторым обслуживающим участком. WTRU может сообщать одно или более измерений первому обслуживающему участку.

WTRU может оперировать безопасностью для передач, связанных с первым обслуживающим участком и/или вторым обслуживающим участком с частичной координацией и/или независимо. Например, каждый из первого обслуживающего участка и второго обслуживающего участка может быть связан с независимыми экземплярами протокола конвергенции пакетной передачи данных (PDCP) для WTRU. WTRU может быть выполнен с возможностью использования одного и того ключа безопасности для шифрования пакетов PDCP, подлежащих отправке либо на первый экземпляр PDCP, связанный с первым обслуживающим участком, либо на второй экземпляр PDCP, связанный со вторым обслуживающим участком. Например, WTRU может быть выполнен с возможностью использования отдельного параметра канала-носителя для каждого из первого экземпляра PDCP, связанного с первым обслуживающим участком, и второго экземпляра PDCP, связанного со вторым обслуживающим участком. Например, соответствующий параметр канала-носителя, используемый для шифрования передач на втором объекте PDCP на втором обслуживающем участие может определяться на основании идентификатора уровня, связанного со вторым обслуживающим участком.

WTRU может реализовывать два или более наборов стеков протоколов для плоскости управления и/или плоскости данных. Например, WTRU может включать в себя первый экземпляр управления доступом к среде (MAC), выполненный с возможностью осуществления доступа к сотам, связанным с первым обслуживающим участком, и второй экземпляр MAC, выполненный с возможностью осуществления доступа к сотам, связанным со вторым обслуживающим участком. WTRU может быть конфигурирован данными, связанными с по меньшей мере одним логическим каналом с использованием либо первого экземпляра MAC, либо второго экземпляра MAC. WTRU может быть выполнен с возможностью деактивации по меньшей мере одного канала-носителя, связанного с первым обслуживающим участком на основании активации соединения со вторым обслуживающим участком. WTRU может быть выполнен с возможностью измерения по меньшей мере одной соты, связанной со вторым обслуживающим участком, и определения необходимости автономной активации по меньшей мере одной соты на основании измерений. Сообщение переконфигурирования RRC может включать в себя предварительную конфигурацию для по меньшей мере одной соты, и WTRU может быть выполнен с возможностью автономной активации по меньшей мере одной соты с использованием процедуры канала произвольного доступа (RACH).

RRC-соединение для WTRU может устанавливать один или более SRB между WTRU и сетью, таким образом, что каждый из установленных SRB можно назначать по меньшей мере одному из первого радиоинтерфейса и второго радиоинтерфейса. Принимаемый/передаваемый PDU RRC может быть связан с одним из одного или более SRB. PDU RRC может приниматься по первому радиоинтерфейсу либо второму радиоинтерфейсу независимо от связанного с ним SRB. RRC-соединение может управляться сетью. WTRU может передавать в сеть указание, указывающее, что WTRU поддерживает операцию множественного планирования.

Краткое описание чертежей

Фиг. 1A - системная схема иллюстративной системы связи, в которой один или более раскрытых вариантов осуществления можно реализовать.

Фиг. 1B - системная схема примера беспроводного приемопередающего блока (WTRU), который можно использовать в системе связи, представленной на фиг. 1A.

Фиг. 1C - системная схема примера сети радиодоступа и примера базовой сети, которую можно использовать в системе связи, представленной на фиг. 1A.

Фиг. 1D - системная схема другого примера сети радиодоступа и другого примера базовой сети, которую можно использовать в системе связи, представленной на фиг. 1A.

Фиг. 1E - системная схема другого примера сети радиодоступа и другого примера базовой сети, которую можно использовать в системе связи, представленной на фиг. 1A.

Фиг. 2A демонстрирует пример опорной архитектуры, которая может реализовывать архитектуру с множеством планировщиков.

Фиг. 2B демонстрирует другой пример опорной архитектуры, которая может реализовывать архитектуру с множеством планировщиков.

Фиг. 3 демонстрирует иллюстративную реализацию централизованной плоскости управления.

Фиг. 4 демонстрирует другую иллюстративную реализацию централизованной плоскости управления.

Фиг. 5 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя MeNB, когда экземпляр RRC заканчивается на MeNB на стороне сети.

Фиг. 6 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя SCeNB, когда экземпляр RRC заканчивается на MeNB на стороне сети.

Фиг. 7 демонстрирует пример стека протоколов в плоскости управления для скоординированной плоскости управления, в которой первый экземпляр RRC заканчивается на первом обслуживающем участке, и второй экземпляр RRC заканчивается на втором обслуживающем участке.

Фиг. 8 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя первый обслуживающий участок, когда экземпляр RRC заканчивается на первом обслуживающем участке на стороне сети.

Фиг. 9 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя второй обслуживающий участок, когда экземпляр RRC заканчивается на втором обслуживающем участке на стороне сети.

Фиг. 10 демонстрирует пример стека протоколов в плоскости управления для распределенной плоскости управления, в котором экземпляр RRC заканчивается на первом обслуживающем участке.

Фиг. 11 демонстрирует пример стека протоколов в плоскости управления, содержащего распределенный подход для SRB0, SRB1 и SRB2 законченного экземпляра RRC на первом обслуживающем участке.

Фиг. 12 демонстрирует пример стека протоколов в плоскости управления, содержащего распределенный подход для SRB, связанного со вторым обслуживающим участком.

Фиг. 13 демонстрирует пример стека протоколов, который может использоваться для трактов данных плоскости пользователя, когда тракты данных разделяются над уровнем PDCP в сети.

Фиг. 14 демонстрирует пример стека протоколов, в котором SRB могут быть связаны с одной SAP, и тракты данных разделяются над уровнем PDCP в сети с использованием централизованной плоскости управления.

Фиг. 15 демонстрирует пример тракта данных, разделенного над уровнем PDCP для плоскости пользователя, в котором используется множество SAP DRB.

Фиг. 16 демонстрирует пример стека протоколов, в котором SRB могут быть связаны с множеством SAP, и тракты данных разделяются над уровнем PDCP в сети с использованием централизованной плоскости управления.

Фиг. 17 и 18 - схемы, демонстрирующие примеры стеков протоколов в плоскости пользователя.

Фиг. 19 демонстрирует пример стека протоколов в плоскости управления тракта данных, разделенного над RLC, в котором PDU PDCP могут переноситься по множеству трактов данных.

Фиг. 20 демонстрирует пример тракта данных, связанного с вторичным уровнем, когда разделение данных происходит под уровнем PDCP (например, над уровнем RLC).

Фиг. 21 демонстрирует пример стека протоколов в плоскости управления, который можно использовать, если тракты данных разделяются над уровнем MAC.

Фиг. 22 демонстрирует пример стека протоколов в плоскости пользователя, который можно использовать, если тракты данных разделяются над уровнем MAC.

Фиг. 23 демонстрирует пример структуры уровня 2 для работы на множестве участков восходящей линии связи, которую можно реализовать как схему раздельной передачи UL.

Фиг. 24 демонстрирует пример структуры уровня 2 для работы на множестве участков восходящей линии связи, в котором используется схема передачи RLC с разделением.

Фиг. 25 демонстрирует пример структуры уровня 2, в котором данные для определенного логического канала могут отображаться во множество транспортных каналов, и транспортные каналы могут быть связаны с разными обслуживающими участками.

Фиг. 26 демонстрирует пример структуры уровня 2 для работы на множестве участков нисходящей линии связи, которую можно использовать для схемы раздельной передачи DL.

Фиг. 27 демонстрирует пример структуры уровня 2 для работы на множестве участков нисходящей линии связи, которую можно использовать для схемы передачи DL RLC с разделением.

Фиг. 28 демонстрирует пример структуры уровня 2, в котором данные нисходящей линии связи для определенного логического канала могут отображаться во множество транспортных каналов, и транспортные каналы могут быть связаны с разными обслуживающими участками.

Осуществление изобретения

Ниже со ссылкой на различные чертежи приведено подробное описание иллюстративных вариантов осуществления. Хотя это описание обеспечивает подробный пример возможных реализаций, следует отметить, что детали приведены в порядке примера и не ограничивают объем заявки.

На фиг. 1A показана схема иллюстративной системы 100 связи, в которой можно реализовать один или более раскрытых вариантов осуществления. Система 100 связи может представлять собой систему множественного доступа, которая обеспечивает контент, например голос, данные, видео, обмен сообщениями, широковещательную передачу и т.д., множеству пользователей беспроводной связи. Система 100 связи может позволять множеству пользователей беспроводной связи осуществлять доступ к такому контенту посредством совместного использования системных ресурсов, включающих в себя беспроводную полосу пропускания. Например, системы 100 связи могут использовать один или более способов доступа к каналу, например множественный доступ с кодовым разделением (CDMA), множественный доступ с временным разделением (TDMA), множественный доступ с частотным разделением (FDMA), ортогональный FDMA (OFDMA), FDMA на одной несущей (SC-FDMA) и пр.

Как показано на фиг. 1A, система 100 связи может включать в себя беспроводные приемопередающие блоки (WTRU) 102a, 102b, 102c и/или 102d (которые в целом или совместно могут именоваться WTRU 102), сеть 103/104/105 радиодоступа (RAN), базовую сеть 106/107/109, коммутируемую телефонную сеть 108 общего пользования (PSTN), интернет 110 и другие сети 112, хотя очевидно, что раскрытые варианты осуществления предусматривают любое количество WTRU, базовых станций, сетей и/или сетевых элементов. Каждый из WTRU 102a, 102b, 102c, 102d может быть устройством любого типа, выполненным с возможностью работы и/или связи в беспроводной среде. В порядке примера, WTRU 102a, 102b, 102c, 102d могут быть выполнены с возможностью передачи и/или приема беспроводных сигналов и могут включать в себя пользовательское устройство (UE), мобильную станцию, стационарный или мобильный абонентский блок, пейджер, сотовый телефон, карманный персональный компьютер (КПК), смартфон, портативный компьютер, нетбук, персональный компьютер, беспроводной датчик, бытовую электронику и пр.

Системы 100 связи также могут включать в себя базовую станцию 114a и базовую станцию 114b. Каждая из базовых станций 114a, 114b может представлять собой устройство любого типа, выполненное с возможностью беспроводной связи с по меньшей мере одним из WTRU 102a, 102b, 102c, 102d для облегчения доступа к одной или более сетям связи, например, базовой сети 106/107/109, интернету 110 и/или сетям 112. В порядке примера, базовые станции 114a, 114b могут представлять собой базовую приемопередающую станцию (BTS), Node-B, eNode B, домашний узел B, домашний eNode B, контроллер участка, точку доступа (AP), беспроводной маршрутизатор и пр. Хотя каждая из базовых станций 114a, 114b изображены как один элемент, очевидно, что базовые станции 114a, 114b могут включать в себя любое количество соединенных между собой базовых станций и/или сетевых элементов.

Базовая станция 114a может входить в состав RAN 103/104/105, которая также может включать в себя другие базовые станции и/или сетевые элементы (не показаны), например, контроллер базовых станций (BSC), контроллер радиосети (RNC), ретрансляционные узлы и т.д. Базовая станция 114a и/или базовая станция 114b может быть выполнена с возможностью передачи и/или приема беспроводных сигналов в конкретной географической области, которая может именоваться сотой (не показана). Сота может дополнительно делиться на секторы соты. Например, сота, связанная с базовой станцией 114a, может делиться на три сектора. Таким образом, в одном варианте осуществления, базовая станция 114a может включать в себя три приемопередатчика, т.е. по одному на каждый сектор соты. В другом варианте осуществления, базовая станция 114a может использовать технологию с множеством входов и множеством выходов (MIMO) и, таким образом, может использовать множество приемопередатчиков для каждого сектора соты.

Базовые станции 114a, 114b могут осуществлять связь с одним или более из WTRU 102a, 102b, 102c, 102d по радиоинтерфейсу 115/116/117, которым может быть любая пригодная беспроводная линия связи (например, радиочастотная (РЧ), микроволновая, инфракрасная (ИК), ультрафиолетовая (УФ), видимого света и т.д.). Радиоинтерфейс 115/116/117 может устанавливаться с использованием любой пригодной технологии радиодоступа (RAT).

В частности, как упомянуто выше, система 100 связи может быть системой множественного доступа и может использовать одну или более схем доступа к каналу, например, CDMA, TDMA, FDMA, OFDMA, SC-FDMA и пр. Например, базовая станция 114a в RAN 103/104/105 и WTRU 102a, 102b, 102c может реализовать технологию радиосвязи, например, наземного радиодоступа (UTRA) универсальной системы мобильной связи (UMTS), которая может устанавливать радиоинтерфейс 115/116/117 с использованием широкополосного CDMA (WCDMA). WCDMA может включать в себя протоколы связи, например, высокоскоростной пакетный доступ (HSPA) и/или усовершенствованный HSPA (HSPA+). HSPA может включать в себя высокоскоростной пакетный доступ нисходящей линии связи (HSDPA) и/или высокоскоростной пакетный доступ восходящей линии связи (HSUPA).

В другом варианте осуществления, базовая станция 114a и WTRU 102a, 102b, 102c могут реализовать технологию радиосвязи, например усовершенствованного наземного радиодоступа UMTS (E-UTRA), которая может устанавливать радиоинтерфейс 115/116/117 с использованием проекта долгосрочного развития систем связи (LTE) и/или LTE-Advanced (LTE-A).

В других вариантах осуществления, базовая станция 114a и WTRU 102a, 102b, 102c могут реализовывать технологии радиосвязи, например, IEEE 802.16 (т.е. Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN) и пр.

Базовая станция 114b, показанная на фиг. 1A, может представлять собой, например, беспроводной маршрутизатор, домашний узел B, домашний eNode B или точку доступа и может использовать любую пригодную RAT для облегчения возможности беспроводного соединения в ограниченной области, например, в торговом помещении, дома, в автомобиле, в общежитии и пр. В одном варианте осуществления, базовая станция 114b и WTRU 102c, 102d могут реализовать технологию радиосвязи, например IEEE 802.11 (например, 802.11ac, 802.11af, и пр.) для установления беспроводной локальной сети (WLAN). В другом варианте осуществления, базовая станция 114b и WTRU 102c, 102d могут реализовать технологию радиосвязи, например IEEE 802.15 для установления беспроводной персональной сети (WPAN). В еще одном варианте осуществления, базовая станция 114b и WTRU 102c, 102d могут использовать RAT на сотовой основе (например, WCDMA, CDMA2000, GSM, LTE, LTE-A и т.д.) для установления пикосоты или фемтосоты. Как показано на фиг. 1A, базовая станция 114b может иметь прямое соединение с интернетом 110. Таким образом, базовая станция 114b может не требоваться для осуществления доступа к интернету 110 через базовую сеть 106/107/109.

RAN 103/104/105 может сообщаться с базовой сетью 106/107/109, которая может быть сетью любого типа, выполненной с возможностью предоставления услуг голосовой связи, передачи данных, приложений и/или голосовой связи по интернет-протоколу (VoIP) одному или более из WTRU 102a, 102b, 102c, 102d. Например, базовая сеть 106/107/109 может предоставлять услуги управления вызовом, услуги тарификации, услуги на основе местоположения мобильного абонента, услуги предоплаченного вызова, возможность соединения с интернетом, распространения видеоматериалов и т.д. и/или осуществляют высокоуровневые функции безопасности, например аутентификацию пользователя. Хотя это не показано на фиг. 1A, очевидно, что RAN 103/104/105 и/или базовая сеть 106/107/109 могут осуществлять прямую или косвенную связь с другими RAN, которые применяют такую же RAT, как RAN 103/104/105 или другую RAT. Например, помимо соединения с RAN 103/104/105, которая может использовать технологию радиосвязи E-UTRA, базовая сеть 106/107/109 также может сообщаться с другой RAN (не показана), применяющей технологию радиосвязи GSM.

Базовая сеть 106/107/109 также может служить шлюзом для WTRU 102a, 102b, 102c, 102d для осуществления доступа к PSTN 108, интернету 110 и/или другим сетям 112. PSTN 108 может включать в себя телефонные сети с коммутацией каналов, которые обеспечивают простую старую телефонную службу (POTS). Интернет 110 может включать в себя глобальную систему соединенных между собой компьютерных сетей и устройств, которые используют общие протоколы связи, например протокол управления передачей (TCP), протокол пользовательских дейтаграмм (UDP) и интернет-протокол (IP) в комплекте интернет-протоколов TCP/IP. Сети 112 могут включать в себя сети проводной или беспроводной связи, находящиеся в собственности и/или эксплуатации других поставщиков услуг. Например, сети 112 могут включать в себя другую базовую сеть, соединенную с одной или более RAN, которая может использовать такую же RAT, как RAN 103/104/105 или другую RAT.

Некоторые или все из WTRU 102a, 102b, 102c, 102d в системе 100 связи могут включать в себя многорежимные возможности, т.е. WTRU 102a, 102b, 102c, 102d могут включать в себя множество приемопередатчиков для осуществления связи с разными беспроводными сетями по разным беспроводным линиям связи. Например, WTRU 102c, показанный на фиг. 1A, может быть выполнен с возможностью осуществления связи с базовой станцией 114a, которая может использовать технологию радиосвязи на сотовой основе, и с базовой станцией 114b, которая может использовать технологию радиосвязи IEEE 802.

На фиг. 1B показана системная схема примера WTRU 102. Как показано на фиг. 1B, WTRU 102 может включать в себя процессор 118, приемопередатчик 120, приемопередающий элемент 122, громкоговоритель/микрофон 124, кнопочную панель 126, дисплей/сенсорную панель 128, стационарную память 130, сменную память 132, источник 134 питания, чипсет 136 глобальной системы позиционирования (GPS) и другие периферийные устройства 138. Очевидно, что WTRU 102 может включать в себя любую подкомбинацию вышеупомянутых элементов, в то же время, согласуясь с вариантом осуществления. Кроме того, варианты осуществления предусматривают, что базовые станции 114a и 114b, и/или узлы, которые могут представлять, например, базовые станции 114a и 114b, но без ограничения, приемопередающую станцию (BTS), Node-B, контроллер участка, точку доступа (AP), домашний node-B, усовершенствованный домашний node-B (eNodeB), домашний усовершенствованный node-B (HeNB), шлюз домашнего усовершенствованного node-B и промежуточные узлы, в том числе, могут включать в себя некоторые или все из элементов, изображенных на фиг. 1B и описанных здесь.

Процессор 118 может быть процессором общего назначения, процессором специального назначения, традиционным процессором, цифровым сигнальным процессором (DSP), множеством микропроцессоров, одним или более микропроцессорами совместно с ядром DSP, контроллером, микроконтроллером, специализированными интегральными схемами (ASIC), схемами на основе вентильной матрицы, программируемой пользователем (FPGA), интегральной схемой (ИС) любого другого типа, конечным автоматом и пр. Процессор 118 может осуществлять кодирование сигнала, обработку данных, управление мощностью, входную/выходную обработку и/или любые другие функциональные возможности, которые позволяют WTRU 102 работать в беспроводной среде. Процессор 118 может быть соединен с приемопередатчиком 120, который может быть соединен с приемопередающим элементом 122. Хотя на фиг. 1B процессор 118 и приемопередатчик 120 показаны как отдельные компоненты, очевидно, что процессор 118 и приемопередатчик 120 могут быть объединены друг с другом в электронной упаковке или микросхеме.

Приемопередающий элемент 122 может быть выполнен с возможностью передачи сигналов на, или приема сигналов от базовой станции (например, базовой станции 114a) по радиоинтерфейсу 115/116/117. Например, в одном варианте осуществления, приемопередающий элемент 122 может представлять собой антенну, выполненную с возможностью передачи и/или приема РЧ сигналов. В другом варианте осуществления, приемопередающий элемент 122 может представлять собой излучатель/детектор, выполненный с возможностью передачи и/или приема, например, сигналов ИК, УФ или видимого света. В еще одном варианте осуществления, приемопередающий элемент 122 может быть выполнен с возможностью передачи и приема РЧ и световых сигналов. Очевидно, что приемопередающий элемент 122 может быть выполнен с возможностью передачи и/или приема любой комбинации беспроводных сигналов.

Кроме того, хотя приемопередающий элемент 122 изображен на фиг. 1B как один элемент, WTRU 102 может включать в себя любое количество приемопередающих элементов 122. В частности, WTRU 102 может использовать технологию MIMO. Таким образом, в одном варианте осуществления, WTRU 102 может включать в себя два или более приемопередающих элементов 122 (например, множество антенн) для передачи и приема беспроводных сигналов по радиоинтерфейсу 115/116/117.

Приемопередатчик 120 может быть выполнен с возможностью модуляции сигналов, которые подлежат передаче приемопередающим элементом 122, и демодуляции сигналов, которые принимаются приемопередающим элементом 122. Как упомянуто выше, WTRU 102 может иметь многорежимные возможности. Таким образом, приемопередатчик 120 может включать в себя множество приемопередатчиков, чтобы WTRU 102 мог осуществлять связь посредством множества RAT, например UTRA и IEEE 802.11.

Процессор 118 WTRU 102 может быть соединен с громкоговорителем/микрофоном 124, кнопочной панелью 126 и/или дисплеем/сенсорной панелью 128 (например, блоком отображения на основе жидкокристаллического дисплея (ЖКД) или блоком отображения на основе органических светодиодов (ОСИД)) и может принимать данные пользовательского ввода от них. Процессор 118 также может выводить пользовательские данные на громкоговоритель/микрофон 124, кнопочную панель 126 и/или дисплей/сенсорную панель 128. Кроме того, процессор 118 может обращаться к информации из, и сохранять данные в, памяти любого пригодного типа, например, стационарной памяти 130 и/или сменной памяти 132. Стационарная память 130 может включать в себя оперативную память (ОЗУ), постоянную память (ПЗУ), жесткий диск, или запоминающее устройство любого другого типа. Сменная память 132 может включать в себя карту модуля идентификации абонента (SIM), карту памяти, карту памяти типа "secure digital" (SD) и пр. В других вариантах осуществления, процессор 118 может обращаться к информации из, и сохранять данные в, памяти, которая физически располагается не на WTRU 102, например, на сервере или домашнем компьютере (не показан).

Процессор 118 может получать питание от источника 134 питания и может быть выполнен с возможностью распределения питания на другие компоненты WTRU 102 и/или управления их мощностью. Источником 134 питания может быть любое пригодное устройство для обеспечения питания WTRU 102. Например, источник 134 питания может включать в себя одну или более батарей сухих элементов (например, никель-кадмиевых (NiCd), никель-цинковых (NiZn), никель-металл-гидридных (NiMH), литий-ионных (Li-ion) и т.д.), солнечные элементы, топливные элементы и пр.

Процессор 118 также может быть соединен с чипсетом 136 GPS, который может быть выполнен с возможностью обеспечения информации местоположения (например, долготы и широты) в отношении текущего местоположения WTRU 102. Помимо или вместо информации из чипсета 136 GPS, WTRU 102 может принимать информацию местоположения по радиоинтерфейсу 115/116/117 от базовой станции (например, базовых станций 114a, 114b) и/или определять свое местоположение на основании хронирования сигналов, принимаемых от двух или более близлежащих базовых станций. Очевидно, что WTRU 102 может получать информацию местоположения посредством любой пригодной реализации определения местоположения, в то же время, согласуясь с вариантом осуществления.

Процессор 118 может быть дополнительно соединен с другими периферийными устройствами 138, которые могут включать в себя один или более программных и/или аппаратных модулей, которые обеспечивают дополнительные признаки, функциональные возможности и/или возможность проводного или беспроводного соединения. Например, периферийные устройства 138 может включать в себя акселерометр, электронный компас, спутниковый приемопередатчик, цифровую камеру (для фото- или видеосъемки), порт универсальной последовательной шины (USB), вибрационное устройство, телевизионный приемопередатчик, гарнитуру для высвобождения рук, модуль Bluetooth®, радиоприемник частотной модуляции (FM), цифровой музыкальный проигрыватель, медиаплеер, видеоигровой модуль, интернет-браузер и пр.

На фиг. 1C показана системная схема RAN 103 и базовой сети 106 согласно варианту осуществления. Как упомянуто выше, RAN 103 может использовать технологию радиосвязи UTRA для осуществления связи с WTRU 102a, 102b, 102c по радиоинтерфейсу 115. RAN 103 также может сообщаться с базовой сетью 106. Как показано на фиг. 1C, RAN 103 может включать в себя Node-B 140a, 140b, 140c, каждый из которых может включать в себя один или более приемопередатчиков для осуществления связи с WTRU 102a, 102b, 102c по радиоинтерфейсу 115. Каждый из Node-B 140a, 140b, 140c может быть связан с конкретной сотой (не показана) в RAN 103. RAN 103 также может включать в себя RNC 142a, 142b. Очевидно, что RAN 103 может включать в себя любое количество Node-B и RNC, в то же время, согласуясь с вариантом осуществления.

Как показано на фиг. 1C, Node-B 140a, 140b могут сообщаться с RNC 142a. Дополнительно, Node-B 140c может сообщаться с RNC142b. Node-B 140a, 140b, 140c могут осуществлять связь с соответствующими RNC 142a, 142b через интерфейс Iub. RNC 142a, 142b могут сообщаться друг с другом через интерфейс Iur. Каждый из RNC 142a, 142b может быть выполнен с возможностью управления соответствующими Node-B 140a, 140b, 140c, с которыми он соединен. Кроме того, каждый из RNC 142a, 142b может быть выполнен с возможностью осуществления или поддержки других функциональных возможностей, например, управления мощностью по внешнему циклу, управления нагрузкой, управления допуском, планирования пакетов, управления передачей обслуживания, макроразнесения, функций безопасности, шифрования данных и пр.

Базовая сеть 106, показанная на фиг. 1C может включать в себя медиашлюз (MGW) 144, центр коммутации мобильной связи (MSC) 146, обслуживающий узел 148 поддержки GPRS (SGSN) и/или узел 150 шлюза поддержки GPRS (GGSN). Хотя каждый из вышеупомянутых элементов изображен как часть базовой сети 106, очевидно, что любой из этих элементов может находиться в собственности и/или эксплуатации объекта, отличного от оператора базовой сети.

RNC 142a в RAN 103 может быть соединен с MSC 146 в базовой сети 106 через интерфейс IuCS. MSC 146 может быть соединен с MGW 144. MSC 146 и MGW 144 могут снабжать WTRU 102a, 102b, 102c доступом к сетям с коммутацией каналов, например PSTN 108, для облегчения связи между WTRU 102a, 102b, 102c и традиционными устройствами стационарной связи.

RNC 142a в RAN 103 также может быть соединен с SGSN 148 в базовой сети 106 через интерфейс IuPS. SGSN 148 может быть соединен с GGSN 150. SGSN 148 и GGSN 150 могут снабжать WTRU 102a, 102b, 102c доступом к сетям с коммутацией пакетов, например интернету 110, для облегчения связи между WTRU 102a, 102b, 102c и устройствами на основе IP.

Как упомянуто выше, базовая сеть 106 также может быть соединена с сетями 112, которые могут включать в себя другие проводные или беспроводные сети, которые находятся в собственности и/или эксплуатации других поставщиков услуг.

На фиг. 1D показана системная схема RAN 104 и базовой сети 107 согласно варианту осуществления. Как упомянуто выше, RAN 104 может использовать технологию радиосвязи E-UTRA для осуществления связи с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. RAN 104 также может сообщаться с базовой сетью 107.

RAN 104 может включать в себя eNode-B 160a, 160b, 160c, хотя очевидно, что RAN 104 может включать в себя любое количество eNode-B, в то же время, согласуясь с вариантом осуществления. Каждый eNode-B 160a, 160b, 160c может включать в себя один или более приемопередатчиков для осуществления связи с WTRU 102a, 102b, 102c по радиоинтерфейсу 116. В одном варианте осуществления, eNode-B 160a, 160b, 160c могут реализовывать технологию MIMO. Таким образом, eNode-B 160a, например, может использовать множество антенн для передачи беспроводных сигналов на WTRU 102a и приема беспроводных сигналов от него.

Каждый из eNode-B 160a, 160b, 160c может быть связан с конкретной сотой (не показана) и может быть выполнен с возможностью принятия решений по управлению радиоресурсами, решений по передаче обслуживания, планирования пользователей на восходящей линии связи и/или нисходящей линии связи и пр. Как показано на фиг. 1D, eNode-B 160a, 160b, 160c могут осуществлять связь друг с другом по интерфейсу X2.

Базовая сеть 107, показанная на фиг. 1D, может включать в себя шлюз 162 управления мобильностью (MME), обслуживающий шлюз 164 и шлюз 166 сети пакетных данных (PDN). Хотя каждый из вышеупомянутых элементов изображен как часть базовой сети 107, очевидно, что любой из этих элементов может находиться в собственности и/или эксплуатации объекта, отличного от оператора базовой сети.

MME 162 может быть соединен с каждым из eNode-B 160a, 160b, 160c в RAN 104 через интерфейс S1 и может выступать в роли узла управления. Например, MME 162 может отвечать за аутентификацию пользователей WTRU 102a, 102b, 102c, активацию/деактивацию канала-носителя, выбор конкретного обслуживающего шлюза в ходе начального соединения WTRU 102a, 102b, 102c и пр. MME 162 также может обеспечивать функцию плоскости управления для переключения между RAN 104 и другими RAN (не показаны), в которой применяются другие технологии радиосвязи, например GSM или WCDMA.

Обслуживающий шлюз 164 может быть соединен с каждым из eNode-B 160a, 160b, 160c в RAN 104 через интерфейс S1. Обслуживающий шлюз 164 может, в целом, маршрутизировать и ретранслировать пользовательские пакеты данных на/от WTRU 102a, 102b, 102c. Обслуживающий шлюз 164 также может осуществлять другие функции, например, привязку плоскостей пользователя при выполнении операций передачи обслуживания между eNode B, запуск поискового вызова при наличии данных нисходящей линии связи для WTRU 102a, 102b, 102c, управление и сохранение контекстов WTRU 102a, 102b, 102c, и пр.

Обслуживающий шлюз 164 также может быть соединен со шлюзом 166 PDN, который может снабжать WTRU 102a, 102b, 102c доступом к сетям с коммутацией пакетов, например интернету 110, для облегчения связи между WTRU 102a, 102b, 102c и устройствами на основе IP.

Базовая сеть 107 может облегчать связь с другими сетями. Например, базовая сеть 107 могут снабжать WTRU 102a, 102b, 102c доступом к сетям с коммутацией каналов, например PSTN 108, для облегчения связи между WTRU 102a, 102b, 102c и традиционными устройствами стационарной связи. Например, базовая сеть 107 может включать в себя, или может осуществлять связь с, IP-шлюзом (например, сервером IP мультимедийной подсистемы (IMS)) который служит интерфейсом между базовой сетью 107 и PSTN 108. Кроме того, базовая сеть 107 могут снабжать WTRU 102a, 102b, 102c доступом к сетям 112, которые могут включать в себя другие проводные или беспроводные сети, которые находятся в собственности и/или эксплуатации других поставщиков услуг.

На фиг. 1E показана системная схема RAN 105 и базовой сети 109 согласно варианту осуществления. RAN 105 может представлять собой сеть для доступа к услугам (ASN), в которой используется технология радиосвязи IEEE 802.16 для осуществления связи с WTRU 102a, 102b, 102c по радиоинтерфейсу 117. Как будет дополнительно рассмотрено ниже, линии связи между разными функциональными объектами WTRU 102a, 102b, 102c, RAN 105 и базовой сетью 109 можно определить как опорные точки.

Как показано на фиг. 1E, RAN 105 может включать в себя базовые станции 180a, 180b, 180c и шлюз 182 ASN, хотя очевидно, что RAN 105 может включать в себя любое количество базовых станций и шлюзов ASN, в то же время, согласуясь с вариантом осуществления. Каждая из базовых станций 180a, 180b, 180c может быть связана с конкретной сотой (не показана) в RAN 105 и может включать в себя один или более приемопередатчиков для осуществления связи с WTRU 102a, 102b, 102c по радиоинтерфейсу 117. В одном варианте осуществления, базовые станции 180a, 180b, 180c могут реализовывать технологию MIMO. Таким образом, базовая станция 180a, например, может использовать множество антенн для передачи беспроводных сигналов на WTRU 102a и приема беспроводных сигналов от него. Базовые станции 180a, 180b, 180c также могут обеспечивать функции управления мобильностью, например, запуск передачи обслуживания, установление туннеля, управление радиоресурсами, классификацию трафика, реализацию политики качества обслуживания (QoS) и пр. Шлюз 182 ASN может выступать в роли точки агрегации трафика и может отвечать за поисковый вызов, кэширование профилей абонентов, маршрутизацию в базовую сеть 109 и пр.

Радиоинтерфейс 117 между WTRU 102a, 102b, 102c и RAN 105 можно определить как опорную точку R1, которая реализует спецификацию IEEE 802.16. Кроме того, каждый из WTRU 102a, 102b, 102c может устанавливать логический интерфейс (не показан) с базовой сетью 109. Логический интерфейс между WTRU 102a, 102b, 102c и базовой сетью 109 можно определить как опорную точку R2, которую можно использовать для аутентификации, авторизации, управления конфигурацией IP-хоста и/или управления мобильностью.

Линию связи между каждой из базовых станций 180a, 180b, 180c можно определить как опорную точку R8, которая включает в себя протоколы для облегчения операций передачи обслуживания WTRU и переноса данных между базовыми станциями. Линия связи между базовыми станциями 180a, 180b, 180c и шлюзом 182 ASN можно определить как опорную точку R6. Опорная точка R6 может включать в себя протоколы для облегчения управления мобильностью на основании событий мобильности, связанных с каждым из WTRU 102a, 102b, 102c.

Как показано на фиг. 1E, RAN 105 может быть соединена с базовой сетью 109. Линия связи между RAN 105 и базовой сетью 109 можно определить как опорную точку R3, которая включает в себя протоколы, например, для облегчения переноса данных и обеспечения возможностей управления мобильностью. Базовая сеть 109 может включать в себя домашний агент мобильного IP (MIP-HA) 184, сервер 186 аутентификации, авторизации и ведения учетных записей (AAA) и шлюз 188. Хотя каждый из вышеупомянутых элементов изображен как часть базовой сети 109, очевидно, что любой из этих элементов может находиться в собственности и/или эксплуатации объекта, отличного от оператора базовой сети.

MIP-HA может отвечать за управление IP-адресами, и может позволять WTRU 102a, 102b, 102c переходить между разными ASN и/или разными базовыми сетями. MIP-HA 184 могут снабжать WTRU 102a, 102b, 102c доступом к сетям с коммутацией пакетов, например интернету 110, для облегчения связи между WTRU 102a, 102b, 102c и устройствами на основе IP. Сервер 186 AAA может отвечать за аутентификацию пользователя и за поддержку обслуживания пользователя. Шлюз 188 может облегчать взаимодействие с другими сетями. Например, шлюз 188 может снабжать WTRU 102a, 102b, 102c доступом к сетям с коммутацией каналов, например PSTN 108, для облегчения связи между WTRU 102a, 102b, 102c и традиционными устройствами стационарной связи. Кроме того, шлюз 188 может снабжать WTRU 102a, 102b, 102c доступом к сетям 112, которые могут включать в себя другие проводные или беспроводные сети, которые находятся в собственности и/или эксплуатации других поставщиков услуг.

Хотя это не показано на фиг. 1E, очевидно, что RAN 105 может быть соединена с другими ASN, и базовая сеть 109 может быть соединена с другими базовыми сетями. Линию связи между RAN 105 и другими ASN можно определить как опорную точку R4, которая может включать в себя протоколы для координации мобильности WTRU 102a, 102b, 102c между RAN 105 и другими ASN. Линию связи между базовой сетью 109 и другими базовыми сетями можно определить как опорную точку R5, которая может включать в себя протоколы для облегчения взаимодействия между домашними базовыми сетями и посещаемыми базовыми сетями.

Раскрыты системы и способы использования многоузлового планирования, позволяющие WTRU обмениваться данными по сети беспроводной связи с использованием более чем одного тракта данных. Например, разные точки передачи/приема радиоинтерфейса могут быть связаны с каждым из трактов данных (например, каждый тракт данных может использовать радиоинтерфейс, который связан с отдельным узлом сети). Разные точки передачи/приема, связанные с разными трактами данных, могут независимо планировать передачи WTRU по их соответствующему тракту данных. Другими словами, первый планировщик может планировать передачи на/от WTRU по первому тракту данных, и второй планировщик может планировать передачи на/от WTRU по второму тракту данных. Разные точки передачи/приема в сети могут сообщаться друг с другом; однако линии передачи данных между разными точками передачи/приема могут быть связаны с относительно высокой задержкой. Таким образом, может быть трудно или непрактично, чтобы разные точки передачи/приема осуществляли скоординированное планирование передач по трактам данных. Таким образом, каждая точка передачи/приема может независимо планировать WTRU для передачи и/или приема по соответствующему тракту передачи. Такие точки передачи/приема могут именоваться обслуживающими участками.

Приведенные здесь примеры можно описать применительно к примерам, реализованным в усовершенствованной универсальной наземной сети радиодоступа (E-UTRAN). Однако раскрытые здесь способы и системы могут применяться к другим сетевым архитектурам и/или использоваться другими узлами сети. Данные, передаваемые на обслуживающий участок (или принимаемые от него) для WTRU, могут поступать в базовую сеть (например, обслуживающий шлюз (S-GW)) (из нее). Обслуживающий участок может поддерживать один или более протоколов уровня 2 (например, MAC, RLC и/или PDCP) для определенного радиоканала-носителя.

Например, WTRU может устанавливать соединение управления радиоресурсами (RRC) между WTRU и сетью беспроводной связи. RRC-соединение может устанавливать или конфигурирует первый радиоинтерфейс между WTRU и первым узлом сети и второй радиоинтерфейс между WTRU и вторым узлом сети. Первый узел может быть eNodeB макросоты (MeNB), и второй узел может быть eNodeB малой соты (SCeNB). В одном примере, между WTRU и MeNB может устанавливаться RRC-соединение, и между WTRU и SCeNB может устанавливаться функция управления. WTRU может принимать данные из сети по первому радиоинтерфейсу и/или второму радиоинтерфейсу. Хотя приведенные здесь можно описать примеры в отношении операции, использующей первый тракт данных (например, также может именоваться первым уровнем, первичным трактом данных, первичным уровнем и т.д.), который связан с MeNB и второй тракт данных (например, также могут именоваться вторым уровнем, вторичным трактом данных, вторичным уровнем и т.д.), описанные здесь способы и системы в равной степени применимы к другим точкам передачи/приема сети, которые независимо планируются (например, двум или более независимо планируемым eNB, двум или более независимо планируемым NB, двум или более независимо планируемым узлам доступа к RAN и т.д.).

Описанные здесь системы и способы можно применять к одной или более инфраструктур с множеством планировщиков, в которых разные узлы сети служат точками передачи/приема для разных трактов данных. Использование множества трактов данных можно облегчить путем отмены соотношения между каналами-носителями, радиоканалами-носителями и/или т.п. Например, в случае использования инфраструктуры с множеством планировщиков канал-носитель усовершенствованной пакетной службы (EPS) может быть связан с множеством радиоканалов-носителей. При использовании режима работы с множеством планировщиков WTRU может быть выполнен с возможностью обмена сигнализацией управления и/или данными плоскости пользователя по одному или более трактам данных.

Тракт данных можно задавать на основании идентификатора одной или более точек доступа к услуге (SAP), которые используются для передачи данных, связанных с трактом данных, на основании идентификатора одного или более сетевых интерфейсов или узлов, которые используются для передачи данных, связанных с трактом данных, на основании одного или более радиоинтерфейсов (например, X2, X2bis, X2′, Uu и т.д.), которые используются для передачи данных, связанных с трактом данных и/или т.п. Дополнительно, тракт данных можно задавать на основании стека протоколов связи (например, включающего в себя один или более из уровня протокола конвергенции пакетной передачи данных (PDCP), уровня управления линией радиосвязи (RLC), уровня управления доступом к среде (MAC), физического уровня (PHY) и т.д.) который можно использовать для задания последовательности обработки для переноса информации, связанной с трактом данных. Информация или данные, передаваемые по тракту данных, может включать в себя одни или более из данных плоскости управления (например, сигнализации слоя без доступа (NAS), сигнализации RRC и т.д.) и/или данных плоскости пользователя (например, IP-пакетов и т.д.). Тракты данных можно независимо планировать из других трактов данных.

Например, в LTE выпуск 11, перенос данных может осуществляться по одному тракту данных между WTRU и сетью. Для плоскости управления, может существовать прямое отображение между SRB и логическим каналом (LCH) по одному интерфейсу Uu (например, интерфейсу между WTRU и eNB). Для плоскости пользователя, может существовать прямое отображение между каналом-носителем EPS, радиоканалом-носителем данных (DRB) и логическим каналом (LCH) по тому же интерфейсу Uu.

Однако при наличии множества независимых планировщиков, WTRU может быть выполнен с возможностью использования более чем одного тракта данных, например, когда каждый тракт данных может устанавливаться между WTRU и узлами сети с использованием разных интерфейсов Uu. Тракт данных также может именоваться уровнем. Например, WTRU может быть выполнен с возможностью передачи и/или приема данных по множеству уровней, причем каждый уровень связан с отдельным трактом данных. Каждый уровень можно планировать независимо от других уровней. Каждый уровень может быть связан с отдельным радиоинтерфейсом для WTRU. Каждый уровень может быть связан с обслуживающим участком, который обслуживает точку передачи и/или приема для тракта данных в сети.

Для поддержки передач по множеству уровней, на WTRU может устанавливаться множество экземпляров MAC. Например, WTRU может быть конфигурирован с множеством экземпляров MAC, каждый из которых связан с соответствующим набором параметров физического уровня и/или радиоканалами-носителями, зависящими от уровня. В порядке примера, WTRU может быть конфигурирован набором информации первичного уровня (который, например, может быть связан с макроуровнем/MeNB/обслуживающим макроучастком), и один или более наборов информации вторичного уровня (который, например, может быть связан с уровнем малых сот/SCeNB/обслуживающим участком малой соты). WTRU может быть конфигурирован одной или более обслуживающих сот для каждого уровня. Например, WTRU может осуществлять агрегацию несущих на каждом из уровней таким образом, что передача и/или прием может происходить из множества сот на определенном уровне.

Например, WTRU может быть выполнен с возможностью работы с одним или более обслуживающих участков (например, также именуемых обслуживающими eNB) на нисходящей линии связи и/или восходящей линии связи. Каждый обслуживающий участок может быть связан с одной или более обслуживающих сот. Например, WTRU может работать с использованием одной обслуживающей соты (например, компонентной несущей) на первом обслуживающем участке (например, MeNB) и может работать с использованием множества обслуживающих сот (например, множества компонентных несущих) на втором обслуживающем участке (например, SCeNB). Таким образом, обслуживающий участок может быть связан с множеством обслуживающих сот. Каждая обслуживающая сота определенного обслуживающего участка может быть конфигурирован для работы на соответствующей компонентной несущей (CC). Обслуживающий участок может поддерживать одну или несколько CC. Каждая CC на обслуживающем участке может работать с использованием другого диапазона частот, чем другие CC обслуживающего участка, в связи с чем, каждая из обслуживающих сот, связанных с определенным обслуживающим участком, может передаваться с использованием отдельной CC. Однако обслуживающие соты от разных обслуживающих участков могут передаваться с использованием одной и той же CC. Таким образом, обслуживающие соты могут быть связаны с одной и той же CC, но с разными обслуживающими участками. WTRU может быть конфигурирован максимальным количестве обслуживающих участков, на которых может работать WTRU (например, 1, 2, 3, 4 и т.д.). Указание максимального количества обслуживающих участков, которое можно разрешить использовать WTRU, может сигнализироваться WTRU в сеть как часть информации возможностей WTRU и/или может определяться сетью на основании эксплуатационного класса WTRU.

Обслуживающий участок может быть связан с одним или более транспортными каналами. Например, на восходящей линии связи WTRU может быть выполнен с возможностью доставки данных на физический уровень с использованием транспортного канала (например, UL-SCH), который связан с обслуживающей сотой, связанной с конкретным обслуживающим участком. В одном примере, каждый транспортный канал может быть специфичен для определенного обслуживающего участка/уровня, хотя транспортный канал может быть связан с множеством обслуживающих сот и/или компонентных несущих на этом обслуживающем участке. Например, UL-SCH может быть связан с конкретным обслуживающим участком (например, обслуживающим участком, связанным с трактом данных, включающим в себя MeNB) и одной или более компонентными несущими, связанными с этим обслуживающим участком (например, множество компонентных несущих, которые связаны с MeNB). Транспортный блок, подлежащий доставке на этот обслуживающий участок, может обслуживаться данными, связанными с транспортным каналом, отображаемым в этот обслуживающий участок. На нисходящей линии связи WTRU может быть выполнен с возможностью приема данных на физическом уровне и доставки данных на транспортный канал (например, DL-SCH), который связан с обслуживающей сотой, связанной с конкретным обслуживающим участком. Например, DL-SCH может быть связан с конкретным обслуживающим участком (например, обслуживающим участком, связанным с трактом данных, включающим в себя SCeNB) и одной или более компонентными несущими, связанными с этим обслуживающим участком (например, множеством компонентных несущих, которые связаны с SCeNB). Транспортный блок, принятый на физическом уровне, может отображаться в транспортный канал, связанный с этим обслуживающим участком, откуда был принят транспортный блок. Определенный обслуживающий участок может быть связан с нулем, одним или более чем одним UL-SCH и нулем, одним или более чем одним DL-SCH.

Каждый обслуживающий участок может быть связан с соответствующим экземпляр MAC на WTRU. WTRU может быть конфигурирован с множеством экземпляров MAC. Каждый экземпляр MAC может быть связан с конкретным обслуживающим участком. Термины обслуживающий участок, уровень, тракт данных, экземпляр MAC, и т.д. могут использоваться здесь взаимозаменяемо. Каждый экземпляр MAC может быть связан с одной или более конфигурированных обслуживающих сот и поддерживать одну или более CC. Каждый UL-SCH и/или DL-SCH может быть связан с определенным экземпляром MAC (например, посредством взаимно-однозначного соответствия между транспортным каналом и экземпляром MAC).

Экземпляр MAC может быть конфигурирован первичной сотой (P-сотой). Для каждого обслуживающего участка (и/или экземпляра MAC), одна из связанных с ним обслуживающих сот может поддерживать по меньшей мере поднабор функциональных возможностей, поддерживаемых первичной обслуживающей сотой (PcCell) в традиционных (например, одноучастковых) системах. Например, одна или более из обслуживающих сот определенного экземпляра MAC может поддерживать передачи PUCCH, которые можно использовать для отправки запросов планирования, обратной связи по HARQ, обратной связи по CSI и/или т.п., связанных с UL-SCH и/или DL-SCH, отображаемыми в соответствующий обслуживающий участок. Обслуживающая сота, которая выполнена с возможностью приема информации управления восходящей линии связи (UCI), связанной с транспортными каналами обслуживающего участка, может именоваться «P-сотой участка» и/или «первичной сотой MAC». Каждый экземпляр MAC может быть конфигурирован одной P-сотой и нулем или более S-сот. Дополнительно, P-сота первичного экземпляра MAC (например, экземпляра MAC, связанного с MeNB) может иметь дополнительные функциональные возможности, специфические для этого экземпляра MAC. Обслуживающий участок может быть связан с трактом данных. Обслуживающий участок может соответствовать одному тракту данных.

RRC можно использовать для конфигурирования множества экземпляров MAC. Например, когда RRC конфигурирует экземпляр MAC для работы, WTRU может определять, связан/а ли принятая/ый конфигурация или параметр с определенным экземпляром MAC на основании явного указания, включенного в поле информационного элемента (IE), который включает в себя конфигурационную информацию. В одном примере, принимается множество конфигураций, WTRU может неявно определять, что каждая конфигурация применяется к соответствующему экземпляру MAC. Например, если в сообщении установления/изменения RRC-соединения принимается множество IE radioResourceConfigDedicated, то WTRU может определять, что первый IE radioResourceConfigDedicated связан с первым экземпляром MAC, и что второй IE radioResourceConfigDedicated связан со вторым экземпляром MAC. В одном примере, различные типы IE можно задавать для конфигурирования вторичного экземпляра MAC (например, IE radioResourceConfigDedicatedSecondaryMACInstance). WTRU может определять, что принятая/ый конфигурация/IE применяется к вторичному экземпляру MAC на основании типа принятого IE. WTRU может определять, что принятая/ый конфигурация/IE применяется к вторичному экземпляру MAC на основании наличия в IE конфигурации слоя доступа (AS) (например, аналогичной IE mobilityControl). Например, если определенная конфигурационная информация AS присутствует в принятой конфигурационной информации, WTRU может определять, что конфигурация применяется к вторичному экземпляру MAC. Если конфигурационная информация AS отсутствует в принятой конфигурационной информации, WTRU может определять, что конфигурация применяется к первичному экземпляру MAC. WTRU может определять, к какому экземпляру MAC применима определенная конфигурация, на основании идентификатора SRB, по которому принимается сообщение конфигурации (например, SRB3 может указывать конфигурационную информацию для вторичного экземпляра MAC), например, если такой SRB ранее был конфигурирован для WTRU. Если отдельные экземпляры/объекты RRC связаны с разными обслуживающими участками, то WTRU может определять, к какому экземпляру MAC применяется конфигурация, на основании объекта RRC, от которого была принята конфигурация.

Разные уровни, используемые WTRU, могут быть связаны с различными типами узлов радиодоступа и/или различными типами сот. Например, первичный уровень может быть связан с макросотой, обслуживаемой MeNB, и вторичный уровень может быть связан с малой сотой, обслуживаемой SCeNB. Конфигурация сети может быть прозрачна для WTRU. Хотя можно описать примеры, в которых планировщики, связанные с разными уровнями, реализуются в разных узлах RAN (например, разных eNB), описанные здесь системы и способы можно применять к конфигурации, в которой множество планировщиков реализовано в одном узле RAN.

На фиг. 2A показана системная схема, демонстрирующая пример сетевой архитектуры, которая может обеспечивать для WTRU множество уровней для передачи/приема. Например, MeNB 202 может обеспечивать для WTRU первый уровень покрытия беспроводной связи (например, макроуровень). SCeNB 204 и/или SCeNB 206 могут обеспечивать для WTRU дополнительные уровни покрытия беспроводной связи (например, второй уровень, третий уровень и т.д.). SCeNB 204 и/или SCeNB может обеспечивать один или более уровней покрытия «малых сот» для WTRU. Один или более SCeNB можно логически группировать для формирования кластеров SCeNB. Это может именоваться кластером. Например, SCeNB 204 и SCeNB 206 могут быть включены в кластер.

MeNB 202 может осуществлять связь с одним или более из SCeNB 204 и/или SCeNB 206 через логический интерфейс связи, который может именоваться интерфейсом X2bis. MeNB 202 может осуществлять связь с кластером из одного или более SCeNB с использованием интерфейса X2bis. SCeNBs в кластерной конфигурации может осуществлять связь с другими SCeNB в кластере и/или может осуществлять связь с центральным контроллером (например, кластерным контроллером, шлюзом малой соты (SCGW) и т.д.). Например, SCGW может заканчивать S1-U для каналов-носителей, связанных с соответствующим уровнем малых сот. Интерфейс X2bis может быть расширением интерфейса X2 (например, интерфейса, используемого eNB для осуществления связи с другими eNB), может быть идентичен интерфейсу X2, и/или X2bis может быть отдельным логическим интерфейсом (например, помимо интерфейса X2). Интерфейс X2bis может представлять собой проводной интерфейс и/или беспроводной интерфейс. В одном примере, интерфейс X2bis можно реализовать в среде связи с относительно высокой задержкой (например, и/или в среде связи, в которой нельзя гарантировать относительно низкую задержку), что, например, затрудняет практическую реализацию скоординированного планирования между MeNB и SCeNB.

На фиг. 2B показана системная схема, демонстрирующая другой пример сетевой архитектуры, которая может обеспечивать для WTRU множество уровней для передачи/приема. Как показано на фиг. 2B, MeNB может осуществлять связь с другим MeNB через интерфейс X2′ и с SCeNB через интерфейс X2bis. Интерфейс X2′ может быть расширением интерфейса X2, может быть идентичен интерфейсу X2, и/или может быть отдельным логическим интерфейсом (например, помимо интерфейса X2).

В режиме множественного планирования WTRU может устанавливать соединение таким образом, что данными можно обмениваться с использованием одного или более трактов данных, причем каждый тракт может использовать радиоинтерфейс (например, Uu), связанный с разными узлами сети (например, MeNB или SCeNodeB). Радиоинтерфейсы для разных трактов данных можно независимо планировать посредством соответствующих узлов сети (например, MeNB или SCeNodeB).

Между WTRU и MeNB может устанавливаться первое RRC-соединение. Первое RRC-соединение может устанавливать радиоканалы-носители SRB0, SRB1 и SRB2 сигнализации. Например, это соединение может устанавливаться согласно принципам LTE выпуск 11. В ходе установления RRC-соединения первого RRC-соединения, WTRU может указывать, поддерживает ли WTRU работу согласно принципам множественного планирования. Например, WTRU может указывать, поддерживает ли он работу с множеством планировщиков многоуровневую работу, при указании эксплуатационного класса WTRU и/или ином указании возможностей WTRU.

Когда WTRU работает согласно принципам множественного планирования, плоскость управления можно расширять для поддержки многоуровневой работы. Например, плоскость управления, связанная с WTRU, работающим с использованием множества уровней, можно реализовать с использованием централизованной плоскости/объекта управления, скоординированной плоскости /объектов управления и/или распределенной плоскости/объекта управления.

Например, с точки зрения сети, централизованная плоскость/объект управления может характеризоваться одним оконечным экземпляром RRC (например, MeNB, другим узлом/объектом сети и т.д.), который дополняется функцией управления между оконечным узлом в сети и SCeNB. В одном примере, при использовании централизованной плоскости управления, функция управления может устанавливаться между оконечным узлом экземпляра RRC и MeNB, например, если оконечный экземпляр RRC-соединения логически отделен от MeNB. С точки зрения WTRU, централизованная плоскость/объект управления может характеризоваться одним объектом RRC. WTRU также может реализовывать одно или более расширений для управления аспектами с множеством планировщиков (например, одним или более SRB), конкретными для поднабора конфигурированных обслуживающих сот/уровней (например, соответствующих SCeNB).

С точки зрения сети, скоординированная плоскость/объекты управления может характеризоваться множеством оконечных экземпляров RRC (например, первым оконечным экземпляром в первом узле сети, например MeNB, вторым оконечным экземпляром во втором узле сети, например SCeNB), которое может дополняться функцией управления, реализованной между соответствующими оконечными узлами. Каждый из экземпляров RRC может реализовывать соответствующий набор SRB и/или соответствующий набор функций управления (например, установления соединения, управления мобильностью и RRM, освобождения соединения и т.д.). С точки зрения WTRU, скоординированная плоскость/объекты управления может характеризоваться множеством объектов RRC. WTRU также может реализовывать одно или более расширений аспектов управления с множеством планировщиков (например, сигнализации, принятой через первый экземпляр RRC), которое может запускать установление второго экземпляра RRC. Управление мобильностью может осуществляться на поуровневой основе. В порядке примера, мобильность может осуществляться на поуровневой основе, если используются кластер SCeNB. Управление мобильностью на поуровневой основе может включать в себя каждый экземпляр RRC, конфигурируемый независимо от другого.

С точки зрения сети, распределенная плоскость/объекты управления может характеризоваться множеством оконечных экземпляров RRC (например, первым оконечным экземпляром в первом узле сети, например MeNB, вторым оконечным экземпляром во втором узле сети, например SCeNB), которое может дополняться функцией управления между оконечными узлами (например, между MeNB и SCeNB). Каждый экземпляр RRC может реализовывать отдельный набор функций (например, MeNB может поддерживать установление соединения, управление мобильностью RLM, транспорт NAS и т.д., тогда как SCeNB может недоставать поддержки одной или более из этих функций). Некоторые функции RRC (например, управление радиоресурсами для применимых обслуживающих сот, например, с использованием переконфигурирования RRC-соединения) могут поддерживаться каждым из экземпляров RRC. Управление мобильностью может осуществляться для каждого уровня, например, в случае развертывания с кластером SCeNB, и в этом случае управление мобильностью может поддерживаться одним или более экземплярами RRC. С точки зрения WTRU, распределенная плоскость/объект управления может характеризоваться одним объектом RRC. WTRU также может реализовывать одно или более расширений, специфических для управления в аспектах с множеством планировщиков. Например, один или более SRB могут относиться к поднабору конфигурированных обслуживающих сот/уровней (например, SRB0, SRB1 и SRB2 могут относиться к управлению на обслуживающих сотах/уровне, соответствующем MeNB, тогда как SRB3 может относиться к обслуживающим сотам/уровню, соответствующему SCeNB). Некоторые функции могут зависеть от SRB (например, переконфигурирование радиоресурсов и/или управление мобильностью), которые можно применять для каждого уровня.

Фиг. 3 демонстрирует иллюстративную реализацию централизованной плоскости управления. Например, централизованная плоскость управления может включать в себя один оконечный экземпляр RRC на стороне сети (например, на контроллере 302 облачной радиосети (RCNC)), один экземпляр RRC на WTRU 304, и использовать управление X2bis. Например, WTRU 304 может устанавливать одно RRC-соединение с сетью. RRC-соединение может управляться централизованным контроллером сети, например RCNC 302.

В сети централизованный контроллер сети, на котором заканчивается экземпляр RRC, может быть отдельным логическим узлом сети (например, RCNC 302) и/или может быть реализован в узле RAN (например, eNB). Например, централизованный контроллер сети можно реализовать в MeNB 306 и/или SCeNB 308. RCNC 302 может осуществлять связь через интерфейс X2bis (например, и/или какой-то другой интерфейс) для конфигурирования SCeNB 308. Например, RCNC 302 может конфигурировать один или более параметров безопасности, каналы-носители усовершенствованной пакетной службы (EPS), функции управления радиоресурсами (RRM), и т.д. для SCeNB 308 через интерфейс X2bis. RCNC 302 может отправлять и/или параметры конфигурации для SCeNB 308 (например, конфигурационную информацию WTRU для одного или более из PHY, MAC, RLC, PDCP, RRC, и т.д. для одной или более обслуживающих сот SCeNB) через интерфейс X2bis. На WTRU 304, один экземпляр RRC и одно RRC-соединение могут использоваться для реализации централизованной плоскости управления.

При использовании централизованной плоскости управления, информацией, связанной с одним или более SRB, можно обмениваться через множество уровней/трактов данных. Например, некоторыми данными, связанными с SRB, можно обмениваться через уровень/тракт данных, включающий в себя MeNB 306, и другими данными, связанными с SRB, можно обмениваться через уровень/тракт данных, включающий в себя SCeNB 308. Как показано на фиг. 3, PDU RRC, соответствующим SRB(x), можно обмениваться по тракту данных, который соответствует радиоканалу-носителю (и/или логическому каналу (LCH)) MeNB и/или радиоканалу-носителю (и/или LCH) SCeNB. PDU RRC, соответствующий SRB(x), может быть включен в транспортный блок, связанный с первым экземпляром MAC, связанным с макроуровнем, и/или со вторым экземпляром MAC, связанным с уровнем малых сот. Централизованную плоскость управления можно реализовать независимо от того, как уровень 2 протокол разделяется между RCNC и MeNB/SCeNB.

В одном примере можно реализовать централизованную плоскость управления, в которой каждый SRB связан с определенным трактом/уровнем данных. Например, фиг. 4 демонстрирует иллюстративную реализацию централизованной плоскости управления, в которой SRB связаны с одним трактом/уровнем данных. Как показано на фиг. 4, WTRU 404 может быть выполнен с возможностью передачи PDU RRC, связанных с первым SRB (например, SRB(0, 1, 2 или x)), на RCNC 402 через первый тракт/уровень данных, который связан с радиоканалом-носителем (и/или LCH) MeNB 406, и PDU RRC, связанных со вторым SRB (например, SRB(y)), на RCNC 402 через второй тракт/уровень данных, который связан с радиоканалом-носителем (и/или LCH) SCeNB 408. PDU RRC могут отображаться в транспортный блок, связанный с надлежащим LCH (например, LCH экземпляра MAC, связанный с SRB). Централизованную плоскость управления, в которой каждый SRB связан с определенным трактом/уровнем данных, можно реализовать независимо от того, как уровень 2 протокол разделяется между RCNC и MeNB/SCeNB.

Легко увидеть, что, примеры могут включать в себя реализации, в которой некоторые SRB, например SRB0, SRB1 и SRB2, могут отображаться в один тракт данных (например, тракт данных, связанный с MeNB), тогда как другие SRB могут отображаться в оба тракта данных. В другом примере, все SRB могут отправляться через один уровень. Например, может не быть SRB, связанных с трактом/уровнем данных для SCeNB.

В одном примере, RCNC может быть совмещен с MeNB и/или реализован им. Фиг. 5 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя MeNB, когда экземпляр RRC заканчивается на MeNB на стороне сети. Если RCNC совмещен с MeNB и/или реализован им, одним или более из SRB0, SRB1, SRB2 и/или SRB3 можно обмениваться через тракт данных, включающий в себя MeNB. Например, WTRU может устанавливать RRC-соединение с MeNB, например, согласно процедурам LTE выпуск 11. MeNB может принимать от WTRU информацию возможностей для WTRU, которая указывает, что WTRU поддерживает работу с множеством планировщиков/многоуровневую работу. MeNB может конфигурировать WTRU для осуществления измерений для частот, которые соответствуют уровню малых сот (например, внутриполосных измерений, межполосных измерений и т.д.). MeNB может принимать отчет об измерении от WTRU и может определять, какая обслуживающая сота SCeNB может быть пригодна для разгрузки трафика на/от WTRU. MeNB может устанавливать для WTRU тракт данных, включающий в себя SCeNB. MeNB может устанавливать соединение с выбранным SCeNB для обеспечения контекстной информации WTRU на SCeNB. Например, MeNB может конфигурировать SCeNB параметрами для установления одного или более каналов-носителей EPS, например, информацией QoS/QCI для WTRU, параметрами безопасности для шифрования и/или аутентификации и/или т.п. MeNB может принимать от SCeNB ответное сообщение, которое может включать в себя информацию конфигурации слоя доступа (конфигурации AS) для одной или более обслуживающих сот SCeNB.

MeNB может передавать на WTRU сообщение переконфигурирования RRC-соединения, которое может включать в себя один или более параметров конфигурации AS, принятых от SCeNB, чтобы конфигурировать WTRU для осуществления доступа к одной или более применимым сотам SCeNB. MeNB может принимать от WTRU ответ, указывающий, что он принял конфигурацию и/или успешно соединился с SCeNB. MeNB может принимать от SCeNB подтверждение, которое указывает, что WTRU успешно осуществил доступ к одной или более обслуживающих сот SCeNB. WTRU может осуществлять доступ к SCeNB с использованием произвольного доступа и/или может обмениваться одним или более сообщениями RRC по SRB, который был установлен для обмена данными управления через тракт данных, включающий в себя SCeNB (например, SRB3). В одном примере, SRB3 может быть SRB, который установлен и/или предназначен для управления линией радиосвязи между WTRU и SCeNB (например, и/или узлом RAN, связанным с вторичным трактом данных).

Фиг. 6 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя SCeNB, когда экземпляр RRC заканчивается на MeNB на стороне сети. Как показано на фиг. 6, одним или более SRB (например, SRB(x) который может быть SRB3) можно обмениваться по тракту, который включает в себя SCeNB. Стек протоколов для такой плоскости управления может включать в себя уровни PHY, MAC и/или RLC оканчивающиеся на SCeNB, и уровни PDCP и/или RRC, оканчивающиеся на MeNB.

Для установления возможности соединения на двух уровнях, WTRU может сначала установить RRC-соединение с MeNB, например, согласно процедурам LTE выпуск 11. При установлении RRC-соединения, WTRU может указывать, что он поддерживает работу с множеством планировщиков/многоуровневую работу, например, как часть информации возможностей WTRU. WTRU может принимать конфигурационную информацию измерения от MeNB. Конфигурационная информация измерения может включать в себя информацию измерения для частот, которые соответствуют уровню малых сот (например, внутриполосных измерений, межполосных измерений и т.д.). WTRU может сообщать измерения согласно конфигурированным критериям запуска. WTRU может принимать от MeNB сообщение переконфигурирования RRC-соединения, и информация переконфигурирования RRC-соединения может включать в себя параметры конфигурации AS для осуществления доступа к одной или более обслуживающих сот SCeNB. WTRU может переконфигурировать по меньшей мере часть своих радиоресурсов для работы на указанной несущей частоте для SCeNB. WTRU может пытаться осуществить начальную процедуру доступа к обслуживающей соте SCeNB (например, принимать системную информацию, рассылаемую от SCeNB). WTRU может отправлять сообщение RRC (например, запрос на переконфигурирование RRC-соединения), которое указывает запрос на установление SRB3 (например, с использованием того же контекста безопасности, что и для других SRB), которым можно обмениваться через тракт данных, включающий в себя SCeNB. WTRU может принимать ответ через SRB3 и/или сообщение переконфигурирования RRC-соединения, обмениваемое через SRB3 (например, по тракту данных, включающему в себя SCeNB), которое конфигурирует одну или более сот, соответствующих соединению SRB3. WTRU может осуществлять переконфигурирование и передавать ответное сообщение «переконфигурирование RRC-соединения завершено».

В одном примере, SRB0, SRB1 и/или SRB2 может заканчиваться на RCNC/MeNB и на WTRU и допускает обмен через тракт данных, включающий в себя MeNB. Например, SRB0, SRB1 и/или SRB2 может быть связан со стеком протоколов в конфигурации плоскости управления, представленной на фиг. 5. В одном примере, SRB3 (и/или другие вспомогательные SRB) может заканчиваться на RCNC/MeNB и на WTRU и допускает обмен через тракт данных, включающий в себя SCeNB. Например, SRB3 может быть связан со стеком протоколов в конфигурации плоскости управления, представленной на фиг. 6. SRB3 можно использовать для переконфигурирования (например, освобождения) радиоресурсов и/или для управления мобильностью для уровня малых сот.

Скоординированная плоскость управления может характеризоваться множеством оконечных экземпляров RRC в сети, одним или более наборами SRB и/или обменом X2bis данных управления. Например, WTRU может устанавливать множество соединений RRC с сетью. Соединения RRC могут располагаться в иерархическом порядке.

Например, с точки зрения сети, как MeNB, так и SCeNB, может быть связан с соответствующим объектом RRC. MeNB может использовать интерфейс X2bis (и/или какой-то другой интерфейс) для конфигурирования SCeNB различными параметрами, связанными с WTRU (например, информацией безопасности, информацией канала-носителя EPS, информацией QoS, информацией RRM и т.д.). MeNB может предписывать WTRU установить вторичное RRC-соединение с обслуживающей сотой SCeNB. SCeNB может устанавливать вторичное RRC-соединение с WTRU и может передавать на WTRU сообщение переконфигурирования RRC-соединения. Сообщение переконфигурирования RRC-соединения может включать в себя конфигурацию AS для применимой(ых) соты() SCeNB (например, конфигурационную информацию WTRU для одного или более из PHY, MAC, RLC, PDCP, RRC и т.д. для одной или более обслуживающих сот SCeNB).

С точки зрения WTRU, после того как WTRU установит RRC-соединение с MeNB, WTRU может принимать из сети сигнализацию управления, которая указывает, что WTRU может устанавливать вторичное RRC-соединение с SCeNB. Такая сигнализация управления может приниматься специализированным образом с использованием установленного RRC-соединения с MeNB. В одном примере, сообщение поискового вызова, рассылаемое в соте SCeNB, может указывать WTRU, что он может устанавливать вторичное RRC-соединение с SCeNB. Страница может отправляться из кластера (или группы) SCeNB. Прежде чем пытаться принять страницу, указывающую, что WTRU может осуществлять многоуровневую работу с использованием соты SCeNB, WTRU может принимать от MeNB специализированную сигнализацию RRC, которая конфигурирует вторичный экземпляр RRC на WTRU для осуществления процедур мобильности в режиме ожидания для одной или более сот определенной полосы частот (например, соответствующей полосе частот, используемой SCeNB). Процедура установления RRC-соединения для вторичного экземпляра RRC может включать в себя указание, что устанавливаемое соединение предназначено вторичного соединения.

Фиг. 7 демонстрирует пример стека протоколов в плоскости управления для скоординированной плоскости управления, в которой первый экземпляр RRC заканчивается на MeNB и второй экземпляр RRC заканчивается на SCeNB. Как показано на фиг. 7, тракт данных для первого RRC-соединения (например, соединения с MeNB) может включать в себя радиоканал-носитель (и/или LCH), отображаемый в MeNB. Например, SRB0, SRB1 и/или SRB2 может устанавливаться через первое RRC-соединение, которое связано с трактом данных, включающим в себя MeNB. Тракт данных для второго RRC-соединения (например, соединения с SCeNB) может включать в себя радиоканал-носитель (и/или LCH), отображаемый в SCeNB. Например, экземпляры SRB0, SRB1 и/или SRB2, связанные со вторым RRC-соединением (например, указанные как SC-SRB0, 1, 2 на фиг. 7), могут устанавливаться через второе RRC-соединение, которое связано с трактом данных, включающим в себя SCeNB.

Первичное соединение (например, соединение, установленное с MeNB) может быть дополнено включением дополнительного SRB (например, проиллюстрированного как SRB(x) на фиг. 7), который может быть каналом-носителем, который используется для управления некоторыми аспектами вторичного RRC-соединения (например, соединения, связанного с SCeNB). Например, дополнительный SRB может использоваться для запуска процедуры установления соединения и/или процедуры освобождение по вторичному тракту/уровню данных. PDU RRC, соответствующим вспомогательному каналу-носителю, можно обмениваться по тракту данных, который соответствует радиоканалу-носителю (и/или LCH) MeNB.

Вторичное соединение (например, соединение, установленное с SCeNB) может быть дополнено включением дополнительного SRB (например, SRB(y), хотя это не показано на фиг. 7), который может быть каналом-носителем, который используется для передачи данных, связанных с первичным RRC-соединением (например, соединением, связанным с MeNB). Например, вспомогательный SRB(y) (и/или аналогичная реализация для мультиплексирования PDU RRC) может заканчиваться на SCeNB и может быть SRB, который используется для перенаправления и/или пересылки PDU RRC на первичный экземпляр RRC на MeNB. Например, данные для SRB0, SRB1 или SRB2 первичного экземпляра RRC может отправляться через SRB(y) на SCeNB, который может пересылать данные на MeNB, например через интерфейс X2bis.

Фиг. 8 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя MeNB, когда экземпляр RRC заканчивается на MeNB на стороне сети. В одном примере скоординированной работы в плоскости управления, MeNB может устанавливать первичное RRC-соединение с WTRU, например, согласно процедурам LTE выпуск 11. MeNB может принимать от WTRU информацию возможностей для WTRU, которая указывает, что WTRU поддерживает работу с множеством планировщиков/многоуровневую работу. MeNB может конфигурировать WTRU для осуществления измерений для частот, которые соответствуют уровню малых сот (например, внутриполосных измерений, межполосных измерений и т.д.). MeNB может принимать отчет об измерении от WTRU и может определять, какая обслуживающая сота SCeNB может быть пригодна для разгрузки трафика на/от WTRU.

Фиг. 9 демонстрирует пример стека протоколов в плоскости управления для SRB, обмениваемых через тракт данных, включающий в себя SCeNB, когда экземпляр RRC заканчивается на SCeNB на стороне сети. WTRU и/или MeNB может предписывать WTRU устанавливать вторичное RRC-соединение, например, вторичное соединение, которое заканчивается на SCeNB. В порядке примера, MeNB может использовать первичное RRC-соединение чтобы предписывать WTRU устанавливать вторичное RRC-соединение с SCeNB. В одном примере, MeNB может инициировать установление соединения с SCeNB до того как WTRU установит вторичное RRC-соединение с рассматриваемым SCeNB. Например, MeNB может устанавливать тракт данных и соединение управления с выбранным SCeNB для переноса контекста WTRU (например, через X2bis). MeNB может конфигурировать SCeNB параметрами для установления одного или более каналов-носителей EPS, например, информацией QoS/QCI для WTRU, параметрами безопасности для шифрования и/или аутентификации и/или т.п. MeNB может принимать от SCeNB ответное сообщение, которое может включать в себя информацию конфигурации AS для одной или более обслуживающих сот SCeNB (например, параметры системной информации, параметры команды передачи обслуживания, аналогичные командам переконфигурирования RRC-соединения информационным элементом MobilityControl). MeNB может передавать на WTRU сообщение переконфигурирования RRC-соединения, которое может включать в себя информацию конфигурации AS, принятую от SCeNB для конфигурации применимой(ых) соты() SCeNB (например, информационный элемент MobilityControl).

В одном примере, WTRU может устанавливать вторичное RRC-соединение с SCeNB, и затем SCeNB может инициировать установление соединения с MeNB (например, после установления вторичного RRC-соединения). Например, после установления вторичного RRC-соединения с WTRU, SCeNB может запрашивать установление тракта данных и соединения управления с соответствующим MeNB для приема контекстной информации WTRU от MeNB. Запрос на контекст WTRU может отправляться SCeNB, тогда как вторичное соединение устанавливается WTRU (например, после/на основании приема запроса RRC-соединения, отправленного с WTRU. Например, MeNB может конфигурировать SCeNB параметрами для установления одного или более каналов-носителей EPS, например, информацией QoS/QCI для WTRU. MeNB и SCeNB могут использовать разные конфигурации безопасности для одного и того же WTRU. MeNB может принимать от SCeNB ответное сообщение, указывающее, что контекстная информация WTRU была принята и/или что вторичное RRC-соединение успешно установлено. MeNB может принимать от WTRU ответ «соединение завершено» и/или подтверждение от SCeNB, которое может указывать, что WTRU установил вторичное соединение с SCeNB.

В примере работы с использованием скоординированной плоскости управления WTRU может устанавливать RRC-соединение с MeNB (например, согласно процедурам LTE выпуск 11). При установлении RRC-соединения, WTRU может указывать, что он поддерживает работу с множеством планировщиков/многоуровневую работу, например, как часть информации возможностей WTRU. WTRU может принимать конфигурационную информацию измерения от MeNB. Конфигурационная информация измерения может включать в себя информацию измерения для частот, которые соответствуют уровню малых сот (например, внутриполосных измерений, межполосных измерений и т.д.). WTRU может сообщать измерения согласно конфигурированным критериям запуска. WTRU может принимать от MeNB сообщение переконфигурирования RRC-соединения, и информация переконфигурирования RRC-соединения может включать в себя параметры конфигурации AS для осуществления доступа к одной или более обслуживающих сот SCeNB. WTRU может переконфигурировать по меньшей мере часть своих радиоресурсов для работы на указанной несущей частоте для SCeNB. WTRU может пытаться осуществить начальную процедуру доступа к обслуживающей соте SCeNB (например, принимать системную информацию, рассылаемую от SCeNB). WTRU может устанавливать RRC-соединение с SCeNB, например, согласно процедурам LTE выпуск 11. WTRU может передавать ответ «переконфигурирование RRC завершено» на один или более из MeNB и/или SCeNB после успешного установления вторичного RRC-соединения.

При использовании скоординированной плоскости управления, один или более независимых SRB могут заканчиваться на каждом из узлов RAN (например, MeNB и SCeNB). Для первичного RRC-соединения, первый набор SRB (например, включающий в себя первый экземпляр SRB0, первый экземпляр SRB1 и/или первый экземпляр SRB2) может заканчиваться на MeNB. Для вторичного RRC-соединения, первый набор SRB (например, включающий в себя первый экземпляр SRB0, первый экземпляр SRB1 и/или первый экземпляр SRB2) может заканчиваться на SCeNB.

Распределенная плоскость управления может характеризоваться одним оконечным экземпляром RRC на стороне сети, одним набором SRB0, SRB 1 и/или SRB 2, управлением X2bis между узлами разных уровней и использованием SRB (например, SRB3) для обмена данными управления между уровнями.

Например, при использовании распределенной плоскости управления WTRU может устанавливать одно RRC-соединение с сетью через MeNB. Хотя RRC-соединение устанавливается с MeNB (например, макроуровнем), некоторые функциональные возможности RRC, связанные с управлением радиоресурсами обслуживающих сот, соответствующих SCeNB, может осуществляться или реализоваться SCeNB. Если SCeNB является элементом кластера SCeNBs, то SCeNB может осуществлять некоторые функции, связанные с мобильностью. Например, если SCeNB реализует одну или более функций RRC и/или функций RRM для обслуживающей(их) соты(), связанной(ых) с SCeNB (например, поднабор функций RRC и/или функций RRM), RRC-соединение, установленное между WTRU и сетью, может включать в себя один или более SRB, используемых для управления трактом данных между SCeNB и WTRU (например, SRB3).

На стороне сети, MeNB может иметь объект RRC, который может быть оконечной точкой RRC-соединения. Например, SRB0, SRB1 и SRB2 могут заканчиваться на WTRU и на MeNB. MeNB может использовать интерфейс X2bis (или аналогичный) для конфигурирования SCeNB для связи с WTRU (например, информацию безопасности, информацию установления канала-носителя EPS, информацию QoS/QCI и т.д.). MeNB может предписывать WTRU осуществлять доступ к обслуживающей соте SCeNB. SCeNB может устанавливать один или более вспомогательных SRB (например, SRB3), например, для осуществления функций RRM обслуживающих сот, связанных с SCeNB. Такой вспомогательный SRB может использоваться для облегчения некоторых функций, связанных с мобильностью, на SCeNB. Вспомогательные SRB (например, SRB3) могут заканчиваться на WTRU и на SCeNB, например, даже когда RRC-соединение заканчивается на MeNB, но не на SCeNB. Вспомогательный SRB можно использовать для сигнализации управления, которая переконфигурирует одну или более обслуживающих сот, соответствующих SCeNB (например, конфигурационную информацию WTRU для одного или более из PHY, MAC, RLC, PDCP, и т.д. для одной или более обслуживающих сот SCeNB).

С точки зрения WTRU, после того как WTRU установит RRC-соединение с MeNB, WTRU может принимать из сети сигнализацию управления, которая указывает, что WTRU может устанавливать вторичное RRC-соединение с SCeNB. Такая сигнализация управления может приниматься специализированным образом с использованием установленного RRC-соединения с MeNB. В одном примере, сообщение поискового вызова, рассылаемое в соте SCeNB, может указывать WTRU, что он может устанавливать вторичное RRC-соединение с SCeNB. Страница может отправляться из кластера (или группы) SCeNB. Прежде чем пытаться принять страницу, указывающую, что WTRU может осуществлять многоуровневую работу с использованием соты SCeNB, WTRU может принимать от MeNB специализированную сигнализацию, которая конфигурирует WTRU для отслеживания канала поискового вызова пригодной соты SCeNB в определенной полосе частот. WTRU может осуществлять доступ к соте SCeNB с использованием процедуры произвольного доступа. Произвольный доступ может быть специализированным произвольным доступом, для использования параметров RACH (например, специализированной преамбулы RACH), принятых в особой сигнализации управления, отправленной от MeNB. WTRU может принимать сигнализацию RRC, которая переконфигурирует обслуживающие соты, соответствующие SCeNB, например через SRB3.

Фиг. 10 демонстрирует пример стека протоколов в плоскости управления для распределенной плоскости управления, в которой экземпляр RRC заканчивается на MeNB. Как показано на фиг. 10, PDU RRC, соответствующим передаче для определенного SRB RRC-соединения, можно обмениваться по тракту данных, который соответствует радиоканалу-носителю (и/или LCH) MeNB и/или радиоканалу-носителю (и/или LCH) SCeNB. Например, PDU RRC, соответствующему передаче для SRB 0, 1 и 2, можно обмениваться по тракту данных, который соответствует радиоканалу-носителю (и/или LCH) MeNB. Это можно представить как SRB 0, 1, 2 на фиг. 10. PDU RRC, соответствующим передаче для вспомогательного SRB (например, SRB3) можно обмениваться по тракту данных, который соответствует радиоканалу-носителю (и/или LCH) SCeNB. Это можно представить как SRB(x) на фиг. 10. SCeNB может пересылать данные управления, связанные с SRB3, на MeNB через интерфейс X2bis. Таким образом, в примере для архитектуры распределенной плоскости управления, некоторые функциональные возможности, связанные с RRC, можно реализовать посредством SCeNB (например, связанным с SRB3) хотя никакие RRC-соединения и/или никакие SRB не заканчиваются на уровне малых сот. Такой поднабор функциональных возможностей RRC проиллюстрирован на основе SCeNB, включающего в себя уровень SC-RRC стека протоколов на фиг. 10 (например, представляя ограниченные функциональные возможности RRC, которые реализуются на малой соте).

В примере стороны сети функциональные возможности в случае распределенной плоскости управления, MeNB может устанавливать RRC-соединение с WTRU, например, согласно процедурам LTE R11. Пример этого может быть показано на фиг. 11. На Фиг. 11 показана схема, демонстрирующая пример стека протоколов в плоскости управления, содержащего распределенный подход для SRB0, SRB1 и SRB2 RRC MeNB. MeNB может принимать возможности WTRU для поддержки работы с множеством планировщиков как часть процедуры установления соединения. MeNB может конфигурировать WTRU измерениями для частот, которые соответствуют уровню улучшения малой соты (например, внутриполосные или межполосные измерения). MeNB может принимать отчет об измерении от WTRU и может определять, какая обслуживающая сота SCeNB может быть пригодна для разгрузки трафика на/от WTRU. MeNB может устанавливать тракт данных и соединение управления с выбранным SCeNB для контекста WTRU. MeNB может конфигурировать SCeNB, например, параметрами для установления одного или более каналов-носителей EPS, информацией QoS/QCI для WTRU, а также параметрами безопасности для шифрования и аутентификации. MeNB может принимать от SCeNB ответное сообщение, которое может включать в себя конфигурацию AS для по меньшей мере одной обслуживающей соты SCeNB. MeNB может передавать на WTRU сообщение переконфигурирования RRC-соединения, которое может включать в себя параметры конфигурации, принятые от SCeNB, для конфигурации применимой(ых) соты() SCeNB. MeNB может принимать ответ завершения от WTRU или подтверждение от SCeNB, причем ответ может указывать, что WTRU произвел доступ к по меньшей мере одной обслуживающей соте SCeNB (например, успешный произвольный доступ и/или обмен по меньшей мере одним сообщением RRC по SRB3). SRB3 может заканчиваться на SCeNB. Например, это может быть показано на фиг. 12. На Фиг. 12 показана схема, демонстрирующая пример стека протоколов в плоскости управления, содержащего распределенный подход для SRB 3 SCeNB.

В одной реализации WTRU может устанавливать RRC-соединение с MeNB, например, согласно процедурам LTE R11. Например, это может быть показано на фиг. 11. WTRU может включить в свои возможности WTRU то, поддерживает ли он работу с множеством планировщиков. WTRU может принимать от MeNB конфигурацию измерения, включающую в себя измерения для частот, которые соответствуют уровню улучшения малой соты (например, внутриполосные или межполосные измерения). WTRU может сообщать измерения согласно конфигурированному критерию запуска. WTRU может принимать от MeNB сообщение переконфигурирования RRC-соединения параметрами конфигурации AS для осуществления доступа к одной или более обслуживающих сот SCeNB. WTRU может переконфигурировать по меньшей мере часть своих радиоресурсов для работы на выбранной несущей частоте и осуществлять начальный доступ к обслуживающей соте (например, прием системного вещания). WTRU может включать в себя начальное сообщение RRC, например, но без ограничения, запрос на установление SRB3, который заканчивается на SCeNB. Это можно делать с использованием того же контекста безопасности, что и для других SRB. Например, это может быть показано на фиг. 12. WTRU может принимать ответ на SRB3 и/или сообщение переконфигурирования RRC-соединения на SRB3, которое конфигурирует одну или более сот, соответствующих соединению SRB3. WTRU может осуществлять переконфигурирование и передавать ответ завершения по SRB3 в ответ на запрос конфигурации от SCeNB. WTRU может передавать ответ завершения на MeNB по SRB1 или SRB2 в ответ на запрос для осуществления доступа к SCeNB.

SRB3 может заканчиваться на WTRU и на SCeNB. Вспомогательный SRB может использоваться после того, как начинается безопасность. SRB3 можно использовать для RRM (например, конфигурацию, переконфигурирование) обслуживающей(их) соты(), связанной(ых) с SCeNB, и/или для управления мобильностью на уровне улучшения малой соты.

При использовании множества планировщиков для передачи по множеству трактов данных, отображение между DRB/SRB и множеством трактов данных может изменяться в зависимости от того, как стек протоколов для передачи данных разделяется между разными узлами сети. Например, первый тракт данных может устанавливаться от WTRU к сети через MeNB (например, макроуровня), и дополнительный(е) тракт(ы) данных может устанавливаться от WTRU к сети через один или более SCeNB. Один или более стеков протоколов можно задавать для плоскости пользователя и/или для плоскости управления для поддержки многоуровневой (например, с множеством планировщиков) передачи.

Например, интерфейс X2bis и/или какой-то другой интерфейс между MeNB и SCeNB может использоваться для реализации различных конфигураций стека протоколов при поддержке работы с множеством планировщиков. Для определенного WTRU тракт данных для плоскости пользователя и тракт данных для плоскости управления может быть реализован по меньшей мере частично, на основе связи, осуществляемой через интерфейс X2bis.

Например, множество трактов данных для определенного WTRU может устанавливаться таким образом, что тракты данных разделяются в сети над уровнем PDCP. Благодаря такой архитектуре каждый из MeNB и SCeNB может включать в себя функциональные возможности, соответствующие уровню PHY, уровню MAC, уровню RLC и уровню PDCP. Плоскость управления можно реализовать таким образом, что объект PDCP, связанный с определенным радиоканалом-носителем (например, DRB и/или SRB), может располагаться на объекте сети, который передает и/или принимает данные управления. Например, объект PDCP, используемый для передачи данных управления через SCeNB, может располагаться на SCeNB, и объект PDCP, используемый для передачи данных через MeNB, может располагаться на MeNB. В одном примере, данные плоскости пользователя и/или данные плоскости управления могут переноситься по радиоканалу-носителю, который может отображаться в один тракт данных (например, в DRB/SRB с одной SAP). В другом примере, данные плоскости пользователя и/или данные плоскости управления могут переноситься по радиоканалу-носителю, который может отображаться во множество трактов данных (например, в DRB/SRB с множеством SAP). Каждый объект PDCP (например, объект PDCP SCeNB, объект PDCP MeNB) может включать в себя конечный автомат безопасности для соответствующего ему тракта данных.

В качестве примера, множество трактов данных, которые разделяются над уровнем PDCP в сети, можно реализовать с использованием одного или более радиоканалов-носителей, которые связаны с одной SAP в сети (например, MeNB или SCeNB). Для поддержки работы с множеством планировщиков, один или более DRB и/или SRB может переноситься между трактами данных (например, мобильность DRB/SRB). Например, SRB, связанный с MeNB, может разгружаться на SCeNB. Если используется распределенная плоскость управления (например, некоторые функциональные возможности RRC могут существовать на MeNB и SCeNB), то SRB3 или некоторые другие SRB может использоваться для обмена информацией управления, связанной с мобильностью.

Например, если определенный радиоканал-носитель связан с одной SAP в сети, для плоскости пользователя канал-носитель радиодоступа (RAB) EPS можно реализовать с использованием одной SAP DRB. Например, фиг. 13 демонстрирует пример стека протоколов, который может использоваться для трактов данных плоскости пользователя (например, тракта данных WTRU-MeNB и тракта данных WTRU-SCeNB), когда тракты данных разделяются над уровнем PDCP в сети.

В плоскости управления, сигнализация NAS и/или RRC может передаваться по одному SRB, связанному с одной SAP. В зависимости от того, используется ли централизованная плоскость управления, скоординированная плоскость управления и/или распределенная плоскость управления, отображение SRB в тракты данных, мобильность SRB и/или реализация стека протоколов для плоскости управления в сети может изменяться.

Например, централизованная плоскость управления можно реализовать таким образом, что одна SAP SRB используется для сигнализации NAS и/или RRC. Например, PDU RRC для SRB0, SRB1 и/или SRB2 могут формироваться объектом RCNC, который можно реализовать на MeNB. Дополнительными расширениями и/или дополнительными информационными элементами можно обмениваться через MeNB для управления радиосоединением между WTRU и SCeNB (например, запуска установления, мобильности и/или освобождения вторичного RRC-соединения). PDU RRC для SRB0, SRB1 и/или SRB2 могут передаваться на WTRU из обслуживающей соты MeNB. В одном примере, PDU RRC для SRB0, SRB1 и/или SRB2 можно обмениваться через узел RAN, с которым WTRU первоначально установлено RRC-соединение (например, до инициирования работы с множеством планировщиков/многоуровневой работы). PDU RRC, соответствующими SRB, назначенному SCeNB (например, SRB3), можно обмениваться в обслуживающей соте SCeNB.

Фиг. 14 демонстрирует пример стека протоколов, в котором SRB могут быть связаны с одной SAP и тракты данных разделяются над уровнем PDCP в сети с использованием централизованной плоскости управления. Например, PDU RRC для данного SRB могут передаваться по одному тракту данных (например, SRB0, SRB1 и/или SRB2 по тракту данных, связанный с MeNB и SRB3 по тракту данных, связанный с SCeNB). Радиоканалы-носители для разных трактов данных могут быть связаны с разными/отдельными объектами PDCP. С точки зрения сети, уровень PDCP, связанный с соединением с WTRU, может располагаться на MeNB и на SCeNB (например, не показано на фиг. 14) или может располагаться на RCNC (например, как показано на фиг. 14). В одном примере, уровень PDCP и уровень RLC на стороне сети могут располагаться на RCNC.

В одном примере, скоординированную плоскость управления можно реализовать таким образом, что одна SAP SRB используется для сигнализации NAS и/или RRC. Например, когда RRC-соединение использует скоординированную плоскость управления, PDU RRC для определенного SRB (например, SRB0, SRB1 и/или SRB2) могут передаваться по одному тракту данных, например, тракту данных, связанному с MeNB. Другими данными управления, предназначенными для запуска установления, мобильности и/или освобождения вторичного RRC-соединения, также можно обмениваться через один тракт данных, связанный с MeNB (например, через обслуживающую соту MeNB). В одном примере, PDU RRC для SRB0, SRB1 и/или SRB2 можно обмениваться через узел RAN, с которым WTRU первоначально установлено RRC-соединение (например, до инициирования работы с множеством планировщиков/многоуровневой работы). Для скоординированной плоскости управления, PDU RRC для SRB0, SRB1 и/или SRB2 могут формироваться SCeNB, и SCeNB может обмениваться локально формируемыми PDU RRC через обслуживающую соту SCeNB. Например, для определенного радиоканала-носителя фиг. 8 и фиг. 9 могут иллюстрировать пример, в котором каждый соответствующий радиоканал-носитель имеет отдельный объект PDCP для каждого экземпляра RRC, использующего скоординированную плоскость управления.

В одном примере, распределенную плоскость управления можно реализовать таким образом, что одна SAP SRB используется для сигнализации NAS и/или RRC. Например, когда RRC-соединение использует распределенную плоскость управления, PDU RRC для SRB0, SRB1 и/или SRB2 могут формироваться объектом MeNB. Дополнительными расширениями и/или дополнительными информационными элементами можно обмениваться через MeNB для управления радиосоединением между WTRU и SCeNB (например, запуска установления, мобильности и/или освобождения вторичного RRC-соединения). PDU RRC для SRB0, SRB1 и/или SRB2 могут передаваться на WTRU из обслуживающей соты MeNB. В одном примере, PDU RRC для SRB0, SRB1 и/или SRB2 можно обмениваться через узел RAN, с которым WTRU первоначально установлено RRC-соединение (например, до инициирования работы с множеством планировщиков/многоуровневой работы). PDU RRC, соответствующими SRB, назначенному SCeNB (например, SRB3), можно обмениваться в обслуживающей соте SCeNB. Например, PDU RRC для SRB3 может формироваться на SCeNB и переноситься на WTRU через обслуживающую соту SCeNB. Фиг. 10 может иллюстрировать пример, в котором каждый соответствующий радиоканал-носитель имеет отдельный объект PDCP для каждого экземпляра RRC, использующего распределенную плоскость управления.

В одном примере, вместо или помимо отображения определенного радиоканала-носителя в одну SAP, один RB может отображаться во множество SAP (например, по множеству логических каналов). Например, в плоскости пользователя может использоваться RAB EPS с множеством SAP DRB. Отображение одного RAB EPS по множеству DRB E-UTRA можно реализовать с использованием различных методов, например в зависимости от того, предназначены ли данные для плоскости данных или плоскости управления, и/или используется ли централизованная, скоординированная или распределенная плоскость управления. Например, данными для плоскости пользователя можно обмениваться по одному из множества трактов данных. Данные, соответствующие определенному каналу-носителю EPS, могут отображаться в одну или более SAP, причем каждая SAP может соответствовать DRB и/или LCH отдельного экземпляра MAC. Фиг. 15 демонстрирует пример тракта данных, разделенного над уровнем PDCP для плоскости пользователя, в которой используется множество SAP DRB. Например, IP-пакетами для определенного канала-носителя EPS можно обмениваться по любому тракту данных (например, тракту, связанному с MeNB, или тракту, связанному с SCeNB).

Если используется множество SAP радиоканала-носителя, для плоскости управления сигнализация NAS и/или RRC может передаваться по множеству SAP SRB. Например, один SRB может отображаться во множество SAP (например, по множеству логических каналов). Данные, соответствующие определенному SRB (например, одному из SRB0, SRB1, SRB2 и/или вспомогательному SRB, например SRB3) могут отображаться в одну или более SAP, причем каждая SAP может соответствовать отдельному экземпляру MAC и передаваться через отдельный узел RAN (например, MeNB или SCeNB).

Фиг. 16 демонстрирует пример стека протоколов, причем SRB могут быть связаны с множеством SAP, и тракты данных разделяются над уровнем PDCP в сети с использованием централизованной плоскости управления. Например, PDU RRC для определенного SRB могут передаваться по множеству трактов данных (например, тракту данных, связанному с MeNB, и/или тракту данных, связанному с SCeNB). Определенный радиоканал-носитель может пользоваться услугами множества объектов PDCP (например, объекта PDCP на SCeNB и объекта PDCP на MeNB). С точки зрения сети, уровень PDCP, связанный с соединением с WTRU, может располагаться на MeNB и на SCeNB (например, как показано на фиг. 16) или может располагаться на RCNC (например, не показан на фиг. 16). В одном примере, уровень PDCP и уровень RLC на стороне сети могут располагаться на RCNC. Для перспективных сетей, каждая SAP, связанная с определенным радиоканалом-носителем, может соответствовать логическому каналу, управляемому отдельным планировщиком. WTRU может принимать данные управления, которые соответствуют определенному SRB, по разным логическим каналам разных экземпляров MAC.

В одном примере, скоординированную плоскость управления можно реализовать таким образом, что радиоканал-носитель (например, SRB) может пользоваться услугами множества объектов PDCP. Например, когда RRC-соединение использует скоординированную плоскость управления, PDU RRC для определенного SRB (например, SRB0, SRB1 и/или SRB2) могут передаваться по множеству трактов данных. Например, может осуществляться мультиплексирование и/или демультиплексирование PDU RRC, связанных с определенным SRB первого объекта RRC, и PDU RRC, связанных с SRB второго объекта RRC.

В одном примере, распределенную плоскость управления можно реализовать таким образом, что радиоканал-носитель (например, SRB) может пользоваться услугами множества объектов PDCP. Например, радиоканал-носитель, связанный с объектом RRC на MeNB, может пользоваться услугами объекта PDCP, расположенного на SCeNB. Фиг. 3 могут иллюстрировать пример распределенной плоскости управления, причем определенный SRB может отображаться во множество SAP радиоканала-носителя.

В одном примере, вместо разделения трактов данных над стеком протоколов PDCP в сети, тракты данных/уровни, используемые WTRU, могут разделяться над уровнем RLC. Таким образом, уровень PDCP может быть включен на одном узле в сети, и PDU уровня PDCP, подлежащие передаче на WTRU, могут отображаться во множество SAP RLC (например, по множеству логических каналов). Уровень PDCP может включать в себя функциональные возможности множества объектов PDCP. Например, объект PDCP может быть связан с конкретным DRB и/или SRB, выделенным для WTRU. Таким образом, если WTRU выделено множество DRB, может существовать множество объектов PDCP (например, как на WTRU, так и в сети) которые обрабатывают пакеты PDCP (например, SDU и PDU), соответствующие DRB/SRB, связанному с конкретным объектом.

Если в сети используется множество экземпляров RLC (например, первый экземпляр RLC на MeNB и второй экземпляр RLC на SCeNB), то пакеты на/от определенного объекта PDCP могут по-разному отображаться в один или более из экземпляров RLC на разных передающих участках. Например, данные, связанные с определенным объектом PDCP (например, данные плоскости пользователя, связанные с определенным DRB) могут отображаться таким образом, что объект PDCP может переносить соответствующие PDU PDCP через одну SAP RLC (например, с использованием прямого отображения между объектом PDCP и объектом RLC на определенном экземпляре RLC). В другом примере, объект PDCP (например, который может соответствовать определенному DRB) может быть выполнен с возможностью переноса соответствующих PDU PDCP с использованием одного или более из множества SAP RLC, например, в котором данные от объекта PDCP могут переноситься с использованием первого экземпляра RLC (например, на MeNB) в некоторые моменты времени и переноситься с использованием второго экземпляра RLC (например, на SCeNB) в другие моменты времени. Объект PDCP, используемый для переноса данных в сети, может находиться в том же или не в том же узле, что и объект RLC, используемый для передачи данных.

Например, в плоскости пользователя объекты PDCP (например, в сети, на WTRU и т.д.) могут быть выполнены с возможностью передачи и/или приема данных с использованием множества SAP RLC. Использование множества SAP RLC может приводить к обмену данными для определенного данного DRB по множеству трактов данных, причем тракты данных расходятся под уровнем PDCP в сети. PDU PDCP, соответствующие определенному каналу-носителю EPS, могут отображаться в одну или более SAP RLC, причем каждая SAP может соответствовать LCH отдельного экземпляра MAC. Например, фиг. 17 и фиг. 18 демонстрируют пример стеков протоколов, которые можно использовать для переноса данных плоскости пользователя, когда тракты данных разделяются под уровнем PDCP в сети.

Объект PDCP может использовать множество трактов данных (например, связанных с разными экземплярами RLC, расположенный на разных объектах сети) для переноса данных управления (например, данных одного или более SRB). Например, данные, связанные с определенным объектом PDCP (например, данные плоскости управления, связанные с данным SRB), могут отображаться таким образом, что объект PDCP может переносить соответствующие PDU PDCP через одну SAP RLC (например, с использованием прямого отображения между объектом PDCP и объектом RLC на определенном экземпляре RLC). В другом примере, объект PDCP (например, который может соответствовать определенному SRB) может быть выполнен с возможностью переноса соответствующих PDU PDCP с использованием одного или более из множества SAP RLC, например, в котором данные от объекта PDCP могут переноситься с использованием первого экземпляра RLC (например, на MeNB) в некоторые моменты времени и переноситься с использованием второго экземпляра RLC (например, на SCeNB) в другие моменты времени. Например, PDU PDCP, связанные с определенным SRB (например, одним из SRB0, SRB1, SRB2 или вспомогательным SRB), могут отображаться в одну или более SAP RLC.

Фиг. 19 демонстрирует пример стека протоколов в плоскости управления тракта данных, разделенного над RLC, причем PDU PDCP могут переноситься по множеству трактов данных. Например, как показано на фиг. 19, PDU PDCP, связанные с SRB(x), могут переноситься через тракт данных, связанный с MeNB (например, с использованием объекта RLC, расположенного на MeNB) и/или могут переноситься через тракт данных, связанный с SCeNB (например, с использованием объекта RLC, расположенного на SCeNB). В одном примере, такая конфигурация может использоваться для реализации описанного здесь подхода централизованной плоскости управления. Объект PDCP для определенного SRB может располагаться на MeNB. Первый объект RLC, используемый для передачи данных для объекта PDCP, может быть совмещен с объектом PDCP на MeNB. Второй объект RLC, используемый для передачи данных для объекта PDCP, может располагаться на SCeNB. Фиг. 20 демонстрирует пример тракта данных, связанного с SCeNB, когда разделение данных происходит под уровнем PDCP (например, над уровнем RLC).

В одном примере, скоординированную плоскость управления можно реализовать таким образом, что радиоканал-носитель (например, SRB) может пользоваться услугами множества объектов RLC. Например, когда RRC-соединение использует скоординированную плоскость управления, PDU RRC для определенного SRB (например, SRB0, SRB1 и/или SRB2) могут передаваться по множеству трактов данных. Например, может осуществляться мультиплексирование и/или демультиплексирование PDU RRC, связанных с определенным SRB, переносимых через первый объект RLC, и PDU RRC, связанных с SRB второго объекта RRC, переносимых через второй объект RLC.

Для распределенной плоскости управления, PDU RRC, связанные с объектом PDCP, расположенным на MeNB, может пользоваться услугами, предоставляемыми объектом RLC, расположенным на SCeNB. Например, такая архитектура может использовать способы, аналогичные описанным в отношении распределенной плоскости управления, когда разделение данных происходит над уровнем PDCP (например, фиг. 16).

В одном примере, разделение тракта данных может происходить над уровнем MAC (например, под уровнем RLC). В такой архитектуре, уровень PDCP и уровень RLC в сети можно реализовать в одном и том же узле в сети (например, на MeNB). Однако с каждым трактом данных может быть связан свой собственный экземпляр MAC, который связан с одним из множества трактов данных. Фиг. 21 демонстрирует пример стека протоколов в плоскости управления, который можно использовать, если тракты данных разделяются над уровнем MAC. Фиг. 22 демонстрирует пример стека протоколов в плоскости пользователя, который можно использовать, если тракты данных разделяются над уровнем MAC.

Для поддержки архитектуры с множеством планировщиков (например, передачи и/или приема через независимо планируемые тракты данных, отправленные через разные обслуживающие участки), структуру уровня 2 на восходящей линии связи и/или нисходящей линии связи можно изменить по сравнению со структурой, используемой для передачи/приема через один тракт данных. Например, на WTRU данные восходящей линии связи (например, PDU RLC, SDU MAC, и т.д.) из логического канала могут мультиплексироваться в транспортные блоки, доставляемые в один из установленных транспортных каналов (например, UL-SCH) связанных с обслуживающим участком или экземпляром MAC. Фиг. 23 демонстрирует пример структуры уровня 2 для работы на множестве участков восходящей линии связи (например, с использованием раздельной UL). Данные, связанные с конкретным радиоканалом-носителем (например, PDU PDCP), могут отображаться экземпляром RLC в один логический канал. Отображение данных из радиоканала-носителя в один экземпляр RLC может именоваться схемой раздельной передачи UL. При использовании схемы раздельной передачи UL, определенный радиоканал-носитель может отображаться в определенный логический канал, который связан с одним из экземпляров MAC. Хотя данные могут отправляться в сеть через множество транспортных каналов (например, может существовать транспортный канал UL-SCH для каждой компонентной несущей экземпляра MAC), данные, отображаемые в определенный логический канал, могут транспортироваться в сеть через один и тот же экземпляр MAC, если используется схема раздельной передачи UL. В порядке примера, схему раздельной передачи UL можно использовать для переноса данных плоскости пользователя, в которой один радиоканал-носитель SAP (например, единичный SAP RLC) используется со стеком протоколов, который разделяется над уровнем PDCP, хотя схема раздельной передачи UL может использоваться также с другими архитектурами.

Данные из конкретного радиоканала-носителя (например, PDU PDCP) могут отображаться в более чем один логический канал и/или могут отображаться во множество логических подканалов. Данные из радиоканала-носителя, которые разделяются между несколькими логическими каналами, могут обрабатываться разными экземплярами RLC (например, причем каждый экземпляр RLC связан с отдельным передающим/приемным участком в сети и/или расположен на нем). Например, множество экземпляров RLC может быть выполнено с возможностью сегментирования и/или повторной передачи данных, связанных с определенным радиоканалом-носителем. Каждый экземпляр RLC может быть связан с отдельным логическим каналом или логическим подканалом для радиоканала-носителя. Поскольку отдельные экземпляры RLC могут использоваться для обработки данных, связанных с одним радиоканалом-носителем, такая схема может именоваться схема передачи RLC с разделением UL. Фиг. 24 демонстрирует пример структуры уровня 2 для работы на множестве участков восходящей линии связи, в котором используется схема передачи RLC с разделением. На WTRU, данные из логического канала, связанного с определенным экземпляром RLC, могут быть связаны с конкретным экземпляром MAC. Хотя данные могут отправляться в сеть через множество транспортных каналов (например, может существовать транспортный канал UL-SCH для каждой компонентной несущей экземпляра MAC), данные, отображаемые в определенный логический канал, могут транспортироваться в сеть через один и тот же экземпляр MAC. В порядке примера, схему передачи RLC с разделением UL можно использовать для передачи данных плоскости пользователя, в которой множество SAP используются со стеком протоколов, который разделяется над уровнем RLC, хотя схема передачи RLC с разделением UL может использоваться также с другими архитектурами.

В одном примере, на WTRU данные восходящей линии связи, связанные с определенным логическим каналом, могут мультиплексироваться в транспортные блоки, связанные с транспортными каналами для множества обслуживающих участков. Например, данные восходящей линии связи из конкретного логического канала допускают мультиплексирование в транспортные блоки, доставляемые на транспортный канал, связанный с любым из обслуживающих участков (например, любой точкой передачи/приема в сети). Фиг. 25 демонстрирует пример структуры уровня 2, в котором данные для определенного логического канала могут отображаться во множество транспортных каналов, и транспортные каналы могут быть связаны с разными обслуживающими участками. Отображение данных из логического канала в транспортные каналы, связанные с разными участками передачи/приема в сети, может именоваться объединенной схемой передачи UL. При использовании объединенной схемы передачи UL, данные восходящей линии связи (например, SDU RLC) из определенного радиоканала-носителя могут поступать на один из множества логических каналов, которые конфигурированы для радиоканала-носителя. Множество экземпляров MAC и/или множество соответствующих логических каналов может быть конфигурировано для использования каналом-носителем (например, заданным в конфигурации канала-носителя). В порядке примера, объединенную схему передачи UL можно использовать для переноса данных плоскости пользователя, в которой любой PDU MAC можно использовать для транспортировки любого PDU RLC. Например, объединенную схему передачи UL можно применять к архитектуре, в которой тракты передачи разделяются над уровнем MAC, хотя объединенная схема передачи UL может использоваться также для других архитектур.

На стороне сети, SDU MAC можно демультиплексировать из транспортного блока, декодированного на обслуживающем участке, который связан с UL-SCH, используемым для передачи. SDU MAC могут обрабатываться объектом RLC на обслуживающем участке и/или может ретранслироваться на второй участок (например, первичный обслуживающий участок) для обработки объектом RLC на втором участке. Если используется объединенный UL, один или более обслуживающих участков может ретранслировать данные (например, SDU MAC) на обслуживающий участок, на котором располагается объект RLC, выполненный с возможностью обработки данных, связанных с рассматриваемым логическим каналом.

Фиг. 26 демонстрирует пример структуры уровня 2 для работы на множестве участков нисходящей линии связи, которую можно использовать для схемы раздельной передачи DL. На стороне сети, данные нисходящей линии связи из логического канала может мультиплексироваться в транспортные блоки, доставляемые в один из установленных транспортных каналов (например, DL-SCH), связанных с обслуживающим участком или экземпляром MAC. На стороне WTRU, данные нисходящей линии связи, связанные с определенным логическим каналом, можно демультиплексировать из транспортных блоков, принятых через один из набора транспортных каналов (например, DL-SCH), связанный с конкретным обслуживающим участком или экземпляром MAC. Отображение данных из радиоканала-носителя в один экземпляр RLC может именоваться схемой раздельной передачи DL. При использовании схемы раздельной передачи DL, определенный радиоканал-носитель может отображаться в определенный логический канал, который связан с одним из экземпляров MAC. Хотя данные могут отправляться на WTRU через множество транспортных каналов (например, может существовать транспортный канал DL-SCH для каждой компонентной несущей экземпляра MAC), данные, отображаемые в определенный логический канал, могут транспортироваться на WTRU через один и тот же экземпляр MAC, если используется схема раздельной передачи DL.

Фиг. 27 демонстрирует пример структуры уровня 2 для работы на множестве участков нисходящей линии связи, которую можно использовать для схемы передачи DL RLC с разделением. Данные из конкретного радиоканала-носителя (например, PDU PDCP) могут отображаться в более чем один логический канал и/или могут отображаться во множество логических подканалов. Данные из радиоканала-носителя, которые разделяются между несколькими логическими каналами, могут обрабатываться разными экземплярами RLC (например, причем каждый экземпляр RLC связан с отдельным передающим/приемным участком в сети и/или расположен на нем). Например, множество экземпляров RLC может быть выполнено с возможностью сегментирования и/или повторной передачи данных, связанных с определенным радиоканалом-носителем. Каждый экземпляр RLC может быть связан с отдельным логическим каналом или логическим подканалом для радиоканала-носителя. Поскольку отдельные экземпляры RLC могут использоваться для обработки данных, связанных с одним радиоканалом-носителем, такая схема может именоваться схема передачи DL RLC с разделением. В сети, данные из логического канала, связанные с определенным экземпляром RLC, могут быть связаны с конкретным экземпляром MAC. Хотя данные могут отправляться на WTRU через множество транспортных каналов (например, может существовать транспортный канал DL-SCH для каждой компонентной несущей экземпляра MAC), данные, отображаемые в определенный логический канал, могут транспортироваться на WTRU через один и тот же экземпляр MAC.

В одном примере, в сети данные нисходящей линии связи, связанные с определенным логическим каналом, может мультиплексироваться в транспортные блоки, связанные с транспортными каналами для множества обслуживающих участков. Например, данные нисходящей линии связи из конкретного логического канала допускают мультиплексирование в транспортные блоки, доставляемые на транспортный канал, связанный с любым из обслуживающих участков (например, любой точкой передачи/приема в сети). Фиг. 28 демонстрирует пример структуры уровня 2, в котором данные нисходящей линии связи для определенного логического канала могут отображаться во множество транспортных каналов, и транспортные каналы могут быть связаны с разными обслуживающими участками. Отображение данных нисходящей линии связи из логического канала в транспортные каналы, связанные с разными участками передачи/приема в сети, может именоваться объединенной схемой передачи DL. При использовании объединенной схемы передачи DL, данные нисходящей линии связи (например, SDU RLC) из определенного радиоканала-носителя могут поступать на один из множества логических каналов, которые конфигурированы для радиоканала-носителя. Множество экземпляров MAC и/или множество соответствующих логических каналов может быть конфигурировано для использования каналом-носителем (например, заданным в конфигурации канала-носителя). В порядке примера, объединенную схему передачи DL можно использовать для переноса данных плоскости пользователя, причем любой PDU MAC можно использовать для транспортировки любого PDU RLC.

Если используется один или более двунаправленных логических каналов (например, выделенный канал управления (DCCH) и/или двунаправленный выделенный канал трафика (DTCH)), можно использовать разные комбинации схем передачи восходящей линии связи и нисходящей линии связи. Например, для определенного логического канала можно использовать схему раздельной передачи DL и объединенную схему передачи UL. В одном примере, обслуживающий участок, связанный с логическим каналом на DL может отличаться от обслуживающего участка, связанного с логическим каналом на UL. Например, схема раздельной передачи DL и схема раздельной передачи UL может использоваться для определенного логического канала. Объект RLC на стороне сети может эксплуатироваться на первом обслуживающем участке в сети, и DL-SCH может передаваться от первого обслуживающего участка. Однако, хотя на втором обслуживающем участке может не быть объекта RLC, SDU MAC UL все еще могут передаваться на второй обслуживающий участок и декодироваться там. SDU MAC UL, передаваемые на второй обслуживающий участок, могут ретранслироваться на первый участок для обработки объектом RLC. Такая схема, в которой первый обслуживающий участок включает в себя объект RLC (например, и/или DL-SCH передается от первого обслуживающего участка), но SDU MAC UL все еще могут передаваться на второй обслуживающий участок (например, в которой второй обслуживающий участок не имеет объекта RLC и пересылает SDU MAC UL на второй обслуживающий участок после декодирования), может именоваться «разъединенной UL/DL». В одном примере, схему раздельной передачи DL и схему раздельной передачи UL можно использовать для один или более двунаправленных логических каналов. Например, обслуживающий участок, соответствующий передающему участку DL для логического канала, и обслуживающий участок, соответствующий точке приема UL для двунаправленного логического канала, могут быть одним и тем же обслуживающим участком, и объект RLC может работать на этом обслуживающем участке, не ретранслируя SDU MAC на другой обслуживающий участок.

Более высокие уровни (например, RRC) могут использоваться для конфигурирования схем передачи восходящей линии связи и/или нисходящей линии связи, подлежащих использованию для определенного передающего участка и/или для определенного логического канала. Например, когда WTRU принимает сигнализацию RRC, конфигурирующую определенный логический канал, причем сигнализация RRC может указывать, подлежит ли использованию объединенная схема передачи (например, UL и/или DL) или схема раздельной передачи (например, UL и/или DL) для логического канала. Например, если используется схема раздельной передачи DL и/или схема раздельной передачи UL, сигнализация RRC может указывать отображение, которое указывает, на/из какой/ого из одного или более обслуживающих участков следует передавать и/или принимать логический канал. В одном примере, отображение логических каналов в обслуживающие участки может быть заданным для одного или более логических каналов, и WTRU может неявно знать, с каким обслуживающим участком связан логический канал, не принимая явного отображения. Например, логические каналы управления (например, DCCH) могут отображаться в транспортные каналы, связанные с первичным обслуживающим участком. Логические каналы трафика (например, DTCH) могут отображаться в транспортные каналы, связанные с вторичным обслуживающим участком.

Если используется схема раздельной передачи DL и/или схема раздельной передачи UL, сигнализация RRC может использоваться для конфигурирования отображения между логическим каналом и соответствующим обслуживающим участком. Например, сигнализация RRC, используемая для конфигурирования логического канала для использования WTRU может включать в себя указание идентификатора логического канала и идентификатора обслуживающего участка (например, и/или идентификатора экземпляра MAC), что позволяет WTRU знать, какой обслуживающий участок следует использовать для логического канала. В одном примере, вместо или помимо использования идентификатора обслуживающего участка (например, и/или идентификатора экземпляра MAC), сигнализация RRC, используемая для конфигурирования логического канала может идентифицировать отображение путем включения идентификатора логического канала и идентификатора обслуживающей соты (например, когда обслуживающая сота связана с одним из обслуживающих участков). Множество логических каналов может быть конфигурировано совместно для связывания с определенным обслуживающим участком. Например, группа логических каналов может идентифицироваться идентификатором группы логических каналов и идентификатором обслуживающего участка (например, и/или идентификатором обслуживающей соты). В одном примере, WTRU может быть способен неявно определять, с каким обслуживающим участком связан определенный логический канал, на основании идентификатора логического канала для этого логического канала. Например, определенные идентификаторы логических каналов могут быть связаны с первичным обслуживающим участком, и другие идентификаторы логических каналов могут быть связаны с вторичным обслуживающим участком.

В одном примере, поднабор логических каналов, из которых данные могут мультиплексироваться в транспортные блоки одного или более транспортных каналов, связанных с конкретным обслуживающим участком (например, и/или экземпляр MAC) может именоваться «группой планирования логических каналов» для обслуживающего участка или экземпляра MAC. Из вышеописанных структур уровня 2, UL (и/или DL) группы планирования логических каналов разных обслуживающих участков могут не зависеть друг друга (например, обработка на более высоких уровнях не перекрываются), например, в случае схемы раздельной передачи UL (например, и/или схемы раздельной передачи DL) используется. Аналогично, если используется схема передачи RLC с разделением UL (например, и/или схема передачи DL RLC с разделением), тракты обработки выше уровня 2 могут не зависеть друг друга.

Примерный случай использования для вторичного обслуживающего участка может быть случай разгрузки передачи данных DL. Например, WTRU может первоначально соединяться с первичным обслуживающим участком (например, который может соответствовать MeNB), но может принимать от первичного обслуживающего участка переконфигурирование, которое переконфигурирует один или более радиоканалов-носителей (например, и/или логические каналы), подлежащих передаче на вторичный обслуживающий участок и/или приему от него. В порядке примера, один или более каналов данных нисходящей линии связи можно переконфигурировать для приема через вторичный обслуживающий участок. Такая схема может освобождать первичный обслуживающий участок от необходимости передачи столь большого объема данных на WTRU, например, в течение периодов, в которых WTRU может хорошо обслуживаться одной или более малых сот. Поскольку малые соты могут обслуживать меньше WTRU, чем обслуживается в макросоте, разгрузка передач данных DL на малые соты может экономить сетевые ресурсы, в то же время поддерживая желаемый уровень обслуживания для WTRU. В одном примере, данные нисходящей линии связи, подлежащие доставке на WTRU, может приниматься MeNB и пересылаться или ретранслироваться на SCeNB для доставки на WTRU. Здесь описаны примеры обработки данных нисходящей линии связи, когда данные нисходящей линии связи могут ретранслироваться первичным обслуживающим участком (например, MeNB) на вторичный обслуживающий участок (например, SCeNB) для доставки на WTRU.

Как данные DL, подлежащие доставке на WTRU, обрабатывается сетью и/или WTRU, может зависеть от местоположения объекта RLC, связанного с данными DL в сети. Например, объект RLC, обрабатывающий данные нисходящей линии связи для радиоканала-носителя, может эксплуатироваться на вторичном обслуживающем участке (например, на SCeNB). Если объект RLC располагается на вторичном обслуживающем участке, объект RLC в сети может формировать PDU RLC и их сегменты размер которых можно адаптировать к размеру транспортного блока, применимому к текущим условиям радиосвязи. Соответствующий логический канал, связанный с формируемыми PDU RLC, может отображаться в DL-SCH от вторичного обслуживающего участка, например, с использованием схемы раздельной передачи DL.

Для двунаправленных логических каналов, если объект RLC на стороне сети располагается на вторичном обслуживающем участке, передачи DL, связанные с двунаправленным логическим каналом, может отправляться от вторичного обслуживающего участка, и один или более вариантов может использоваться WTRU для передачи данных UL, связанных с двунаправленным логическим каналом. Например, данные UL для двунаправленного логического канала могут отображаться в UL-SCH, связанный с вторичным обслуживающим участком (например, схема раздельной передачи UL на вторичный обслуживающий участок). Если WTRU передает данные UL на вторичный обслуживающий участок, один и тот же объект RLC на стороне сети может обрабатывать как данные восходящей линии связи, так и данные нисходящей линии связи для двунаправленного логического канала. Объект PDCP, используемый для обработки данных восходящей линии связи и/или нисходящей линии связи для двунаправленного логического канала, также может работать на вторичном обслуживающем участке.

В одном примере, данные UL для двунаправленного логического канала могут отображаться в UL-SCH, связанный с первичным обслуживающим участком (например, схема раздельной передачи UL на первичный обслуживающий участок). В другом примере, данные UL для двунаправленного логического канала могут отображаться в UL-SCH, связанный с первичным обслуживающим участком и/или вторичным обслуживающим участком (например, объединенная схема передачи UL).

Например, данные UL для двунаправленного логического канала могут отображаться в UL-SCH, связанный с первичным обслуживающим участком, например, когда WTRU не осуществляет передачи UL на вторичный обслуживающий участок. Однако объект RLC на стороне сети все же может располагаться на вторичном обслуживающем участке даже когда передачи UL на вторичный обслуживающий участок не осуществляются. Если данные UL для двунаправленного логического канала отображается в UL-SCH, связанный с первичным обслуживающим участком, PDU RLC, которые демультиплексируются из транспортных блоков восходящей линии связи, которые декодируются на первичном обслуживающем участке, могут ретранслироваться первичным обслуживающим участком на вторичный обслуживающий участок для обработки объектом RLC на вторичном обслуживающем участке.

В одном примере, PDU RLC, передаваемые WTRU, которые связаны с двунаправленным логическим каналом, данные DL которого передаются через вторичный обслуживающий участок, можно демультиплексировать из транспортных блоков восходящей линии связи, которые могут приниматься и декодироваться на первичном обслуживающем участке. Эти PDU RCL может обрабатываться объектом приема RLC, работающим на первичном обслуживающем участке. Объект приема RLC на первичном обслуживающем участке может выдавать информацию управления (например, через сетевой интерфейс, например X2bis) на объект RLC, манипулирующий тем же логическим каналом на вторичном обслуживающем участке. Например, объект RLC на первичном обслуживающем участке, который принимает PDU RLC от WTRU, может отправлять информацию, относящуюся к идентификатору/порядковому номеру PDU RLC, которые были и/или не были успешно приняты, на объект RLC на вторичном обслуживающем участке, чтобы объект RLC мог на вторичном обслуживающем участке формировать и выдавать отчеты статуса и другую информацию управления на равноправный объект RLC на стороне WTRU (например, через передачи нисходящей линии связи). В одном примере, PDU RLC, демультиплексированные из транспортных блоков восходящей линии связи, принятых и декодированных на вторичном обслуживающем участке, могут ретранслироваться на объект приема RLC на первичном обслуживающем участке без обработки объектом RLC на вторичном обслуживающем участке. PDU RLC, принятые на UL вторичным обслуживающим участком, могут пересылаться на экземпляр RLC первичного обслуживающего участка для обработки при использовании объединенной схемы передачи UL.

В одном примере, WTRU может передавать PDU управления RLC на восходящей линии связи на вторичный обслуживающий участок, тогда как PDU данных RLC могут передаваться на первичный обслуживающий участок. Например, PDU управления RLC, формируемые объектом RLC на WTRU, могут мультиплексироваться в транспортные блоки, доставляемые на транспортном канале, связанном с вторичным обслуживающим участком, тогда как PDU данных RLC могут мультиплексироваться в транспортные блоки, доставляемые на транспортном канале, связанном с первичным обслуживающим участком. В одном примере, определенный двунаправленный логический канал может разделяться на два двунаправленных логических подканала. Первый логический подканал двунаправленного логического канала может быть связан с PDU данных RLC, которые передаются WTRU на первый обслуживающий участок (например, первичный обслуживающий участок), и с PDU управления RLC, которые принимаются от первичного обслуживающего участка. Второй логический подканал двунаправленного логического канала может быть связан с PDU данных RLC, которые принимаются WTRU от второго обслуживающего участка (например, вторичного обслуживающего участка), и с PDU управления RLC, которые передаются на вторичный обслуживающий участок.

В одном примере, объект RLC может располагаться на первичном обслуживающем участке. Например, PDU RLC, подлежащие передаче на нисходящей линии связи на WTRU, могут пересылаться на вторичный обслуживающий участок от объекта RLC на первичном обслуживающем участке с использованием сетевого интерфейса (например, X2bis). Например, объект MAC на вторичном обслуживающем участке может принимать PDU RLC от объекта RLC на первичном обслуживающем участке и передавать PDU RLC на WTRU через одну или более сот вторичного обслуживающего участка. Объект RLC, расположенный на первичном обслуживающем участке, может соответствовать одному объекту RLC, который выполнен с возможностью формирования PDU RLC, связанных с первичным и/или вторичным обслуживающими участками. В одном примере, данные нисходящей линии связи, передаваемые на WTRU, могут отправляться через вторичный обслуживающий участок, что позволяет объекту RLC, расположенному на первичном обслуживающем участке, обеспечивать любые PDU RLC, подлежащие доставке на WTRU, вторичному обслуживающему участку для передачи.

Поскольку первичный обслуживающий участок может формировать PDU RLC, подлежащие доставке через вторичный обслуживающий участок, и объект RLC, расположенный на первичном обслуживающем участке, может не знать условия канала, близкие к реальному времени, присутствующие на вторичном обслуживающем участке во время формирования PDU RLC, некоторая сегментация и/или другие решения по планированию могут осуществляться на вторичном обслуживающем участке после того, как он принимает PDU RLC, подлежащие доставке на WTRU, от первичного обслуживающего участка. Например, объект RLC, расположенный на узле, который отличается от узла, который принимает решения по планированию для передачи данных этого объекта RLC (например, объект RLC располагается на первичном обслуживающем участке, но экземпляр MAC, осуществляющий планирование, располагается на вторичном обслуживающем участке) может формировать один или более PDU RLC, которые не имеют надлежащего размера с учетом размера транспортного блока, выделенного экземпляром MAC, осуществляющим планирование. Например, PDU RLC, формируемый экземпляром RLC на первичном обслуживающем участке, может не укладываться в размер транспортного блока, выделенный экземпляром MAC на вторичном обслуживающем участке. Во избежание задержки передачи такого PDU RLC пока планировщик не выделит транспортный блок, который может вмещать в себя PDU RLC (что, например, может быть трудно с учетом текущих условий канала), можно задавать методы, позволяющие избегать ситуаций, в которых передача может задерживаться и/или некоторая сегментация и/или ограниченные функциональные возможности RLC могут осуществляться на вторичном обслуживающем участке, несмотря на то, что объект RLC располагается на первичном обслуживающем участке.

Например, во избежание формирования сравнительно больших PDU RLC, которые могут задерживаться после поступления на экземпляре MAC вторичного обслуживающего участка, объекту RLC на первичном обслуживающем участке можно запрещать формировать PDU RLC, превышающие максимальный размер PDU RLC. Устанавливая максимальный размер PDU RLC для PDU RLC, формируемых на объекте RLC, который располагается на другом обслуживающем участке, чем экземпляр MAC, используемый для передачи данных на WTRU, можно минимизировать вероятность того, что PDU RLC не укладываются в размер транспортного блока, установленный экземпляром MAC вторичного обслуживающего участка. Максимальный размер PDU RLC для PDU RLC, передаваемых обслуживающим участком, который не включает в себя объект RLC, сформировавший PDU RLC, может быть меньше, чем максимальный размер PDU RLC для PDU RLC, которые передаются от обслуживающего участка, который включает в себя объект RLC. В одном примере, PDU RLC, передаваемые от обслуживающего участка, который включает в себя объект RLC, сформировавший PDU RLC, можно не ограничивать в отношении максимального размера PDU RLC.

В одном примере, хотя вторичный обслуживающий участок может не включать в себя полный объект RLC, функциональные возможности сегментации RLC могут располагаться на вторичном обслуживающем участке, например, над экземпляром MAC, связанным с вторичной обслуживающей сотой. Например, объект RLC на первичном обслуживающем участке может быть выполнен с возможностью первоначально формировать PDU RLC, подлежащие передаче от одного или более из первичного и/или вторичного обслуживающего участка. Объект RLC на первичном обслуживающем участке может быть выполнен с возможностью осуществления функциональных возможностей сегментации PDU RLC, передаваемых через соты, принадлежащие первичному обслуживающему участку. Однако объект RLC на первичном обслуживающем участке может быть выполнен с возможностью отказываться от сегментирования формируемых им PDU RLC, которые подлежат передаче через соты, принадлежащие вторичному обслуживающему участку. Функциональные возможности сегментации RLC для PDU RLC, передаваемых через вторичный обслуживающий участок, могут располагаться, например, на вторичном обслуживающем участке, даже если остаются функциональные возможности RLC для обработки тех PDU RLC, которые располагается на первичном обслуживающем участке в сети. Вторичный обслуживающий участок может принимать PDU RLC, формируемые первичным обслуживающим участком, и может сегментировать PDU RLC, подлежащие передаче через экземпляр MAC, связанный с вторичным обслуживающим участком. Сегментация PDU RLC на вторичном обслуживающем участке может быть прозрачна для объекта RLC, расположенного на первичном обслуживающем участке.

PDU состояния RLC (например, PDU управления RLC, включающие в себя отчет о состоянии RLC) могут отправляться на объект RLC на первичном обслуживающем участке. В одном примере, когда объект RLC на первичном обслуживающем участке принимает PDU статуса RLC для PDU RLC, сегментированного на вторичном обслуживающем участке, PDU статуса RLC могут пересылаться на вторичный обслуживающий участок и/или обрабатываться вторичным обслуживающим участком. В одном примере, когда объект RLC принимает PDU статуса RLC, который отрицательно квитирует PDU RLC, сегментированный на вторичном обслуживающем участке, объект RLC может повторно передавать все исходные PDU RLC, даже если некоторые из сегментов были положительно квитированы, при условии, что сегмент исходного PDU RLC был отрицательно квитирован. Таким образом, отчет о статусе RLC может обрабатываться на первичном обслуживающем участке без необходимости знать что-либо о сегментации на вторичном обслуживающем участке.

В одном примере, экземпляр MAC передающий PDU RLC (например, экземпляр MAC на вторичном обслуживающем участке) может быть выполнен с возможностью поддержки сегментации PDU RLC. Например, PDU RLC могут формироваться объектом RLC первичного обслуживающего участка и могут пересылаться на экземпляр MAC соты на вторичном обслуживающем участке. После приема PDU RLC, экземпляр MAC может определять, осуществлять ли сегментацию PDU RLC, например, на основании наличия места в планируемом транспортном блоке. Экземпляр MAC может осуществлять сегментацию и конкатенацию PDU RLC. Поскольку экземпляр MAC принимающей стороны может повторно собирать сегменты PDU RLC, формируемого экземпляром MAC, дополнительная информация сегментации может добавляться в заголовок MAC. Например, информация сегментации может обеспечивать указание, включает ли в себя PDU MAC, который включает в себя заголовок, SDU MAC, который соответствует полному PDU RLC, SDU MAC, который соответствует первому сегменту PDU RLC, SDU MAC, который соответствует среднему сегменту PDU RLC, и/или SDU MAC, который соответствует последнему или конечному сегменту PDU RLC. Заголовок MAC может включать в себя порядковый номер для каждого PDU MAC. WTRU может переупорядочивать PDU MAC и повторно собирать SDU MAC, например, на основании порядкового номера и/или дополнительной информации сегментации, которая указывает, соответствует ли SDU MAC первому, среднему или конечному сегменту определенного PDU RLC. В одном примере, SDU MAC могут быть снабжены порядковыми номерами, и заголовок MAC может указывать номер сегмент определенного SDU MAC.

После приема PDU MAC от экземпляра MAC вторичного обслуживающего участка, экземпляр MAC на принимающем объекте (например, WTRU) может повторно собирать сегментированные SDU MAC и пересылать несегментированные SDU MAC на объект RLC. Например, на основании порядковых номеров принятых PDU MAC, WTRU может переупорядочивать принятые PDU MAC и/или разбирать PDU MAC. Если объект сегментация указывает, что сегментация SDU MAC осуществлялась объектом MAC, WTRU может повторно собирать сегменты, включенные во множество PDU MAC, в SDU MAC.

Поскольку объект RLC и объект MAC могут не быть совмещены в определенном узле сети (например, объект RLC может располагаться на первичном обслуживающем участке, и объект MAC может располагаться на вторичном обслуживающем участке), и сетевой интерфейс между первичным и вторичным обслуживающими участками может быть связан со сравнительно большими задержками, буферизацию и/или управление потоками можно реализовать между первичным и вторичным обслуживающими участками, чтобы гарантировать непрерывность передач. Например, управление потоками может осуществляться для того, чтобы планировщик, расположенный на вторичном экземпляре MAC, надлежащим образом планировал ресурсы для передачи PDU данных RLC, переправленных от первичного обслуживающего участка. Например, экземпляр MAC на вторичном обслуживающем участке может запрашивать информацию, связанную с передачей одного или более PDU RLC от объекта RLC на первичном обслуживающем участке. В порядке примера, экземпляр MAC может запрашивать один или более из указания количества битов данных, планируемых экземпляром MAC для передачи на WTRU, указания продолжительности времени, необходимой для передачи на WTRU запрашиваемого количества битов, указания продолжительности времени, необходимой для передачи на WTRU буфера определенного размера, указания доступного объема радиоресурсов для передачи на WTRU, указания средней скорости передачи данных, поддерживаемой для передачи на WTRU, и/или запроса опроса первичного обслуживающего участка для определения, могут ли еще быть данные, подлежащие передаче на WTRU.

Объект RLC на первичном обслуживающем участке может быть выполнен с возможностью снабжения планировщика вторичного обслуживающего участка (например, расположенного в экземпляре MAC вторичного обслуживающего участка) информацией, связанной с объемом данных, типом данных и/или характеристиками данных, которые подлежат передаче на WTRU. Например, первичный обслуживающий участок может отправлять информацию, связанную с данными, буферизованными для передачи с WTRU на экземпляр MAC на вторичном обслуживающем участке (например, с использованием сетевого интерфейса). Первичный обслуживающий участок может выдавать экземпляру MAC вторичного участка полный отчет о статусе буфера для данных DL, подлежащих передаче на WTRU (например, данных, подлежащих передаче через первичный или вторичный обслуживающий участок). Первичный обслуживающий участок может выдавать экземпляру MAC вторичного участка отчет о статусе буфера для данных DL, подлежащих передаче на WTRU, который передается/отображается во вторичный обслуживающий участок. Первичный обслуживающий участок может отправлять экземпляру MAC вторичного участка запрос, который указывает, что данные подлежат передаче через соты вторичного обслуживающего участка. Например, запрос может указывать суммарное количество буферов, подлежащих передаче через вторичный обслуживающий участок, и/или желаемую битовую скорость.

Экземпляры AMC на разных обслуживающих участках могут реализовывать разные правила для манипулирования передачами данных и их обработки. Например, правила мультиплексирования логических каналов, управления мощностью, осуществления передачи PUSCH UL могут различаться в зависимости от используемого участка.

В порядке примера, мониторинг линии радиосвязи (RLM) может осуществляться экземпляром MAC, связанный с первичным обслуживающим участком (например, на WTRU), но экземпляр MAC, связанный с вторичным участком (например, на WTRU) может отказываться от осуществления RLM, если конкретно не конфигурирован сетью для этого. В одном примере, обнаружение RLF на первичном экземпляре MAC может приводить к переустановлению RRC-соединения, тогда как обнаружение RLF на вторичном экземпляре MAC может не приводить к переустановлению RRC-соединения. В одном примере, сброс MAC для вторичного экземпляра MAC может не приводить к сбросу другого экземпляра MAC (например, первичного экземпляра MAC и/или другого вторичного экземпляра MAC). Сброс MAC для вторичного экземпляра MAC может подвешивать DRB, которые связаны только со сбрасываемым экземпляром MAC; однако DRB, связанные для этого со сбрасываемым экземпляром MAC и также с другим экземпляром MAC, могут оставаться активными, поскольку в ходе процедуры сброса данные могут передаваться через другой экземпляр MAC.

При использовании DRX, зависящего от экземпляра MAC (например, разные экземпляры MAC могут применять разные конфигурации DRX), состояние DRX первичного MAC может иметь превосходство или приоритет над состоянием DRX вторичного MAC. Например, если WTRU выполнен с возможностью отказываться от осуществления передач восходящей линии связи в одновременно двух экземплярах MAC, WTRU в течение активного времени DRX в первичном экземпляре MAC может заключить, что WTRU должен находиться в неактивном состоянии DRX во вторичном экземпляре MAC. В одном примере, когда SR запускается на основании того, что данные становятся доступными для определенного RB (например, DRB, SRB, и т.д.), WTRU может осуществлять передачу SR с использованием экземпляра MAC, который соответствует рассматриваемому RB. В одном примере, когда SR запускается на основании того, что данные становятся доступными для определенного DRB, WTRU может осуществлять передачу SR с использованием экземпляра MAC, который соответствует рассматриваемому DRB, но если SR запускается на основании данных, подлежащих передаче для SRB, процедура SR может осуществляться в первичном экземпляре MAC (например, даже когда SRB связан с вторичным экземпляром MAC, например SRB3).

В одном примере, экземпляр MAC, связанный с каждым из обслуживающих участков, может работать независимо друг от друга. Например, можно задавать множество экземпляров MAC (или объектов), причем каждый экземпляр MAC может использовать транспортные каналы, связанные с одним обслуживающим участком. Каждый из экземпляров MAC может использовать независимые конфигурации MAC, например независимые наборы параметров, переменные состояния, таймеры, объекты HARQ и т.д. Работа MAC независимая от участка, может применяться к работе, включающей в себя одно или более из процедур произвольного доступа, поддержания выравнивания по времени восходящей линии связи (например, каждый экземпляр MAC может поддерживать свои собственные активное время, таймеры, относящиеся к DRX, параметры, относящиеся к DRX, таймер TAT и т.д.), активации/деактивации S-сот (например, каждый экземпляр MAC может иметь P-соту и/или одну или более S-сот), переноса данных DL-SCH, переноса данных UL-SCH (например, запроса планирования, выдачи отчета о статусе буфера, выдачи отчета о запасе мощности, назначения приоритетов логических каналов и т.д.), работы в режиме прерывистого приема (DRX), процедур переконфигурирования MAC, процедур сброса MAC, частично устойчивого планирования и/или т.п.

В порядке примера, экземпляр MAC на определенном обслуживающем участке может быть выполнен с возможностью осуществления выдачи отчета о статусе буфера (BSR). Можно применять разные процедуры выдачи отчета о статусе буфера, например, на основании архитектуры/схемы передачи уровня 2, используемой на восходящей линии связи.

В порядке примера, выдача отчета по BSR может осуществляться независимо разными экземплярами MAC. Например, множество процедур BSR может выполняться независимо и/или одновременно, в которых определенная процедура BSR может соответствовать определенному обслуживающему участку (например, и/или экземпляру MAC). Процедура BSR, связанная с определенным экземпляром MAC может выполняться в группе планирования логических каналов обслуживающего участка/экземпляре MAC/быть связана с группой планирования логических каналов обслуживающего участка/экземпляром MAC. Отчет по BSR, формируемый как часть процедуры BSR, связанной с определенным экземпляром MAC, может быть включен в элемент управления MAC, который включен в транспортный блок для транспортного канала, связанного с обслуживающим участком/экземпляром MAC. Отчет по BSR для определенного экземпляра MAC может формироваться на основании информации, связанной с передачей/приемом рассматриваемого экземпляра MAC (например, выделенных ресурсов UL, разрешения(й) UL, передачи/приема PDU MAC, информации, рассматриваемой при определении, применимом к формированию BSR заполнения, отмены запущенных BSR, значения BSR и т.д.), но не информации, связанной с передачей других экземпляров MAC. Параметры BSR, например, таймер повторной передачи BSR (например, retxBSR-Timer) и/или таймер периодического BSR (например, periodicBSR-Timer) могут иметь разные значения в зависимости от обслуживающего участка или экземпляра MAC, с которым связаны параметры BSR. Независимая выдача отчета по BSR может использоваться для одной или более схем передачи UL/структур уровня 2. Например, независимая выдача отчета по BSR может использоваться, если используется схема раздельной передачи UL/структура уровня 2. Таким образом, разным объектам планирования на стороне сети можно сообщать статус буфера, относящийся к группе планирования логических каналов для соответствующего обслуживающего участка/экземпляра MAC.

В одном примере, выдача общего отчета по BSR может осуществляться по множеству экземпляров MAC. Например, одна объединенная процедура BSR может работать по множеству обслуживающих участков и/или логических каналов. Объединенная процедура BSR может снабжать каждый планировщик информацией, связанной с передачами на обслуживающем участке, связанном с планировщиком, и/или информацией, связанной с передачами на других обслуживающих участках, используемых WTRU.

Например, при всяком запуске BSR, BSR может передаваться для каждого обслуживающего участка. BSR для определенного обслуживающего участка может передаваться по транспортному каналу, связанному с обслуживающим участком. BSR для обслуживающего участка может включать в себя информацию, формируемую на основании данных восходящей линии связи, которые подлежат передаче на этот обслуживающий участок. BSR может не передаваться на один или более обслуживающих участков, даже если BSR был запущен в отсутствие данных для передачи из группы планирования логических каналов, связанной с обслуживающим участком. BSR заполнения может передаваться от одного или более обслуживающих участков, например, при достаточном количестве битов заполнения в одном из транспортных блоков для этого обслуживающего участка. Содержание BSR, передаваемого для обслуживающего участка может определяться на основании данных из соответствующей группы планирования логических каналов обслуживающего участка. Если данные из определенного логического канала мультиплексируются на транспортные блоки для более чем одного обслуживающего участка, BSR может отражать статус после формирования PDU MAC для разных обслуживающих участков (например, в результате, WTRU не создает впечатления, что имеется больше данных, чем фактически подлежат передаче путем сообщения данных во множестве BSR множеству участков).

Данные, рассматриваемые WTRU как доступные для передачи с целью формирования BSR, могут включать в себя один или более из SDU RLC, PDU данных RLC, сегментов PDU данных RLC, и/или PDU статуса RLC, связанных с группой планирования логических каналов экземпляра MAC, для которого формируется BSR. SDU PDCP и/или PDU PDCP можно не рассматривать для формирования BSR. Рассматривая SDU RLC, PDU данных RLC и/или PDU статуса RLC, связанных с группой планирования логических каналов экземпляра MAC, для которого формируется BSR, как доступные для передачи, выдачу отчета о статусе BSR можно эффективно реализовать в схеме передачи RLC с разделением/структура уровня 2.

В одном примере, данные, рассматриваемые как доступные для передачи с целью формирования BSR, могут включать в себя часть или все SDU PDCP и/или PDU PDCP, например, SDU PDCP и/или PDU PDCP, которые можно рассматривать как доступные для каждой процедуры выпуска 11. Если часть SDU PDCP и/или PDU PDCP рассматривается как доступные, часть может соответствовать отношению, обеспечиваемому более высокими уровнями. Часть может соответствовать большему из «коэффициента использования ресурсов» обслуживающего участка (или экземпляра MAC) и минимального значения. «Коэффициент использования ресурсов» может соответствовать отношению ресурсов UL, выделенных в определенный период времени для транспортных каналов, связанных с соответствующим обслуживающим участком/экземпляром MAC), и суммой всех ресурсов UL, выделенных в тот же период времени для транспортных каналов, связанных со всеми обслуживающими участками/экземплярами MAC. В одном примере, SDU PDCP и/или PDU PDCP можно рассматривать доступные для передачи в процедуре формирования BSR, если SDU PDCP и/или PDU PDCP связаны с конкретным обслуживающим участком/экземпляром MAC, для которого формируется передача. SDU PDCP и/или PDU PDCP, связанные с другими участками (например, участками, которые не связаны с формируемым BSR), могут не считаться доступными для передачи при вычислении BSR другого обслуживающего участка.

Данные, рассматриваемые как доступные для передачи, могут включать в себя часть полного объема данных, рассматриваемых как доступные для передачи для логического канала в определенной группе планирования логических каналов. Если часть SDU PDCP и/или PDU PDCP рассматривается как доступные, часть может соответствовать отношению, обеспечиваемому более высокими уровнями. Часть может соответствовать большему из «коэффициента использования ресурсов» обслуживающего участка (или экземпляра MAC) и минимального значения.

WTRU может быть конфигурирован одним или более наборов ресурсов для отправки запросов планирования (SR) в сеть. Для многоуровневой работы, WTRU может выделять ресурсы для осуществления SR на множестве уровней (например, первый ресурс может быть доступен на первичном уровне, и второй ресурс может быть доступен на вторичном уровне). Примером ресурса, который можно использовать для передачи SR в сеть, может быть конфигурация PRACH для запроса планирования произвольного доступа (RA-SR). Другим примером ресурса, который можно использовать для передачи SR может быть конфигурация принятого физического канала управления восходящей линии связи (PUCCH), которая принимается WTRU (например, через сигнализацию RRC), которая выделяет выделенные ресурсы PUCCH определенному WTRU для отправки запросов планирования (например, выделенные ресурсы SR (D-SR)). Конфигурация PUCCH может задавать периодическое выделение физических ресурсов PUCCH, которые WTRU может использовать для отправки SR на определенном уровне. В одном примере, WTRU может выбирать ресурс для использования для осуществления SR на основании одной или более характеристик данных, подлежащих передаче. Например, пример характеристики данных, которую можно использовать для выбора надлежащего ресурса для отправки SR, может включать в себя идентификатор канала-носителя (например, DRB, SRB и т.д.), связанный с данными, подлежащими передаче. Другой пример характеристики данных, которую можно использовать для выбора надлежащего ресурса для отправки SR, может включать в себя связь определенного канала-носителя с конкретным уровнем (например, первичным уровнем, вторичным уровнем и т.д.).

В порядке примера, WTRU может быть конфигурирован конфигурацией PRACH для P-соты первичного уровня. WTRU также может быть конфигурирован конфигурацией PRACH для обслуживающей соты вторичного уровня. Дополнительно, WTRU может быть конфигурирован выделенным ресурсом для отправки SR на PUCCH на одном или более уровней, например в обслуживающей соте вторичного уровня. WTRU может быть конфигурирован первым DRB и/или первым SRB, который может быть связан с первичным уровнем. WTRU может быть конфигурирован вторым DRB и/или вторым SRB, который может быть связан с вторичным уровнем. Если новые данные становятся доступными для передачи для одного или более из RB, конфигурированных для WTRU, и SR запускается, WTRU может выбирать ресурс для использования для осуществления процедуры SR на основании уровня, связанного с RB, запустившего запрос. Например, если SR запущен из данных на первом SRB, WTRU может осуществлять RA-SR в P-соте первичного уровня. Если SR запущен из данных, связанных со вторым DRB, WTRU может осуществлять D-SR и/или RA-SR в обслуживающей соте вторичного уровня.

В одном примере, WTRU может быть выполнен с возможностью осуществления процедуры SR в P-соте первичного уровня после сбоя процедуры SR на вторичном уровне. Например, при отправке SR на первичном уровне для RB, связанного с вторичным уровнем, WTRU может отправлять указание данных, доступных для обоих RB, связанных с вторичным уровнем (например, которые запустили SR) и любых данных, доступных для передачи, связанных с RB, отображаемым в первичный уровень в BSR. В одном примере, WTRU может пересвязывать один или более RB, связанных с вторичным уровнем, с первичным уровнем на основании сбоя SR на вторичном уровне.

В одном примере, как WTRU обрабатывает сбой SR, может базироваться на том, какой уровень, включенный в ресурс SR, используется для не удавшейся процедуры SR (например, первичный уровень, вторичный уровень и т.д.) и/или типе ресурса SR, используемого для не удавшейся процедуры SR (например, RA-SR, D-SR и т.д.). Например, когда WTRU определяет, что процедура D-SR не смола использовать ресурсы PUCCH соты вторичного уровня, WTRU может быть выполнен с возможностью инициирования процедуры RA-SR в соте вторичного уровня. Например, сота, используемая для RA-SR на вторичном уровне, может быть той же сотой, которая использовалась для не удавшейся процедуры D-SR, или может быть другой сотой вторичного уровня (например, WTRU может сначала проверить ту же соту, затем другую соту вторичного уровня). Если WTRU определяет, что RA-SR также дает сбой для вторичного уровня, WTRU может инициировать процедуру SR в P-соте первичного уровня. SR в P-соте первичного уровня может осуществляться согласно конфигурации SR для WTRU в P-соте. Например, если WTRU конфигурирован выделенными ресурсами PUCCH для отправки SR в P-соте, может осуществляться процедура D-SR. Если WTRU не конфигурирован выделенными ресурсами PUCCH для SR в P-соте, WTRU может инициировать процедуру RA-SR. Если процедуры SR в P-соте первичного уровня дают сбой, WTRU может попытаться переустановить RRC-соединение с P-сотой первичного уровня. В другом примере, если любая процедура SR (например, D-SR или RA-SR) дает сбой на вторичном уровне, WTRU может пытаться осуществить процедуру SR в P-соте первичного уровня (например, вместо того, чтобы попытаться сначала осуществить другой тип процедуры SR на вторичном уровне).

В одном примере, WTRU может быть выполнен с возможностью осуществления процедуры SR (например, процедуры RA-SR) на первичном уровне на основании данных, которые запустили SR, связанный с RB вторичного уровня. Например, процедуру RA-SR на первичном уровне можно использовать для SR для данных, связанных с RB на вторичном уровне. WTRU может указывать в процедуре RA-SR, что данные связаны с RB, отображаемым во вторичный уровень. В одном примере, WTRU может инициировать процедуру мобильности на основании сбоя SR на вторичном уровне. Например, если процедура SR дает сбой на вторичном уровне, WTRU может быть выполнен с возможностью осуществления процедуры пересвязывания (например, процедуры переконфигурирования RRC) для одного или более радиоканалов-носителей, которая перемещает RB, связанные с уровнем, на котором SR дал сбой, на другой уровень (например, первичный уровень). В одном примере, WTRU может определять, что RLF UL произошел на определенном уровне после сбоя RACH, с использованием ресурсов PRACH рассматриваемого уровня (например, для процедуры SR). Например, для сбоя SR, соответствующего вторичному уровню, WTRU может инициировать процедуру, связанную с мобильностью канала-носителя на другом уровне (например, первичном уровне).

WTRU может использовать разные процедуры для поддержания временного выравнивания разных уровней. Например, процедуры временного выравнивания (TA), используемые в определенной соте (например, P-соте), могут базироваться на том, с каким уровнем связана процедура TA. Например, WTRU может осуществлять различные действия в отношении временного выравнивания в первой соте первого уровня (например, P-соте первичного уровня) на основании обнаружения одного или более условий, связанных со второй сотой на втором уровне (например, сотой на вторичном уровне). Например, сбой SR на вторичном уровне может запускать одно или более действий, связанных с TA, на первичном уровне.

В порядке примера, WTRU может считать, что таймер временного выравнивания (TAT) (например, некоторые или все применимые TAT, например, если конфигурировано множество групп TA), связанный с определенным уровнем, истек, после обнаружения сбоя D-SR и/или сбоя RA-SR на этом уровне. Например, WTRU может считать, что TAT P-соты вторичного уровня истек, на основании определения, что процедура SR не смола использовать ресурс P-соты вторичного уровня.

В одном примере, истечение TAT (например, или триггер, который предписывает WTRU считать TAT истекшим) в первой соте первого уровня может запускать отправку расширенного SR/BSR в другой соте, связанной с другим уровнем. Например, если WTRU определяет, что TAT, связанный с одной или более сот (например, P-сотой) вторичного уровня, истек и/или должен был истечь (например, на основании сбоя SR), WTRU может отправлять BSR в соту первичного уровня (например, P-соту первичного уровня). Например, BSR, отправленный через первичный уровень, может включать в себя информацию в отношении любых данных для RB, связанных с вторичным уровнем, подлежащих передаче, помимо любых данных, связанных с RB первичного уровня, которые подлежат передаче.

В одном примере, истечение TAT (например, или триггер, который предписывает WTRU считать TAT истекшим) может запускать мобильность RB на другой уровень и/или подвешивание RB. Например, WTRU может пересвязывать один или более RB, связанных с уровнем, который включает в себя соту, для которой TAT истек (например, или должен был истечь) с другой сотой на другом уровне (например, с первичным уровнем). В одном примере, связывание RB может осуществляться, когда все TAT, применимые к вторичному уровню, истекли или должны были истечь. В таком случае, если TAT истек на первой соте вторичного уровня, но этот TAT второй соты еще не истек, WTRU может отказываться от осуществления мобильности RB на другой уровень пока TAT второй соты не истечет или не должен будет истечь. Если RB пересвязан с другим уровнем, после того, как один или более TAT стартуют или выполняются на вторичном уровне, WTRU может переконфигурировать RB, которые были перемещены для пересвязывания с вторичным уровнем. В одном примере, подвешивание RB может осуществляться WTRU, когда все TAT, применимые к вторичному уровню, истекли или должны были истечь. В таком случае, если TAT истек на первой соте вторичного уровня, но этот TAT второй соты еще не истек, WTRU может отказываться от подвешивания RB. Если WTRU не подвешивает RB на основании истечения всех TAT, связанных с определенным уровнем, после того, как WTRU определяет, что по меньшей мере один TAT, применимый к вторичному уровню, стартовал и/или выполняется в данный момент, WTRU может рассматривать рассматриваемые RB как активные.

В одном примере, истечение TAT (например, или триггер, который предписывает WTRU считать TAT истекшим) может запускать деактивацию экземпляра/уровня MAC, связанного с истекшим TAT. Например, если WTRU определяет, что TAT, связанный с одной или более сот (например, P-сотой) вторичного уровня, истек или должен был истечь, WTRU может деактивировать некоторые или все соты рассматриваемого экземпляра MAC. В одном примере, истечение TAT (например, или триггер, который предписывает WTRU считать TAT истекшим) может предписывать WTRU подвешивать один или более радиоканалов-носителей, зависящих от уровня. Например, если WTRU определяет, что TAT, связанный с одной или более сот (например, P-сотой) вторичного уровня, истек или должен был истечь, WTRU может подвешивать один или более радиоканалов-носителей, связанных с рассматриваемым уровнем. В одном примере, истечение TAT (например, или триггер, который предписывает WTRU считать TAT истекшим) может предписывать WTRU осуществлять процедуру мобильности, которая перемещает/пересвязывает один или более каналов-носителей, зависящие от уровня, с другим уровнем. Например, если WTRU определяет, что TAT, связанный с одной или более сот (например, P-сотой) вторичного уровня, истек или должен был истечь, WTRU может инициировать процедуру мобильности для переконфигурирования радиоканалов-носителей для пересвязывания с другим уровнем (например, первичным уровнем).

В одном примере, истечение TAT (например, или триггер, который предписывает WTRU считать TAT истекшим) может запускать переключатель активного экземпляра/уровня MAC. Например, если WTRU определяет, что TAT, связанный с одной или более сот (например, P-сотой) вторичного уровня, истек или должен был истечь, WTRU может инициировать процедуру для активации одной или более сот (например, P-соты) первичного экземпляра MAC, например, если первичный экземпляр MAC деактивирован.

Управление на основе уровня 1 (например, уровня PHY) и/или уровня 2 (например, MAC, RRC и т.д.) динамического управления радиоресурсами (RRM) может осуществляться для координации многоуровневого RRM. Например, управление и выделение ресурсов физического уровня для каждого уровня может быть сложным и может зависеть от типа архитектуры плоскости управления, которая используется (например, распределенной плоскости управления, скоординированной плоскости управления, централизованной плоскости управления и т.д.).

Например, WTRU может быть конфигурирован возможностью двойного соединения таким образом, что SRB заканчиваются на одном уровне (например, первичном уровне) и/или один или более уровней может не иметь SRB, заканчивающихся на обслуживающем участке для уровня. В таком случае, конфигурационная информация и другие данные управления для поддержки RRM может определяться для уровня (например, вторичного уровня/уровня SCeNB) одним или более из RCNC (например, который может располагаться на MeNB), обслуживающего участка другого уровня (например, MeNB) и/или обслуживающим участком рассматриваемого уровня (например, SCeNB). Конфигурационная информация может поступать на надлежащий узел сети, на котором заканчивается SRB, по одному или более интерфейсам между уровнями (например, X2bis). Например, WTRU может быть конфигурирован таким образом, что SRB оканчиваются на MeNB, но информация управления для SRB может поступать на другие обслуживающие участки (например, SCeNB).

Однако в некоторых сценариях задержка межуровневых передач/интерфейсов может составлять проблему для RRM. Например, RRM и/или переконфигурирование на вторичном уровне (например, связанном с SCeNB) может усложняться за счет того, что интерфейс между обслуживающим участком макроуровня, на котором может заканчиваться SRB (например, MeNB), и обслуживающим участком вторичного уровня (например, SCeNB) может быть связан с относительно высокой задержкой и/или может вносить сравнительно большую задержку. Уменьшение задержки для переконфигурирования экземпляра MAC и физическая конфигурация уровня, по-прежнему обеспечивая гибкость планировщика (например, применительно к выделению ресурсов), может быть связано с несколькими функциями планирования, например, одним или более из группирования интервалов времени передачи (TTI), выделения PUCCH для D-SR, выдачи отчета по CQI, обратной связи по смешанному автоматическому запрашиванию повторной передачи (HARQ) (например, включающей в себя формат HARQ), выделения ресурсов зондирующего опорного сигнала (SRS), конфигурирования опорных сигналов и т.д. Например, параметры, включенные в один или более IE, например, sps-Config, mac-MainConfig (например, включающий в себя ttiBundling, drx-Config и т.д.), physicalConfigDedicated (например, включающий в себя pucch-ConfigDedicated, cqi-ReportConfig, soundingRS-UL-ConfigDedicated, schedulingRequestConfig, cqi-ReportConfig-r10, csi-RS-Config-r10, soundingRS-UL-ConfigDedicatedAperiodic-r10, csi-RS-ConfigNZP и т.д.), могут быть чувствительными по времени, и задержки в сигнализации и/или конфигурировании таких параметров могут представлять проблему.

В порядке примера, синхронизации момента переконфигурирования (например, времени начала применения новой конфигурации) может быть трудно добиться в многоуровневой настройке, например, если внутрисетевая связь между обслуживающими участками связана с высокой задержкой, и плоскость управления (например, и/или конкретный SRB) заканчивается на одном из уровней. Например, если WTRU принимает сообщение переконфигурирования RRC, которое переконфигурирует один или более аспектов, связанных с возможностью соединения на вторичном уровне (например, связанных с SCeNB), хронирование и/или синхронизация между планировщиком на вторичном уровне и экземпляром MAC, связанным с вторичным уровнем на WTRU, может составлять проблему. Например, WTRU может быть выполнен с возможностью определения фиксированного момента времени, начиная с которого новая конфигурация предполагается действительной.

Вопрос хронирования и синхронизации также может вставать на стороне сети, например, когда сеть пытается перевыделить ресурсы с одного WTRU на другой, поскольку сети может сначала потребоваться определить возможное событие, после которого такие ресурсы могут быть доступны для выделения определенному WTRU. Например, сеть может пытаться определить, когда ресурсы могут быть доступны на определенном WTRU, с целью деактивации группирования TTI, освобождения ресурсов PUCCH для D-SR, выделения экземпляра выдачи отчета по CQI, приема обратной связи по HARQ (например, включающей в себя формат HARQ), определения, когда применять новую конфигурацию DRX, освобождения ресурсов SRS, изменения опорных сигналов и/или т.п. Например, сеть может пытаться определить, когда WTRU может и/или начнет применять один или более параметров, включенных в IE, например, sps-Config, mac-MainConfig (например, включающих в себя ttiBundling, drx-Config и т.д.), physicalConfigDedicated (например, включающего в себя pucch-ConfigDedicated, cqi-ReportConfig, soundingRS-UL-ConfigDedicated, schedulingRequestConfig, cqi-ReportConfig-r10, csi-RS-Config-r10, soundingRS-UL-ConfigDedicatedAperiodic-r10, csi-RS-ConfigNZP и т.д.). Хронированием активации и деактивации ресурсов частично устойчивого планирования (SPS) можно управлять с использованием сигнализации управления уровня PHY (например, активировать и деактивировать посредством команд PDCCH).

Например, WTRU и один или более обслуживающих участков могут быть выполнены с возможностью установления одной или более предварительных конфигураций для набора параметров, могут назначать индекс каждому заранее конфигурированному набору параметров и могут использовать явную сигнализацию управления и/или неявные правила для переключения активной конфигурации (например, для активации и/или деактивации определенного набора параметров). Например, WTRU и/или обслуживающие участки разных уровней могут использовать локальное, гибкое и/или динамическое управление ресурсами физического уровня для определенного уровня и/или планировщика (например, для SCeNB) без необходимости вводить и/или использовать компонент RRC с окончанием SRB на уровне, для которого установлена конфигурация (например, вторичном уровне с обслуживающим участком SCeNB).

Например, вместо или помимо опоры на сигнализацию RRC для конфигурирования статических параметров для RRM (например, которые можно использовать для уровней, в которых один или более SRB заканчиваются на компоненте RRC на обслуживающем участке), что позволяет планировщику для определенного уровня (например, на SCeNB) заранее конфигурировать различные конфигурации RRM (например, посредством сигнализации RRC и т.п.) и сигнализировать, какое заранее конфигурированное выделение использовать (например, посредством сигнализации PHY или MAC; на основании неявных правил, на основании событий запуска и т.д.).

Различные методы могут использоваться для конфигурирования множества наборов параметров RRM. Используемый здесь термин «параметры RRM» может означать один или более из параметров, относящихся к группированию TTI, выделению PUCCH для D-SR, DRX, SR, выдаче отчета по CQI, обратной связи по HARQ (например, включающей в себя формат HARQ), выделению ресурсов SRS, конфигурированию опорных сигналов, других параметров уровня PHY и/или т.п. Например, параметры RRM могут включать в себя один или более элементов информации, которые могут быть включены в IE, например, sps-Config, mac-MainConfig (например, включающие в себя ttiBundling, drx-Config и т.д.), physicalConfigDedicated (например, включающий в себя pucch-ConfigDedicated, cqi-ReportConfig, soundingRS-UL-ConfigDedicated, schedulingRequestConfig, cqi-ReportConfig-r10, csi-RS-Config-r10, soundingRS-UL-ConfigDedicatedAperiodic-r10, csi-RS-ConfigNZP и т.д.). Дополнительно, различные поднаборы/конфигурации параметров RRM могут обрабатываться и/или манипулироваться независимо/отдельно. Например, наборы параметры SPS могут быть заранее конфигурированы отдельно от наборов параметров физического уровня конфигурации. Аналогично, наборы параметров DRX могут манипулироваться отдельно от наборов параметров выдачи отчета по CQI. Параметры, связанные с одной или более разными функциями управления, могут группироваться в группы предварительной конфигурации (например, параметры DRX, сгруппированные с параметрами TTI, параметры выдачи отчета по CQI могут группироваться с параметрами конфигурации D-SR и т.д.). Используемый здесь термин «параметры RRM» может использоваться для обозначения одного или более вышеописанных (или аналогичных) параметров, либо по отдельности, либо в различных комбинациях. Термин «конфигурация RRM» может означать группу из одного или более параметров RRM, которые могут группироваться для предварительной конфигурации и/или могут совместно активироваться.

Например, WTRU может принимать сигнализацию RRC (например, сообщение переконфигурирования RRC-соединения), которая конфигурирует один или более наборов параметров RRM. WTRU может принимать конфигурацию с одним или более индексированным набором параметров. Например, WTRU могут быть заранее конфигурированы одним или более наборов параметров физического уровня конфигурации (например, physicalConfigDedicated) и/или одним или более наборов параметров конфигурации MAC (например, mac-MainConfig). Например, каждая конфигурация могут группироваться как отдельный элемент (например, defaultConfig, и нуль или более alternativeConfig). В примере каждая принятая конфигурация может быть связана со значением индекса, которое можно назначать при приеме конфигурации и/или может быть определена неявно. Например, каждое значение конфигурации может обеспечиваться в порядке возрастания номера индекса (например, первая конфигурация в сообщении имеет индекс 0, вторая конфигурация имеет индекс 1 и т.д.). Одна или более из конфигураций может быть конфигурацией, принятой по умолчанию. Например, принятое сообщение переконфигурирования может явно указывать, какой принятый набор параметров (например, конфигурация) считается конфигурацией, принятой по умолчанию, и/или первой конфигурацией и/или конфигурацию с назначенным индексом 0 и/или первую конфигурацию, которая применяется в соте, можно рассматривать как конфигурацию, принятую по умолчанию. Принятые конфигурации RRM могут быть специфичны для определенной соты или могут быть общими для множества сот. Принятые конфигурации RRM могут быть специфичны для определенного уровня или могут быть общими для множества уровней. После приема множества наборов параметров (например, множества наборов конфигураций RRM), WTRU может завершать переконфигурирование путем применения параметров, соответствующих набору, принятому по умолчанию.

В порядке примера, WTRU может принимать конфигурацию с наборами параметров, сгруппированными как одна или более виртуальных сот. Например, WTRU может принимать один или более наборов параметров RRM, например один или более наборов конфигураций физического уровня. Конфигурация может приниматься таким образом, что конфигурация соответствует виртуальной соте. Виртуальная сота может быть связана с конфигурацией, аналогичной традиционной соте, хотя конфигурация может активироваться и/или деактивироваться динамически. Например, WTRU может принимать множество конфигураций виртуальной соты (например, множество наборов параметров RRM, в котором каждый набор соответствует отдельной виртуальной соте) для определенного sCellIndex, определенного physCellId, определенного dl-CarrierFreq и/или т.п. Принятые конфигурации виртуальной соты могут соответствовать множеству потенциальных конфигураций, которые можно применять в определенной соте. В одном примере, каждой конфигурации виртуальной соты и/или каждому набору параметров RRM можно назначать virtualCellId в целях идентификации. Идентификатор (например, virtualCellId) может явно сигнализироваться и/или может определяться неявно. Например, каждая конфигурация виртуальной соты может обеспечиваться в порядке возрастания идентификационного номера (например, первая конфигурация в сообщении имеет virtualCellId 0, вторая конфигурация имеет virtualCellId 1 и т.д.). Одна или более из конфигураций виртуальной соты может быть конфигурацией, принятой по умолчанию. Например, принятое сообщение переконфигурирования может явно указывать какая принятая конфигурация виртуальной соты считается конфигурацией, принятой по умолчанию и/или первой конфигурацией и/или конфигурацией с назначенным virtualCellId 0, и/или первую конфигурацию виртуальной соты, которая применяется в соте, можно рассматривать как конфигурацию, принятую по умолчанию. Конфигурации виртуальной соты могут быть специфичны для определенной соты или могут быть общими для множества сот. Конфигурации виртуальной соты могут быть специфичны для определенного уровня или могут быть общими для множества уровней. После приема конфигураций виртуальной соты, WTRU может завершать переконфигурирование путем применения параметров, соответствующих конфигурации, принятой по умолчанию, виртуальной соты.

Сигнализация управления может использоваться для активации конфигурации RRM и/или конфигурации виртуальной соты, деактивации конфигурации RRM и/или конфигурации виртуальной соты, изменения конфигурации RRM и/или конфигурации виртуальной соты, удаления конфигурации RRM и/или конфигурации виртуальной соты и/или т.п. Например, сигнализация управления может применяться к одной или более сотам в уровне (например, возможно, группам или поднаборам сот в уровне), к конкретному типу соты в уровне (например, P-соте, S-соте(ам), и т.д.), к группе временного выравнивания (TAG) и т.д.

например, сигнализация физического уровня может использоваться для активации конфигурации RRM и/или конфигурации виртуальной соты, деактивации конфигурации RRM и/или конфигурации виртуальной соты, изменения конфигурации RRM и/или конфигурации виртуальной соты, удаления конфигурации RRM и/или конфигурации виртуальной соты и/или т.п. В порядке примера, сигнализация физического уровня, используемая для активации уровня, активации P-соты, активации S-соты и т.д., также может включать в себя указание надлежащей конфигурации RRM и/или конфигурации виртуальной соты, которую следует применять. В одном примере, отдельная сигнализация физического уровня может использоваться для указания, какую конфигурацию RRM и/или конфигурацию виртуальной соты следует применять в соте, на уровне, который включает в себя соту, в другой соте на уровне, который включает в себя соту, на другом уровне, в другой соте другого уровня, в TAG и/или т.п.

Например, будучи конфигурированным множеством конфигураций RRM и/или множеством конфигураций виртуальной соты для определенной соты, определенной группы сот, определенного уровня и т.д., WTRU может принимать сигнализацию управления, например, на PDCCH и/или расширенном PDCCH (ePDCCH), которая активирует определенную конфигурацию RRM и/или конфигурацию виртуальной соты. Например, WTRU может принимать индекс и/или virtualCellId, соответствующий определенной конфигурации RRM и/или конфигурации виртуальной соты в поле информации управления нисходящей линии связи (DCI) и/или посредством другой сигнализации физического уровня.

Например, WTRU может принимать DCI, который активирует конфигурацию RRM и/или конфигурацию виртуальной соты для одной или более сот, и WTRU может определять, какую конфигурацию RRM и/или конфигурацию виртуальной соты применять, на основании одного или более из явного индекса и/или идентификатора виртуальной соты, указанного в DCI, идентификатора пространства поиска, в котором DCI был успешно декодирован (например, каждое пространства поиска и/или участок пространства поиска может неявно отображаться в определенный индекс и/или виртуальную соту), временного идентификатора радиосети (RNTI), используемого для декодирования DCI (например, каждой конфигурации RRM и/или конфигурации виртуальной соты можно назначать RNTI и/или неявное отображение можно предполагать на основании того, какой RNTI используется), идентификатора первого (или последнего или какого-либо другого CCE в диапазоне, используемом для декодирования DCI) элемента канала управления (CCE), связанного с DCI (например, CCE могут неявно отображаться в конфигурации RRM и/или конфигурации виртуальной соты), и/или т.п.

Сигнализация физического уровня может указывать активацию и/или деактивацию конфигурации RRM и/или конфигурации виртуальной соты, например, путем включения соответствующего индекса и/или идентификатора виртуальной соты в формате сигнализации. Если WTRU работает с использованием нестандартной конфигурации RRM и/или конфигурации виртуальной соты, нестандартная конфигурация RRM и/или конфигурация виртуальной соты деактивируется и/или удаляется, WTRU может неявно определять использование принятой по умолчанию конфигурации RRM и/или конфигурации виртуальной соты для рассматриваемого уровня (например, конфигурации с индексом/virtualCellId 0), если явно не указана другая конфигурация RRM и/или конфигурация виртуальной соты.

WTRU может отправлять обратную связь для подтверждения переконфигурирования. Например, WTRU может передавать обратную связь для указания успешного завершения переконфигурирования и/или успешного приема сигнализации физического уровня. Например, WTRU может передавать ACK/NACK HARQ для принятой сигнализации физического уровня, используемой для активации и/или деактивации конфигурации RRM и/или конфигурации виртуальной соты. Например, положительная обратная связь (например, ACK) может указывать успешный прием сигнализации физического уровня, которая изменила конфигурацию RRM и/или конфигурацию виртуальной соты. Например, обратная связь ACK/NACK HARQ может передаваться спустя фиксированное время после успешного приема сигнализации управления. Обратная связь ACK/NACK может передаваться с использованием конфигурации RRM и/или конфигурации виртуальной соты, которая ранее была применена во время приема сигнализации физического уровня, которая изменила конфигурацию RRM и/или конфигурацию виртуальной соты (например, в подкадре n) сигнализации управления, которая изменила конфигурацию. Например, если сигнализация управления физического уровня была принята в подкадре n, обратная связь может передаваться в подкадре n+4.

В одном примере, обратная связь для ACK/NACK HARQ для принятой сигнализации физического уровня, используемой для активации и/или деактивации конфигурации RRM и/или конфигурации виртуальной соты может передаваться с использованием конфигурации RRM и/или конфигурации виртуальной соты, указанной в сигнализации управления физического уровня. Например, обратная связь ACK/NACK может передаваться с использованием новой конфигурации RRM и/или конфигурации виртуальной соты в подкадре n+(reconfigurationDelay). reconfigurationDelay может быть конфигурируемым аспектом (который, например, может быть указан в сигнализации активации физического уровня и/или может быть заранее конфигурирован набором конфигурации RRM/виртуальной соты) или может быть эквивалентен некоторой фиксированной задержке обработки (например, 15 мс). В одном примере, сигнализация физического уровня, используемая для активации и/или деактивации конфигурации RRM и/или конфигурации виртуальной соты может указывать конкретный ресурс для передачи обратной связи ACK/NACK. В одном примере, WTRU может передавать первую обратную связь, указывающую, успешно ли принята сигнализация физического уровня, используемая для активации и/или деактивации конфигурации RRM и/или конфигурации виртуальной соты (например, с использованием описанного здесь способа), и вторую обратную связь для указания успешного завершения переконфигурирования, как указано сигнализацией управления (например, с использованием описанного здесь способа). В одном примере, подтверждение успешного переконфигурирования в новую конфигурацию RRM и/или конфигурацию виртуальной соты может осуществляться путем передачи преамбулы произвольного доступа. Например, после того, как WTRU успешно применяет новую конфигурацию RRM и/или конфигурацию виртуальной соты, WTRU может инициировать процедуру RACH. msg3 может включать в себя CE MAC, который указывает активированную конфигурацию RRM и/или конфигурацию виртуальной соты.

Сигнализация уровня 2, например сигнализация MAC, может использоваться для активации конфигурации RRM и/или конфигурации виртуальной соты, деактивации конфигурации RRM и/или конфигурации виртуальной соты, изменения конфигурации RRM и/или конфигурации виртуальной соты, удаления конфигурации RRM и/или конфигурации виртуальной соты и/или т.п. Например, сигнализация MAC, используемая для активации уровня, активации P-соты, активации S-соты и т.д., также может включать в себя указание надлежащей конфигурации RRM и/или конфигурации виртуальной соты, которую следует применять.

Например, WTRU может принимать элемент управления MAC (CE), который активирует определенную конфигурацию RRM и/или конфигурацию виртуальной соты. Например, WTRU может принимать индекс и/или virtualCellId, соответствующий определенной конфигурации RRM и/или конфигурации виртуальной соты в поле CE MAC. В одном примере, CE MAC, используемый для активации определенной конфигурации RRM и/или конфигурации виртуальной соты, может включать в себя битовую карту, и каждый бит битовой карты может соответствовать определенной конфигурации RRM и/или конфигурации виртуальной соты. Например, первый бит битовой карты может соответствовать индексу/идентификатору виртуальной соты 0, второй бит битовой карты может соответствовать индексу/идентификатору виртуальной соты 1, и т.д. 1 может указывать, что соответствующая конфигурация RRM и/или конфигурация виртуальной соты активирована, и 0 может указывать, что соответствующая конфигурация RRM и/или конфигурация виртуальной соты деактивирована (или наоборот).

В одном примере, WTRU может принимать CE активации/деактивации MAC, который активирует и/или деактивирует уровень, активирует и/или деактивирует соту на уровне, активирует и/или деактивирует группу сот на уровне, и т.д. CE активации/деактивации MAC может включать в себя явный индекс и/или virtualCellId, соответствующий определенной конфигурации RRM и/или конфигурации виртуальной соты для активированной соты, группы сот и/или уровня. Также можно использовать описанную здесь битовую карту.

В одном примере, WTRU может принимать CE RRMConfig MAC для конкретной соты, группы сот и/или уровня. CE RRMConfig MAC может включать в себя явный индекс и/или virtualCellId, соответствующий определенной конфигурации RRM и/или конфигурации виртуальной соты для конфигурированной соты, группы сот и/или уровня. Также можно использовать описанную здесь битовую карту.

Независимо от используемого способа сигнализации, если WTRU работает с использованием нестандартной конфигурации RRM и/или конфигурации виртуальной соты, нестандартная конфигурация RRM и/или конфигурация виртуальной соты деактивируется и/или удаляется (например, посредством сигнализации MAC), WTRU может неявно определять использование принятой по умолчанию конфигурации RRM и/или конфигурации виртуальной соты для рассматриваемой соты/группы сот/уровня (например, конфигурации с индексом/virtualCellId 0), если явно не указана другая конфигурация RRM и/или конфигурация виртуальной соты.

WTRU может отправлять обратную связь для подтверждения переконфигурирования, принятого посредством сигнализации MAC. Например, WTRU может передавать обратную связь для указания успешного завершения переконфигурирования и/или успешного приема CE MAC. В порядке примера, обратная связь может быть включена в CE MAC и/или PUCCH (например, спустя фиксированное время после передачи ACK HARQ для транспортного блока, в котором был принят сигнализация L2/MAC). В одном примере, подтверждение успешного переконфигурирования в новую конфигурацию RRM и/или конфигурацию виртуальной соты может осуществляться путем передачи преамбулы произвольного доступа. Например, после того, как WTRU успешно применяет новую конфигурацию RRM и/или конфигурацию виртуальной соты, WTRU может инициировать процедуру RACH. msg3 может включать в себя CE MAC, который указывает активированную конфигурацию RRM и/или конфигурацию виртуальной соты.

Неявные правила могут использоваться для активации конфигурации RRM и/или конфигурации виртуальной соты, деактивации конфигурации RRM и/или конфигурации виртуальной соты, изменения конфигурации RRM и/или конфигурации виртуальной соты, удаления конфигурации RRM и/или конфигурации виртуальной соты и/или т.п. Например, будучи заранее конфигурирован множеством конфигураций RRM и/или конфигураций виртуальной соты для определенной соты, группы сот, уровня и т.д., WTRU может определять события или триггер, который может активировать и/или деактивировать конфигурацию RRM и/или конфигурацию виртуальной соты.

Например, WTRU может принимать сигнализацию управления (например, CE активации/деактивации MAC), которая активирует соту, группу сот, уровень и т.д., заранее конфигурированную для использования WTRU. WTRU может неявно определять, что принятая по умолчанию конфигурация RRM и/или конфигурация виртуальной соты для рассматриваемой соты, группы сот, уровня и т.д. следует, напротив, применять отсутствующую явную сигнализацию.

WTRU может быть выполнен с возможностью поддерживать таймер действительности для активной конфигурации RRM и/или конфигурации виртуальной соты (например, для нестандартной конфигурации RRM и/или конфигурации виртуальной соты). Например, WTRU может запускать таймер действительности для определенной конфигурации RRM и/или конфигурации виртуальной соты после приема активации конфигурации RRM и/или конфигурации виртуальной соты и/или после приема явной сигнализации управления, которая активирует конфигурацию RRM и/или конфигурацию виртуальной соты. WTRU может деактивировать конфигурацию RRM и/или конфигурацию виртуальной соты для определенной соты, группы сот, уровня и т.д. по истечении таймера действительности такой конфигурации RRM и/или конфигурации виртуальной соты. В одном примере, может не существовать таймера действительности для конфигурации, принятой по умолчанию. Таймер действительности может перезапускаться после приема сигнализации, которая повторно активирует конфигурацию RRM и/или конфигурацию виртуальной соты.

В одном примере, истечение TAT для соты, группы сот, уровня и т.д. может деактивировать и/или удалять конфигурацию RRM и/или конфигурацию виртуальной соты. Например, WTRU может быть выполнен с возможностью деактивации конфигурации RRM и/или конфигурации виртуальной соты для определенной соты, группы сот, уровня и т.д. по истечении применимого TAT. В одном примере, истечение TAT может предписывать WTRU деактивировать нестандартную конфигурацию RRM и/или конфигурацию виртуальной соты, но не принятую по умолчанию конфигурацию RRM и/или конфигурацию виртуальной соты.

WTRU может деактивировать конфигурацию RRM и/или конфигурацию виртуальной соты для определенной соты, группы сот, уровня и т.д. После обнаружения условий сбоя линии радиосвязи для рассматриваемой соты, группы сот, уровня и т.д. В одном примере, обнаружение сбоя линии радиосвязи может предписывать WTRU деактивировать нестандартную конфигурацию RRM и/или конфигурацию виртуальной соты, но не принятую по умолчанию конфигурацию RRM и/или конфигурацию виртуальной соты.

WTRU может деактивировать конфигурацию RRM и/или конфигурацию виртуальной соты для определенной соты, группы сот, уровня и т.д. после определения, что рассматриваемая сота, группа сот, уровень и т.д. действует в режиме DRX (например, долгом DRX) и что истекло z периодов DRX, где x может быть аспектом конфигурации. В одном примере, определение, что рассматриваемая сота, группа сот, уровень, и т.д. действует в режиме DRX (например, долгий DRX) и что истекло z периодов DRX, может предписывать WTRU деактивировать нестандартную конфигурацию RRM и/или конфигурацию виртуальной соты, но не принятую по умолчанию конфигурацию RRM и/или конфигурацию виртуальной соты.

WTRU может деактивировать конфигурацию RRM и/или конфигурацию виртуальной соты для определенной соты, группы сот, уровня и т.д. после деактивации (например, неявной и/или явной) рассматриваемой соты, группы сот, уровня и т.д. (например, когда он деактивирует соту или рассматриваемый уровень). В одном примере, деактивация рассматриваемой соты, группы сот, уровня и т.д. может предписывать WTRU деактивировать нестандартную конфигурацию RRM и/или конфигурацию виртуальной соты, но не принятую по умолчанию конфигурацию RRM и/или конфигурацию виртуальной соты.

WTRU может возвращаться к принятой по умолчанию конфигурации RRM и/или конфигурации виртуальной соты после неявной и/или явной деактивации нестандартной конфигурации RRM и/или конфигурации виртуальной соты (например, если явно не указана какая-либо другая конфигурация RRM и/или конфигурация виртуальной соты). UE может использовать сигнализацию управления (например, сообщение RRC, CE MAC, который указывает активную конфигурацию), которая указывает, что WTRU недостает действительной конфигурации и/или которая указывает, что в данный момент используется другая конфигурация (например, конфигурация, принятая по умолчанию).

Может задаваться хронирование завершения переконфигурирования в другую конфигурацию RRM и/или конфигурацию виртуальной соты. Например, WTRU может пытаться завершить переконфигурирование в x подкадрах. Значение x может быть фиксированным (например, время обработки 15 мс) и/или значение x может быть конфигурировано как часть конфигурации RRM и/или конфигурации виртуальной соты. В одном примере, задержка может определяться, начиная с подкадра n, в котором принимается применимая сигнализация управления, которая активирует конфигурацию RRM и/или конфигурацию виртуальной соты (например, сигнализацию L1/L2). В одном примере, задержка может определяться, начиная с времени, когда передается обратная связь для применимой сигнализации управления (например, сигнализация L1/L2). В одном примере, задержка может определяться, начиная с времени, когда передается подтверждение успешного переконфигурирования.

Возможно в течение периода [n, n+x], WTRU может не принимать PDCCH и/или ePDCCH. В одном примере, WTRU может начинать использовать новую конфигурацию RRM и/или конфигурацию виртуальной соты, как только получает возможность переконфигурировать свой приемопередатчик, и может начинать принимать PDCCH и/или ePDCCH и/или может осуществлять передачу по восходящей линии связи с использованием конфигурации, применимой на момент приема рассматриваемой сигнализации управления. В одном примере, WTRU может быть позволено начинать использовать новую конфигурацию RRM и/или конфигурацию виртуальной соты после передачи квитирования приема сигнализации управления (например, подкадра n+4).

В одном примере, один или более из описанных здесь способов можно объединить, чтобы планировщик мог гибко управлять RRM на узле без окончания SRB. Например, WTRU может принимать сообщение переконфигурирования RRC-соединения. Сообщение переконфигурирования RRC-соединения может быть связано с/передаваться через SRB, который заканчивается на объекте RRC на MeNB. Сообщение переконфигурирования RRC-соединения может добавлять, изменять, удалять и т.д. одну или более сот, связанных с вторичным уровнем (например, обслуживающий участок для вторичного уровня может быть SCeNB). Сообщение переконфигурирования может включать в себя множество конфигураций RRM и/или конфигураций виртуальной соты для одной или более добавляемых и/или изменяемых сот (например, и, возможно, для удаленных сот) на вторичном уровне. Различные конфигурации RRM и/или конфигурации виртуальной соты можно индексировать и/или один или более параметров RRM в конфигурациях RRM и/или конфигурациях виртуальной соты можно индексировать. Одну из конфигураций RRM и/или конфигураций виртуальной соты можно рассматривать как конфигурацию, принятую по умолчанию, и/или один или более параметров RRM в конфигурациях RRM и/или конфигурациях виртуальной соты можно рассматривать значение параметра, принятое по умолчанию. Первоначально конфигурированную конфигурацию RRM и/или конфигурацию виртуальной соты можно рассматривать как конфигурацию, принятую по умолчанию и/или первоначально конфигурированные параметры RRM можно рассматривать как параметры, принятые по умолчанию. Принятую по умолчанию конфигурацию RRM и/или конфигурацию виртуальной соты и/или параметры RRM, принятые по умолчанию, можно явно указывать, например, связывая их с индексом 0 и/или указывая их в списке первыми. Группирование аспектов конфигурации с использованием виртуальной соты. Например, для определенной несущей частоты можно задавать множество конфигураций обслуживающей соты.

WTRU может принимать сигнализацию уровня 1 (например, PHY) и/или уровня 2 (например, MAC) (например, DCI на PDCCH, CE MAC и т.д.), которая может указывать индекс для одной или более конфигураций RRM и/или конфигураций виртуальной соты для применения и/или одного или более параметров RRM для применения. WTRU может квитировать прием в подкадре n такой сигнализации управления (например, возможно, включающей в себя указание индекса конфигурации в обратной связи) путем передачи ACK HARQ на PUCCH согласно текущей конфигурации RRM и/или конфигурации виртуальной соты (например, в подкадре n+4). Прием такой сигнализации управления на WTRU (например, с индексом конфигурации) может активировать соответствующую конфигурацию RRM и/или конфигурацию виртуальной соты (например, и/или ее параметры RRM). WTRU может возобновлять декодирование PDCCH и/или ePDCCH по истечении определенного времени (например, фиксированного и/или сигнализируемого) после приема рассматриваемой сигнализации (например, в подкадре n+4, подкадре n+15 и т.д.). В одном примере, активация/деактивация виртуальной соты может использоваться в качестве способа группирования.

С точки зрения сети, SCeNB может сообщать MeNB несколько значений конфигурации для одной или более конфигураций RRM и/или конфигураций виртуальной соты. SCeNB может указывать способ индексирования, подлежащий использованию. Например, такая конфигурация могут пересылаться по интерфейсу между SCeNB и MeNB (например, модифицированному X2, например X2bis). SCeNB может подготавливать сообщение переконфигурирования RRC-соединения с конфигурацией(ями) RRM и/или конфигурацией(ями) виртуальной соты и отправлять сообщение переконфигурирования RRC-соединения на MeNB для пересылки на WTRU. Затем планировщик в экземпляре MAC, связанном с для вторичного уровня может использовать сигнализацию L1 и/или сигнализацию L2 для динамического переключения между значениями конфигурации для одного или более аспектов RRM.

Когда WTRU выполнен с возможностью работать с использованием множества уровней или обслуживающих участков, которые связаны с разными планировщиками, радиоканал-носитель может быть связан исключительно с одним экземпляром MAC и/или множеством экземпляров MAC. Одна или более обслуживающих сот, связанных с определенным уровнем/экземпляром MAC могут давать сбой, например, вследствие плохих условий линии радиосвязи, сбоя переконфигурирования, сбоя мобильности, сбоя линии радиосвязи, и/или по другим причинам. Кроме того, WTRU, конфигурированным одной или более обслуживающими сотами, связанными с определенным уровнем/экземпляром MAC, можно манипулировать по отдельному набору обслуживающих сот, который может быть связан с отдельным сетевым объектом (например, логическим объектом, например, сотой или физическим объектом, например eNB). Описаны способы компенсации потерь на линии радиосвязи на одном или более обслуживающих участков/экземплярах MAC и/или решения мобильности в зависимости от конкретного обслуживающего участка (например, применяемые к набору обслуживающих сот, связанных с конкретным уровнем/экземпляром MAC). Раскрыты способы и системы эффективного управления экземплярами MAC, чтобы гарантировать непрерывность обслуживания в ходе событий мобильности. Например, описаны способы и системы для осуществления событий мобильности, когда один или более радиоканалов-носителей (например, SRB и/или DRB) связаны с уровнем/MAC, для которого осуществляется событие мобильности.

В порядке примера, WTRU может устанавливать соединение с первым eNB. Например, первым eNB может быть MeNB. Соединение с первым eNB можно рассматривать как первичный уровень, и/или первый eNB можно рассматривать как первый обслуживающий участок и/или первичный обслуживающий участок. Как часть обмен возможностями WTRU в ходе начальной процедуры RRC-соединения с первым обслуживающим участком, WTRU может обеспечивать первый набор возможностей WTRU, например, для установления соединения с первым обслуживающим участком согласно процедурам возможности соединения, выпуск 11. Дополнительно, как часть начальной процедуры соединения с первым участком, WTRU может обеспечивать второй набор возможностей WTRU, и второй набор возможностей WTRU может быть связан с информацией возможности соединения, поддерживаемой WTRU для установления возможности соединения со вторым уровнем или обслуживающим участком. Затем MeNB и другой eNB (например, SCeNB) могут координироваться для конфигурирования WTRU для осуществления доступа к множеству обслуживающих участков согласно соответствующим возможностям, например с использованием множества экземпляров MAC.

В одном примере, при установлении соединения с первым eNB (например, MeNB, связанный с первичным уровнем/первым обслуживающим участком) WTRU может включать в себя указание, поддерживает ли WTRU возможность двойного соединения, например, как часть информации возможностей WTRU. Если WTRU указывает, что возможность двойного соединения поддерживается, WTRU может включать в себя соответствующие возможности WTRU для осуществления доступа к вторичному обслуживающему участку при установлении соединения с первым обслуживающим участком. После успешного соединения с первым обслуживающим участком, WTRU может, например, при первоначальном установлении возможности соединения с SCeNB, передавать второй набор возможностей WTRU на SCeNB. Затем MeNB и SCeNB могут конфигурировать соединение для WTRU для каждого из обслуживающих участков с использованием их соответствующих параметров согласно информации возможностей, которую обеспечивает WTRU.

После установления соединения с первичным обслуживающим участком (например, RRC-соединение) например, с использованием процедур выпуска 11, начальная конфигурация вторичного уровня может осуществляться по-разному. Например, WTRU, который соединен с первым eNB (например, MeNB, первичным уровнем, первым обслуживающим участком, соединением через первый экземпляр MAC и т.д.), может быть выполнен с возможностью работы с одной или более сот от второго eNB (например, SCeNB, вторичного уровня, второго обслуживающего участка, соединения через второй экземпляр MAC и т.д.). Например, WTRU может принимать сигнализацию плоскости управления (например, сигнализацию RRC), таким образом, что второй набор сот может быть выполнен с возможностью формирования вторичного уровня для конфигурации WTRU. Конфигурация вторичного уровня может осуществляться с использованием сигнализации RRC, принятой с использованием выделенных ресурсов и/или специализированных сообщений RRC.

В порядке примера, начальная конфигурация соединения вторичного обслуживающего участка может осуществляться с использованием процедуры переконфигурирования. WTRU может осуществлять процедуру переконфигурирования с первичным уровнем, и процедура переконфигурирования может использоваться для установления возможности соединения с вторичным обслуживающим участком. Таким образом, сигнализация от первичного обслуживающего участка может использоваться для конфигурирования WTRU для работы с использованием вторичного уровня. Сигнализация, конфигурирующая вторичный уровень, может приниматься через ресурсы первичного уровня, например, если RRC-соединение, связанное с первичным уровнем, используется для конфигурирования вторичного уровня. Может использоваться процедура переконфигурирования RRC-соединения. Например, WTRU может осуществлять процедуру переконфигурирования RRC-соединения с первичным обслуживающим участком, которая конфигурирует WTRU для работы с использованием вторичного обслуживающего участка.

Начальная конфигурация вторичной обслуживающей соты может быть типом события мобильности. Например, после установления RRC-соединения с первичным обслуживающим участком, ресурсы, связанные с первичным обслуживающим участком, могут использоваться для осуществления процедуры мобильности. В ходе процедуры мобильности WTRU может поддерживать свою конфигурацию, возможность соединения и/или операционный статус с первичным обслуживающим участком, но может добавлять одну или более обслуживающих сот вторичного уровня к своей конфигурации. Например, процедура переконфигурирования RRC-соединения может осуществляться, когда информационный элемент управления мобильностью передается на WTRU (например, команда передачи обслуживания может отправляться на WTRU). Вместо того чтобы интерпретировать команду передачи обслуживания в том смысле, что WTRU должен осуществлять передачу обслуживания от соты первичного обслуживающего участка к какой-либо другой соте, команда передачи обслуживания может конфигурировать одну или более сот вторичного обслуживающего участка, подлежащих использованию помимо сот первичного обслуживающего участка. Команда передачи обслуживания может включать в себя указание, что команда передачи обслуживания призвана устанавливать возможность двойного соединения вместо запуска передачи обслуживания WTRU от соты первичного обслуживающего участка. Сигнализация, связанная с мобильностью, принятая посредством ресурсов первичного уровня, может конфигурировать первичную соту (P-соту) на вторичном уровне на целевом eNB (например, SCeNB). После установления соединения с P-сотой вторичного уровня, WTRU может принимать сообщение переконфигурирования RRC-соединения от целевого eNB (например, SCeNB), которое добавляет дополнительные обслуживающие соты, например, S-соты, связанные с вторичным обслуживающим участком.

Начальная конфигурация вторичного уровня/обслуживающего участка (например, переконфигурирование первичного обслуживающего участка и/или событие мобильности на первичном обслуживающем участке) может включать в себя переназначение радиоканала-носителя. Например, при осуществлении процедуры переконфигурирования соединения и/или процедуры мобильности с первичным обслуживающим участком для установления возможности соединения с вторичным обслуживающим участком, один или более существующих радиоканалов-носителей (например, радиоканалов-носителей, ранее связанных с передачей первичного обслуживающего участка) могут перемещаться на вторичный уровень/обслуживающий участок. Радиоканалы-носители могут перемещаться исключительно на вторичный обслуживающий участок и/или могут перемещаться, таким образом, чтобы быть связанными как с первичным обслуживающим участком, так и с вторичным обслуживающим участком.

Добавление вторичного уровня может осуществляться после активации безопасности для первичного уровня. Например, для добавления P-соты вторичного обслуживающего участка, WTRU может ждать, пока не будет активирован контекст безопасности, связанный с соединением WTRU с первичным обслуживающим участком. Например, конфигурация вторичного обслуживающего участка может осуществляться после активации безопасности слоя доступа (AS) и/или после установления SRB2 с по меньшей мере одним DRB (например, и не подвешенным) для соединения, связанного с первым eNB (например, первичным уровнем).

В одном примере, общий контекст безопасности может использоваться по множеству обслуживающих участков, и идентификаторы каналов-носителей могут быть зависящими от WTRU. Если вторичный уровень реализует контекст безопасности, который является общим с контекстом безопасности первичного уровня или какого-либо другого активного обслуживающего участка (например, для одной или более из плоскости управления и/или плоскости пользователя), конфигурация вторичного уровня может осуществляться с использованием общего пространства идентификаторов для идентификации каналов-носителей (например, srb-Identity и/или drb-Identity). Например, если один или более обслуживающих участков используют одну и ту же идентификацию каналов-носителей, схема передачи может устанавливаться таким образом, что ни один из используемых идентификаторов каналов-носителей, не используется на множестве уровней/обслуживающих участков с разными объектами PDCP. Это позволяет WTRU избегать сценария, в котором разные PDU PDCP передаются с использованием одних и тех же ключей безопасности и одного и того же порядкового номера (например, такой сценарий может создавать трудности в обработке/идентификации на уровне PDCP на WTRU).

В одном примере, отдельные контексты безопасности могут использоваться для разных обслуживающих участков, и идентификаторы каналов-носителей могут быть зависящими от уровня. Например, если отдельные контексты безопасности используются в соответствии с уровнями, процедура переконфигурирования (например, используемая для первоначального конфигурирования вторичного уровня) может осуществляться, пока безопасность не активна на вторичном уровне. Если вторичный уровень реализует отдельный контекст безопасности (например, для одной или более из плоскости управления и/или плоскости пользователя), конфигурация вторичного уровня может осуществляться, когда безопасность еще не начата/активирована (например, для начальной конфигурации вторичного уровня) и/или не удалась (например, для переконфигурирования, которое перемещает один или более RB на другой уровень). Зависящая от уровня команда режима безопасности может использоваться для активации безопасности на вторичном уровне. Например, процедура активация безопасности может осуществляться и/или команда режима безопасности может отправляться для определенного уровня всякий раз, когда изменяется Kenb зависящий от уровня и/или когда изменяется COUNT NAS.

В зависимости от текущей нагрузки в сети и/или объема данных, подлежащих передаче на и/или от WTRU, WTRU может быть конфигурирован первичным уровнем и нулем или более вторичных уровней. WTRU может быть конфигурирован информацией измерения в зависимости от уровня и/или смещениями, зависящими от соты, для задания области соты. WTRU может быть конфигурирован объектом измерения (например, measObj). Этот объект измерения может зависеть от соты и/или зависеть от уровня. Объект измерения могут быть связаны с одной или более другими конфигурациями событий (например, eventConfiguration), например, в зависимости от конфигурации WTRU. Конфигурация событий может включать в себя один или более критериев, которые запускают один или более варианты поведения WTRU. Например, в отношении объекта измерения, WTRU может быть конфигурирован одной или более конфигурациями событий (например, критериями), которые устанавливают условия, при которых запускается WTRU, для осуществления действия на основании измерений WTRU, связанных с объектом измерения. В порядке примера, объект измерения может устанавливать измерение для обслуживающей соты первичного и/или вторичного обслуживающего участка, и конфигурации событий могут указывать одно или более пороговых значений и/или величин смещения, связанных с объектом измерения. Если рассматриваемое измерение выше конфигурированного порогового значения, ниже конфигурированного порогового значения, превышает определенное значение смещения и т.д., WTRU может быть предписано осуществлять событие, связанное с конфигурацией событий. Начальная конфигурация вторичной соты может включать в себя одну или более связей между объектами измерения для соты вторичного обслуживающего участка и одной или более конфигураций событий, которые устанавливают действия, которые WTRU должен осуществлять на первичном и/или вторичном уровне, если измерение отвечает заданным критериям. Объект измерения могут быть связаны с одной или более конфигурациями событий с использованием идентификатором измерения (measId), который используется сетью для обозначения определенного объекта или конфигурации измерения.

Например, объект измерения для определенного уровня может быть конфигурирован для данной обслуживающей соты уровня. Четные конфигурации могут устанавливать действия, подлежащие осуществлению WTRU, на основании того, что качество обслуживающей соты становится выше первого порогового значения (например, условие, которое может запускать первое поведение), на основании того, что качество обслуживающей соты становится ниже второго порогового значения (например, условие, которое может заканчивать первое поведение и/или которое может запускать второе поведение), и т.д. Один или более объектов измерения и одна или более конфигураций событий может использоваться для задания области расширения диапазона соты (CRE). Область CRE может устанавливаться в отношении макросоты (например, связанной с MeNB) и одной или более малых сот (например, связанных с одним или более SCeNB). Область CRE MeNB может быть связана с областями, в которых WTRU находится в зоне покрытия MeNB и также в зоне покрытия одной или более малых сот SCeNB. Пока WTRU находится в CRE, трафик из макросоты может выгружаться в одну или более из малых сот. CRE можно задавать на основании измерений сот на одном или более уровней. WTRU может быть выполнен с возможностью определения, находится ли он в CRE, на основании измерений одной или более малых сот (например, превышает ли качество обслуживающей соты пороговое значение, ниже ли оно порогового значения и т.д.), оставаясь соединенным с макросотой. Поведение WTRU можно задавать на основании одного или более из условий, находится ли WTRU в зоне покрытия области CRE, обнаруживает ли WTRU вхождение в область CRE (например, от центра соты или к нему), обнаруживает ли WTRU покидание область CRE (например, от центра соты или к нему) и/или т.п.

Условия, обнаруженные в первой соте, связанной с первым обслуживающим участком или уровнем, может запускать определенное поведение WTRU на вторичном обслуживающем участке или уровне. Например, если соседняя сота на другом уровне становится лучше, чем обслуживающая сота текущего уровня (например, за счет заданного смещения), WTRU может быть предписано осуществлять первую функцию и/или останавливать осуществление вторую функцию. Аналогично, если соседняя сота на другом уровне становится хуже, чем обслуживающая сота текущего уровня (например, за счет заданного смещения), WTRU может быть предписано осуществлять вторую функцию и/или останавливать осуществление первой функции.

WTRU может быть конфигурирован одним или более значениями смещения (например, значениями, на которые соседняя сота может быть выше или ниже значения текущей обслуживающей соты для запуска поведения) и/или одного или более абсолютных пороговых значений (например, конкретных уровней, на которых измерение запускает определенное поведение). Применительно к многоуровневой работе, если выполняются определенные критерии, связанные с измерениями, осуществляемыми на соте, связанной с первичным уровнем и/или соте, связанной с вторичным уровнем, WTRU может осуществлять одно или более действий, связанных с конкретным уровнем (например, инициировать декодирование сигнализации управления в другой соте/на другом уровне, активировать соту/уровень и т.д.). Таким образом, вместо (и/или помимо) традиционных триггеров выдачи отчета об измерении, определенное измерение может запускать другое поведение на других уровнях. Например, WTRU, конфигурированный возможностью двойного соединения, может быть конфигурирован измерением на первом уровне и может получать предписание осуществлять действия, связанные с обслуживающей сотой вторичного уровня (например, измерение соты на вторичном уровне) на основании выполнения определенных критериев в отношении измерения на первичном уровне. Например, критерии измерения могут устанавливаться для указания того, что WTRU находится в области CRE, но что качество вторичной соты снижается (например, указания того, что WTRU перемещается к границе малой соты). Такие критерии измерения могут использоваться для предписания WTRU отправить запрос на переустановление по меньшей мере одного канала-носителя, конфигурированного для использования на вторичном уровне.

В одном примере, WTRU может быть выполнен с возможностью пытаться определить, находится ли он в области CRE, но что качество соты, связанной с вторичным уровнем, снижается. Например, измерения могут быть конфигурированы таким образом, что если WTRU обнаруживает, что качество вторичной обслуживающей соты падает ниже порогового значения, но все еще находится в области CRE (например, указывая, что WTRU перемещается к границе соты), WTRU может быть вынужден начинать прием сигнализации управления в другой соте. Например, другая сота может быть связана с другим SCeNB, для которого WTRU заранее конфигурирован, но который не был активирован на WTRU. WTRU может начинать попытки приема сигнализации управления (например, сигнализации RRC) в другой соте, чтобы пытаться поддерживать непрерывность сеанса в ходе активации/деактивации другого уровня. Например, измерения могут указывать, что WTRU перемещается к границе малой соты, и WTRU может быть вынужден инициировать прием сигнализации управления в макросоте. Поскольку макросота может иметь более высокую зону покрытия, чем малые соты, более вероятно, что WTRU примет сигнализацию управления через макросоту при перемещении к границе соты малой соты. Инициирование приема сигнализации управления в макросоте может осуществляться вместо и/или после передачи отчета об измерении в сеть (например, посредством текущей обслуживающей соты уровня малых сот).

Процедуры переконфигурирования могут использоваться для конфигурирования одной или более вторичных сот для использования. Например, может использоваться процедура переконфигурирования RRC-соединения WTRU для конфигурирования вторичного уровня с использованием обмена сигнализацией управления с первичным уровнем. Конфигурация второго набора сот, которые связаны с вторичным обслуживающим участком и/или вторичным экземпляром MAC (например, именуемым вторичным уровнем) может осуществляться как часть процедуры переконфигурирования RRC-соединения. Например, сигнализация управления, используемая для установления конфигурации для одной или более сот на вторичном уровне, может включать в себя сообщение переконфигурирования RRC-соединения без информационного элемента mobilityControlInfo (например, принимаемое через соту первичного уровня). Например, WTRU может принимать сообщение RRCConnectionReconfiguration, например, посредством передачи из соты, связанной с первичным уровнем и/или по SRB, связанному с первичным уровнем (например, в случае начальной конфигурации для уровня малых сот). В одном примере, если вторичный уровень уже установлен, сообщение RRCConnectionReconfiguration может приниматься посредством передачи из соты, связанной с вторичным уровнем и/или по SRB, связанному с вторичным уровнем (например, переконфигурирование параметров PHY/MAC для вторичного уровня; для добавления, удаления, пересвязывания и/или перемещения одного или более RB с одного уровня на другой и т.д.).

В одном примере, вместо повторного использования сообщения RRCConnectionReconfiguration для конфигурирования вторичного уровня, новое сообщение RRC может устанавливаться для конфигурирования экземпляра MAC, связанного с вторичным уровнем. Например, сообщение RRCConnectionReconfigurationSecondaryLayer можно задавать для первоначального конфигурирования и/или переконфигурирования вторичного уровня. Если используется сообщение RRCConnectionReconfiguration, в сообщение может быть включено указание, которое указывает, что переконфигурирование осуществляется для конфигурирования/переконфигурирования вторичного уровня вместо или помимо первичного уровня. Конфигурационную информацию для вторичного уровня можно применять к второй группе сот, обслуживаемых обслуживающим участком, связанным с вторичным уровнем (например, SCeNB). Соты вторичного уровня можно планировать независимо от сот других уровней. Конфигурация для вторичного уровня может включать в себя конфигурационную информацию для P-соты и нуль или более S-сот. В одном примере, соты определенного уровня могут быть связаны с одной и той же группой предварительного хронирования.

Используется ли сообщение переконфигурирования для первоначального конфигурирования вторичного уровня и/или переконфигурирования вторичного уровня, сообщение переконфигурирования может включать в себя один или более параметров, которые WTRU может применять для работы на вторичном уровне (например, могут быть параметры помимо существующих параметров такого сообщения RRC). Например, сообщение RRCConnectionReconfiguration, используемое для конфигурирования/переконфигурирования вторичного уровня может включать в себя специализированную конфигурацию радиоресурсов для одной или более обслуживающих сот вторичного уровня (например, IE radioResourceConfigDedicated для соты вторичного обслуживающего участка). Например, специализированная конфигурация радиоресурсов может быть предназначена для P-соты вторичного уровня. В одном примере, сообщение RRCConnectionReconfiguration, используемое для конфигурирования/переконфигурирования вторичного уровня, может включать в себя указание и/или список из одного или более вторичных уровней, подлежащих добавлению и/или изменению (например, IE sLayerCellToAddModList, который может идентифицировать добавляемые уровни). В одном примере, сообщение RRCConnectionReconfiguration, используемое для конфигурирования/переконфигурирования вторичного уровня, может включать в себя список из одной или более обслуживающих сот для добавления (и/или для изменения), соответствующего соте вторичного уровня (например, pCellToAddModList, который указывает информацию для P-соты() для добавления/изменения и/или sCellToAddModList, который указывает информацию для S-соты() для добавления/изменения). Например, для каждого указанного уровня (например, через IE sLayerCellToAddModList), может обеспечиваться список сот для добавления (например, через pCellToAddModList и/или sCellToAddModList).

В одном примере, сообщение RRCConnectionReconfiguration, используемое для конфигурирования/переконфигурирования вторичного уровня, может включать в себя один или более параметров для вывода ключа безопасности. Например, сообщение переконфигурирования может указывать, нужно ли выводить новые ключи безопасности для использования с вторичным уровнем и/или указание способа, подлежащего использованию для вывода ключа безопасности. В одном примере, сообщение RRCConnectionReconfiguration, используемое для конфигурирования/переконфигурирования вторичного уровня, может включать в себя указание идентификатора уровня (например, IE layer-identity, IE mac-instanceIdentity и т.д.). Идентификатор уровня можно использовать для вывода идентификаторов для одного или более SRB вторичного уровня (например, в целях безопасного ввода, например, параметра канала-носителя). Например, для определенного SRB значение, обеспечиваемое RRC более низким уровням для вывода 5-битового параметра канала-носителя, используемого в качестве входных данных для шифрования и для защиты целостности, может быть значением соответствующего srb-Identity + 2 * layer-identity, например, с MSB, заполненных нулями. В порядке примера, первичному уровню может выделяться идентификатор 0. Идентификатор вторичного уровня может неявно выводиться на основании последовательности конфигурации. В одном примере, сообщение RRCConnectionReconfiguration, используемое для конфигурирования/переконфигурирования вторичного уровня, может включать в себя указание одного или более соответствующих RB (например, одного или более DRB и/или SRB), связываемых с вторичным уровнем. Если каналы-носители могут разделяться по разным уровням, сообщение RRCConnectionReconfiguration, используемое для конфигурирования/переконфигурирования вторичного уровня, может включать в себя идентификатор точки доступа к услуге, связанный с вторичным уровнем (например, такое указание также можно обеспечивать, даже если каналы-носители относятся конкретно к определенному уровню).

После приема сообщения RRCConnectionReconfiguration, WTRU может осуществлять различные функции, например, на основании содержания сообщения переконфигурирования. Например, WTRU может добавлять первую соту для вторичного уровня, добавлять дополнительную соту к вторичному уровню, удалять соту из вторичного уровня и т.д. В порядке примера, если сообщение переконфигурирования указывает добавление одного или более вторичных уровней и/или одну или более сот вторичного уровня, WTRU может осуществлять начальную конфигурацию соты для вторичного уровня. В порядке примера, если сота, подлежащая добавлению, является первой сотой, конфигурируемой и добавляемой для определенного вторичного уровня, WTRU может создавать вторичный экземпляр MAC, например, с использованием IE mac-MainConfig, обеспеченного в IE radioResourceConfigDedicated, который может быть включен в сообщение переконфигурирования. WTRU может связывать вновь созданный вторичный экземпляр MAC с идентификатором. Например, явное указание идентификатора может обеспечиваться в сообщении переконфигурирования и/или может неявно создаваться на основании приращения счетчика конкретных (например, конфигурированных) экземпляров MAC. WTRU может конфигурировать физический уровень (например, возможно, с использованием отдельной цепи приемопередатчика), связанный с вторичным экземпляром MAC. Например, параметры для физического уровня могут быть включены в IE radioResourceConfigDedicated, включенный в конфигурацию, применимую к экземпляру MAC (например, physicalConfigDedicated). WTRU может неявно рассматривать первую соту, конфигурированную для использования на вновь созданном уровне как P-соту для вторичного уровня. WTRU может синхронизироваться с нисходящей линией связи конфигурированной соты для вновь добавленного уровня (например, если сота конфигурирована как P-сота рассматриваемого уровня). Если добавляемая сота не является первой сотой, конфигурируемой для вторичного уровня, WTRU может применять любые конфигурации, принятые для соты, к существующему экземпляру MAC, и может отказываться от создания нового экземпляра MAC.

Сообщение переконфигурирования может использоваться для удаления или устранения соты из вторичного уровня. Например, если переконфигурирование указывает, что сота должна быть удалена, WTRU может удалять указанную(ые) соту(ы) и обновлять конфигурацию экземпляра MAC. Если вторичный экземпляр MAC конфигурирован нулем сот после завершения обработки сообщения переконфигурирования (например, каждая из сот для уровня удалена), WTRU может удалять соответствующий вторичный экземпляр MAC из своей конфигурации.

В одном примере, использование сообщения переконфигурирования RRC-соединения без IE mobilityControlInfo может быть связано с изменением существующего соединения для вторичного уровня, но не для добавления нового уровня (например, использование сообщения переконфигурирования без IE mobilityControlInfo происходит, когда WTRU уже конфигурирован для возможности двойного соединения и один или более вторичных уровней изменяется). Например, если WTRU ранее не принял начальную конфигурацию для вторичного уровня в сообщении переконфигурирования RRC-соединения, которое включает в себя IE mobilityControlInfo, WTRU может определять необходимость отбрасывать конфигурацию RRC, включенную в сообщение переконфигурирования без IE mobilityControlInfo, которое применимо к ранее не конфигурированному уровню.

Например, конфигурация вторичного уровня может устанавливаться на основании процедуры переконфигурирования RRC-соединения, которая включает в себя IE mobilityControlInfo. Конфигурация второго набора сот и/или вторичного экземпляра MAC (например, вторичного уровня) может осуществляться как часть процедуры переконфигурирования RRC-соединения. Сообщение переконфигурирования RRC-соединения, включающее в себя информационный элемент mobilityControlInfo, может именоваться командной передачи обслуживания. Если команда передачи обслуживания является типом сигнализации, используемой для добавления вторичного уровня (например, и сообщение переконфигурирования RRC-соединения без IE mobilityControlInfo используется для изменения существующих конфигураций уровней), то WTRU может осуществлять одно или более из описанных здесь действий для добавления нового уровня после получения команды передачи обслуживания (например, добавление P-соты к новому уровню, создание вторичного экземпляра MAC, связывание вторичного экземпляра MAC с идентификатором, конфигурирование физического уровня, синхронизация с P-сотой нового уровня и т.д.). Дополнительно, если команда передачи обслуживания является типом сигнализации, используемым для добавления вторичного уровня (например, и сообщение переконфигурирования RRC-соединения без IE mobilityControlInfo используется для изменения конфигураций существующих уровней), то команда передачи обслуживания может включать в себя один или более из описанных здесь параметров конфигурации для добавления нового уровня (например, специализированную конфигурацию радиоресурсов для соты нового уровня, список из одного или более уровней для добавления, список из одной или более обслуживающих сот для уровня, параметр для вывода ключа безопасности, идентификатор уровня, указание соответствующих RB и т.д.).

WTRU может принимать указание, что процедура переконфигурирования, включающая в себя команду передачи обслуживания, предназначена для добавления уровня. WTRU может поддерживать свою конфигурационную информацию для конфигурированных в данный момент обслуживающих сот, если команда передачи обслуживания является добавлением нового уровня. Указание, что команда передачи обслуживания используется для добавления уровня, может явно указывать, для каких других уровней WTRU должен поддерживать свою текущую конфигурацию.

Если WTRU не удается переконфигурировать первичный уровень в ходе процедуры переконфигурирования, WTRU может освобождать и очищать любую конфигурацию, соответствующую как первичному уровню, так и одному или более вторичных уровней. WTRU может осуществлять обработку сбоя переконфигурирования, как в традиционных процедурах, например, путем повторного выбора другой сотой, инициируя процедуру переустановления, перевода в режим ожидания и/или т.п.

После успешного завершения процедуры RRC, которая используется для первоначального конфигурирования вторичного уровня, и/или после успешного завершения процедуры RRC, которая переконфигурирует один или более вторичных уровней, WTRU может автономно запускать переконфигурирование RACH, может отслеживать порядок RACH после переконфигурирования и после времени активации, и/или активировать одну или более сот через RACH.

Например, WTRU может быть выполнен с возможностью автономно запускать переконфигурирование RACH после успешного добавления и/или переконфигурирования вторичного уровня. WTRU может инициировать процедуру RACH для вторичного уровня. В одном примере, UE может принимать указание в сообщении переконфигурирования для уровня, что следует осуществлять процедуру RACH. В одном примере, процедура RACH может осуществляться, если WTRU принимает сообщение переконфигурирования, конфигурирующее новый уровень с использованием ресурсов первичного уровня (например, от MeNB), но не тогда, когда переконфигурирование осуществляется через вторичный уровень. Процедура RACH может осуществляться с использованием специализированной конфигурации PRACH, обеспеченной в процедуре переконфигурирования (например, в команде передачи обслуживания или другом сообщении переконфигурирования). В одном примере, наличие конфигурации PRACH в сообщении переконфигурирования может указывать, что WTRU должен инициировать процедуру RACH по завершении процедуры переконфигурирования. Процедура RACH может осуществляться с использованием ресурсов восходящей линии связи обслуживающей соты вновь добавленного или переконфигурированного вторичного уровня. Процедура RACH может осуществляться через P-соту вторичного уровня. Процедура RACH может осуществляться на S-соте вторичного уровня. Какую соту вновь добавленного/переконфигурированного уровня следует использовать для процедуры RACH, может указываться в сообщении переконфигурирования. TAT, связанный с обслуживающей сотой, на которой нужно осуществлять процедуру RACH, можно рассматривать как остановленный или не выполняющийся после процедуры переконфигурирования.

В одном примере, WTRU может отслеживать порядок RACH после процедуры переконфигурирования и/или после времени активации для вторичного уровня. Например, WTRU может начинать мониторинг для порядка RACH на PDCCH для обслуживающей соты вторичного уровня по завершении процедуры переконфигурирования, добавляющей и/или изменяющей вторичный уровень. WTRU может начинать мониторинг PDCCH по истечении конфигурированного и/или заранее заданного времени активации. Обслуживающая сота, отслеживаемая на предмет порядка RACH, может быть P-сотой вновь созданного/переконфигурированного вторичного уровня и/или может быть S-сотой вновь созданного/переконфигурированного вторичного уровня. Какую соту вновь добавленного/переконфигурированного уровня следует отслеживать на предмет порядка RACH, может указываться в сообщении переконфигурирования. TAT, связанный с обслуживающей сотой, на которой нужно осуществлять процедуру RACH (например, в ходе которой принимается порядок RACH) можно рассматривать как остановленный или не выполняющийся после процедуры переконфигурирования.

В одном примере, соты вновь созданного/переконфигурированного уровня можно рассматривать как первоначально деактивированные. После активации уровня, WTRU может быть выполнен с возможностью осуществления процедуры RACH на соте активируемого уровня. Например, WTRU может определять необходимость связывания деактивированного состояния с каждой из сот вновь добавленного/переконфигурированного уровня. В одном примере, S-соты уровня могут быть первоначально деактивированы, но P-соту уровня можно рассматривать как активированную после приема конфигурации для уровня. Прием сигнализации управления, которая активирует соту вновь добавленного/переконфигурированного уровня, может предписывать WTRU осуществлять процедуру RACH и/или начинать мониторинг PDCCH соты вновь добавленного/переконфигурированного уровня. Например, прием сигнализации управления (например, от MeNB), которая активирует одну или более сот вторичного уровня (например, которая принимается, пока все соты) вторичного уровня находятся в деактивированном состоянии), может предписывать WTRU осуществлять процедуру RACH и/или начинать мониторинг PDCCH для соты активируемого уровня.

WTRU может быть выполнен с возможностью передачи и/или приема сигнализации RRC от независимых eNB и/или независимых объектов RRC в сети. Например, согласно процедурам LTE выпуск 11, при инициировании процедуры RRC, WTRU может быть дано максимально допустимое время для завершения процедуры RRC. Например, типичные значения максимальной продолжительности времени, необходимой WTRU для завершения процедуры RRC, могут находиться в диапазоне от 15 мс до 20 мс, в зависимости от процедуры RRC. RRC также поддерживает последовательный прием сообщений RRC, например, когда сообщение RRC, которое инициирует вторую процедуру, принимается, пока первая процедура RRC выполняется и еще не завершена. В таком случае, WTRU может обрабатывать сообщения RRC последовательно. Когда WTRU имеет возможность соединения с одним eNB, сеть может гарантировать правильную координацию сигнализации RRC таким образом, чтобы минимизировать требования к обработке и хронированию WTRU.

Когда один и тот же eNB отправляет оба сообщения, eNB может быть способен определить полную задержку для комбинации процедур RRC. Задержка может определяться независимо от того, сколько сообщений RRC отправляет eNB на WTRU. В этом сценарии может не быть неопределенности хронирования на eNB, и eNB может полностью управлять синхронизацией.

Когда возможность двойного соединения конфигурирована (например, WTRU соединен и/или пытается соединиться с множеством уровней), могут возникать конфликты в случаях, когда eNB не полностью скоординированы. Например, WTRU может принимать сигнализацию управления от множества eNB, каждый из которых инициирует соответствующую процедуру RRC. Принятая сигнализация управления может отправляться по разным трактам передачи (например, Uu для MeNB и Uu для SCeNB). Например, тракт, используемый для отправки сообщений RRC, может зависеть от того, применима ли сигнализация к конфигурации WTRU для MeNB или для SCeNB. В таком случае, существует более высокая вероятность того, что WTRU может принимать сообщение RRC, которое запускает вторую процедуру RRC (например, с SCeNB), тогда как WTRU уже имеет текущую процедуру RRC (например, с MeNB) (или наоборот).

Когда WTRU принимает сообщения RRC от разных eNB (например, SCeNB и MeNB), второму eNB может быть трудно гарантировать синхронизацию и завершение процедуры с WTRU. Например, это может быть трудность в определении задержки до завершения процедуры, поскольку WTRU уже может осуществлять другую процедуру RRC, инициированную первым eNB. Второй eNB может не знать о другой процедуре RRC, которую осуществляет WTRU. Кроме того, WTRU может быть трудно осуществлять процедуры RRC параллельно (например, а не последовательно), например, при наличии зависимости (или взаимодействия) между двумя процедурами RRC. Например, в одной или более из конфликтующих процедур могут возникать проблемы, связанные с синхронизацией, неопределенностью хронирования, дополнительной задержкой и т.д.

Например, может возникать конфликт, когда WTRU принимает PDU RRC для разных процедур RRC. В одном примере, WTRU может быть выполнен с возможностью отдавать предпочтение одной из процедур RRC, которая может быть связана с первым уровнем над другой процедурой RRC, которая может быть связана со вторым уровнем. Например, WTRU может осуществлять прием множества PDU RRC в одном и той же подкадре (или в окнах обработки, которые могут перекрываться) связывая приоритет с каждым сообщением. Приоритет можно назначать согласно заранее заданным правилам, например, таким образом, что WTRU может последовательно осуществлять соответствующие процедуры в порядке возрастания приоритета. Например, приоритет, назначенный определенной процедуре RRC и/или определенному сообщению RRC могут базироваться на идентификаторе уровня, с которым связан PDU RRC (например, первичный уровень/MeNB может иметь более высокий приоритет, чем вторичный уровень/SCeNB), идентификатор SRB, по которому WTRU принимает PDU RRC (например, SRB0, SRB1, SRB2 может иметь более высокий приоритет, чем SRB3), тип процедуры, с которым связан PDU RRC (например, событие мобильности, например команда передачи обслуживания может иметь более высокий приоритет, чем процедура переконфигурирования) и/или т.п.

В одном примере, в случае приема конфликтующих PDU RRC, WTRU может быть выполнен с возможностью отдавать предпочтение PDU RRC, который синхронизирует на основании требования к задержке. Например, WTRU могут назначать более низкий приоритет PDU RRC, связанному с процедурой, завершение которой может запускать процедуру RACH. Хронирование процедуры с более высоким приоритетом может поддерживаться, тогда как вторая процедура все еще может осуществляться, не внося неопределенность хронирования при условии, что процедура RACH, которая осуществляется по завершении процедуры RRC более низкого приоритета, может синхронизировать WTRU и сеть.

В одном примере, после приема PDU RRC, при выполнении другой процедуры RRC, WTRU может быть выполнен с возможностью отдавать предпочтение одной из процедур и подвешивать/прерывать другую процедуру RRC. Например, WTRU может подвешивать или прерывать текущую процедуру на основании приема сообщения RRC, для которого определен более высокий приоритет. Например, WTRU может определять, что два принятых PDU RRC и/или текущая процедура и принятый PDU RRC конфликтуют, и в этом случае WTRU может инициировать логику сбоя процедуры RRC для PDU RRC и/или процедуру с самым низким приоритетом. В одном примере, WTRU может подвешивать процедуру, завершение которой может приводить к процедуре RACH в случае такого конфликта.

Например, два или более PDU RRC может приниматься одновременно или почти одновременно. В порядке примера, WTRU может принимать множество PDU RRC в одном и том же подкадре и/или в течение определенного времени. Первый PDU RRC может быть связан с процедурой, применимой к первому eNB/уровню, и второй PDU RRC может быть связан с процедурой, применимой ко второму eNB/уровню. В случае такого конфликта, WTRU может осуществлять параллельную обработку процедур RRC, последовательную обработку процедур RRC и/или может отбрасывать или осуществлять процедуру сбоя для одной или более из процедур RRC.

Например, WTRU может обрабатывать оба сообщения таким образом, чтобы процедуры RRC могли осуществляться параллельно. Например, WTRU может определять необходимость параллельного осуществления процедур RRC, если процедуры RRC независимы друг от друга. Например, WTRU может определять, что обе процедуры переконфигурируют разные аспекты RRC (например, разные параметры, разные RB, разные экземпляры MAC, разные компоненты приемопередатчика и/или их независимые комбинации), и что повторные конфигурации не конфликтуют друг с другом. WTRU может осуществлять процедуры RRC параллельно на основании определения, что обе процедуры независимы по природе (например конфигурирование измерения и переконфигурирование выделенных ресурсов). Например, WTRU может определять, что требование к обработке (например, применительно к максимальной задержке) для завершения процедуры() такие же, как в случае, когда каждая процедура осуществляется отдельно. Альтернативно, WTRU может быть выполнен с возможностью осуществления синхронизации с сетью (например, путем осуществления процедуры RACH). Например, если неопределенность хронирования вносится и для MeNB, и для SCeNB, для процедуры RRC вследствие конфигурации возможности двойного соединения, WTRU может быть выполнен с возможностью осуществления процедуры RACH для одной или более процедур RRC, которые изменяют соответствующие параметры физического уровня WTRU и/или для каждого из переконфигурированных физических уровней.

В одном примере, WTRU может быть выполнен с возможностью осуществления последовательной обработки двух или более процедур RRC. WTRU может обрабатывать принятые сообщения последовательно, таким образом, что процедуры RRC осуществляются последовательно. Например, WTRU может определять необходимость последовательного осуществления процедур RRC на основании определения, что обе процедуры RRC независимы друг от друга. WTRU может определять, какой процедуре отдавать предпочтение (например, для осуществления в первую очень) на основании одного или более из идентификатора eNB, связанного с процедурой RRC, идентификатора SRB, связанного с процедурой RRC, типа принимаемого PDU RRC, типа процедуры RRC и/или т.п.

Например, WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию идентификатора eNB (и/или уровня/интерфейса Uu), связанного с процедурой RRC. Например, WTRU может отдавать предпочтение обработке PDU RRC, связанного с MeNB, а не SCeNB.

Например, WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию идентификатора SRB, связанного с процедурой. Например, WTRU может определять, что SRB, по которому принимается PDU RRC, тот же самый или отличается от SRB, по которому принимается PDU RRC, которой инициировал текущую процедуру. В одном примере, если SRB, используемые для первого eNB и для второго eNB, различны, то определенным SRB можно отдавать предпочтение над другими SRB. Например, если SRB для определенного WTRU совместно использовали одно и то же пространство идентификаторов для разных уровней/экземпляров MAC, то WTRU может определять, какой процедуре отдавать предпочтение, непосредственно на основании идентификатора SRB для процедур. В противном случае, если SRB для первого уровня отличаются от SRB для второго уровня, то WTRU может определять, какой процедуре RRC отдавать предпочтение, на основании связи(ей) между идентификатором SRB и eNB (например, WTRU может иметь SRB0, 1, и/или 2 для каждого eNB, и приоритет может базироваться, прежде всего, на идентификаторе SRB и, в случае одного и того же идентификатора SRB, на основании идентификатора уровня). Например, WTRU может отдавать предпочтение обработке PDU RRC, связанного с SRB0, SRB1 и/или SRB2, над PDU RRC, связанным с SRB3.

WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию способа мультиплексирования, используемого для приема PDU RRC, связанных с конфигурацией WTRU для разных eNB. Например, WTRU может определять приоритет, связанный с определенной процедурой RRC на основании функции, которая позволяет мультиплексировать PDU RRC (или информационные элементы в PDU), относящиеся к конфигурации для разных eNB. Например, идентификатор интерфейса Uu, который использовался для транспортировки PDU RRC, может использоваться для установления приоритета. Формат PDU RRC (например, например, указание, принятое в PDU RRC и/или тип информационного(ых) элемента(ов), включенного(ых) в PDU RRC), может использоваться для установления приоритета RRC. Идентификатор подкадра, в котором WTRU принял PDU RRC, может использоваться для определения приоритета для манипулирования процедурами RRC (например, в случае нисходящей линии связи WTRU мультиплексируется по времени между eNB).

WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию типа принятого PDU RRC. Например, WTRU может определять приоритет, связанный с определенным PDU RRC, как функцию того, инициирует ли PDU RRC новую процедуру RRC, или же он является PDU для текущей процедуры. WTRU может быть выполнен с возможностью отдавать предпочтение PDU RRC для текущей процедуры над PDU RRC, который инициирует новую процедуру RRC. В одном примере, если PDU RRC, применимые к конфигурациям WTRU для любого eNB/уровня, могут приниматься по любому из транспортных трактов (например, PDU RRC для процедур RC, связанных с разными уровнями, могут приниматься по одному и тому же транспортному тракту), то текущим процедурам можно отдавать предпочтение над вновь инициированными процедурами. Например, WTRU может отдавать предпочтение PDU RRC, связанному с текущей процедурой, над PDU RRC, который инициирует новую процедуру.

WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию типа процедуры, связанной с принятым(и) PDU RRC. Например, WTRU может определять приоритет, связанный с PDU RRC, на основании типа процедуры RRC, с которой связан PDU RRC. Например, WTRU может отдавать предпочтение PDU RRC, связанному с событием мобильности или с событием безопасности, над PDU RRC, связанным с переконфигурированием вторичного уровня.

WTRU может быть выполнен с возможностью отбрасывать и/или инициировать процедуру сбоя для процедуры RRC, которая конфликтует с другой процедурой RRC более высокого приоритета. Например, WTRU может определять, что второй PDU RRC следует игнорировать, и/или что WTRU следует перейти к логике сбоя для процедуры RRC, связанной со вторым PDU RRC, на основании определения, что другая процедура RRC отменяет и/или конфликтует с процедурой RRC, связанной со вторым PDU RRC, и что другая процедура RRC имеет более высокий приоритет, чем процедура RRC, связанная со вторым PDU RRC. Например, WTRU может отбрасывать PDU RRC или инициировать логику сбоя для процедуры RRC, связанной с PDU RRC, на основании определения, что процедуры зависят друг от друга. Например, WTRU может принимать сообщение переконфигурирования RRC с IE mobilityControlInfo (например, команду передачи обслуживания), которое предписывает WTRU удалить конфигурацию, связанную с SCeNB, и осуществить передачи обслуживания к другой соте для RRC-соединения. WTRU также может принимать сообщение переконфигурирования RRC, которое предназначено для переконфигурирования SCeNB (например, конфигурации физического уровня SCeNB). В таком случае, WTRU может обрабатывать и осуществлять процедуру мобильности (например, связанную с командой передачи обслуживания) и определять, что процедура переконфигурирования для SCeNB недействительна. В одном примере, WTRU может передавать сообщение, указывающее сбой, для осуществления второй процедуры, и сообщение может включать в себя указание причины сбоя (например, «отмены со стороны MeNB»).

Аналогичные правила на основе приоритета можно применять на WTRU для процедур RRC, инициируемых WTRU. Например, когда WTRU определяет, что более чем одну процедуру RRC следует запускать в течение некоторого заданного периода времени, WTRU может использовать правила приоритета для определения, как обрабатывать конфликты для двух или более процедур RRC, инициируемых WTRU.

В одном примере, WTRU может быть выполнен с возможностью приема одного или более PDU RRC для процедуры RRC во время выполнения другой процедуры RRC. Например, текущую процедуру RRC можно применять к первому eNB/уровню, и принятый(е) PDU RRC может(ут) быть связан(ы) с процедурой, применимой ко второму eNB/уровню. В таком случае, можно задавать аналогичные правила, осуществляющие параллельную обработку процедур RRC, последовательную обработку процедур RRC и/или отбрасывание или осуществление процедуры сбоя для одной или более из процедур RRC, что имеет место, когда два или более PDU RRC принимаются одновременно или почти одновременно.

Например, WTRU может обрабатывать принятый PDU RRC, применимый к конфигурации для второго eNB/уровня, таким образом, что вторая процедура RRC осуществляется параллельно текущей процедуре RRC. Например, WTRU может определять необходимость параллельного осуществления процедур RRC, если процедуры RRC независимы друг от друга. Например, WTRU может определять, что обе процедуры переконфигурируют разные аспекты RRC (например, разные параметры, разные RB, разные экземпляры MAC, разные компоненты приемопередатчика и/или их независимые комбинации), и что повторные конфигурации не конфликтуют друг с другом. WTRU может осуществлять процедуры RRC параллельно на основании определения, что обе процедуры независимы по природе (например конфигурирование измерения и переконфигурирование выделенных ресурсов). Например, WTRU может определять, что требование к обработке (например, применительно к максимальной задержке) для завершения процедуры() такие же, как в случае, когда каждая процедура осуществляется отдельно. Альтернативно, WTRU может быть выполнен с возможностью осуществления синхронизации с сетью (например, путем осуществления процедуры RACH). Например, если неопределенность хронирования вносится и для MeNB, и для SCeNB, для процедуры RRC вследствие конфигурации возможности двойного соединения, WTRU может быть выполнен с возможностью осуществления процедуры RACH для одной или более процедур RRC, которые изменяют соответствующие параметры физического уровня WTRU и/или для каждого из переконфигурированных физических уровней.

В одном примере, WTRU может быть выполнен с возможностью обработки второго сообщения по завершении текущей процедуры, таким образом, что процедуры RRC осуществляются последовательно. Например, WTRU может определять необходимость последовательного осуществления процедур RRC на основании определения, что обе процедуры RRC независимы друг от друга. В одном примере, WTRU может определять, что текущую процедуру следует подвешивать таким образом, что другому PDU RRC следует отдавать приоритет на основании одного или более из идентификатора eNB, связанного с процедурами RRC, идентификатора SRB, связанного с процедурой RRC, типа принимаемого PDU RRC, типа процедуры RRC и/или т.п.

Например, WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию идентификатора eNB (и/или уровня/интерфейса Uu), связанного с процедурой RRC. Например, WTRU может отдавать предпочтение процедуре, связанной с MeNB, а не с SCeNB. Например, WTRU может подвешивать (или останавливать, или завершать со сбоем) текущую процедуру, чтобы инициировать новую процедуру, если новая процедура предназначена для MeNB/первичного уровня, и текущая процедура предназначена для SCeNB /вторичного уровня.

Например, WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию идентификатора SRB, связанного с процедурой. WTRU может определять, что SRB, для которого принимается PDU RRC, имеет более высокий приоритет, чем связанный с PDU RRC, которой инициировал текущую процедуру. Например, WTRU может отдавать предпочтение обработке PDU RRC, связанного с SRB0, SRB1 или SRB2, над процедурой RRC, инициированной PDU RRC, связанным с SRB3.

WTRU может определять, какой процедуре RRC отдавать предпочтение/осуществлять в первую очередь, как функцию типа процедуры, связанной с принятым(и) PDU RRC, и текущей процедуры RRC. Например, WTRU может отдавать предпочтение PDU RRC, связанному с событием мобильности или с событием безопасности, над завершением текущей процедуры, связанной с переконфигурированием вторичного уровня.

WTRU может быть выполнен с возможностью отбрасывать и/или инициировать процедуру сбоя для текущей процедуры RRC, которая конфликтует с PDU RRC, который принят и определен как имеющий более высокий приоритет. WTRU может быть выполнен с возможностью игнорировать PDU RRC, связанный с более низким приоритетом, если выполняется процедура RRC более высокого приоритета. Например, WTRU может определять, что второй PDU RRC следует игнорировать, и/или что WTRU следует перейти к логике сбоя для процедуры RRC, связанной со вторым PDU RRC, на основании определения, что другая процедура RRC отменяет и/или конфликтует с процедурой RRC, связанной со вторым PDU RRC, и что другая процедура RRC имеет более высокий приоритет, чем процедура RRC, связанная со вторым PDU RRC. Например, WTRU может отбрасывать PDU RRC или инициировать логику сбоя для процедуры RRC, связанной с PDU RRC, на основании определения, что процедуры зависят друг от друга. Например, WTRU может иметь текущую процедуру мобильности на основании приема сообщения переконфигурирования RRC с IE mobilityControlInfo (например, команду передачи обслуживания), которая предписывает WTRU удалить конфигурацию, связанную с SCeNB, и осуществить передачи обслуживания к другой соте для RRC-соединения. В таком случае, WTRU может обрабатывать и осуществлять процедуру мобильности (например, связанную с командой передачи обслуживания) и определять, что процедура переконфигурирования для SCeNB недействительна. В одном примере, WTRU может передавать сообщение, указывающее сбой, для осуществления второй процедуры, и сообщение может включать в себя указание причины сбоя (например, «отмены со стороны MeNB»).

В одном примере, WTRU может подвешивать текущую процедуру RRC, если текущая процедура конфликтует с PDU RRC, принятым для другого уровня, и завершение текущей процедуры RRC приведет к синхронизации события с рассматриваемым eNB (например, завершение процедуры RRC приведет к процедуре RACH).

WTRU может быть выполнен с возможностью осуществления одного или более действий после сбоя переконфигурирования для вторичного уровня и/или после определения необходимости инициирования процедуры сбоя переконфигурирования (например, вследствие конфликтов между множеством процедур RRC). WTRU может определять, что переконфигурирование определенного уровня не удалось, на основании одной или более из неудачи в интерпретации и/или декодировании сообщения переконфигурирования, неудачи в успешном применении конфигурации, обеспеченной в ходе процедуры переконфигурирования, неудачи в успешном осуществлении произвольного доступа с использованием новой конфигурации, определение принятой конфигурации превышает возможности WTRU (например, принятую конфигурацию нельзя применять на основании возможностей WTRU), обнаружение конфликтующей сигнализации плоскости управления, обнаружение RLF и/или т.п. Если WTRU определяет, что ему не удалось конфигурировать одну или более (или все) из обслуживающих сот для вторичного уровня и/или экземпляра MAC, WTRU может осуществлять различные действия. Например, если WTRU определяет, что процедура переконфигурирования RRC-соединения не удалась, WTRU может возвратиться к предыдущей конфигурации для вторичного уровня (например, в случае неудачного переконфигурирования для вторичного уровня и/или одного уровня). В одном примере, WTRU может возвращаться к первичному уровню и прекращать использование конфигураций для вторичных уровней (например, в случае сбоя мобильности для всех вторичных уровней). WTRU может инициировать процедуру RRC-соединения переустановления на первичном уровне, например, для переустановления радиоканалов-носителей (например, DRB, возможно, DRB, но не SRB), связанных с вторичным уровнем, для которого переконфигурирование не удалось. Например, WTRU может осуществлять процедуру переустановления для всех DRB, связанных с вторичным уровнем, для которого произошел сбой переконфигурирования и/или для конкретных DRB вторичного уровня, которые были предметом не удавшейся процедуры переконфигурирования. В порядке примера, WTRU может отправлять в сеть указание причины сбоя переконфигурирования. Например, если сбой переконфигурирования произошел вследствие конфликта с другой процедурой RRC, реализуемой WTRU (например, для другого уровня), WTRU может указывать, что произошел конфликт, например, указывая причину как “превышены возможности WTRU” или какую-либо аналогичную/другую причину. WTRU может инициировать передачу отчета об измерении на макроуровень, когда не удалось определить процедуру переконфигурирования для вторичного уровня. Например, отчет может включать в себя один или более результатов измерения для уровня, который не удалось переконфигурировать. В порядке примера, WTRU может определять, что WTRU не удалось конфигурировать вторичный уровень, если WTRU не удается успешно применять конфигурацию для P-соты вторичного уровня. Например, WTRU может определять, что ему не удалось успешно синхронизироваться с P-сотой, и/или если ему не удалось успешно осуществить произвольный доступ в P-соте. Такие сбои могут предписывать WTRU рассматривать переконфигурирование как сбой.

WTRU может быть выполнен с возможностью осуществления процедуры переустановления RRC-соединения, например, на основании того, что не удалось успешно переконфигурировать один или более уровней. Нижеследующие примеры можно использовать для процедуры переустановления RRC-соединения (или вторичного уровня). Например, WTRU может определять, что некоторые или все обслуживающие соты вторичного уровня (например, P-сота вторичного уровня) испытывают проблемы с линией радиосвязи. WTRU может обнаружить условия сбоя, которые могут указывать, что передачи для DRB вторичного уровня будут неудачны или более невозможны. Например, если DRB связаны исключительно с вторичным уровнем, и одна или более сот вторичного уровня испытывают проблемы с линией радиосвязи (например, объявлен RLF), WTRU может определить, что ему не удастся осуществить связь с использованием каналов-носителей. В порядке примера, процедура переустановления может осуществляться для DRB, которые уже не удовлетворяют требованиям QoS, но не для DRB, которые все еще удовлетворяют требованиям QoS. Переустановление RRC может осуществляться для SRB (например, SRB3). Например, процедура переустановления может осуществляться для SRB, связанного с вторичным уровнем, если процедура переустановления указывает, что вторичный уровень все еще используется для рассматриваемых RB после завершения процедуры. Процедура переустановления может быть, когда первичный уровень (например, P-сота первичного уровня) испытывает сбой линии радиосвязи и/или когда вторичный уровень (например, P-сота вторичного уровня) испытывает сбой линии радиосвязи.

Например, WTRU может определять, что процедуру переустановления следует осуществлять для определенного уровня на основании обнаружения одного или более условий сбоя. Примеры условий сбоя могут включать в себя один или более из RLF DL, RLF UL, сбоя передачи обслуживания для вторичного уровня, сбоя безопасности (например, сбоя проверки целостности), указания от более низкого уровня (например, MAC), что процедура конфигурирования и/или переконфигурирования не удалась, сбоя переконфигурирования, который связан с переконфигурированием вторичного уровня, и/или других ситуаций сбоя. В случае обнаружения условий сбоя для определенного уровня, WTRU может попытаться инициировать запрос на переустановление в соте уровня, который не удовлетворяет условию сбоя. Например, переустановление возможно в соту уровня, конфигурированного для использования WTRU, но который может находиться в деактивированном состоянии/состоянии ожидания. В одном примере, WTRU может пытаться осуществить переустановление на конфигурированном и активном уровне, который отличается от уровня, на котором обнаружен сбой. Например, если сота, используемая для процедуры переустановления, ранее была неактивной, WTRU может сначала возобновить нормальную работу и/или активировать рассматриваемую соту. Например, неактивный уровень может быть сотой (например, P-сотой) первичного уровня. В одном примере, запрос на переустановление может инициироваться на соту вторичного уровня.

Например, после обнаружения сбоя в соте определенного уровня (например, вторичного уровня), WTRU может инициировать процедуру переустановления, например, в соте первичного уровня и/или соте другого вторичного уровня. WTRU может подвешивать один или более DRB, связанных с уровнем, для которого осуществляется переустановление (например, DRB, связанных со вторичным уровнем, на котором произошел сбой). В одном примере, WTRU может освобождать все соты уровня для которого осуществляется переустановление. WTRU может сбрасывать (например, и/или ликвидировать) экземпляр MAC, который соответствует уровню, для которого осуществляется переустановление. Например, WTRU может инициировать передачу сообщения RRC (например, переустановление RRC-соединения (или аналогичное) сообщение, которое указывает «сбой уровня»), которое может включать в себя идентификатор уровня, для которого осуществляется переустановление (например, в reestablishmentCause). Если процедура переустановления запущена на основании конфигурации событий, WTRU может включать в себя measID и/или указание «снижения качества» и/или «недостаточного качества». Если WTRU осуществляет переустановление через уровень, который находится в деактивированном состоянии/состоянии ожидания, WTRU может включать в себя идентификатор, например, идентификатор WTRU и/или идентификатор контекста. Например, идентификатором может быть значением, назначенным WTRU в конфигурации уровня, для которого осуществляется переустановление, и/или уровня, по которому осуществляется процедура переустановления. В порядке примера, идентификатором может быть C-RNTI, назначенный WTRU в конфигурации уровня, для которого осуществляется переустановление, и/или уровня, по которому осуществляется процедура переустановления.

WTRU может принимать сообщение переконфигурирования RRC-соединения. Сообщения переконфигурирования могут пересвязывать один или более DRB с уровнем, для которого условие сбоя не обнаружено (например, с первичным уровнем). WTRU может сносить и/или удалять конфигурацию для экземпляра MAC, который соответствует уровню, на котором произошел сбой. В одном примере, сообщение переконфигурирования может пересвязывать DRB уровня, на котором произошел сбой (например, и/или SRB) с новым вторичным уровнем и/или с первичным уровнем. WTRU может повторно использовать экземпляр MAC, который соответствует уровню, на котором произошел сбой, для нового вторичного уровня и/или может создавать новый экземпляр MAC для вновь конфигурированного вторичного уровня. Нужно ли использовать первичный уровень или вторичный уровень для пересвязывания RB, могут указываться с использованием идентификатора уровня, включенного в сообщение переконфигурирования.

Если WTRU выполнен с возможностью осуществления переконфигурирования (например, на основании осуществления переустановления уровня, на основании наступления события мобильности, на основании активации/деактивации уровня и т.д.), WTRU может переустанавливать PDCP для DRB, связанного с переконфигурируемым уровнем (и/или для SRB переконфигурируемого уровня). Например, если экземпляр PDCP зависит от WTRU (например, например, в архитектуре, в которой принимающие/передающие объекты PDCP изменяются после события мобильности на первичном уровне, но не после события мобильности, связанного с вторичным уровнем), WTRU может переустанавливать PDCP путем осуществления поднабора процедуры переустановления PDCP, которые осуществлялись бы в случае необходимости переустановления первичного уровня. Например, WTRU может пропускать переустановление PDCP, в том смысле, что WTRU может продолжать протокол сжатия заголовка, не сбрасывая его, может поддерживать контекст безопасности и/или может оставлять информацию упорядочение нетронутой. В одном примере, WTRU может передавать отчет о статусе PDCP на восходящей линии связи, если он конфигурирован. WTRU может переустанавливать RLC для рассматриваемых DRB (и/или SRB, если применимо).

После успешного завершения процедуры переконфигурирования на основании сбоя вторичного уровня, WTRU может определять, что переустановление DRB для уровня, на котором произошел сбой, было успешным. WTRU может возобновлять использование любых подвешенных RB для уровня, на котором произошел сбой, например на другом уровне, заданном процедурой переконфигурирования. WTRU может включать в себя отчет о статусе, указывающий данные плоскости пользователя, которые еще предстоит успешно передать/принять после того, как он возобновит DRB, которые были переконфигурированы. WTRU может осуществлять запрос на переустановление на DRB вторичного уровня, если он определяет сбой линии радиосвязи восходящей линии связи. В одном примере, переустановление для DRB вторичного уровня может осуществляться для P-соты вторичного уровня, но не для S-сот вторичного уровня.

Поскольку разные обслуживающие участки способны обеспечивать WTRU доступ и услуги относительно независимо друг от друга, поведение WTRU в такой архитектуре может отличаться от поведения WTRU в архитектуре одного тракта данных. Например, WTRU может соединяться с первым, первичным обслуживающим участком (MeNB). WTRU может устанавливать RRC-соединение с первичным обслуживающим участком аналогично выпуску 11. В ходе процесса соединения, WTRU может отправлять в сеть указание, которое указывает, что WTRU поддерживает возможность соединения участка множественного обслуживания. На основании приема указания, сеть может заранее конфигурировать WTRU для осуществления доступа к одному или более вторичных обслуживающих участков. Например, первичный обслуживающий участок может отправлять сообщение переконфигурирования RRC-соединения на WTRU. Сообщение переконфигурирования RRC-соединения может включать в себя указание, что переконфигурирование нужно для добавления дополнительных экземпляров MAC и/или для добавления дополнительных уровней передачи.

WTRU может сохранять конфигурационную информацию для одного или более уровней. Однако, хотя принятая(ые) конфигурация(и) может(гут) быть действительной(ыми), фактические соединения между WTRU и заранее конфигурированные обслуживающие участки могут быть деактивированы. Конфигурационная информация, сохраненная WTRU, могут сохраняться и/или оставаться действительной, пока WTRU не примет сообщение, которое удаляет, изменяет и/или освобождает конфигурацию. В одном примере, сохраненная конфигурационная информация может быть действительной в течение заданного периода времени, и указание периода времени может входить в состав конфигурации. WTRU можно считать действительным пока не произойдет заданное событие (например, пока не произойдет повторный выбор соты на первичном уровне). Например, сохраненную конфигурационную информацию можно считать действительной пока не произойдет событие мобильности (например, пока WTRU не переместится в другой PLMN, другую зону отслеживания и т.д.).

Конфигурация первичного уровня может быть действительной в течение других периодов времени, чем конфигурация вторичного уровня. Например, событие может предписывать WTRU игнорировать конфигурацию вторичного уровня, но не первичного уровня (или наоборот). Сеть может “заранее конфигурировать” или “подготавливать” WTRU конфигурационной информацией для одного или более уровней (например, первичного уровня, вторичного уровня и т.д.) без активации одного или более уровней. Затем сеть может отправлять сигнализацию на WTRU для указания того, что WTRU должен активировать один или более заранее конфигурированных уровней. WTRU может отдавать предпочтение конфигурации первого уровня над конфигурацией второго уровня. Например, WTRU может отдавать предпочтение конфигурации первичного уровня (например, который может соответствовать макроуровню и/или обслуживаться MeNB) для таких функций, как переустановление соединения и/или мобильность, если другой уровень дает сбой (например, вторичный уровень).

Конфигурационная информация для множества уровней может конфигурировать WTRU для использования множества экземпляров MAC. В зависимости от обстоятельств, в которых WTRU пытается осуществить доступ к разным обслуживающим участкам, WTRU может быть выполнен с возможностью поддерживать разное количество активных обслуживающих участков в любой определенный момент времени. Например, WTRU может иметь один экземпляр MAC (или уровень), активный в любое определенное время. Конфигурация, в которой один экземпляр MAC (или уровень) активен в любое определенное время, может именоваться одной возможностью соединения MAC. WTRU может поддерживать один активный уровень, например, какой бы уровень ни обеспечивал наилучшую возможность соединения в определенный момент времени. Например, уровни малой соты могут использоваться для достижения выигрышей в пропускной способности и/или могут использоваться для выгрузки трафика из макроуровня. Если уровни малой соты используются для разгрузки макроуровня, то WTRU может деактивировать первичный уровень после активации вторичного уровня и осуществления доступа к нему.

Например, как упомянуто выше, WTRU может сначала соединяться с макроуровнем. После приема информации предварительной конфигурации для одного или более потенциальных вторичных уровней, WTRU может активировать вторичный уровень и начать осуществлять доступ к вторичному обслуживающему участку. Затем WTRU может деактивировать соединение с первичным обслуживающим участком, поддерживая при этом соединение с вторичным обслуживающим участком. Таким образом, WTRU может эффективно выгружаться из макроуровня, поддерживая при этом непрерывное обслуживание на уровне малых сот.

В одном примере, если первичный уровень неактивен и/или не используется для передачи и/или приема данных, конфигурация/контекст для первичного уровня может сохраняться на WTRU, но WTRU может отказываться от использования конфигурации/контекста для первичного уровня для передач. Конфигурация первичного уровня и/или конфигурации, связанные с обслуживающими сотами для первичного уровня, можно рассматривать как находящиеся в состоянии ожидания или деактивированные, но могут сохраняться в памяти для последующей повторной активации и использованию. WTRU может принимать сигнализацию управления, которая деактивирует один или более уровней и/или активирует один или более уровней. В одном примере, деактивация определенного уровня может предписывать WTRU активировать другой уровень.

В течение периода, когда макроуровень деактивирован, WTRU может продолжать отслеживать обслуживающий участок макроуровня. Например, процедуры, связанные с мобильностью, и/или RRC-соединение WTRU могут быть связаны с соединением WTRU с первичным обслуживающим участком. Перенос выгруженных данных может осуществляться через один или более активных вторичных обслуживающих участков. Чтобы гарантировать, что WTRU все еще способен осуществлять доступ к обслуживающему макроучастку в случае повторной активации макроуровня (например, для осуществления мобильности или другой процедуры управления, для отправки и/или приема данных и т.д.), WTRU может продолжать измерять обслуживающий макроучасток (например, MeNB). WTRU может осуществлять мониторинг на основании одного или более триггеров. Например, определение необходимости осуществления измерений на обслуживающем макроучастке (например, и/или на одном или более других деактивированных уровнях) может базироваться на одном или более триггеров. Триггеры для осуществления таких измерений более подробно описаны ниже. Аналогично, можно задавать триггер(ы) для отправки отчета об измерении, включающего в себя информацию, связанную с измерениями качества, осуществляемыми на WTRU. Триггер(ы) для отправки отчета об измерении могут быть идентичны или отличны от триггера(ов) для осуществления измерений. В целях объяснения и наглядности, примеры триггера(ов) для осуществления измерений и триггера(ов) для отправки отчета об измерении можно описать здесь совместно. Однако допустимо, чтобы различные комбинации триггеров использовались для запуска осуществления измерения и выдачи отчета об измерении. Например, первый триггер, например, качество обслуживающей соты активного уровня, падающее ниже порогового значения, может предписывать WTRU осуществлять измерения на деактивированной обслуживающей соте другого уровня. Второй триггер, например, качество обслуживающей соты другого уровня, превышающее пороговое значение и/или лучшего, чем у текущей обслуживающей соты активного уровня, на заданную пороговую величину, может предписывать WTRU выдать отчет об измерениях обслуживающего участка деактивированного уровня в сеть (например, активный обслуживающий участок). Активный обслуживающий участок может использовать информацию измерения, чтобы предписывать WTRU активировать один или более деактивированных уровней. Например, первичный обслуживающий участок может отправлять на WTRU сигнализацию MAC (например, CE MAC), которая указывает, что заранее конфигурированный, деактивированный вторичный уровень, подлежит активации. Сигнализация MAC может указывать, что один или более уровней (например, активированный в данный момент первичный уровень) следует деактивировать после активации другого уровня, и/или WTRU может неявно определять необходимость деактивации активного уровня на основании активации другого уровня.

Кроме того, вместо или помимо активации и деактивации уровней, запускаемой явной сигнализацией из сети, один или более заранее конфигурированных уровней может автономно активироваться и/или деактивироваться WTRU. Например, вместо или помимо отправки в сеть отчетов об измерениях деактивированных обслуживающих участков, WTRU может локально оценивать измерения для определения, следует ли активировать деактивированный уровень и/или деактивировать активированный уровень. Поскольку WTRU может использовать такие же критерии, как сеть, для оценивания, следует ли активировать или деактивировать уровень, триггеры для автономной активации и/или деактивации, осуществляемой WTRU, могут быть аналогичны описанным триггерам, которые предписывают WTRU осуществлять измерения или деактивированный уровень и/или отправлять отчеты об измерениях в сеть (например, активный обслуживающий участок). Таким образом, в целях объяснения и наглядности, триггеры, предписывающие WTRU автономно активировать и/или деактивировать уровень, можно описывать совместно с триггерами, предписывающими WTRU осуществлять измерения и/или отправлять отчеты об измерениях. Однако легко видеть, что различные комбинации таких триггеров можно реализовать таким образом, что первый набор триггеров может предписывать WTRU осуществлять измерения, второй набор триггеров может предписывать WTRU выдать отчет об измерениях, и третий набор триггеров может предписывать WTRU автономно активировать и/или деактивировать уровень. Первый, второй и/или третий наборы триггеров могут отличаться друг от друга, могут частично перекрываться и/или могут полностью перекрываться (например, триггеры для осуществления измерений могут быть идентичны триггеру для выдачи отчета об измерениях). Различные комбинации триггеров - хотя совместно описаны здесь - находятся в заявленном объеме этого раскрытия.

В одном примере, WTRU может быть выполнен с возможностью активации или использования более чем одного экземпляра MAC (или уровня) в определенное время. Например, первый экземпляр MAC может быть активен и конфигурирован для передачи/приема по первичному уровню, и второй экземпляр MAC может быть активен и конфигурирован для передачи/приема по вторичному уровню. Разные экземпляры MAC могут быть одновременно активны в некоторые моменты времени, тогда как один экземпляр MAC может быть активен в другие моменты времени.

WTRU может осуществлять деактивацию уровня. Например, WTRU может принимать сигнализацию управления, которая деактивирует определенную соту определенного уровня (например, первичную соту (P-соту) на уровне, вторичную соту (S-сота) на уровне, и т.д.) множество сот определенного уровня и/или все соты определенного уровня. WTRU может быть выполнен с возможностью осуществления агрегации несущих на разных уровнях, например, таким образом, что WTRU может передавать и/или принимать данные из множества сот, связанных с уровнем. Однако, в отличие от многоуровневой передачи с использованием множества трактов данных, агрегация несущих может отличаться тем, что каждая из передач, отправленных из соты/несущей, агрегируется путем планирования одним и тем же объектом, или может планироваться независимыми объектами скоординированным образом (например, может существовать интерфейс связи с низкой задержкой между объектами планирования). Для передачи по разным уровням или трактам данных, независимые объекты планирования лишены тесной координации и/или могут осуществлять связь по линии связи, задержка которой затрудняет и/или делает непрактичной координацию планирования WTRU между уровнями. P-сота может означать первичную соту уровня, которая может быть сотой, посредством которой конфигурируется или устанавливается агрегация несущих для уровня. Каждый уровень может дополнительно использовать одну или более S-сот, которые могут быть сотами/несущими агрегации несущих, связанными с уровнем. P-сота может использоваться для планирования передач на S-соте и/или передачи можно планировать непосредственно через S-соту. WTRU может быть выполнен с возможностью автономной деактивации P-сот и/или S-сот, например, по истечении таймера после периода неактивности планирования для рассматриваемой соты.

Формирование RRC-соединения может устанавливать один или более радиоканалов-носителей сигнализации (SRB) между WTRU и сетью, например таким образом, что каждый из установленных SRB можно назначать одному или более из первого радиоинтерфейса или второго радиоинтерфейса. Данные управления, принятые WTRU, по, могут быть включены в один или более протокольных блоков данных (PDU) RRC. PDU RRC может быть связан с одним из одного или более SRB. В одном примере, PDU RRC может приниматься по первому радиоинтерфейсу либо второму радиоинтерфейсу независимо от связанного с ним SRB. В другом примере, PDU RRC может приниматься по назначенному радиоинтерфейсу, связанному с соответствующим SRB. RRC-соединение может управляться сетью. Сеть может содержать контроллер облачной радиосети (RCNC), который управляет RRC-соединением. WTRU может передавать в сеть указание, указывающее, что WTRU поддерживает операцию множественного планирования.

В одном примере, WTRU может быть выполнен с возможностью работы с использованием одного или более SRB, связанных с MeNB или сотами, обслуживаемыми MeNB (например, могут именоваться macro(SRB)), одного или более SRB, связанных с SCeNB или сотами, обслуживаемыми SCeNB (например, могут именоваться sc(SRB)), одного или более радиоканалов-носителей данных (DRB), связанных с MeNB или сотами, обслуживаемыми MeNB (например, могут именоваться macro(DRB)), и/или одного или более DRB, связанных с SCeNB или сотами, обслуживаемыми SCeNB (например, могут именоваться sc(DRB)). В одном примере, WTRU может устанавливать macro(SRB) с MeNB и устанавливать sc(SRB) и sc(DRB) с SCeNB.

Например, экземпляр MAC на WTRU может быть конфигурирован и активен для вторичного уровня, и может использоваться данные как для плоскости пользователя (например, sc(DRB)), так и плоскости управления (например, sc(SRB)). В некоторых сценариях, передача и/или прием могут более часто осуществляться с использованием SCeNB, поэтому вторичный уровень можно рассматривать как основной уровень для осуществления процедур передачи/приема данных плоскости управления и/или данных физического уровня. Даже когда большинство передач данных отправляется через SCeNB, WTRU все же может конфигурировать экземпляр MAC для первичного уровня, который, например, можно использовать для данных плоскости управления (например, для трафика, который может отправляться через любой уровень, для трафика, который может отправляться только посредством первичного уровня и т.д.). В некоторых сценариях, экземпляр MAC первичного уровня может быть активен в то же время, что и вторичный уровень экземпляр MAC, который может именоваться возможностью двойного соединения MAC. macro(SRB) может использоваться для передачи информации управления относительно высокой важностью, поэтому в некоторых примерах WTRU может быть выполнен с возможностью отказываться от деактивации P-соты первичного уровня (и/или всего первичного уровня) чтобы гарантировать своевременную передачу данных macro(SRB). Однако в других примерах такая информация управления может доставляться через вторичный уровень, поэтому в течение периодов неактивности первичный уровень может быть деактивирован и/или может работать согласно принципам режима ожидания для экономии мощности и сетевых ресурсов. В, WTRU может быть выполнен с возможностью периодически или с перерывами отслеживать канал управления (например, PDCCH для команд канала произвольного доступа (RACH), канал поискового вызова и т.д.), даже если вторичный уровень активен и/или если первичный уровень деактивирован.

В одном примере, WTRU может быть выполнен с возможностью обмена данными плоскости управления с использованием первичного уровня (например, через macro(SRB)) и данными плоскости пользователя через вторичный уровень (например, через sc(DRB)). Такой сценарий может быть в случае, когда, например, WTRU разгружен с MeNB на SCeNB для переноса данных. Экземпляр MAC, который конфигурирован и активен для первичного уровня, может использоваться, оставаясь активным, и использоваться для передачи информации управления. Экземпляр MAC может быть конфигурирован и активен для вторичного уровня и может использоваться для переноса данных плоскости пользователя. macro(SRB) может использоваться для передачи информации управления относительно высокой важностью, поэтому в некоторых примерах WTRU может быть выполнен с возможностью отказываться от деактивации P-соты первичного уровня (и/или всего первичного уровня) чтобы гарантировать своевременную доставку данных macro(SRB). Однако в других примерах такая информация управления может доставляться через вторичный уровень, поэтому в течение периодов неактивности первичный уровень может быть деактивирован и/или может работать согласно принципам режима ожидания для экономии мощности и сетевых ресурсов. В качестве примера, WTRU может быть выполнен с возможностью периодически или с перерывами отслеживать канал управления (например, PDCCH для команд канала произвольного доступа (RACH), канал поискового вызова и т.д.), даже если вторичный уровень активен и/или если первичный уровень деактивирован.

Независимо от того, как данные и информация управления переносятся на WTRU (например, через один или более из первичных и/или вторичных уровней), WTRU может быть выполнен с возможностью поддерживать или сохранять конфигурационную информацию для каждого из уровней/экземпляров MAC даже после деактивации экземпляра MAC. Например, WTRU может быть выполнен с возможностью сохранения конфигурации для первичного уровня даже после деактивации первичного уровня. Таким образом, WTRU может быть способен быстро возвращаться на макроуровень даже если он был деактивирован. Быстрое возвращение на макроуровень может позволять быстрое восстановление после сбоя линии радиосвязи (RLF) на вторичном уровне и может помогать избегать сбоев линии радиосвязи в сценариях передачи обслуживания между малыми сотами.

Сигнализация RRC может использоваться для конфигурирования работы первичного уровня и/или вторичного уровня. Конфигурация уровня может включать в себя одну или более из конфигурационной информации PHY, конфигурационной информации MAC, конфигурационной информации RLC, конфигурационной информации PDCP, конфигурационной информации радиоканала-носителя (RB), информации временного идентификатора радиосети соты (C-RNTI) и т.д. Конфигурационная информация, обеспеченная для первичного уровня, может включать в себя полный набор конфигурационной информации (например, конфигурационную информацию PHY, конфигурационную информацию MAC, конфигурационную информацию RLC, конфигурационную информацию PDCP, конфигурационную информацию RB, информацию C-RNTI и т.д.) что позволяет WTRU осуществлять процедуры передачи и приема на первичном уровне. В одном примере, WTRU также может быть конфигурирован поднабором конфигурационной информации для передачи и приема на вторичном уровне. Например, WTRU может быть конфигурирован конфигурационной информацией MAC, конфигурационной информацией RLC, конфигурационной информацией PDCP и поднабором информации ресурсов/конфигурации уровня PHY, подлежащим использованию на вторичном уровне. Другая конфигурационная информация, например оставшаяся информация ресурсов/конфигурации уровня PHY (например, конфигурационная информация PUCCH и т.д.) может быть включена в сообщение переконфигурирования, которое отправляется для активации вторичного уровня. Таким образом, WTRU может быть заранее конфигурирован большей частью конфигурационной информации для использования вторичного уровня, и определенная конфигурационная информация может обеспечиваться после активации (например, чтобы гарантировать, что конфигурация не конфликтует с текущей конфигурацией, используемой на первичном уровне).

Конфигурация первичного уровня может включать в себя полную конфигурационную информацию, связанную с работой как SRB, так и DRB на этом уровне, или может включать в себя поднабор конфигурации (например, только SRB). Поднабор конфигурации может позволять WTRU осуществлять один или более из приема данных, связанных с SRB, приема сообщения переконфигурирования RRC, осуществлять передачу обслуживания и/или осуществлять процедуру переконфигурирования.

WTRU может быть выполнен с возможностью, после приема конфигурации для второго уровня (и/или оставшейся конфигурационной информации, например, информации PHY, которая не была обеспечена как часть начальной предварительной конфигурации), неявно определять необходимость активации второго уровня, и может начинать использовать вторичный уровень как активный уровень. WTRU может сохранять конфигурацию для первичного уровня после активации вторичного уровня, что позволяет повторно активировать первичный уровень в более позднее время. В другом примере, WTRU может неявно предполагать, что первичный уровень является активным уровнем (и сохранять контекст неактивных уровней в памяти для дальнейшего использования), если сеть явно не указывает, что другой уровень является активным уровнем. Контекст, хранящийся на WTRU для неактивного уровня, можно считать действительным, пока он явно не удален сетью. Конфигурационную информацию можно считать действительной в течение заданного периода времени. Конфигурационную информацию для вторичного уровня можно удалять после перехода на другой вторичный уровень и/или после перехода на первичный уровень.

При работе с использованием вторичного уровня, WTRU может сохранять контекстную/конфигурационную информацию первичного уровня и рассматривать первичный уровень как деактивированный и/или в режиме ожидания. В одном примере, вместо того, чтобы полностью деактивировать первичный уровень, WTRU может иметь конфигурацию независимого прерывистого приема (DRX), чтобы контекст первичного уровня оставался актуальным. В течение периода DRX, WTRU может периодически проверять соты, связанные с первичным уровнем, для передач (например, считывать PDCCH). WTRU может отслеживать деактивированный уровень в ходе активных периодов цикла DRX, даже если он активно отслеживает/использует другой уровень. WTRU также можно обеспечить явным указанием, какой уровень первоначально активен во время приема конфигурационной информации RRC. Таким образом, информация переконфигурирования RRC-соединения может включать в себя конфигурационную информацию для множества уровней и может дополнительно указывать, какой из уровней первоначально активен. Затем WTRU может сохранять конфигурационную информацию для неактивных уровней для дальнейшего использования, используя конфигурацию активного уровня для осуществления процедур приема и передачи.

Один или более триггеров могут предписывать WTRU активировать первичный уровень, активировать неактивный уровень, и/или сообщать информацию качества для одного или более уровней. Например, пока WTRU работает с вторичным уровнем как с активным уровнем, WTRU может быть вынужден использовать первичный уровень (или возвращаться к нему) (например, для передачи и/или приема плоскости пользователя и/или плоскости управления) для приема сообщения переконфигурирования RRC. Например, сообщение переконфигурирования RRC может указывать, что WTRU должен осуществлять передачу обслуживания, может помогать WTRU избегать сбоя линии радиосвязи, может облегчать осуществление быстрого переустановления к первичному уровню и/или т.п. Переключение на первичный уровень может быть временным (например, WTRU может переключаться обратно после приема данных плоскости управления), и WTRU может быть выполнен с возможностью использования P-соты первичного уровня для приема данных плоскости управления.

В одном примере, WTRU может принимать из сети явную, динамическую сигнализацию, которая предписывает WTRU переключать уровни, активировать определенный уровень и/или деактивировать определенный уровень. Например, порядок PDCCH и/или PDU управления MAC (например, элементы управления MAC (CE)) могут использоваться для предписания WTRU переключать уровни, активировать уровень и/или деактивировать уровень. В порядке примера, WTRU может принимать порядок PDCCH или PDU управления MAC, который указывает, что WTRU должен деактивировать активный в данный момент экземпляр MAC (например, уровень) и/или активировать другой экземпляр/уровень MAC. Явное указание активации может явно указывать, какой уровень следует активировать, или WTRU может неявно определять, какой уровень подлежит активации.

Различные неявные критерии могут использоваться WTRU для определения необходимости активации неактивного уровня/уровня ожидания (например, первичного уровня), переключения на неактивный уровень/уровень ожидания (например, первичный уровень) и/или деактивации определенного уровня. Например, WTRU может начинать мониторинг ранее неактивного (например, начинать считывание или мониторинг PDCCH неактивного уровня с использованием сохраненного C-RNTI для неактивного уровня) на основании обнаружения различных критериев. В одном примере, хотя WTRU может начинать некоторую обработку/мониторинг неактивного уровня на основании обнаружения неявных триггеров, WTRU может быть выполнен с возможностью отказываться от переключения на уровень или полной активации уровня, пока из сети не будет принято явное указание делать это (например, через порядок PDCCH или PDU управления MAC).

Например, качество нисходящей линии связи, наблюдаемое WTRU, может использоваться в качестве неявных критериев для определения необходимости начинать мониторинг (например, частичный мониторинг) неактивного уровня и/или сообщать в сеть указание качества нисходящей линии связи неактивного уровня. Можно описать следующие критерии того, чтобы WTRU начал отправлять отчет об измерении для неактивного уровня; однако такие триггеры также можно использовать для предписания WTRU начинать мониторинг неактивного уровня (например, мониторинг PDCCH соты на неактивном уровне). Дополнительно, такие критерии также могут быть применимы для предписания WTRU активировать и/или деактивировать уровень.

Например, WTRU может отслеживать качество нисходящей линии связи одного или более уровней, для которых он принял конфигурационную информацию, но которые в данный момент не активны. Может существовать один или более триггеров, которые предписывают WTRU осуществлять измерения на соте, связанной с неактивным уровнем (например, такие триггеры также могут предписывать WTRU начинать мониторинг соты для передач, активировать и/или деактивировать различные соты и/или т.п.). Например, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем, когда бы ни запускался отчет об измерении (например, для другого уровня/соты или для неактивного уровня/соты). В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем на основании заданного происходящего события (например, передачи обслуживания, события, указанного в конфигурации, и т.д.).

WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), когда отчет об измерении запускается на активном уровне (например, вторичном уровне), и качество активного уровня ниже заданного порогового значения (например, указывающего, что WTRU теряет покрытие на активном уровне). Например, WTRU может определять, что качество активного уровня снижается и/или что измерения следует осуществлять на неактивном уровне на основании одного или более из измерений мощности принятого опорного сигнала(RSRP) для активного уровня, падающего ниже порогового значения, измерений качества принятого опорного сигнала (RSRQ) для активного уровня, падающего ниже порогового значения, определения, что индикатор качества канала (CQI) для соты, связанной с активным уровнем ниже порогового значения, определения, что CQI для обслуживающей соты активного уровня (например, обслуживающей соты для SCeNB) ниже порогового значения, и определения, что CQI для не обслуживающей соты активного уровня (например, какой-либо другой соты, связанной с SCeNB) превышает пороговое значение, и/или WTRU запускает таймер T301 (например, после обнаружения ухудшений условий линии радиосвязи).

В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании отчета об измерении, указывающего, что наилучшая сота (например, сота наивысшего качества) на активном в данный момент уровне (например, вторичном уровне) изменилась. WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем, на основании отчета об измерении, указывающего, что наилучшая сота (например, сота наивысшего качества) на первичном уровне изменилась. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании запуска или отправки отчета об измерении и рассинхронизации активного экземпляра MAC (например, после запуска T310 и/или после запуска T311 и т.д.). WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании неудачного приема команды передачи обслуживания в течение заданного периода времени, когда качество активного уровня ниже порогового значения.

В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем) на основании обнаружения условия рассинхронизации на активном уровне и/или на основании обнаружения заданного количества условий рассинхронизации на активном уровне. WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании обнаружения условия рассинхронизации на активном уровне в течение периода времени, конфигурированного сетью и/или на основании обнаружения условия рассинхронизации определенного количества таймеров в заданном окне. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании обнаружения одного или более из RLF DL и/или RLF UL на активном уровне. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем) на основании потери WTRU временного выравнивания с активным в данный момент уровнем (например, истечения таймера временного выравнивания (TAT), например, в котором TAT P-соты активного уровня истекает, если множество групп предварительного хронирования конфигурировано для рассматриваемого уровня). В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании обнаружения сбоя запроса планирования (SR). Например, WTRU может попытаться переустановить возможность соединения на неактивном уровне (например, первичном уровне), прежде чем пытаться осуществить процедуры переустановления RRC-соединения на активном в данный момент уровне. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровне), на основании превышения порогового значения качества неактивного уровня в течение конфигурированного периода времени. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем, на основании качества обслуживающей соты первичного уровня или качества обслуживающей соты активного уровня, который ниже порогового значения, и отсутствия других сот, уровень которых превышает пороговое значение (например, активный уровень теряет покрытие).

В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем) на основании приема команды деактивации для активного уровня (например, которая может быть неявной активацией первичного уровня). В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании приема WTRU сообщения переконфигурирования RRC (например, сообщение может деконфигурировать или деактивировать активный уровень. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании того, что оцененная скорость изменения качества канала на активном (например, вторичном уровне) превышает пороговое значение (и/или становится выше порогового значения) в течение конфигурированного периода времени. Например, скорость изменения канала можно оценивать путем измерения опорного сигнала, передаваемого из активного (например, вторичного) уровня. Другая мера скорости изменения канала могут базироваться на зоне Доплера канала и/или абсолютном значении доплеровского сдвига канала. Оцененная скорость изменения канала может быть пропорциональна (и основываться на) мультипликативно обратной величине времени когерентности канала. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании того, что оцененная скорость изменения усредненных потерь на тракте вследствие замирания на активном в данный момент (например, вторичном) уровне превышает пороговое значение (или становится выше порогового значения) в течение конфигурированного периода времени. Например, скорость изменения усредненных потерь на тракте вследствие замирания можно оценивать путем вычитания усредненного по времени уровня принятой мощности опорного сигнала первого временного окна из соответствующего уровня предыдущего временного окна. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании приема от RLC указания, что достигнуто максимальное количество повторных передач. В одном примере, WTRU может быть выполнен с возможностью осуществления измерений на соте, связанной с неактивным уровнем (например, первичным уровнем), на основании приема от MAC указания проблемы произвольного доступа.

WTRU может начинать мониторинг PDCCH, связанного с первичным уровнем или неактивным уровнем с использованием сохраненного C-RNTI на основании обнаружения одного или более из условий, используемых для запуска измерений неактивного уровня. Однако, в одном примере, WTRU может отказываться от переключения на неактивный уровень и/или от осуществления полной активации неактивного уровня, пока не принято явное указание (например, через порядок PDCCH и/или PDU управления MAC), указывающее, что следует осуществлять переключение или активацию.

WTRU может быть конфигурирован конфигурацией измерения, которая используется для определения параметров для использования при осуществлении измерений. Например, конфигурация измерения может быть общей для всех сот на уровне, общей для всех сот в кластере (например, если используются кластеры), конфигурированных отдельно для обслуживающих и необслуживающих сот для каждого уровня, и/или конфигурированных отдельно для каждой соты на определенном уровне. Например, WTRU может быть конфигурирован соответствующими опорными сигналами (CSI-RS) информации состояния канала нулевой мощности для разных сот/уровней для измерений CQI. WTRU может быть выполнен с возможностью усреднения периода времени, таким образом, что измерения осуществляются и фильтруются по периоду усреднения. WTRU может быть конфигурирован идентификатором узла, на который следует отправлять отчет (например, MeNB, SCeNB и т.д.). WTRU может быть выполнен с возможностью периодически использовать выдачу отчета об измерении и/или может быть конфигурирован одним или более триггеров для отправки апериодических отчетов (например, пороговых значений качества канала для запуска отчета).

Сеть может подавать на WTRU конфигурации измерения, зависящие от уровня. Например, принятая/ый конфигурация или параметр конфигурации может явно указывать, к какому уровню применима конфигурация. В одном примере, конфигурация измерения может указывать ID кластера, к которому применима конфигурация измерения. Конфигурация измерения может включать в себя список сот, для которых WTRU может осуществлять выдачу отчета об измерении на определенном уровне, и/или которые может отслеживать WTRU. Конфигурация измерения может указывать цикл измерений, подлежащий использованию для измерения сот в уровне на основании активации и/или деактивации другого уровня. Например, активация соты на первом уровне может запускать более частые измерения (например, быстрый цикл измерений) для соседних сот. Конфигурация измерения может включать в себя список разрешенных сот, которые соседствуют с сотами для конфигурированной малой соты. В одном примере, если малая сота активирована (например, активирован уровень малых сот), WTRU может прекращать использование цикла измерений measCycleSCell (например, цикла измерений, обычно используемого для S-сот в деактивированном состоянии), и может использовать другой (например, более быстрый) цикл измерений. В одном примере, активация первой соты может запускать уменьшающее масштабирование measCycleSCell до меньшего значения.

WTRU может быть выполнен с возможностью сообщения информации измерения для каждой соты, которую он в данный момент отслеживает, для поднабора сот и/или для одного или более кластеров сот. Например, какие соты измерять, можно определять на основании идентификатора кластера соты, которая запустила отчет, и/или соты, для которой сообщается измерение. Например, WTRU может быть конфигурирован черным списком/белым списком для определения, какие события инициируют выдачу отчета об измерении для сот в определенном кластере. Например, отчет об измерении может запускаться для соты в первом кластере, если запуск основан на критериях, связанных с сотой другого кластера (например, при измерении межкластерной мобильности). В одном примере, WTRU может быть конфигурирован идентификатором кластера таким образом, что WTRU измеряет каждую из сот в кластере, если измерения запускаются для любой соты в кластере.

WTRU может отправлять отчет измерений качества на основании обнаружения триггера для периодического и/или апериодического измерения неактивной соты, (например, по запросу сети). Отчет может отправляться на узел сети на первичном и/или вторичном уровне. Например, если WTRU обнаруживает триггер, который можно использовать для запуска измерения неактивного уровня/соты, WTRU может отправлять отчет об измерении в сеть, и отчет об измерении может указывать, что запустило отчет. WTRU может отправлять отчеты об измерениях периодически, например, конфигурируя и настраивая таймер, подлежащий использованию для запуска передачи периодического отчета. Сеть может отправлять запрос на отчет об измерении. Апериодический запрос на измерение может отправляться на WTRU, например, с использованием одного или более из порядка PDCCH, PDU управления MAC и/или запроса на измерение RRC. Апериодические запросы могут приниматься из первичного уровня (например, связанного с MeNB) и/или вторичного уровня (например, связанного с SCeNB). Например, MeNB может запрашивать отчет об измерении для сот, принадлежащих любому уровню (например, первичному уровню и/или вторичному уровню). В порядке примера, SCeNB может отправлять запрос на измерение, который указывает, что WTRU должен отправить отчет об измерении на MeNB (например, через RRC). SCeNB может отправлять запрос на основании обнаружения ухудшения качества линии радиосвязи (например, на основании качества RL UL, отчетов CQI, принятых для вторичного уровня, которые ниже порогового значения, и т.д.). Запрос на отчет об измерении может отправляться с использованием сигнализации PHY, MAC и/или RRC. В одном примере, запрос может отправлять SCeNB, например, с использованием CE MAC.

WTRU может обеспечивать измерения и/или указание качества соты/уровня с использованием одного или более из сообщения RRC, сообщения управления MAC и/или сообщения уровня 1 (PHY). Например, выбранные измерения могут отправляться в отчете об измерении RRC и/или как часть запроса на установление/переустановление RRC. Сообщение управления MAC (например, элемент управления MAC) может использоваться для отправки измерений. Например, CE MAC может использоваться для отправки информации измерения для каждой сообщаемой соты совместно с ID соты, связанным с измерением (например, измерения можно связывать с сотой с использованием SCellIndex). Если используется выдача отчета уровня 1 (PHY), отчет может передаваться через PUCCH.

Для каждого/й сообщаемого/й уровня/соты, WTRU может отправлять один или более из RSRP всех сообщаемых сот, RSRP сот из белого списка выдачи отчета, и/или RSRP сот в заданном кластере, для которого осуществляется отчет. В одном примере, для каждого/й сообщаемого/й уровня/соты WTRU может отправлять один или более из RSRQ всех сообщаемых сот, RSRQ сот из белого списка выдачи отчета, и/или RSRQ сот в заданном кластере, для которого осуществляется отчет. Отчет может включать в себя одно или более из значения CQI, измеренного для соты, идентификатора соты, запустившей отчет; списка DRB, обслуживаемых уровнем, который испытывает сбой, и/или указание синхронизации/рассинхронизации.

WTRU может быть выполнен с возможностью и/или запрашивания сетью для отправки отчета об измерении различными способами. Например, если WTRU выполнен с возможностью отправки отчета через первичный уровень, и на первичном уровне возникает сбой, отчет может отправляться на другом активном уровне. Например, отчет может отправляться на активную малую соту, и узел малой соты может пересылать его на MeNB с использованием магистральной линии связи. В одном примере, WTRU может быть выполнен с возможностью выдачи отчета об измерениях на первичный уровень, который может быть связан с macro eNB. В одном примере, отчет может отправляться как на первичный уровень, так и на активный вторичный уровень и/или все активные уровни. В одном примере, отчет может отправляться через сообщение RRC на первичный уровень (например, макроуровень), и MeNB может пересылать информацию на другие уровни, которые могут использовать отчет. Отчет об измерении может отправляться на тот же узел, откуда был принят запрос. Узел, на который следует отправлять отчет об измерении, может быть конфигурирован и/или указан принятой конфигурацией выдачи отчета об измерении. Если выдача отчета об измерении осуществляется по RRC, то если вторичный RRC используется вторичным уровнем (например, соединенным через SCeNB), можно выбирать надлежащий SRB для отправки информации измерения.

В одном примере, если WTRU обнаруживает, что условия линии радиосвязи упали ниже конфигурированного порогового значения на уровне малой соты, WTRU может отправлять отчет об измерении на MeNB на другом уровне. Например, если CQI активного уровня малых сот меньше конфигурированного порогового значения, WTRU может быть вынужден отправить в сеть указание в отношении условий радиосвязи.

В другом примере, триггером для отправки информации измерения на первичный уровень может быть получение явной сигнализации, отправленной eNB малой соты, например, с использованием CE MAC. Например, если SCeNB обнаруживает, что измерение CQI WTRU упало ниже порогового значения, он может отправлять триггер на RRC WTRU для отправки апериодического отчета об измерении RRC на MeNB на другом уровне (например, макроуровне). В одном примере, SCeNB непосредственно отправлять указание по магистрали на MeNB или пересылать отчет об измерении от WTRU на Macro.

В одном примере, конфигурация измерения может включать в себя список разрешенных сот. Например, разрешенные соты могут образовывать список сот, которые соседствуют с сотами для конфигурированной малой соты. Если малая сота/уровень малой соты активируется, соседние соты могут прекращать использовать частоту измерения, заданную параметром конфигурации measCycleSCell (например, цикл измерений для S-сот в деактивированном состоянии), и может начинать использовать другой (например, более быстрый) цикл измерений. В одном примере, активация одной соты может запускать уменьшающее масштабирование частоты цикла измерений (например, уменьшающее масштабирование measCycleSCell) до меньшего значения. В одном примере, SCeNB может отправлять команду на WTRU для запрашивания апериодического отчета об измерении CQI для отправки на MeNB (например, по RRC). Например, апериодическое измерение CQI может запускаться, если SCeNB обнаруживает ухудшение условий канала восходящей линии связи.

Когда WTRU обнаруживает один или более из триггеров для осуществления измерений и/или выдачи отчета о них, WTRU может определять необходимость активации и/или деактивации уровня на основании обнаружения триггера. Например, после определения необходимости активации экземпляра MAC первичного уровня на основании обнаружения триггера для осуществления измерений или выдачи отчета о них, WTRU может поддерживать вторичный экземпляр MAC как активный. В другом примере, после активации первичного уровня, WTRU может деактивировать вторичный уровень. В одном примере, один или более из триггеров для осуществления измерений и/или выдачи отчета о них может предписывать WTRU активировать вторичный уровень. В одном примере, один или более из триггеров для осуществления измерений и/или выдачи отчета о них может предписывать WTRU деактивировать вторичный уровень, для которого качество линии радиосвязи ухудшилось. В одном примере, вместо непосредственной активации или деактивации определенного уровня на основании обнаружения одного или более из триггеров для осуществления измерений и/или выдачи отчета о них, WTRU может отправить в сеть указание, которое указывает, что триггер обнаружен. Затем WTRU может ожидать явного указания для активации неактивного уровня (например, первичного уровня) и/или деактивации активного уровня (например, вторичного уровня). Например, указание необходимости переключения или активации первичного уровня может передаваться на WTRU по PDCCH/MAC первичного уровня. WTRU может отслеживать PDCCH первичного уровня с использованием сохраненной конфигурации в течение определенного конфигурированного периода времени после обнаружения одного или более из триггеров осуществления измерения /выдачи отчета. Если таймер истекает, и никакого указания не принимается, WTRU может продолжать работать с вторичным уровнем как активным уровнем. Указание также может передаваться по PDCCH/MAC вторичного уровня или через сообщение RRC.

Когда WTRU обнаруживает один или более из триггеров для осуществления измерений и/или выдачи отчета о них, WTRU может инициировать процедуру RRC, например, процедура переустановления RRC-соединения. Процедура RRC может использоваться для указания сети, что один или более уровней деактивированы и/или активированы. Например, согласно одному или более из триггеров для осуществления измерений и/или выдачи отчета о них, WTRU может активировать первичный экземпляр MAC, например, с использованием сохраненного конфигурация. WTRU может инициировать запрос планирования на первичном уровне, например, с использованием RACH (например, RA-SR). Будучи запланированным, WTRU может передавать сообщение RRC (например, запрос на переустановление RRC-соединения), которое может включать в себя один или более из идентификатора контекста, идентификатора WTRU и/или другую информацию, которую сеть может использовать для определения идентификатора WTRU и соответствующей конфигурации для осуществления доступа к соте. Информация идентификатора может составлять часть конфигурации первичного уровня, ранее принятой WTRU.

WTRU может принимать сообщение конфигурации/структуры в ответ на сообщение RRC. Например, сообщение конфигурации/структуры может указывать, что WTRU должен повторно использовать один или более из контекста безопасности, C-RNTI, параметров PHY, параметров MAC, параметров RLC, параметров PDCP и т.д., заранее конфигурированных для использования на первичном уровне. В одном примере, если сообщение конфигурации/структуры явно не обеспечивает другие параметры или не указывает, что заранее конфигурированные параметры следует отбрасывать, WTRU может предположить, что ранее обеспеченные и сохраненные параметры действительны. Сообщение конфигурации/структуры может включать в себя дополнительные параметры конфигурации, которые могут дополнять или обновлять по меньшей мере часть сохраненной конфигурации для первичного уровня. Затем WTRU может осуществлять процедуру(ы) мобильности, связанную(ые) с конфигурированными (например, активными и/или подвешенными) DRB таким образом, что DRB можно пересвязывать с первичным уровнем. Если процедура RRC оканчивается неудачей, WTRU может освобождать сохраненную конфигурацию для первичного уровня и инициировать процедуру переустановления RRC, осуществлять начальный доступ и/или переходить в режим ожидания.

WTRU может быть выполнен с возможностью осуществления различных действий после активации первичного уровня. Например, если WTRU обнаруживает триггер (например, триггеры, описанные для инициирования измерений, выдачи отчета об измерении, активации/деактивации уровня и т.д.), WTRU может определять необходимость инициирования мониторинга PDCCH первичного уровня с использованием заранее конфигурированной конфигурационной информации, продолжая нормальную работу на вторичном уровне. В одном примере, WTRU может остановить мониторинг вторичного уровня после определения необходимости начать мониторинг PDCCH первичного уровня. В одном примере, WTRU может ожидать полной активации первичного уровня (например, вместо того, чтобы продолжать мониторинг PDCCH), пока WTRU не примет явный порядок PDCCH, который указывает, что WTRU следует активировать первичный уровень. Например, порядок PDCCH может указывать WTRU, что ему следует активировать первичный уровень с использованием заранее конфигурированного набора ресурсов для первичного уровня. Порядок PDCCH может конфигурировать WTRU выделенным ресурсом/преамбулой RACH для использования для начального доступа UL на первичном уровне. В одном примере, порядок PDCCH может соответствовать порядку PDCCH для процедуры RACH. WTRU может определять, что порядок PDCCH для процедуры RACH соответствует предписанию WTRU активировать первичный уровень. Порядок PDCCH также может приниматься на вторичном уровне и использоваться как триггер, предписывающий WTRU активировать первичный уровень.

На основании определения необходимости активации первичного уровня, WTRU может активировать и создавать экземпляр MAC, связанный с первичным уровнем, с использованием заранее конфигурированной конфигурационной информации. В рамках процедуры активации, WTRU может попытаться инициировать доступ UL к первичному уровню. Например, WTRU может инициировать процедуру произвольного доступа на первичной соте. Одно или более из заранее конфигурированной конфигурационной информации и/или сообщения динамический активации уровня (например, порядка PDCCH) может включать в себя одно или более из выделенной преамбулы/ресурса RACH для использования начальной процедуры доступа и/или специализированного C-RNTI, подлежащий использованию на первичном уровне.

WTRU может отправлять в сеть сообщение UL на первичном уровне, например, в рамках начальной процедуры произвольного доступа. Сообщение UL может включать в себя один или более из отчета о статусе буфера (BSR) для каналов-носителей, используемых на ранее активированном уровне, идентификации или указания предыдущего уровня, отчета о статусе PDCP для каналов-носителей, используемых на предыдущем уровне, идентификатора WTRU (например, C-RNTI первичного уровня, какого-либо другого уникального ID WTRU), сообщения переустановления RRC (например, указывающего причину сбоя на предыдущем уровне, и/или другой информации), и/или какого-либо другого сообщения RRC, которое указывает, что WTRU запрашивает переключение уровней и перенос каналов-носителей между уровнями (например, которое может указывать радиоканалы-носители, отчет о статусе буфера для каждого канала-носителя, расположенного на другом уровне, ID WTRU, контекст PDCP и отчет о статусе и/или ID предыдущего уровня и т.д.). Если WTRU использовал DRX на первичном уровне, WTRU может перейти к активному времени или к более короткому циклу DRX, и/или WTRU может отправить указание, что он перешел к приему в активное время. WTRU может отправлять SR, и передача SR может быть неявным указанием того, что WTRU находится в активном времени и пытается переключать уровни.

После активации первичного уровня WTRU может поддерживать вторичный уровень как активный или может деактивировать вторичный уровень. Деактивация вторичного уровня позволяет WTRU временно подвешивать работу вторичного уровня MAC. Пока вторичный уровень деактивирован, WTRU может не осуществлять передачу и/или прием на физическом уровне. WTRU может удалять конфигурацию вторичного уровня после явного указания из сети и/или после передачи обслуживания вторичного уровня. Если WTRU деактивирует вторичный уровень, он может удалить экземпляр MAC и освободить ресурсы PHY, связанные с вторичным уровнем. В другом примере, после активации первичного уровня WTRU может поддерживать вторичный уровень как активный и может продолжать нормальные процедуры приема/передачи на вторичном уровне.

WTRU может быть выполнен с возможностью, после активации первичного уровня, осуществлять одну или более процедур мобильности канала-носителя для переноса одного или более каналов-носителей или потоков данных на другой тракт данных (например, первичный уровень). Например, набор из одного или более SRB может конфигурироваться после активации первичного уровня и отображаться в первичный экземпляр MAC. Конфигурация SRB для использования после активации первичного уровня может быть включена в заранее конфигурированную конфигурационную информацию, сохраненную на WTRU. В одном примере, каналы-носители как плоскости управления, так и плоскости пользователя, используемые WTRU после активации первичного уровня, могут быть заранее конфигурированы и сохранены как конфигурационная информация для первичного уровня на WTRU. В одном примере, поднабор RB из вторичного уровня может переключаться и повторно отображаться в первичный уровень.

Радиоканалы-носители, которые ранее были активны на вторичном уровне, могут переноситься на первичный уровень, могут оставаться на вторичном уровне и/или могут освобождаться. Например, сеть может быть выполнен с возможностью осуществлять переконфигурирование и операции мобильности радиоканалов-носителей с одного уровня на другой. В порядке примера, если первичный уровень активирован, WTRU может подвешивать передачу/приема радиоканала-носителя на вторичном уровне, но оставлять/сохранять контекст канала-носителя для этого уровня для использования в будущем. В другом примере, когда первичный уровень активирован, WTRU может оставлять каналы-носители вторичного уровня активными и продолжать процедуры приема/передачи этих каналов-носителей, также передавая/принимая данные на макроуровне. Например, WTRU может быть выполнен с возможностью приема данных плоскости управления через макроуровень (например, но не данные плоскости пользователя) после активации макроуровня, или может принимать как данные плоскости управления, так и данные плоскости данных на вновь активированном макроуровне (например, конфигурированном сетью в информации предварительной конфигурации). WTRU может перемещать радиоканал-носитель из вторичного уровня на первичный уровень после приема сообщения переконфигурирования RRC либо на макроуровне, либо на вторичном уровне. Например, сообщение переконфигурирования RRC может приниматься как часть сообщения 4, когда активируется первичный уровень, и инициируется процедура RACH.

WTRU может осуществлять частичное переконфигурирование/мобильность радиоканала-носителя при первоначальной активации первичного уровня, (например, переносить SRB, но не DRB). WTRU может осуществлять частичное переконфигурирование/мобильность радиоканала-носителя (например, переносить SRB, но не DRB) после приема из сети явного указания (например, порядка PDCCH, управления MAC или ответа успешного произвольного доступа), указывающего, что один или более каналов-носителей подлежит переносу. WTRU может осуществлять полную мобильность радиоканала-носителя на первичный уровень, если выполнен с возможностью делать это, в информации предварительной конфигурации для первичного уровня.

В одном примере, WTRU может автономно инициировать мобильность радиоканала-носителя из вторичного уровня на первичный уровень и удалять контекст вторичного уровня. Автономная мобильность может базироваться на заранее конфигурированной информации, и/или WTRU может предполагать, что вторичный уровень следует деактивировать, если первичный уровень активирован, если сеть явно не указывает, что вторичный уровень должен остаться активным. После осуществления переключения DRB и/или SRB, либо посредством управляемых сетью, либо автономно осуществляемых WTRU процедур, WTRU может до процедуры RRC (например, процедуры переустановления RRC-соединения) применять и/или подтверждать повторные конфигурации RB.

Как упомянуто выше, WTRU может использовать соединение по множеству трактов данных по различным причинам. Например, множество обслуживающих участков можно использовать для достижения выигрышей в пропускной способности по данным (например, допуская межуровневую агрегацию ресурсов, доступных WTRU), обеспечения автономной мобильности WRTU (например, позволяющей WTRU определять и осуществлять доступ к сотам различных уровней, что может обеспечивать соединение наивысшего качества в любой определенный момент времени), что позволяет WTRU восстанавливать возможность соединения после сбоя (например, если WTRU обнаруживает RLF и/или снижение качества определенного уровня, WTRU может переключаться на другой уровень, например, без необходимости осуществлять процедуру переустановления), и/или для управляемой сетью мобильности (например, выгрузки трафика с одного уровня на другой и/или по другим причинам сетевого управления). Поскольку возможность соединения с разными обслуживающими участками может устанавливаться по разным причинам, триггеры и/или процедуры для осуществления доступа к вторичному обслуживающему участку и/или деактивированному уровню могут различаться в зависимости от цели соединения с участком множественного обслуживания. Например, если доступ к вторичному обслуживающему участку имеет целью достижение выигрышей в пропускной способности по данным, WTRU может поддерживать первичный обслуживающий участок в активированном состоянии после активации вторичного обслуживающего участка. Однако, если WTRU активирует вторичный обслуживающий участок в целях разгрузки макроуровня, WTRU может деактивировать первичный уровень после активации вторичного уровня. Аналогично, триггеры для осуществления измерений, отправки отчетов об измерениях, и/или активации и/или деактивации уровня может различаться в зависимости от цели осуществления операции на участке множественного обслуживания.

В порядке примера, рассмотрим случай, когда возможность двойного соединения с участком используется для достижения выигрышей в пропускной способности для WTRU. В этом примере, множество обслуживающих участков может использоваться по существу одновременно WTRU для увеличения объема данных, передаваемых и/или принимаемых WTRU. Например, WTRU первоначально может находиться в состоянии RRC_CONNECTED с одним уровнем. WTRU может принимать сообщение переконфигурирования, которое конфигурирует WTRU для осуществления доступа к одной или более сотам второго уровня. Переконфигурирование может активировать второй уровень, или переконфигурирование может заранее конфигурировать уровень для последующей активации. Например, если переконфигурирование конфигурирует WTRU для «возможности двойного соединения», оставляя одну или более сот добавленного уровня в деактивированном состоянии, WTRU может принимать конфигурацию измерения для осуществления измерений на сотах деактивированного уровня. Предварительная конфигурация может включать в себя информацию, указывающую обстоятельства, в которых WTRU может быть вынужден отправлять отчеты об измерениях на активный уровень и/или автономно активировать заранее конфигурированный уровень. Например, на основании обнаружения триггера, принятого в принятой конфигурации, и/или некоторого неявно определенного триггера, WTRU может инициировать одну или более процедур для выдачи отчета об измерениях качества в сеть (например, активированного уровня) что позволяет активному обслуживающему участку (например, объекту RRC) затем переконфигурировать (например, посредством RRC) и/или активировать (например, посредством CE MAC) одну или более сот деактивированного уровня. В одном примере, вместо или помимо того, чтобы вынужденно отправлять отчет об измерении, WTRU может быть выполнен с возможностью автономной активации одной или более сот деактивированного уровня на основании обнаружения одного или более триггеров, указанных при переконфигурировании и/или неявном определении. Например, WTRU может инициировать процедуру RACH в соте, подлежащей активации, для извещения сети об активации, получения временного выравнивания восходящей линии связи, получения выделенных ресурсов (например, запросить планирование) и/или установления конфигурации для осуществления доступа к соте. WTRU может поддерживать оба уровня активными по существу одновременно для увеличения общей пропускной способности по данным.

В одном примере, WTRU может быть выполнен с возможностью осуществления доступа к множеству уровней как часть мобильности, автономно осуществляемой на WTRU. Например, если вторичные обслуживающие участки соответствуют SCeNB, зона покрытия вторичных обслуживающих участков может быть относительно мала (например, по сравнению с MeNB). Однако SCeNB могут быть развернуты в кластерах, что обеспечивает возможность доступа к множеству SCeNB со стороны WTRU в относительно малой области. В этом случае, WTRU может быть выполнен с возможностью отслеживания различных SCeNB для определения, какой обслуживающий участок может обеспечивать наивысшее качество доступа к WTRU в определенный момент времени. Поскольку зона покрытия сот для этих обслуживающих участков может быть относительно ограниченной, WTRU может входить и/или выходить из зон покрытия чаще, чем в конфигурациях макросот. Таким образом, вместо того, чтобы опираться только на мобильность под управлением сети (например, передачу обслуживания под управлением сети, активацию уровня под управлением сети и т.д.), WTRU может быть выполнен с возможностью осуществления некоторых автономных процедур мобильности. Например, WTRU может быть выполнен с возможностью автономно переключаться с первого уровня (например, малой соты) на второй уровень (например, малую соту), активировать деактивированный уровень (например, малую соту), деактивировать активированный уровень (например, малую соту) и/или т.п.

Например, WTRU первоначально может находиться в состоянии RRC_CONNECTED, при этом осуществляя доступ одному или более уровням. WTRU может принимать и/или может иметь ранее принятым сообщение переконфигурирования, которое конфигурировало WTRU для осуществления доступа к одной или более сотам уровня, который в данный момент не активен. Например, WTRU может соединяться с первичным уровнем, связанным с MeNB, и первым вторичным уровнем, связанным с первым SCeNB. WTRU может иметь предварительные конфигурации для множества других вторичных обслуживающих участков, связанных с другими SCeNB. WTRU может быть конфигурирован конфигурацией измерения для осуществления измерений на сотах одного или более деактивированных уровней. Предварительная конфигурация может включать в себя информацию, указывающую обстоятельства, в которых WTRU может быть вынужден автономно активировать заранее конфигурированный уровень и/или деактивировать активный в данный момент уровень. Например, на основании обнаружения критериев, которые указывают, что деактивированный уровень малых сот имеет более высокое качество, чем текущий уровень малых сот (например, качество соты деактивированного уровня больше, чем качество соты активированного уровня на величину смещения и/или заданное пороговое значение), WTRU может быть выполнен с возможностью автономной активации одной или более сот деактивированного уровня и/или деактивации уровня малых сот, с которым осуществляется соединение в данный момент. В порядке примера, малые соты могут входить в состав кластера малых сот, и WTRU может авторизоваться сетью для осуществления автономной мобильности между малыми сотами в кластере. WTRU может инициировать процедуру RACH в соте, подлежащей активации, для извещения сети об активации, получения временного выравнивания восходящей линии связи, получения выделенных ресурсов (например, запросить планирование) и/или установления конфигурации для осуществления доступа к соте.

В одном примере, WTRU может быть выполнен с возможностью осуществления доступа к множеству уровней для поддержания возможности соединения в течение периодов, когда один или более уровней находятся в условиях низкого качества радиосвязи. Например, WTRU может быть выполнен с возможностью осуществления некоторой формы мобильности, автономно осуществляемой на WTRU, чтобы сбой линии радиосвязи на определенном уровне не препятствовал WTRU в осуществлении связи с сетью или ином поддержании его соединения с сетью. Например, WTRU, определив ухудшение соты (например, P-соты) вследствие сбоя на активном уровне (например, WTRU обнаруживает проблемы с линией радиосвязи; WTRU определяет RLF UL и/или RLF DL; измеренное качество сигнала падает ниже порогового значения, и т.д.), может предпринимать одно или более действий на другом уровне для поддержания непрерывности сеанса. Например, WTRU первоначально может находиться в состоянии RRC_CONNECTED, при этом осуществляя доступ одному или более уровням. WTRU может принимать и/или может иметь ранее принятым сообщение переконфигурирования, которое конфигурировало WTRU для осуществления доступа к одной или более сотам уровня, который в данный момент не активен. WTRU может иметь предварительные конфигурации для множества других обслуживающих участков и может быть выполнен с возможностью их автономной активации. WTRU может осуществлять RLM на одной или более сот (например, P-соте) активного уровня. UE может определять, что он испытывает ухудшение (например, потери при соединении с рассматриваемой сотой), например, одну или более из проблем с линией радиосвязи, условий рассинхронизации, RLF UL, RLF DL и/или т.п. на основании обнаружения неблагоприятных условий канала, WTRU может инициировать процедуру для автономной активации одной (или более сот) первичного уровня (например, если ранее деактивированы) и/или какой-либо другой, деактивированной позже, и инициировать процедуру RACH для извещения сети о сбое другого уровня, для получения временного выравнивания UL первичного уровня, для получения выделенных ресурсов на первичном уровне, для получения конфигурации таких ресурсов; и/или для инициирования процедуры переконфигурирования для уровня, связанного со сбоем. WTRU может принимать переконфигурирование RRC с информацией управления мобильностью или без нее (например, переконфигурирование или команду HO) от первичного уровня (например, уровня, связанного с объектом RRC), которое переконфигурирует ресурсы, отображаемые в уровень, на котором произошел сбой. Например, ресурсы можно перемещать на первичный уровень и/или другой вторичный уровень.

В одном примере, WTRU может быть выполнен с возможностью осуществления доступа к множеству уровней для поддержки мобильности под управлением сети по множеству уровней. Например, WTRU может быть выполнен с возможностью информирования сети об обнаружении нового уровня (например, на основании измерений), что позволяет обслуживающему участку осуществлять управление соединениями под управлением сети. Например, WTRU первоначально может находиться в состоянии RRC_CONNECTED с одним уровнем. WTRU может принимать сообщение переконфигурирования, которое конфигурирует WTRU для осуществления доступа к одной или более сотам второго уровня. Переконфигурирование может активировать второй уровень, или переконфигурирование может заранее конфигурировать уровень для последующей активации. Например, если переконфигурирование конфигурирует WTRU для «возможности двойного соединения», оставляя одну или более сот добавленного уровня в деактивированном состоянии, WTRU может принимать конфигурацию измерения для осуществления измерений на сотах деактивированного уровня. Принятая конфигурация измерения может указывать критерии для определения, следует ли считать соту доступной и/или пригодный. Если сота отвечает критериям, WTRU может быть выполнен с возможностью выдачи отчета от измерениях сот этого уровня. Сеть может использовать сообщаемые измерения для запуска мобильности WTRU, например, путем отправки переконфигурирования RRC с информацией управления мобильностью или без нее (например, переконфигурирования и/или команды HO), которое указывает, что WTRU должен начать осуществление доступа к соте.

WTRU может быть выполнен с возможностью осуществления процедуры мобильности для одной или более обслуживающих сот обслуживающего участка. Например, обслуживающая сота вторичного обслуживающего участка может подвергаться другим процедурам мобильности, чем процедуры мобильности обслуживающей соты первичного обслуживающего участка, например, если объект RRC на стороне сети располагается на первичном обслуживающем участке. В одном примере, процедуры мобильности для одного или более RB (например, DRB, SRB и т.д.) могут осуществляться таким образом, что RB перемещаются из первого обслуживающего участка во второй обслуживающий участок. В порядке примера случай использования, RB может отображаться в первый вторичный обслуживающий участок, и WTRU может перемещаться таким образом, чтобы найти лучшее покрытие на другом вторичном обслуживающем участке (например, обслуживающем участке, обслуживаемом другим SCeNB). Способы и системы раскрыты для мобильности плоскости пользователя и/или плоскости управления, когда WTRU перемещает один или более каналов-носителей, отображаемых в первый вторичный обслуживающий участок, в другой вторичный обслуживающий участок (например, поддерживая при этом постоянное соединение с первичным обслуживающим участком, обслуживаемым MeNB).

В порядке примера возможных архитектур, в которых может быть полезна мобильность RB между обслуживающими участками, рассмотрим случай, когда экземпляр PDCP и экземпляр RLC на стороне сети могут располагаться в первичном обслуживающем участке (например, на вторичном обслуживающем участке может не быть экземпляров PDCP и/или на вторичном обслуживающем участке может не быть экземпляров RLC). В таком сценарии, для определенного RB DL-SCH и/или UL-SCH может быть доступен как в первичном обслуживающем участке, так и во вторичном обслуживающем участке (что, например, можно именовать объединенным RB) и/или DL-SCH и/или UL-SCH может быть доступен для передачи, связанной с вторичным обслуживающим участком, но не для первичного обслуживающего участка (например, хотя также могут быть применимы другие сценарии для отображений RB). В другом примере, экземпляр PDCP на стороне сети может располагаться в первичном обслуживающем участке (например, на вторичном обслуживающем участке может не быть экземпляров PDCP), но экземпляр RLC может существовать на каждом из первичного обслуживающего участка и вторичного обслуживающего участка. Аналогично, могут существовать соответствующие экземпляры PDCP и экземпляры RLC на каждом из первичного обслуживающего участка и вторичного обслуживающего участка. В любом случае, могут существовать сценарии или конфигурации, в которой для определенного RB DL-SCH и/или UL-SCH может быть доступен на вторичном обслуживающем участке, но не для первичного обслуживающего участка. Может не существовать других архитектур, в которых для определенного RB передача на первичный обслуживающий участок может быть недоступна.

Поскольку предполагается, что для по меньшей мере некоторых типов SCeNB зона покрытия может быть относительно ограниченной (например, меньше, чем у MeNB), мобильный WTRU может входить и/или выходить из зоны покрытия одной или более обслуживающих сот для вторичных обслуживающих участков. В таком случае, можно задавать процедуры передачи обслуживания для перемещения одного или более каналов-носителей между SCeNB и/или между SCeNB и MeNB. Эти операции передачи обслуживания могут не быть истинными операциями передачи обслуживания WTRU (например, причем весь контекст WTRU может переноситься из первого обслуживающего участка во второй обслуживающий участок), поскольку RRC-соединение может быть неизменным, например, в случае централизованного объекта управления (например, и/или первичное RRC-соединение может быть неизменным в случае скоординированных объектов управления или распределенных объектов управления). Раскрыты способы и системы для управления изменениями мобильности для RB, отображаемых в SCeNB, когда RRC-соединение с RCNC/MeNB может быть неизменным. В порядке примера, мобильность SCeNB (например, мобильность одного или более RB из первого вторичного обслуживающего участка во второй вторичный обслуживающий участок) можно описать как «мобильность плоскости пользователя» и/или «операции передачи обслуживания радиоканала-носителя данных».

Например, для поддержки мобильности SCeNB, WTRU может быть выполнен с возможностью измерения и/или обнаружения одной или более целевых сот. WTRU может быть выполнен с возможностью управлять, под управлением сети и/или автономно, передачей обслуживания между исходной сотой на первом обслуживающем участке и целевой сотой на втором обслуживающем участке. WTRU может быть выполнен с возможностью управления потоком данных UL и DL для поддержки работы без потерь и минимизации/устранения дублирования передаваемых данных.

Например, первичный обслуживающий участок (например, обслуживающий участок, связанный с MeNB и/или обслуживающий участок, в котором экземпляр RRC/первичный экземпляр RRC поддерживается на стороне сети), может быть выполнен с возможностью управления каналом-носителем и/или соединение мобильности для вторичных обслуживающих участков. Например, если используется централизованная архитектура управления, первичный обслуживающий участок может быть выполнен с возможностью управления мобильностью RB на одном или более вторичных обслуживающих участков с использованием RRC-соединения для WTRU. RCNC и/или MeNB может быть выполнен с возможностью координации мобильности вторичного обслуживающего участка с WTRU, исходного вторичного обслуживающего участка и/или целевого вторичного обслуживающего участка.

Например, первичный обслуживающий участок (например, RCNC и/или MeNB) может быть выполнен с возможностью запуска мобильности SCeNB на основании событий измерения, сообщаемых первичному обслуживающему участку. WTRU может быть конфигурирован RCNC и/или MeNB для обнаружения и выдачи отчета об описанных здесь событиях измерения. Например, WTRU может быть выполнен с возможностью сравнения качества потенциальных малых сот SCeNB и/или макросоты MeNB с малыми сотами SCeNB, с которыми он в данный момент осуществляет доступ.

В одном примере, первичный обслуживающий участок (например, RCNC и/или MeNB) может быть выполнен с возможностью запуска мобильности SCeNB на основании выдачи отчета по CQI от WTRU и/или качества приема SRS, ретранслируемого от SCeNB на MeNB. WTRU может быть выполнен с возможностью выдачи отчета CQI первичному обслуживающему участку и/или вторичному обслуживающему участку. WTRU может передавать SRS для множества малых сот, например, включающих в себя одну или более сот, на которые WTRU в данный момент не может активно передавать и/или от которых он не может активно принимать.

В одном примере, мобильность SCeNB на WTRU может инициироваться процедурой переконфигурирования RRC, запущенной RCNC и/или MeNB. Процедура переконфигурирования RRC может включать в себя отправку с MeNB на WTRU сигнализации, которая включает в себя один или более информационных элементов, которые указывают, что WTRU должен осуществлять ограниченную процедуру мобильности для определенных DRB без изменения соединения WTRU с первичным обслуживающим участком (например, указывают, что переконфигурирование предназначено для мобильности SCeNB). Например, один или более потоков данных (например, DRB) могут перемаршрутизироваться от вторичной обслуживающей соты, связанной с первым вторичным обслуживающим участком, на другую вторичную обслуживающую соту, связанную со вторым вторичным обслуживающим участком. Объем и тип информации, включенной в сообщение переконфигурирования, может зависеть от того, как тракты данных разделяются в сети (например, над RLC, над PDCP и т.д.). Например, сообщение переконфигурирования может явно указывать один или более из идентификатора одного или более радиоканалов-носителей, подлежащих перемещению, идентификатора SAP целевого обслуживающего участка, порядковых номеров передачи и приема для перемещаемых RB и т.д. Сообщения переконфигурирования могут указывать информацию доступа для осуществления доступа к целевой соте на новом вторичном обслуживающем участке. Например, информация доступа может включать в себя специализированную конфигурацию произвольного доступа и/или другую системную информацию целевой соты. В одном примере, WTRU уже может иметь один или более каналов-носителей, отображаемых в целевой обслуживающий участок, и процедура переконфигурирования может предназначаться для перемещения дополнительных каналов-носителей из другого обслуживающего участка в целевой обслуживающий участок.

Первичный обслуживающий участок (например, RCNC и/или MeNB) может заранее конфигурировать WTRU конфигурационной информацией для одного или более потенциальных целевых вторичных обслуживающих участков (например, SCeNB). Поскольку WTRU могут быть заранее конфигурированы информацией доступа для потенциальных целевых сот, связанных с разными вторичными обслуживающими участками (например, SCeNB), процедура мобильности может осуществляться с использованием процедур сигнализации RRC для конфигурирования и выполнения передачи обслуживания. Например, переключение соты WTRU может осуществляться путем включения и/или отключения (например, активации и/или деактивации) сот, связанных с одним или более SCeNB. Например, сигнализация управления MAC (например, CE MAC) может использоваться для инициирования переключения соты между множеством заранее конфигурированных сот вторичного обслуживающего участка. Дополнительно, хотя можно описать примеры мобильности между вторичными обслуживающими участками, раскрытые способы и системы в равной степени применимы к переключению потоков данных между одним или более вторичными обслуживающими участками (например, SCeNB) и первичным обслуживающим участком (например, MeNB).

В одном примере, вторичный обслуживающий участок может запускать мобильность потока данных и/или может помогать первичному обслуживающему участку в осуществлении мобильности потока данных. Например, если скоординированная архитектура управления и/или распределенная архитектура управления используются, некоторые функциональные возможности RRC-соединения могут управляться на вторичном обслуживающем участке. В таких сценариях, вторичные обслуживающие участки (например, SCeNB) могут быть выполнены с возможностью запуска и/или управления мобильностью вторичного обслуживающего участка (например, SCeNB) и/или может помогать первичному обслуживающему участку (например, MeNB) с мобильностью вторичных обслуживающих участков (например, SCeNB). Например, в скоординированной архитектуре управления и/или в распределенной архитектуре управления один или более SRB могут управляться вторичным обслуживающим участком таким образом, что вторичные обслуживающие участки (например, SCeNB) могут быть конфигурированы трактом прямой сигнализации управления на WTRU. Вторичный обслуживающий участок может использовать тракт управления для отправки сигнализации управления (например, сигнализации управления MAC), которую можно использовать в целях мобильность SCeNB (например, активации и/или деактивации вторичного обслуживающего участка).

Вторичные обслуживающие участки (например, SCeNB) может конфигурировать события измерения и принимать отчеты об измерениях от WTRU. WTRU может быть конфигурирован вторичным обслуживающим участком для обнаружения и выдачи отчета о событиях измерения. Например, WTRU может быть выполнен с возможностью сравнения качества потенциальных малых сот SCeNB и/или макросоты MeNB с малыми сотами SCeNB, с которыми он в данный момент осуществляет доступ.

Если вторичный обслуживающий участок определил необходимость запуска мобильности вторичного обслуживающего участка на основании отчетов об измерении RRC и/или другой информации (например, использования ресурсов, балансировки трафика и т.д.), то вторичный обслуживающий участок (например, SCeNB) может отправлять сообщение переконфигурирования RRC на WTRU, чтобы предписывать WTRU перенаправлять один или более потоков данных (например, DRB и/или SRB) в целевую соту, связанную с другим вторичным обслуживающим участком (например, SCeNB). В одном примере, вторичный обслуживающий участок (например, SCeNB) может информировать первичный обслуживающий участок (например, MeNB) о желаемой процедуре мобильности (например, по интерфейсу X2bis), и первичный обслуживающий участок может осуществлять процедуру переконфигурирования, которая запускает мобильность вторичного обслуживающего участка.

Можно определить способы и системы манипулирования данными для потоков данных, претерпевающих процедуру мобильности вторичного обслуживающего участка. Например, если WTRU осуществляет «передачу обслуживания вторичного обслуживающего участка» между сотами, связанными с разными вторичными обслуживающими участками (например, SCeNB) или между первичным обслуживающим участком (например, MeNB) и вторичным обслуживающим участком (SCeNB), WTRU может быть выполнен с возможностью управления передачей данных UL и DL таким образом, что данные, связанные с перемещаемым потоком данных, надлежащим образом манипулируются во избежание потери данных и/или минимизации/устранения дублирования передаваемых данных. Метод(ы), используемый(е) для минимизации негативного влияния мобильности вторичного обслуживающего участка на переносимый(е) поток(и) данных, могут зависеть от разделения уровня 2 между первичным обслуживающим участком (например, RCNC и/или MeNB) и вторичным обслуживающим участком (например, SCeNB). Например, разные методы, позволяющие избегать потери данных и/или минимизировать дублирование/повторную передачу данных может зависеть от того, разделяется ли стек протоколов для потоков данных над MAC, над RLC или над PDCP. Например, если разделение осуществляется над PDCP, то можно использовать процедуры, связанные с передачей обслуживания мобильности eNB X2 и PDCP. Если разделение осуществляется над RLC и/или над MAC, один или более дополнительных методов могут использоваться для переноса данных и координации передачи UL и/или DL в целевой соте.

Если разделение уровня 2 осуществляется над RLC и/или над MAC, то SDU, переносимые между первичным обслуживающим участком (например, RCNC и/или MeNB) и SCeNB, можно идентифицировать уникальными порядковыми номерами. Использование уникальных порядковых номеров для SDU, переносимых между первичным и вторичным обслуживающими участками, позволяет избежать потери данных и поддержать правильную последовательность передачи на DL и/или UL. Например, если разделение уровня 2 осуществляется над RLC, то можно использовать порядковые номера PDU PDCP. Если разделение уровня 2 осуществляется над MAC, то можно использовать порядковые номера RLC. Порядковые номера можно назначать SDU, передаваемым по интерфейсу X2bis.

Способы, которые можно использовать для манипулирования передачи в ходе мобильности SCeNB, могут объединяться с манипулированием управления потоками для передачи вторичного обслуживающего участка DL. Например, реализация управления потоками DL может использоваться для минимизации данных, буферизованных на вторичном обслуживающем участке (например, SCeNB), например, таким образом, что данные, отправляемые и возвращаемые по X2bis, можно минимизировать. Например, схема передачи на основе окна и/или схема передачи на кредитной основе может использоваться для идентификации передаваемых пакетов данных. Схема передачи на основе окна и/или схема передачи на кредитной основе может повторно использоваться после мобильности вторичного обслуживающего участка для идентификации данных, которые были или не были успешно квитированы WTRU.

Если происходит событие мобильности вторичного обслуживающего участка, то не квитированные данные могут пересылаться на целевой вторичный обслуживающий участок (например, SCeNB). Исходный вторичный обслуживающий участок (например, SCeNB) может пересылать не квитированные SDU на целевой вторичный обслуживающий участок (например, SCeNB) и/или указывать первичный обслуживающий участок (например, RCNC и/или MeNB) не квитированные порядковые номера и/или последний из последовательно доставляемого порядкового номера, таким образом, что первичный обслуживающий участок (например, RCNC и/или MeNB) может пересылать правильные SDU на целевой вторичный обслуживающий участок (например, SCeNB).

Если уровень 2 разделяется над RLC, и мобильность вторичного обслуживающего участка запускается, то на DL может предварительно формироваться достаточно PDU PDCP во избежание ограничения планирования DL вторичными обслуживающими участками (например, SCeNB). Объект PDCP DL в первичном обслуживающем участке (например, RCNC и/или MeNB) может не знать о статусе передачи этих PDU PDCP. Первичный обслуживающий участок может быть выполнен с возможностью определения статуса передачи PDU PDCP для снижения задержки передачи в ходе события мобильности вторичного обслуживающего участка.

Например, вторичный обслуживающий участок (например, SCeNB) может возвращать на первичный обслуживающий участок (например, RCNC и/или MeNB) SDU RLC DL, которые не были квитированы WTRU на уровне RLC. Порядковые номера SDU RLC, не принятых успешно, и/или порядковый номер доставляемого последним по порядку SDU RLC могут указываться первичному обслуживающему участку. Порядковые номера могут указывать статус передачи, когда происходит мобильность вторичного обслуживающего участка (например, SCeNB).

Указание порядковых номеров SDU RLC может осуществляться, когда вторичный обслуживающий участок (например, SCeNB) указывает SDU RLC, которые были квитированы равноправным объектом RLC, первичному обслуживающему участку (например, RCNC и/или MeNB), который может поддерживать буферизацию данных DL для RLC (например, на RCNC и/или MeNB). Такие способы, как протокол переноса на основе окна, реализация на кредитной основе и/или т.п. может использоваться для управления потоком SDU RLC. Первичный обслуживающий участок (например, RCNC и/или MeNB) может знать статус доставки SDU RLC. Статус доставки SDU RLC может использоваться после мобильности вторичного обслуживающего участка (например, SCeNB) для координации доставки данных DL на целевой вторичный обслуживающий участок (например, SCeNB). Указанными порядковыми номерами могут быть порядковый номер PDCP или другие порядковые номера, используемые для управления потоком данных между первичным обслуживающим участком (например, RCNC и/или MeNB) и вторичным обслуживающим участком (например, SCeNB).

Для манипулирования данными UL в сети, вторичный обслуживающий участок (например, SCeNB) может пересылать последовательно принимаемые SDU RLC на первичный обслуживающий участок (например, RCNC и/или MeNB) (например, может пересылать автоматически). Вторичный обслуживающий участок (например, SCeNB) может пересылать непоследовательные SDU RLC после мобильности вторичного обслуживающего участка (например, SCeNB).

Манипулирование данными UL на WTRU может быть аналогичным манипулированию данными DL в сети. SDU RLC, которые не были успешно квитированы, могут указываться PDCP. Это можно объединять с обеспечением указаний успешной передачи RLC SDU RLC на PDCP.

Как упомянуто выше, хотя процедуры для мобильности вторичного обслуживающего участка могут быть описаны здесь для мобильности между SCeNB, способы можно использовать для мобильности между SCeNB и MeNB.

В одном примере, мобильность вторичного обслуживающего участка (например, SCeNB) может осуществляться с разделением уровня 2 над MAC. Если запускается мобильность вторичного обслуживающего участка (например, SCeNB), то предстоящие данные, уже обеспеченные вторичному обслуживающему участку (например, SCeNB), могут манипулироваться экземплярами RLC в первичном обслуживающем участке (например, RCNC и/или MeNB). На DL может предварительно формироваться достаточно PDU RLC во избежание ограничения планирования DL вторичными обслуживающими участками (например, SCeNB). Объект RLC DL на первичном обслуживающем участке (например, RCNC и/или MeNB) может не знать о статусе передачи PDU RLC. Способы могут использоваться для определения статуса передачи для снижения задержки передачи.

После мобильности вторичного обслуживающего участка (например, SCeNB), вторичный обслуживающий участок (например, SCeNB) может идентифицировать статус передачи предстоящих PDU RLC, буферизованных на вторичном обслуживающем участке (например, SCeNB) и/или последнего переданного SDU MAC для поддерживаемого экземпляра RLC. Статус передачи может указывать, какие SDU MAC были обработаны и переданы MAC, и/или какие SDU MAC были квитированы по HARQ со стороны WTRU.

Способы могут использоваться для объединения указания статуса передачи SDU MAC с переносом SDU MAC между первичным обслуживающим участком (например, RCNC и/или MeNB) и вторичным обслуживающим участком (например, SCeNB). Например, вторичный обслуживающий участок (например, SCeNB) может поддерживать достаточно буферизованных SDU MAC во избежание ограничения планирования DL. Первичный обслуживающий участок (например, RCNC и/или MeNB) может ограничивать количество заранее сформированных PDU RLC. Поток SDU MAC между RCNC и вторичным обслуживающим участком (например, SCeNB) может управляться, например, с использованием протокола переноса на основе окна и/или схемы на кредитной основе.

SDU MAC можно идентифицировать первичному обслуживающему участку (например, RCNC и/или MeNB) их порядковым номером RLC и/или другими порядковыми номерами, используемыми для управления потоком данных между первичным обслуживающим участком (например, RCNC и/или MeNB) и вторичным обслуживающим участком (например, SCeNB). WTRU может формировать отчет о статусе для каждого перемаршрутизированного экземпляра AM RLC, который является переносом вследствие мобильности вторичного обслуживающего участка (например, SCeNB), например, после инициализации MAC в целевой соте. Для UM RLC, первичный обслуживающий участок (например, RCNC и/или MeNB) может использовать указание порядкового номера, описанное здесь, для определения, где следует начинать передачу DL на целевом вторичном обслуживающем участке (например, SCeNB).

Для AM RLC отчет о статусе RLC в целевой соте может использоваться для определения, где должны начинаться передачи в целевой соте (например, для манипулирования данными UL). Этот отчет о статусе может формироваться (например, автоматически формироваться) первичным обслуживающим участком (например, RCNC и/или MeNB) после завершения мобильности вторичного обслуживающего участка (например, SCeNB). Для UM RLC, WTRU может знать, где передачи прекращаются в соте исходного вторичного обслуживающего участка (например, SCeNB), и может возобновлять передачи из этой точки целевой соты на вторичном обслуживающем участке (например, SCeNB). WTRU может использовать обратную связь по HARQ в соте исходного вторичного обслуживающего участка (например, SCeNB), чтобы лучше аппроксимировать, где следует инициировать передачи UL.

Для поддержки принципов множественного планирования можно реализовать RLF и процедуры переустановления в первичных и/или вторичных обслуживающих участках в течение периодов неблагоприятных условий канала. Например, WTRU может иметь один или более DRB/SRB, которые связаны с одним экземпляром MAC. Если RLM конфигурирован для вторичного экземпляра MAC (например, связанного с SCeNB), то WTRU может определять, что RLF произошел в одной или более обслуживающих сотах (например, P-соте, всех обслуживающих сотах и т.д.), конфигурированных для экземпляра MAC. Определив, что произошел RLF, WTRU может передавать сигнализацию управления восходящей линии связи (например, RRC) с использованием экземпляра MAC (например, первичного экземпляра MAC, связанного с MeNB) для которого RLF не произошел. Сигнализация RRC может включать в себя запрос на переустановление RRC-соединения (или аналогичный) и может отправляться по SRB1 и/или по тракту данных соответствующему первичному экземпляру MAC. Запрос на переустановление может указывать, что переустановление не предназначено для первичного экземпляра MAC, хотя передача была отправлена через первичный экземпляр MAC. Например, запрос на переустановление может включать в себя указание экземпляра MAC, испытавшего сбой, и/или может отправляться по SRB3. WTRU может подвешивать рассматриваемые DRB/SRB (например, DRB и/или SRB3, которые отображаются во вторичный экземпляр MAC, испытавший сбой). WTRU может сбрасывать экземпляр MAC, испытавший сбой. WTRU может освобождать P-соту и/или S-соты экземпляра MAC, испытавшего сбой. WTRU может переустанавливать PDCP и/или RLC для одного или более из подвешенных DRB, когда он принимает сообщение переконфигурирования RRC-соединения, которое пересвязывает один или более из рассматриваемых RB с экземпляром MAC (например, предыдущим экземпляром MAC и/или новым экземпляром MAC). WTRU может возобновлять один или более подвешенных DRB. WTRU может возобновлять подвешенный SRB, например, если RB пересвязываются с вторичным экземпляром MAC.

Для мобильности DRB, WTRU может иметь один или более DRB/SRB, которые связаны с одним экземпляром MAC. WTRU может принимать переконфигурирование RRC-соединения, которое переконфигурирует WTRU таким образом, что можно удалить одну или более из обслуживающих сот определенного экземпляра MAC. WTRU может сбрасывать рассматриваемый экземпляр MAC. WTRU может подвешивать рассматриваемые DRB и SRB (например, при наличии), пока не примет сигнализацию управления, которая пересвязывает один или более из рассматриваемых RB с экземпляром MAC. WTRU может переустанавливать PDCP для рассматриваемых DRB и SRB (например, при наличии). WTRU может переустанавливать RLC для рассматриваемых DRB и SRB (например, при наличии).

Выдача отчета об измерении может осуществляться между сотами различных уровней, и измерения сот на определенном уровне могут сообщаться через одну или более сот других уровней. Для помощи WTRU в осуществлении и/или обеспечения отчета об измерениях, малую соту (например, SCeNB) можно конфигурировать таким образом, что сигналы синхронизации и опорные сигналы, рассылаемые в малых сотах, могут отличаться от сигналов, используемых с целью обнаружения и измерения макросот (например, первичного сигнала синхронизации (PSS)/вторичного сигнала синхронизации (SSS), опорных сигналов, зависящих от соты, и т.д.). Например, сигналы синхронизации и/или опорные сигналы можно задавать для рассылки из малых сот. WTRU может быть выполнен с возможностью обнаружения и/или измерения сот, которые поддерживают вновь заданные сигналы синхронизации и опорные сигналы. Например, WTRU может определять, что сота является малой сотой, на основании обнаружения сигналов синхронизации и/или опорных сигналов, которые связаны с работой малой соты.

Например, когда WTRU принимает конфигурацию измерения, WTRU может получать извещение о том, что сигналы синхронизации и/или опорные сигналы, которые связаны с работой малой соты, могут присутствовать на определенной частоте и/или подлежат измерению в качестве определенного объекта измерения. Конфигурация измерения может указывать WTRU, могут ли традиционные типы сигналов присутствовать на указанной частоте. Конфигурация измерения может включать в себя дополнительную информацию, которая помогает WTRU в обнаружении сигналов синхронизации и/или опорных сигналов, которые связаны с работой малой соты. Например, конфигурация измерения может указывать один или более периоды времени, когда сигналы синхронизации и/или опорные сигналы, которые связаны с работой малой соты, могут передаваться/приниматься, и/или одно или более свойств сигналов синхронизации и/или опорных сигналов, которые связаны с работой малой соты.

Например, конфигурация измерения может указывать период времени, в течение которого могут передаваться/приниматься сигналы синхронизации и/или опорные сигналы, которые связаны с работой малой соты. Указание в отношении хронирования передачи сигнала синхронизации и/или опорного сигнала может быть функцией номера кадра и/или номера подкадра. Например, номер кадра и/или номер подкадра может соответствовать кадрам/подкадрам первичного уровня. Передача сигналов синхронизации и/или опорных сигналов, которые связаны с работой малой соты, может происходить по шаблону периодически повторяющихся подкадров. Например, конфигурационная информация может указывать частоту, с которой повторяется шаблон.

В одном примере, конфигурация измерения может указывать одно или более свойств для одного или более сигналов синхронизации и/или опорных сигналов, которые связаны с работой малой соты. Например, конфигурация измерения может указывать индекс и/или идентификатор, который используется для формирования сигнала синхронизации и/или опорного сигнала, который связан с работой малой соты (например, индекс базовой последовательности Задова-Чу). В одном примере, конфигурация измерения может включать в себя указание типа соты и/или типа сигнала, который WTRU может ожидать найти на конфигурированной частоте. Например, тип соты и/или тип сигнала может использоваться как указание одного или более из типа технологии доступа, связанной с сотой, устойчивых скоростей передачи данных, достижимых в соте, текущего состояния соты (например, переполненная, доступная и т.д.) и/или т.п. Тип соты и/или индекс, используемый для формирования сигнала синхронизации и/или опорного сигнала, который связан с работой малой соты, может указывать одно или более условий, которым должен удовлетворять WTRU, чтобы оперировать ресурсами соты или использовать их. Например, тип соты и/или индекс, используемый для формирования сигнала синхронизации и/или опорного сигнала, который связан с работой малой соты, может указывать одну или более из возможностей, необходимых для осуществления доступа к соте, максимальной скорости, на которой WTRU может работать, находясь в соте, информации, связанной со скоростью изменения условий канала в соте и/или т.п.

WTRU может сообщать результаты измерения для измерений, осуществляемых на одной или более обнаруженных малых сот, которые передают сигналы синхронизации и/или опорные сигналы, которые связаны с работой малой соты. Например, WTRU может сообщать измерения, осуществляемые на малой соте, после обнаружения соты, которая рассылает сигналы синхронизации и/или опорные сигналы, которые связаны с работой малой соты. WTRU может быть выполнен с возможностью выдачи отчета об измерениях малой соты и/или информации измерения сигналов синхронизации и/или опорных сигналов, которые связаны с работой малой соты, на основании обнаружения триггера, например, принятой мощности или качества, превышающего определенное пороговое значение. В одном примере, даже если WTRU обнаруживает конфигурированный триггер для выдачи отчета об измерениях, связанных с работой малой соты, WTRU может отказываться от выдачи отчета об измерениях, если WTRU не удовлетворяет одному или более условий оперирования ресурсами соты или их использования. Например, сигналы синхронизации и/или опорные сигналы, которые связаны с работой малой соты, могут указывать одну или более возможностей, которыми должен обладать WTRU для работы в соте. WTRU может сообщать измерения для соты, если WTRU обнаруживает триггер выдачи отчета об измерении и WTRU отвечает критериям для осуществления доступа к соте.

WTRU может включать один или более элементов информации в отношении малой соты в отчет об измерении. Например, отчет об измерении может включать в себя один или более из идентификатора измеряемого сигнала, идентификатора измеряемой соты, указания типа измеряемого сигнала, указания типа измеряемой соты, указания свойства обнаруженного сигнала, и указания свойства обнаруженной соты и/или т.п. Отчет об измерении может указывать, относится ли обнаруженный/измеренный сигнал к традиционному типу или является сигналом синхронизации и/или опорным сигналом, который связан с работой малой соты. Отчет об измерении может включать в себя информацию, указывающую, может ли WTRU работать в обнаруженной соте. Другая информация, которая может быть включена в отчет об измерении, может содержать один или более из результатов измерения в отношении скорости изменения канала, состояния мобильности WTRU, нескольких недавних событий мобильности, произошедших с WTRU в определенный период времени (например, например, количества процедур переконфигурирования с мобильностью, количества процедур переустановления и т.д.) и/или т.п.

WTRU может осуществлять оценку состояния мобильности (MSE). Например, в рамках процедур MSE, WTRU может определять/отсчитывать количество операций передачи обслуживания (например, и/или повторных выборов соты), осуществляемых WTRU за период времени. На основании количества операций передачи обслуживания (например, и/или повторных выборов соты), осуществляемых за период времени, WTRU может определять свое собственное состояние мобильности. Например, WTRU может определять, что работает в состоянии низкой, средней или высокой мобильности. Состояние, определенное в MSE, может использоваться для масштабирования одной или более переменных мобильности, например, таймера Treselection. Например, значение таймера Treselection можно масштабировать до большего значения для менее мобильных WTRU и можно масштабировать до меньшего значения для более мобильных WTRU.

Независимые состояния мобильности могут быть связаны с первичным и вторичным уровнями. Например, первичный уровень может быть связан с первым состоянием мобильности для WTRU, и вторичный уровень может быть связан со вторым состоянием мобильности для WTRU, если WTRU работает с использованием возможности двойного соединения. Например, MSE на каждом уровне можно определять, отдельно отсчитывая количество повторных конфигураций, предусматривающих мобильность на каждом уровне. WTRU может поддерживать независимые значения MSE и/или осуществляют независимые определения в отношении SE для каждого конфигурированного уровня. WTRU может быть выполнен с возможностью масштабирования одного или более параметров, связанных с определенным уровнем, на основании MSE, определенной независимо для этого уровня. Например, один или более конфигурированных параметров передачи обслуживания (например, времени запуска (TTT)) для определенного уровня можно масштабировать на основании определения MSE для этого уровня. События, связанные с одним или более объектами измерения, соответствующими определенному уровню, можно масштабировать согласно MSE для этого уровня. В одном примере, WTRU может измерять события, связанные с P-сотой уровня при определении информации MSE для этого уровня, но может отказываться от рассмотрения S-соты для этого уровня при определении MSE для уровня.

В одном примере, WTRU также может отсчитывать другие события, связанные с мобильностью, для определения информации MSE, например на поуровневой основе. Например, для определенного первичного и/или вторичного уровня, WTRU может поддерживать отсчет(ы) одного или более из количества сбоев линии радиосвязи DL, количества сбоев линии радиосвязи UL, количества повторных конфигураций MAC для вторичного уровня, количества уникальных сот, выявленных для определенного уровня, обнаружил ли WTRU условия радиосвязи, превышающие заданное пороговое значение на протяжении более заданного периода времени, для соты вторичного уровня, и/или т.п. WTRU может использовать отсчеты для определения информации MSE для уровня. Продолжительность времени, в течение которого отсчеты измеряются для MSE, может быть функцией характеристик соты (например, размера соты и т.д.).

WTRU может быть выполнен с возможностью осуществления одной или более автономных процедур мобильности. Например, WTRU может быть конфигурирован для работы в множестве обслуживающих сот, связанных с вторичным уровнем. Одна или более сот, конфигурированных для использования WTRU на вторичном уровне может находиться в деактивированном состоянии. WTRU может быть выполнен с возможностью осуществления измерений сот на вторичном уровне (например, активированных и/или деактивированных сот). Такие измерения активированных и/или деактивированных сот на вторичном уровне могут предписывать WTRU осуществлять одно или более автономных событий мобильности. В порядке примера, WTRU может быть вынужден начинать осуществление измерений с целью автономной мобильности на основании информации буфера передачи WTRU. Например, если один или более буферов включают в себя объем данных, превышающий заданное пороговое значение, то WTRU может начинать осуществление измерений для автономной мобильности.

Например, WTRU может определять, что один или более измеренных показателей качества, связанных с деактивированной сотой вторичного уровня, стали лучше, чем один или более измеренных показателей качества активированной соты вторичного уровня, например, на величину, превышающую конфигурированное значение смещения. Вместо или помимо сравнения измерений между активированной сотой вторичного уровня и деактивированной сотой вторичного уровня (например, со значением смещения), WTRU может сравнивать измерения деактивированной соты вторичного уровня с пороговым значением для осуществления автономной мобильности. Например, WTRU может определять, что измерения, связанные с деактивированной сотой вторичного уровня, стали лучше/больше порогового значения.

Если измеренное качество деактивированной соты превышает измеренное качество активированной соты (например, на величину, превышающую значение смещения) и/или измеренное качество деактивированной соты превышает пороговое значение, WTRU может быть выполнен с возможностью инициирования процедуры для установления соединения физического уровня с деактивированной сотой (например, WTRU может пытаться соединиться с сотой и/или активировать ее в конфигурации вторичного уровня WTRU). Такая процедура может включать в себя процедуру для перевода деактивированной соты из спящего режима в активный режим. Например, WTRU может инициировать процедуру доступа и/или создавать соединение с ранее деактивированной сотой. Такая процедура может быть аналогична процедуре установления соединения. Например, UE может осуществлять процедуру RACH посредством ресурсов восходящей линии связи ранее деактивированной соты. Процедура RACH может осуществляться с использованием специализированной сигнализации PRACH. Например, специализированные параметры RACH могут позволять eNB, обслуживающему соту, к которой WTRU пытается осуществить доступ, уникально идентифицировать WTRU. Вместо или помимо попытки осуществления доступа к соте через RACH, WTRU может передавать сигнализацию RRC на рассматриваемый eNB. По успешном завершении процедур RACH и/или RRC, WTRU может перемещать соту и рассматривать ее как находящуюся в активированном состоянии. В одном примере, WTRU может переводить свою предыдущую соту (например, вторичного уровня) в деактивированное состояние, например, если предыдущая сота уже не обладает достаточным качеством. В одном примере, WTRU может передавать сигнализацию управления для извещения MeNB об автономной со стороны WTRU активации соты на вторичном уровне. WTRU также может указывать деактивацию своей предыдущей соты на вторичном уровне, если применимо. MeNB может координироваться с соответствующим(и) SCeNB для правильной маршрутизации пакетов и другой информации, связанной с возможностью двойного соединения WTRU.

WTRU может быть выполнен с возможностью конфигурирования/переконфигурирования одного или более радиоканалов-носителей на основании приема сигнализации переконфигурирования (например, сигнализация переконфигурирования может быть связана или не связана с мобильностью). Например, после приема сообщения RRCConnectionReconfiguration, WTRU может осуществлять различные действия, связанные с RB, связанные с первичным и/или вторичным радиоканалом-носителем. Например, если сообщение переконфигурирования указывает добавление по меньшей мере одного SRB для вторичного уровня (например, SRB0, SRB1 и/или SRB2 в случае скоординированной плоскости управления, SRB3 в случае распределенной плоскости управления, может не применяться к централизованной плоскости управления, и т.д.), WTRU может быть выполнен с возможностью осуществления различных действий на основании его текущей возможности соединения. Например, если WTRU имеет одно RRC-соединение и RRC-соединение осуществляется с первичным уровнем (например, как в распределенной плоскости управления), WTRU может неявно определять, что идентификатор для SRB, подлежащего добавлению на вторичном уровне, является SRB3 (например, INTEGER(3)) независимо от значения srb-Identity в сообщении переконфигурирования (например, если присутствует).

Если добавляемым SRB является первый SRB для вторичного уровня, и если вторичный уровень реализует отдельный контекст безопасности для плоскости управления, то WTRU может конфигурировать более низкие уровни (например, PDCP) согласно алгоритму защиты целостности и ключу Krrint, выведенному для и применимому к вторичному уровню и/или может конфигурировать более низкие уровни (например, PDCP) согласно алгоритму шифрования и ключам Kupenc, Krrcenc, выведенным для и применимым к вторичному уровню. WTRU может считать безопасность неактивной (например, не запущенной), до успешного завершения процедуры активации режима безопасности для вторичного уровня. Если добавляемым SRB является первый SRB для вторичного уровня, и если вторичный уровень реализует контекст безопасности, который является общим с макроуровнем для плоскости управления (и/или с любым другим уровнем, для которого безопасность уже активирована), WTRU может применять контекст безопасности (например, ключи) макроуровня (например, или другого уровня с совместно используемой безопасностью) к вторичному уровню и считать, что безопасность запустилась для вторичного уровня. WTRU может связывать вновь добавленный SRB с экземпляром MAC для вторичного уровня. Например, данные плоскости управления для соответствующего канала-носителя могут передаваться с использованием логического канала, связанного с соответствующим экземпляром MAC.

Если принятое сообщение переконфигурирования указывает добавление по меньшей мере одного DRB для вторичного уровня и/или если сообщение переконфигурирования указывает, что по меньшей мере один DRB перешел с первого уровня (например, первичного уровня) на второй уровень (например, вторичный уровень) или наоборот, то WTRU может осуществлять различные действия для добавления или перевода конфигурации канала-носителя на определенный уровень. Например, если вторичный уровень реализует контекст безопасности, который является общим с макроуровнем для плоскости пользователя (и/или с другим уровнем, для которого безопасность уже активирована), WTRU применяет новое значение для drb-identity. Если вторичный уровень реализует контекст безопасности, который является общим с макроуровнем для плоскости пользователя (и/или с другим уровнем, для которого безопасность уже активирована), WTRU может конфигурировать более низкие уровни (например, PDCP) согласно алгоритму шифрования и ключу Kupenc, применимому к макроуровню (например, или другому уровню с совместно используемой безопасностью). Если вторичный уровень реализует отдельный контекст безопасности для плоскости пользователя, WTRU может конфигурировать более низкие уровни (например, PDCP) согласно алгоритму шифрования и ключу Kupenc, выведенному для и применимому к вторичному уровню. WTRU может быть выполнен с возможностью связывания добавленного(ых) и/или переносимого(ых) DRB с экземпляром MAC, связанным с вторичным уровнем. Например, любые данные плоскости пользователя для соответствующего канала-носителя могут передаваться с использованием логического канала, связанного с экземпляром MAC для вторичного уровня. Аналогичные методы можно применять для перемещения SRB между уровнями, как описано для перемещения DRB между уровнями.

Если переконфигурирование указывает, что по меньшей мере один DRB пересвязывается/переводится с первого уровня (например, первичного уровня) на второй уровень (например, вторичный уровень) или наоборот, WTRU может быть выполнен с возможностью переустановления PDCP для рассматриваемого DRB, переустановления RLC для рассматриваемого DRB, возобновления использования рассматриваемого DRB, если он был подвешен (например, в случае переустановления), и/или объект PDCP, связанный с DRB, может быть выполнен с возможностью манипулирования повторными передачами не квитированных SDU PDCP (например, на основании отчета о статусе PDCP).

Мобильность радиоканалов-носителей на определенном уровне может применять текущий механизм обновления безопасности. Например, если на WTRU применяется безопасность, зависящая от уровня, в зависимости от архитектуры плоскости управления/пользователя, применение обновления безопасности может приводить к операции изменения ключа, которая является функцией изменения RRC-соединения и экземпляра MAC. Например, ключ может изменяться, когда и RRC-соединение, и экземпляр MAC меняются на другой eNB (например, при любой мобильности на макроуровне и/или на уровне малых сот). В одном примере, мобильность радиоканала-носителя между уровнями может приводить к тому, что канал-носитель поддерживает тот же контекст безопасности. Например, если применяется макро безопасность, зависящая от уровня, в зависимости от архитектуры плоскости управления/пользователя, операция изменения ключа может быть функцией изменения RRC-соединения и типа RRC-соединения (например, является ли он первичным/макроуровнем или вторичным/ уровнем малых сот). Например, ключ может изменяться для перемещенного канала-носителя, когда RRC-соединение, связанное с макросотой, меняются на другой eNB, но не иначе. Мобильность радиоканалов-носителей может приводить к применению повторного назначения ключей вследствие события мобильности на радиоканале-носителе. Например, если применяется безопасность, зависящая от WTRU, в зависимости от архитектуры плоскости управления/пользователя, операция изменения ключа может быть функцией изменения RRC-соединения, изменения типа RRC-соединения (например, является ли он первичным/макроуровнем или вторичным/ уровнем малых сот) и/или изменения экземпляра MAC. Например, ключ изменяется для перемещенного канала-носителя на основании любого из изменения узла, связанного с RRC-соединением (например, с уровня макросот на уровень малых сот или наоборот), причем экземпляр MAC меняется на другой eNB, и/или т.п.

Можно описать примеры обеспечения защищенной связи между WTRU и SCeNB. Описанные здесь примеры можно применять к архитектурам, в которых протокол PDCP заканчивается на SCeNB для по меньшей мере одного радиоканала-носителя, хотя примеры можно применят и к другим архитектурам. Например, PDCP может заканчиваться на SCeNB для одного или более радиоканалов-носителей данных (DRB) и/или одного или более радиоканалов-носителей сигнализации (например, SRB3). Например, SRB, связанный с экземпляром PDCP на SCeNB, может быть выполнен с возможностью переноса сообщений плоскости управления, управляющих возможностью соединения между WTRU и SCeNB. Протоколы управления для манипулирования возможностью соединения между WTRU и SCeNB могут именоваться вторичным RRC. Вторичный RRC может быть или не быть выполнен с возможностью обеспечения мобильности для соединения между WTRU и SCeNB.

Равноправные объекты PDCP на WTRU и SCeNB могут использовать один или более ключей безопасности. Например, равноправные объекты PDCP на WTRU и SCeNB могут использовать K_RRCint ^(s) и K_RRCenc ^(s), например, для защиты целостности и шифрования вторичных сообщений RRC между SCeNB и WTRU, соответственно. Равноправные объекты PDCP на WTRU и SCeNB могут использовать K_UPenc ^(s) для шифрования пользовательских данных (DRB), переносимых между SCeNB и WTRU.

Описаны примеры вывода вышеописанных ключей безопасности. В одном примере, те же ключи, которые используются на MeNB, могут использоваться на SCeNB, и вычисление канала-носителя может изменяться. Например, один или более ключей безопасности, применяемых между WTRU и SCeNB, могут быть идентичны одному или более ключам безопасности, применяемым между WTRU и MeNB. Например, одни и те же ключи безопасности можно использовать для одних и тех же целей на каждом из MeNB и SCeNB. WTRU может применять один и тот же ключ безопасности для любого радиоканала-носителя независимо от того, в какой экземпляр MAC (или обслуживающий участок/уровень) отображается радиоканал-носитель.

Для обеспечения повторного использования ключей безопасности без ущерба для безопасности, 5-битовый параметр канала-носителя, используемый в качестве входных данных для операции шифрования, может различаться для любой пары радиоканалов-носителей, конфигурированной для WTRU независимо от того, одинаковы ли соответствующие экземпляры MAC (или обслуживающие участки/уровни). Например, RB, связанные с разными уровнями можно назначать разные идентификаторы RB, включающие в себя радиоканалы-носители сигнализации. В одном примере, для шифрования можно использовать другой 5-битовый входной параметр идентификации канала-носителя (например, BEARER), чем конфигурированный параметр идентификатора RB. Например, 5-битовый входной параметр идентификации канала-носителя, используемый для шифрования, можно выбирать на основании идентификатора RB и идентификатора уровня, с которым связан канал-носитель. Например, параметр BEARER можно задать равным идентификатору RB, если канал-носитель связан с MeNB, и задать равным идентификатору RB + 16, если канал-носитель связан с SCeNB. В другом примере, параметр BEARER можно задать равным сумме идентификатора RB и идентификатора уровня (например, который может принимать разные значения в зависимости от того, связан ли канал-носитель с MeNB или SCeNB). В другом примере, параметр BEARER можно задать равным идентификатору RB, если канал-носитель связан с MeNB, и задать равным идентификатору RB + 31, если канал-носитель связан с SCeNB.

В одном примере, для обеспечения повторного использования ключа безопасности без ущерба для безопасности, 32-битовый параметр COUNT, используемый в качестве входных данных для операции шифрования, может быть конфигурирован так, чтобы различаться для любой пары радиоканалов-носителей, конфигурированной для использования для WTRU. Например, параметр COUNT может различаться для каждого канала-носителя независимо от того, одинаковы ли соответствующие экземпляры MAC (или обслуживающие участки/уровни). В порядке примера, WTRU может использовать для шифрования 32-битовый входной параметр COUNT, который отличается от COUNT объекта PDCP, соответствующего радиоканалу-носителю, на котором шифруются данные. Например, входной параметр COUNT можно выбирать как функцию COUNT объекта PDCP, соответствующего радиоканалу-носителю, на котором шифруются данные, и другого параметра, который указывает, с каким уровнем связан RB. Например, параметр COUNT можно задать равным COUNT PDCP, связанному с объектом PDCP радиоканала-носителя, если канал-носитель связан с MeNB, и если канал-носитель связан с SCeNB, значение COUNT можно задать равным COUNT объекта PDCP + смещение. Например, смещение может быть равно 2³¹ - 1. В другом примере, параметр COUNT можно задать равным сумме COUNT для соответствующего объекта PDCP для канала-носителя и идентификатора уровня (например, который может принимать разные значения в зависимости от того, связан ли канал-носитель с MeNB или SCeNB). В другом примере, параметр COUNT можно задать равным сумме COUNT для соответствующего объекта PDCP, идентификатора RB и идентификатора уровня (например, или какой-либо другой функции, отличной от суммы на основании этих параметров). В другом примере, параметр COUNT можно задать равным значению COUNT объекта PDCP для канала-носителя, если канал-носитель связан с MeNB, и задать равным сумме значения COUNT объекта PDCP для канала-носителя + идентификатор RB, если канал-носитель связан с SCeNB.

SCeNB может получать соответствующие ключи непосредственно от MeNB посредством магистральной сигнализации (например, по интерфейсу X2bis) до и/или в ходе конфигурации вторичного уровня. В одном примере, SCeNB может получать один ключ KeNB от MeNB и выводить разные ключи для шифрования и защиты целостности на основании KeNB. В этом примере, ключ KeNB, используемый SCeNB, может быть идентичен ключу KeNB, используемому MeNB.

SCeNB может использовать иные ключи, чем MeNB. В одном примере, ключ безопасности, применяемый между WTRU и SCeNB, может отличаться от ключа безопасности, применяемого между WTRU и MeNB с той же целью (например, шифрования DRB, шифрования SRB, защиты целостности SRB и т.д.). WTRU может быть выполнен с возможностью одновременно применять два набора ключей безопасности. Первый набор ключей (например, K_UPenc, K_RRCint, K_RRCenc и т.д.) можно применять к радиоканалам-носителям, отображаемым в экземпляр MAC, соответствующий MeNB, тогда как один или более ключей из второго набора ключей (например, K_UPenc ^(s), K_RRCint ^(s), K_RRCenc ^(s) и т.д.) можно применять к радиоканалам-носителям, отображаемым в экземпляр MAC, соответствующий SCeNB.

Например, WTRU может быть выполнен с возможностью вывода ключей, используемых для радиоканалов-носителей, связанных с MeNB, и ключей, используемых для радиоканалов-носителей, связанных с SCeNB, с использованием одного и того же KeNB. Например, WTRU может выводить набор ключей MeNB (например, K_UPenc, K_RRCint, K_RRCenc и т.д.) с использованием первого набора различителей типа алгоритма (например, RRC-enc-alg, RRC-int-alg, UP-enc-alg), и WTRU может выводить набор ключей SCeNB (например, K_UPenc ^(s), K_RRCint ^(s), K_RRCenc ^(s) и т.д.) с использованием второго набора различителей типа алгоритма (например, RRC-enc-alg^(s), RRC-int-alg^(s), UP-enc-alg^(s)).

В одном примере, WTRU может быть выполнен с возможностью вывода значения KeNB^(s) (например, для вывода ключей, связанных с каналами-носителями, соответствующими SCeNB) из KeNB (например, который используется для вывода ключей, связанных с каналами-носителями, соответствующими MeNB). Например, WTRU может поддерживать два активных в данный момент ключа (KeNB и KeNB^(s)) для первичного и вторичного уровней, соответственно. На основании ключа KeNB^(s) WTRU может выводить один или более из второго набора ключей, связанных с каналами-носителями, соответствующими SCeNB (например, K_UPenc ^(s), K_RRCint ^(s), K_RRCenc ^(s) и т.д.). После начальной конфигурации вторичного уровня, WTRU может выводить ключ KeNB^(s) из активного в данный момент ключа KeNB, используемого на первичном (макро) уровне.

Вывод KeNB^(s) из KeNB может осуществляться на основании горизонтального алгоритма вывода ключа, например, на основании идентификатора физического уровня/идентификатора физической соты (PCI) и частоты EARFCN-DL обслуживающей соты вторичного уровня, указанных в принятом сообщении переконфигурирования, которое конфигурировало вторичный уровень. В одном примере, вывод может осуществляться на основании вертикального алгоритма вывода ключа. Например, вертикальный вывод ключа может осуществляться, если сообщение переконфигурирования включает в себя параметр nextHopChainingCount (NCC) и если этот параметр отличается от NCC, связанного с KeNB. NCC, связанный с KeNB^(s), может, таким образом, отличаться от NCC, связанного с KeNB.

На стороне сети, MeNB может выводить значение KeNB^(s) из KeNB и сообщать KeNB^(s) SCeNB посредством магистральной сигнализации при подготовке конфигурации вторичного уровня. MeNB может сохранять KeNB^(s) для дополнительного вывода ключа в последующих повторных конфигурациях.

В одном примере, KeNB^(s) можно выводить на основании параметра UL COUNT NAS^(s). Например, WTRU может выводить ключ KeNB^(s) из дополнительного UL COUNT NAS^(s), используемого с целью вывода ключа на вторичном уровне. Например, UL COUNT NAS^(s) можно выводить путем применения смещения к UL COUNT NAS первичного уровня. Например, для вывода ключа KeNB^(s), UL COUNT NAS можно заменить (UL COUNT NAS + смещение), причем смещение может быть достаточно большим, чтобы препятствовать повторному использованию значений UL COUNT NAS. В другом примере, UL COUNT NAS^(s) можно выводить из UL COUNT NAS MeNB, заполняя 24-битовое внутреннее представление UL COUNT NAS 8-битовой последовательностью (например, которая представляет собой не просто 8 нулей в старших битах). В другом примере, дополнительный UL COUNT NAS^(s) можно выводить путем применения некоторой функции преобразования к UL COUNT NAS MeNB. Например, UL COUNT NAS^(s) можно задать равным 2 x UL COUNT NAS +0 или 2x UL COUNT NAS+1, и т.д. В другом примере, KeNB уровня MeNB можно выводить с использованием (2 x COUNT NAS +0), тогда как KeNB^(s) уровня SCeNB можно выводить с использованием (2x UL COUNT NAS +1). В другом примере, UL COUNT NAS MeNB и UL COUNT NAS^(s) SCeNB можно задать равным сумме UL COUNT NAS и идентификатора уровня (например, который может принимать разные значения в зависимости от того, связан ли канал-носитель с MeNB или SCeNB). Хотя эти примеры дополнительного вычисления UL COUNT NAS^(s) выражаются применительно к UL COUNT NAS, аналогичные примеры вывода UL COUNT NAS^(s) можно выразить применительно к DL COUNT NAS.

В одном примере, KeNB^(s) можно выводить из дополнительного параметра Kasme^(s). Например, WTRU может выводить ключ KeNB^(s) из дополнительного ключа (например, ключа Kasme^(s)), используемого с целью вывода ключа на вторичном уровне. Ключ Kasme^(s) может сохраняться на MME и может выводиться как на UE, так и на MME с использованием способа, аналогичного способу, используемому для вывода Kasme. WTRU может поддерживать дополнительный ключ NH^(s) и параметр NCC^(s) с целью вертикального вывода ключа KeNB^(s). На стороне сети, помимо пары NH и NCC, используемой с целью вывода KeNB, MME может обеспечивать целевому eNB дополнительный ключ NH^(s) и параметр NCC^(s). После переконфигурирования, предусматривающего изменение MeNB, WTRU может получать оба параметра NCC и NCC^(s) и, соответственно, обновлять свои ключи NH и NH^(s). Ключ NH^(s) можно обновлять даже если он не используется для вывода ключа KeNB^(s).

Kasme^(s) можно выводить несколькими способами. Например, WTRU может выводить Kasme^(s) из дополнительного вектора аутентификации, используемого с целью вывода ключа на вторичном уровне. В порядке примера, WTRU может принимать дополнительное случайное число (например, RAND^(s)) и дополнительное число аутентификации (например, AUTN^(s)) от MME в ходе процедуры аутентификации и согласование ключа (AKA). Затем WTRU использует RAND^(s) и SQN^(s), включенные в дополнительное AUTN^(s) для формирования дополнительной пары (CK^(s), IK^(s)), которую WTRU может затем использовать для формирования дополнительного Kasme^(s). MME также может отправлять на WTRU дополнительный KSI^(s) (идентификатор набора ключей), например, как часть сообщения команды режима безопасности NAS.

В одном примере, WTRU может использовать «мнимый» или виртуальный ID^(s) обслуживающей сети (ID^(s) SN) или вторичный ID^(s) SN для вывода дополнительного Kasme^(s). Например, WTRU может принимать дополнительный ID SN (например, ID^(s) SN) из сети (например, MME). В одном примере, WTRU может формировать дополнительный ID SN (например, ID^(s) SN) и может передавать дополнительный ID SN (например, ID^(s) SN) в сеть. В одном примере, WTRU и сеть могут независимо формировать дополнительный ID SN (например, ID^(s) SN), например, на основании заранее установленных правил или алгоритма).

В одном примере, WTRU может выполнять дополнительную процедуру AKA (например, AKA^(s)) с MME. Дополнительная процедура AKA может быть упрощенной версией существующей процедуры AKA, в которой WTRU может вычислять дополнительные CK^(s) и IK^(s) и может пропускать вычисление RES (например, ответ на вызов аутентификации). Затем WTRU может использовать дополнительные CK^(s), IK^(s) для формирования дополнительного Kasme^(s). MME также может отправлять на UE дополнительный KSI (например, KSI^(s)) для формирования дополнительного Kasme^(s).

После перехода от EMM-IDLE к EMM-CONNECTED, когда WTRU уже конфигурирован двумя ключами Kasme (например, Kasme для MeNB и Kasme^(s) для SCeNB), WTRU и MME может координировать использование зависящего от уровня Kasme различными способами. Например, WTRU может включать в себя два KSI в начальном сообщении NAS (например, сообщении запроса услуги). WTRU может указывать отображение KSI в уровень eNB в начальном сообщении NAS. Если отображение KSI в уровень не указано, WTRU может затем определить, какой K_ASME отображается в какой уровень eNB (например, какой K_ASME используется для вывода какого KeNB на MME), например, посредством «слепого согласования» KeNB. После приема команды режима безопасности AS (например, сообщения SecurityModeCommand RRC) от eNB, с которым соединен WTRU, WTRU может выводить два KeNB и соответствующие ключи целостности RRC с использованием двух зависящих от уровня K_ASME, идентифицированных двумя KSI, включенными в начальное сообщение NAS. WTRU может итерационно проверять целостность сообщения команды режима безопасности RRC с использованием ключа(ей) целостности RRC выведенного(ых) из каждого из двух KeNB. WTRU может рассматривать KeNB, используемый для формирования ключа целостности RRC, используемого для успешной проверки целостности команды режима безопасности AS, как KeNB, назначенный MME для eNB, с которым WTRU имеет текущее RRC-соединение. Аналогично, WTRU может определять K_ASME, используемый MME для формирования целостности NAS и ключа шифрования с использованием принципа «слепого согласования» для первого сообщения NAS, принятого после процедуры запроса услуги. Например, WTRU может осуществлять «слепое согласование» для определения связи Kasme с уровнем eNB, даже если WTRU указывает отображение KSI в уровень eNB первоначально в сообщении запроса услуги.

В одном примере, WTRU может включать в себя один KSI в начальном сообщении NAS, например, сообщение запроса услуги. Например, как WTRU, так и сеть, могут предположить, что KSI предназначен для уровня MeNB. В другом примере, как WTRU, так и сеть, могут предположить, что KSI является тем, что отображается в уровень SCeNB. В одном примере, как WTRU, так и сеть, могут предположить, что KSI отображается в уровень eNB, к которому UE имеет RRC-соединение. В одном примере, сеть может явно сигнализировать WTRU отображение KSI в надлежащий уровень eNB. Новая процедура (например, новая процедура NAS) может выполняться между базовой сетью и WTRU для установления отображения KSI в уровень eNB. MME может запускать выполнение этой процедуры. В одном примере, WTRU может выводить отображение Kasme в уровень eNB из сообщения команды режима безопасности AS.

При последующем переконфигурировании, предусматривающим событие мобильности (и/или когда IE mobilityControlInfo включен в сообщение), когда WTRU уже поддерживает два набора активных в данный момент ключей, выведенных из KeNB и KeNB^(s), WTRU может выводить новые ключи для первичного уровня, вторичного уровня или обоих, согласно одному или более способам.

В одном примере, WTRU может поддерживать указание наиболее недавно выведенного ключа (например, который может соответствовать либо KeNB, либо KeNB^(s)). Наиболее недавно выведенный ключ может использоваться как основа для вывода нового ключа KeNB* или KeNB*^(s) после переконфигурирования. После вывода нового ключа в ходе последующей процедуры переконфигурирования, результатом вывода становится новый наиболее недавно выведенный ключ. Если переконфигурирование предусматривает вывод двух новых ключей (например, по одному для каждого уровня), последующий (например, второй) новый ключ можно выводить из первого нового ключа. Порядок вывода ключа может указываться в сообщении переконфигурирования или быть заранее заданным (например, сначала первичный уровень или сначала вторичный уровень, и т.д.). WTRU может сохранять наиболее недавно выведенный ключ, даже если соответствующий уровень для этого ключа удаляется при последующем переконфигурировании. На стороне сети, MeNB также может сохранять два ключа KeNB и KeNB^(s) и указывать, какой из них является наиболее недавно выведенным ключом.

После переконфигурирования, например, переконфигурирование вследствие мобильности на вторичном уровне, MeNB может выводить новый ключ KeNB*^(s) из наиболее недавно выведенного ключа и сообщать значение KeNB*^(s) целевому SCeNB. После переконфигурирования, предусматривающего мобильность на первичном уровне, но не на вторичном уровне, MeNB может выводить новый ключ KeNB* из наиболее недавно выведенного ключа и сообщать значение KeNB* целевому MeNB и/или целевому SCeNB. После переконфигурирования, предусматривающего мобильность на первичном и вторичном уровнях, MeNB может сначала выводить новый ключ KeNB* из наиболее недавно выведенного ключа и затем выводить новый ключ KeNB*^(s) из KeNB*. MeNB может сообщать значения KeNB* и KeNB*^(s) целевому MeNB, и целевой MeNB может сообщать значения KeNB*^(s) целевому SCeNB. Новый наиболее недавно выведенный ключ в этом случае может быть KeNB*^(s).

В одном примере, после переконфигурирования, предусматривающего мобильность на первичном уровне, WTRU может выводить новый ключ KeNB* из своего активного в данный момент ключа KeNB, и, после переконфигурирования, предусматривающего мобильность на вторичном уровне, WTRU может выводить новый ключ KeNB*^(s) из своего активного в данный момент ключа KeNB^(s). Таким образом, любой или оба из активных в данный момент ключа KeNB и/или ключа KeNB^(s) может/могут использоваться как основа для дополнительного вывода ключа в зависимости от того, какой(ие) уровень(и) участвует(ют) в следующем переконфигурировании. Тот же принцип может использоваться на MeNB для вывода новых ключей KeNB*^(s) и/или KeNB*.

В одном примере, WTRU может активировать безопасность AS уровня SCeNB, когда установлен SRB1 (например, к MeNB) и до установления SRB2. В другом примере, WTRU может активировать безопасности уровня SCeNB после установления SRB2. Как часть активации безопасности AS SCeNB, UE может выводить KeNB^(s) и соответствующий набор ключей безопасности (например, K_UPenc ^(s), K_RRCint ^(s), K_RRCenc ^(s) и т.д.) с использованием одного или более из описанных здесь способов.

Вышеописанные процессы можно реализовать в виде компьютерной программы, программного обеспечения и/или программно-аппаратного обеспечения, записанного на машиночитаемом носителе для выполнения компьютером и/или процессором. Примеры машиночитаемых носителей включают в себя, не ограничиваясь, электронные сигналы (передаваемые по проводным и/или беспроводным соединениям) и/или машиночитаемым носителям данных. Примеры машиночитаемых носителей данных включают в себя, но не ограничиваясь, постоянную память (ПЗУ), оперативная память (ОЗУ), регистр, кэш-память, полупроводниковые запоминающие устройства, магнитные носители например, не ограничиваясь, внутренние жесткие диски и съемные диски, магнитооптические носители, и/или оптические носители, например диски CD-ROM, и/или цифровые универсальные диски (DVD). Процессор совместно с программным обеспечением может использоваться для реализации радиочастотного приемопередатчика для использования на WTRU, UE, терминале, базовой станции, RNC, и/или любом главном компьютере.

Изобретение относится к мобильной связи. Раскрыты системы и способы для работы WTRU (беспроводного приемопередающего блока) с использованием множества планировщиков. WTRU обменивается данными с сетью по более чем одному тракту данных таким образом, что каждый тракт данных может использовать радиоинтерфейс, соединенный с отдельным узлом сети, и каждый узел может быть связан с независимым планировщиком. WTRU устанавливает RRC-соединение между WTRU и сетью. RRC-соединение устанавливает первый радиоинтерфейс между WTRU и первым обслуживающим участком сети и второй радиоинтерфейс между WTRU и вторым обслуживающим участком сети. Между WTRU и MeNB (eNode макросоты) устанавливается RRC-соединение, и между WTRU и SCeNB (eNode малой соты) устанавливается функция управления. Технический результат заключается в обеспечении многоузлового планирования, позволяющего WTRU обмениваться данными по сети беспроводной связи с использованием более чем одного тракта данных. 2 н. и 13 з.п. ф-лы, 33 ил.

1. Способ работы беспроводного приемопередающего блока (WTRU) с использованием множества экземпляров управления доступом к среде (MAC), причем способ содержит этапы, на которых:
WTRU устанавливает соединение управления радиоресурсами (RRC) через первый экземпляр MAC;
WTRU принимает сообщение переконфигурирования RRC-соединения через первый экземпляр MAC, причем сообщение переконфигурирования RRC-соединения содержит конфигурацию WTRU для добавления или изменения одной или более сот, связанных со вторым экземпляром MAC RRC-соединения, каждый из первого экземпляра MAC и второго экземпляра MAC связан с отдельной конфигурацией физического уровня, подлежащей применению к общему типу радиоинтерфейса, каждый радиоканал-носитель сигнализации (SRB) для RRC-соединения отображается в первый экземпляр MAC, и сообщение переконфигурирования указывает, что по меньшей мере один радиоканал-носитель данных (DRB) выполнен с возможностью использования на втором экземпляре MAC;
WTRU активирует второй экземпляр MAC; и
WTRU отслеживает канал управления по меньшей мере одной из одной или более сот, связанных со вторым экземпляром MAC, на основании активации второго экземпляра MAC.

2. Способ по п. 1, в котором по меньшей мере один DRB содержит новый радиоканал-носитель (RB), установленный для использования через второй экземпляр MAC.

3. Способ по п. 1, в котором по меньшей мере один DRB содержит DRB, который был ранее отображен в первый экземпляр MAC, и сообщение переконфигурирования RRC-соединения предписывает WTRU начать связывать RB, который был ранее отображен в первый экземпляр MAC, со вторым экземпляром MAC.

4. Способ по п. 1, в котором сообщение переконфигурирования содержит множество конфигураций управления радиоресурсами (RRM) для одной или более сот, связанных со вторым экземпляром MAC.

5. Способ по п. 1, в котором общий тип радиоинтерфейса содержит интерфейс Uu усовершенствованного наземного радиодоступа (E-UTRA) универсальной системы мобильной связи (UMTS).

6. Способ по п. 1, в котором каждый из первого экземпляра MAC и второго экземпляра MAC отображаются в отдельные объекты управления линией радиосвязи (RLC).

7. Способ по п. 6, в котором первый экземпляр MAC и второй экземпляр MAC совместно используют по меньшей мере один общий объект протокола конвергенции пакетной передачи данных (PDCP).

8. Способ по п. 1, в котором каждый из первого экземпляра MAC и второго экземпляра MAC связан с соответствующей первичной сотой и одной или более соответствующими вторичными сотами.

9. Способ по п. 1, в котором сетевой объект RRC для RRC-соединения расположен на обслуживающем участке, который включает в себя экземпляр MAC равноправного объекта, соответствующий первому экземпляру MAC.

10. Способ по п. 1, дополнительно содержащий этапы, на которых:
осуществляют одно или более измерений по меньшей мере одной из одной или более сот, связанных со вторым экземпляром MAC; и
сообщают одно или более измерений через первый экземпляр MAC.

11. Беспроводной приемопередающий блок (WTRU), содержащий процессор, выполненный с возможностью:
установления соединения управления радиоресурсами (RRC) через первый экземпляр MAC;
приема сообщения переконфигурирования RRC-соединения через первый экземпляр MAC, причем сообщение переконфигурирования RRC-соединения содержит конфигурацию WTRU для добавления или изменения одной или более сот, связанных со вторым экземпляром MAC RRC-соединения, каждый из первого экземпляра MAC и второго экземпляра MAC связан с отдельной конфигурацией физического уровня, подлежащей применению к общему типу радиоинтерфейса, каждый радиоканал-носитель сигнализации (SRB) для RRC-соединения отображается в первый экземпляр MAC, и сообщение переконфигурирования указывает, что по меньшей мере один радиоканал-носитель (RB) выполнен с возможностью использования на втором экземпляре MAC;
активации второго экземпляра MAC; и
отслеживания канала управления по меньшей мере одной из одной или более сот, связанных со вторым экземпляром MAC, на основании активации второго экземпляра MAC.

12. WTRU по п. 11, в котором каждый из первого экземпляра MAC и второго экземпляра MAC связан по меньшей мере с одним общим экземпляром протокола конвергенции пакетной передачи данных (PDCP) для WTRU.

13. WTRU по п. 12, в котором процессор дополнительно выполнен с возможностью использования одного и того же ключа безопасности для шифрования пакетов PDCP, подлежащих отправке через первый экземпляр MAC или второй экземпляр MAC.

14. WTRU по п. 11, в котором первый экземпляр MAC выполнен с возможностью осуществления доступа к сотам, связанным с первым обслуживающим участком, с использованием первой конфигурации общего типа радиоинтерфейса, и второй экземпляр MAC выполнен с возможностью осуществления доступа к сотам, связанным со вторым обслуживающим участком, с использованием первой конфигурации общего типа радиоинтерфейса.

15. WTRU по п. 11, в котором процессор выполнен с возможностью активации одной или более сот, связанных со вторым экземпляром MAC, с использованием по меньшей мере процедуры канала произвольного доступа (RACH).