Управление передачей данных в сети беспроводной связи

Управление передачей данных в сети беспроводной связи

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

[1] Настоящее изобретение относится к системе беспроводной (радио) подвижной связи и беспроводному (радио) терминалу, предназначенным для осуществления беспроводной связи.

Известный уровень техники

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

[3] Для поддержки широкополосного беспроводного доступа (например, WiMAX - технология широкополосного доступа в микроволновом диапазоне) существуют различные типы радиоинтерфейсов широкополосного беспроводного доступа, например, технологии сотовой связи 3G (например, универсальная система мобильной связи «UMTS», широкополосный множественный доступ с кодовым разделением каналов «W-CDMA» и т.д.) и технологии множественного доступа на основе использования нескольких несущих частот (например, технологии, использующие мультиплексирование с ортогональным разделением частот - «OFDMA», OFDMA-TDMA, OFDMA-CDMA и т.д.). Мультиплексирование (уплотнение) каналов с ортогональным разделением частот включает в себя использование подканалов, как минимум, четырех типов («OFDM»; «Flash OFDM» - «ОРОМ»для срочной связи; «sOFDMA» - расширяемая «OFDMA»; и «OFDMA»).

[4] Мультиплексирование с ортогональным разделением частот «OFDM» включает в себя разделение радиосигнала на несколько подсигналов (субсигналов) меньшего размера, которые затем одновременно передаются приемнику на различных частотах. Мультиплексирование с ортогональным разделением частот «OFDM» - это вид передачи с использованием нескольких несущих частот, где все поднесущие частоты ортогональны друг другу. Определенные стандарты IEEE и стандарты 3GPP относятся к различным аспектам мультиплексирования с ортогональным разделением частот «OFDM». Например, на принципах мультиплексирования с ортогональным разделением частот «OFDM» основаны разделы стандарта 3GPP, связанные с различными аспектами системы «LTE» - долгосрочное эволюционное развитие (такими, как развивающаяся универсальная система подвижной связи «E-UMTS».

[5] На фиг.1 и 2 приведены примеры структуры развивающейся универсальной системы подвижной связи «E-UMTS». Развивающаяся универсальная система подвижной связи «E-UMTS» представляет собой систему, которая стала результатом эволюции универсальной системы подвижной связи «UMTS», и в настоящее время организация по стандартам 3GPP ведет работу по ее стандартизации.

[6] Как показано на фиг.1 и 2, сеть развивающейся универсальной системы подвижной связи «E-UMTS» обычно состоит из базовой сети «CN», развивающейся универсальной наземной сети радиодоступа «E-UTRAN» и терминала. Сеть «E-UTRAN» состоит из базовой станции (то есть, «Узел-В», или «Узел-eNB»), а также узла доступа (такого, как шлюз доступа «AG»), расположенного на выходе сети системы «E-UMTS» и соединенного с одной или несколькими внешними сетями. Шлюз доступа «AG» можно разделить на модуль, который обрабатывает трафик пользователя (поток пользовательских данных), и модуль, который обрабатывает трафик управления (поток данных управления). В этом случае шлюз доступа «AG», который обрабатывает трафик пользователя, и шлюз доступа «AG», который обрабатывает трафик управления, могут взаимодействовать друг с другом через вновь определенный интерфейс. Для одной базовой станции «Узел-eNB» может существовать одна или несколько ячеек. Между базовыми станциями «Узел-eNB» для передачи пользовательского трафика и трафика управления может использоваться интерфейс. Базовая сеть «CN может состоять из узлов и т.п., используемых для регистрации, и других функций для пользователей терминалов «UE» и шлюза доступа «AG». Кроме того, может использоваться интерфейс, различающий сеть «E-UTRAN» и базовую сеть.

[7] Кроме того, в сети системы «E-UMTS» может быть сервер плоскости управления «CPS», который осуществляет функции управления радиосвязью (беспроводной связью), элемент для управления ресурсами радиосвязи «RRM», который осуществляет функции управления ресурсами радиосвязи, элемент для управления мобильностью «ММЕ», который осуществляет функции управления мобильностью для подвижного терминала. Здесь следует понять, что конкретные названия указанных элементов в различных сетях могут быть и другими.

[8] Различные уровни протокола интерфейса радиосвязи между мобильным терминалом и сетью можно разделить на первый уровень (L1), второй уровень (L2) и третий уровень (L3) на основе трех нижних уровней модели взаимодействия открытых систем (OSI), хорошо известной в технологии систем связи. Среди этих уровней физический уровень, который является частью уровня L1, предоставляет услугу по передаче информации с использованием физического канала, тогда как уровень управления ресурсами радиосвязи «RRC», расположенный на уровне L3, выполняет функцию управления ресурсами радиосвязи между мобильным терминалом и сетью. Для этого уровень управления ресурсами радиосвязи «RRC» осуществляет обмен сообщениями уровней управления ресурсами радиосвязи - «RRC-сообщения» между мобильным терминалом и сетью. Выполнение функций уровня управления ресурсами радиосвязи «RRC» может быть распределено между базовой станцией «Узел-В», сервером плоскости управления «СР8»/элементом для управления ресурсами радиосвязи «RRM» и/или элементом для управления мобильностью «ММЕ».

[9] Протокол интерфейса радиосвязи по горизонтали включает в себя физический уровень, уровень канала передачи данных и сетевой уровень, а по вертикали включает в себя плоскость пользователя для передачи пользовательской информации и плоскость управления для передачи сигналов управления. Протокол интерфейса радиосвязи может быть разделен на уровень 1 (L1), уровень 2 (L2) и уровень 3 (L3) на основе трех нижних уровней модели взаимодействия открытых систем (OSI), хорошо известной в технологии систем связи.

[10] На фиг.3 и 4 представлен пример структуры протокола радиоинтерфейса в соответствии со стандартами сети радиодоступа третьего поколения 3GPP. Ниже будут описаны конкретные уровни радиопротокола:

плоскости управления, представленные на фиг.3, и плоскости пользователя, представленные на фиг.4. Физический уровень (т.е. уровень 1) использует физический канал для поставки услуги передачи данных на вышерасположенный уровень. Физический уровень соединен с расположенным над ним уровнем управления доступом к среде «MAC», посредством транспортного канала, и данные передаются между уровнем управления доступом к среде «MAC» и физическим уровнем через этот транспортный канал. Кроме того, через физический канал передаются данные между разными физическими уровнями, например между соответствующими физическими уровнями передающей стороны (передатчиком) и принимающей стороны (приемником).

[11] Уровень управления доступом к среде «MAC» уровня 2 предоставляет услуги уровню управления радиоканалом «RLC» (который является вышерасположенным уровнем) посредством логического канала. Уровень управления радиоканалом «RLC» уровня 2 поддерживает надежную передачу данных. Следует заметить, что уровни управления радиоканалом «RLC» на фиг.3 и 4 обозначены штриховыми линиями, поскольку, если функции уровня управления радиоканалом «RLC» реализованы на уровне управления доступом к среде «MAC» и выполняются им, уровень управления радиоканалом «RLC» может отсутствовать. Уровень протокола сходимости пакетных данных «PDCP» уровня 2 выполняет функцию сжатия заголовка, которая сокращает ненужную информацию управления, чтобы данные, передаваемые с использованием пакетов Интернет-протокола «IP», например IPv4 или IPv6, могли эффективно передаваться через интерфейс радиосвязи (беспроводной связи) с относительно малой полосой пропускания.

[12] Уровень управления ресурсами радиосвязи «RRC», расположенный в самой нижней части уровня L3, определен только в плоскости управления и обеспечивает управление логическими каналами, транспортными каналами и физическими каналами в отношении создания, реконфигурации и прекращения или отмены действия широкополосных радиоканалов «RB». Здесь радиоканал «RB» - это услуга, оказываемая вторым уровнем (L2) для передачи данных между терминалом и сетью «UTRAN».

[13] Что касается каналов, используемых в нисходящей линии связи для передачи данных из сети на мобильный терминал, то и в их состав входят широковещательный канал «ВСН», предназначенный для передачи системной информации, а также совместно используемый канал «SCH», предназначенный для передачи трафика пользователя или управляющих сообщений. Что касается каналов, используемых в восходящей линии связи для передачи данных с мобильного терминала в сеть, то и в их состав входят канал с произвольным доступом «RACH», предназначенный для передачи исходного управляющего сообщения, а также совместно используемый канал «SCH», предназначенный для передачи трафика пользователя или управляющих сообщений.

[14] Далее более подробно обсуждаются особенности уровня управления радиоканалом «RLC».

[15] Основной функцией уровня управления радиоканалом «RLC» является обеспечение качества обслуживания «QoS» для каждого однонаправленного радиоканала (далее, радиоканала «RB») и соответствующая передача данных. Поскольку услуга радиоканала «RB» является услугой, предоставляемой протоколом радиосвязи уровня 2 вышерасположенному уровню, весь уровень 2 в целом влияет на качество обслуживания «QoS», но, в частности, большое воздействие оказывает управление радиоканалом «RLC». Чтобы гарантировать качество обслуживания «QoS», которое является индивидуальным для каждого радиоканала «RB», управление радиоканалом «RLC» имеет отдельный (независимый) модуль управления радиоканалом «RLC» для каждого радиоканала «RB» и предоставляет два типа режимов управления радиоканалом «RLC» для поддержки различного качества обслуживания «QoS», а именно режим без подтверждения приема «UM» и режим с подтверждением приема «AM». Способы работы в указанных двух режимах управления радиоканалом «RLC» различаются, поскольку соответственно различаются поддерживаемые ими стандарты качества обслуживания «QoS», поэтому их более конкретные функции также различаются. Следовательно, управление радиоканалом «RLC» следует рассматривать в связи с его режимом работы.

[16] Управление радиоканалом «RLC» имеет два режима работы: режим без подтверждения приема - «UM», который не предусматривает ответ или подтверждение приема передаваемых данных, и режим с подтверждением приема «AM», в котором предусматривается ответ или подтверждение приема. В режиме без подтверждения приема «UM» управление радиоканалом «RLC» передает каждый блок протокольных данных «PDU» после присоединения к нему заголовка, содержащего порядковый номер «SN», что позволяет приемнику получить информацию о том, какие блоки протокольных данных «PDU» потеряны во время передачи. Благодаря этой функции управления радиоканалом «RLC». без подтверждения приема «UM», в плоскости пользователя обрабатываются передаваемые широковещательные или многоадресные данные или пакеты данных, передаваемые в реальном времени, такие как речь (например, при IP-телефонии), и обеспечивается потоковый режим домена услуг с пакетной коммутацией «PS», тогда как в плоскости управления обрабатываются передаваемые сообщения управления ресурсами радиосвязи «RRC» - («RRC-сообщения»), для которых нет необходимости в получении подтверждения приема, среди всех «RRC-сообщений», определенным терминалом внутри ячейки или определенной группой терминалов.

[17] Подобно управлению радиоканалом «RLC» без подтверждения приема «UM» управление радиоканалом «RLC» с подтверждением приема «AM» формирует блок протокольных данных «PDU» путем добавления заголовка блока протокольных данных «PDU», содержащего порядковый номер «SN», но в отличие от управления радиоканалом «RLC» без подтверждения приема «UM», имеется большая разница в том, что приемник, выдает сигнал подтверждения приема блока протокольных данных «PDU», передаваемого передатчиком. При работе управления радиоканалом «RLC» с подтверждением приема «AM» причина, по которой приемник выдает сигнал подтверждения приема, заключается в том, чтобы дать возможность приемнику запросить повторную передачу тех блоков протокольных данных «PDU», которые не приняты надлежащим образом, и эта функция повторной передачи является наиболее важной характеристикой управления радиоканалом «RLC» с подтверждением приема «AM». В результате, целью управления радиоканалом «RLC» с подтверждением приема «AM» является обеспечение безошибочной передачи данных с помощью повторных передач, и для этого управление радиоканалом «RLC» с подтверждением приема «AM» обычно обрабатывает пакетные данные не в реальном времени, например с помощью протокола управления передачей (межсетевым протоколом) «ТСР»/Интернет-протоколом «IP» домена с пакетной коммутацией «PS» в плоскости пользователя, и обрабатывает «RRC-сообщения», для которых требуется прием подтверждения приема, среди всех «RRC-сообщений», передаваемых на определенный терминал внутри ячейки.

[18] Что касается аспектов направленности передачи, то в режиме управления радиоканалом «RLC» без подтверждения приема «UM» используется односторонняя связь, тогда как в режиме управления радиоканалом «RLC» с подтверждением приема «AM» используется двусторонняя связь, поскольку имеется обратная связь от приемника. Из-за того, что двустороння связь обычно используется в коммуникациях прямой связи типа «точка-точка», для управления радиоканалом «RLC» с подтверждением приема «AM» используется только выделенный логический канал. Имеются также различия в структурных аспектах, из-за чего управление радиоканалом «RLC» без подтверждения приема «UM» обладает структурой единственного типа, состоящей из одного модуля управления радиоканалом «RLC, предназначенного или для передачи, или для приема данных, но для управления радиоканалом «RLC» с подтверждением приема «AM» в одном модуле управления радиоканалом «RLC» предусмотрены и передатчик, и приемник.

[19] Причиной усложненности управления радиоканалом «RLC» с подтверждением приема «AM» является его функция повторной передачи. Чтобы увеличить эффективность передачи данных, для управления повторной передачей данных в уровне управления радиоканалом «RLC» с подтверждением приема «AM» в дополнение к буферу приема/передачи имеется буфер повторной передачи, для управления потоком используется окно передачи/приема, применяется функция опроса, посредством которой передатчик запрашивает информацию о состоянии у равноправного модуля уровня управления радиоканалом «RLC» в приемнике, используется отчет о состоянии для приемника, чтобы дать отчет о состоянии буфера приемника равноправному уровню управления радиоканалом «RLC» передатчика, используется статус блока протокольных данных «PDU», предназначенный для пересылки информации о статусе, используется функция совмещения, при выполнении которой статус блока протокольных данных «PDU» вкладывается в данные блока протокольных данных «PDU», и выполняются другие функции. Кроме того, если модуль управления радиоканалом «RLC» с подтверждением приема «AM» обнаруживает серьезную ошибку в своей работе, используются сообщение «Reset PDU», для запроса равноправного модуля управления радиоканалом «RLC» с подтверждением приема «AM» на сброс всех операций и параметров в исходное состояние, а также сообщение «Reset Ack PDU» - для ответа на указанное сообщение «Reset PDU». Кроме того, для поддержки указанных функций управление радиоканалом «RLC» с подтверждением приема «AM» запрашивает параметры протоколов различного типа, переменные состояния и таймеры. Блоки протокольных данных «PDU», используемые для передачи управляющих данных управления радиоканалом «RLC» с подтверждением приема «AM», таких как: отчет о состоянии, статус блока протокольных данных «PDU», сообщение «Reset PDU» и т.п., называются блоками «PDU» управления, а блоки протокольных данных «PDU», используемые для поставки пользовательских данных, называются блоками «PDU» данных.

[20] Система подвижной связи отличается от проводной сети тем, что услуги могут поставляться на перемещающиеся терминалы без перерывов. То есть должны поддерживаться ситуации, когда терминал перемещается из одного района в другой отличающийся район. Если терминал удаляется от базовой станции, к которой он имеет доступ в данный момент, и приближается к новой базовой станции, сеть должна выполнять операции по перемещению точки доступа терминала в новую базовую станцию. Когда доступ терминала к предыдущей базовой станции прерывается, то до момента получения доступа к новой базовой станции передача и прием данных невозможны.

[21] Однако все пользовательские данные имеют лимит времени передачи. Например, в случае голосового вызова речевые данные (или информация) должны передаваться принимающему абоненту в течение заданного периода времени. Кроме того, данные, например данные протокола управления передачей «TCP», должны посылаться с передатчика и приниматься приемником в течение заданного периода времени, а приемник в течение определенного периода времени должен отправить передатчику сигнал подтверждения приема. Иначе передатчик повторно передаст данные протокола управления передачей «TCP».

Сущность изобретения

Техническая проблема

[22] В общем, терминал и базовая станция при передаче и приеме непрерывно обмениваются информацией о подтверждении приема переданных или принятых данных. Например, в случае пакетов протокола управления передачей «TCP», если один пакет во время передачи потерян объектами нижерасположенного уровня, скорость передачи элементов протокола управления передачей «TCP» быстро уменьшается. Например, если объект протокола управления передачей «TCP» посылает и принимает данные со скоростью 100 Мбит/с, то если даже будет потерян один пакет, скорость передачи данных протокола управления передачей «TCP» может значительно уменьшиться, например, до 10 Кбит/с.

[23] Соответственно, чтобы уменьшить в отношении пакетов протокола управления передачей «TCP», система подвижной связи для поддержки передачи трафика данных (таких как пакеты протокола управления передачей «TCP») через радиоинтерфейс (например, между базовой станцией и терминалом) использует режим без потерь («no-loss»). Указанный режим без потерь можно считать эквивалентным режиму управления радиоканалом «RLC» с подтверждением приема «AM», и если передатчик не принимает сигнал подтверждения приема переданных им данных в течение определенного времени, или если происходит ошибка приема указанных переданных данных, то происходит повторная передача указанных данных.

[24] Однако, как объяснялось выше, повторная передача выполняется не всегда, а только в случае, когда сигнал подтверждения приема отсутствует в течение максимального времени задержки передачи для данного радиоинтерфейса.

Техническое решение

[25] Существует необходимость в улучшении управления передачей данных в системе радиосвязи.

[26] Соответственно, особенности настоящего изобретения разработаны для того, чтобы решить указанные проблемы известных технических решений. Предложенные особенности минимизируют ненужное дублирование передачи пользовательских данных через радиоинтерфейс посредством выполнения эффективного управления данными в процедуре передачи абонентского соединения (хендовер) для мобильного терминала, так, чтобы скорость передачи данных можно было увеличить и тем самым улучшить качество услуг для пользователя.

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

[27] На фиг.1 представлен один пример структуры сети развивающейся универсальной системы подвижной связи «E-UMTS» (программа - «LTE» - долгосрочное эволюционное развитие).

[28] На фиг.2 представлен другой пример структуры сети развивающейся универсальной системы подвижной связи «E-UMTS» (программа - «LTE» - долгосрочное эволюционное развитие).

[29] На фиг.3 и 4 представлен пример структуры протокола радиоинтерфейса в соответствии со стандартом сети радиодоступа третьего поколения 3GPP.

[30] На фиг.5 представлен пример процедуры передачи абонентского соединения (хендовер) в соответствии с одним из многих возможных вариантов осуществления настоящего изобретения.

Примеры осуществления изобретения

[31] Ниже будет описан пример процедуры передачи абонентского соединения (хендовер) в настоящий момент определенной в стандарте долгосрочного эволюционного развития «LTE». Данная процедура может быть сведена к следующим шагам, которые приведены для примера и не могут ограничивать возможные другие дополнительные и альтернативные шаги и элементы.

[32] 1) Мобильный терминал передает отчет об измерениях на базовую станцию «BS», когда удовлетворяются определенные условия, заданные базовой станцией «BS».

[33] 2) Исходная базовая станция «BS», чтобы определить передачу абонентского соединения (хендовер), обращается к отчету об измерениях от мобильного терминала. Исходная базовая станция посылает запрос на целевую базовую станцию с предложением подготовиться к передаче абонентского соединения.

[34] 3) После получения ресурсов целевая базовая станция передает на исходную базовую станцию информацию о конфигурации вместе с временным идентификатором радиосети ячейки (соты) («C-RNTI») соответствующего мобильного терминала. Исходная базовая станция передает пользовательские и другие данные на целевую базовую станцию.

[35] 4) Мобильный терминал принимает от исходной базовой станции команду на выполнение перехода абонентского соединения (хендовера).

[36] 5) Мобильный терминал повторно создает среду радиоканала с целевой базовой станцией. Сюда включается также временная синхронизация.

[37] 6) Целевая базовая станция передает ответ с информацией о синхронизации. После этого мобильный терминал посылает на целевую базовую станцию сообщение с подтверждением передачи абонентского соединения (хендовер).

[38] 7а) Целевая базовая станция информирует исходную базовую станцию об успешном выполнении передачи абонентского соединения (хендовера).

[39] 7b) Местоположение мобильного терминала в базовой сети «CN» обновляется.

[40] Однако в приведенной выше процедуре все пользовательские данные нисходящего канала в исходной базовой станции передаются на целевую базовую станцию, а все успешно принятые пользовательские данные восходящего канала передаются от исходной базовой станции в базовую сеть. Кроме того, в процедуре передачи абонентского соединения (хендовера) все новые пользовательские данные нисходящего канала, доставляемые в базовую сеть, передаются из базовой сети непосредственно на целевую базовую станцию. Целевая базовая станция передает на мобильный терминал все пользовательские данные, принятые из базовой сети и от исходной базовой станции.

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

[42] Аналогичным образом даже в случае, когда пользовательские данные восходящего канала, передаваемые мобильным терминалом, принимаются надлежащим образом соответствующей базовой станцией до начала передачи абонентского соединения (хендовера), если указанная информация не была доставлена на мобильный терминал, то соответствующая базовая станция считает, что она пропустила указанные пользовательские данные и передает запрос на мобильный терминал на повторную передачу данных. Соответственно, если мобильный терминал передает такие пользовательские данные снова, это приводит к бесполезному расходованию ресурсов.

[43] Следует избегать указанного бесполезного расходования ресурсов. Это не имело бы значения, если бы объем радиоресурсов был неограниченным, но т.к. объем ресурсов ограничен, повторная передача одних и тех же данных ухудшает возможности передачи новых данных. Это будет означать, что определенные пользовательские данные не будут доставляться в течение заданного периода времени, и в связи с этим может значительно ухудшиться скорость передачи данных.

[44] Один из аспектов особенностей настоящего изобретения заключается в понимании авторами настоящего изобретения проблем и недостатков известного технического решения процедуры передачи абонентского соединения (хендовера), описанной выше и более подробно рассматриваемой ниже. На основе такого понимания и было разработано настоящее изобретение.

[45] Возможности, предложенные в настоящем изобретении, можно считать улучшением вышеописанного процесса передачи абонентского соединения (хендовера). Например, стандарт 3GPP и действующий стандарт LTE не позволяют адекватно решать проблему необходимых отправки и приема информации о состоянии (связанной с состоянием приема различных блоков данных) по каналу между сетью (узлы «Node В») и мобильным терминалом «UE» при выполнении передачи абонентского соединения (хендовера) (или переключении). В частности, при выполнении передачи абонентского соединения (хендовера) исходная базовая станция («Node В», «eNB! и т.д.) посылает информацию на целевую базовую станцию («Node В», «eNB» и т.д.), связанную с блоками данных, принимаемыми (или не принимаемыми) по восходящему и/или нисходящему каналу. Это позволяет улучшить сигнализацию между базовой станцией и мобильным терминалом «UE» во время и после хендовера. В результате, бесполезное расходование радиоресурсов минимизируется, что позволяет добиться оптимальных скоростей передачи данных.

[46] Следует заметить, что в настоящем описании, в основном, рассматривается передача пакетов согласно Интернет-протоколу (IP), которая может регулироваться протоколом управления передачей «TCP» и протоколом дейтаграмм пользователя «UDP». Обычно в протоколе управления передачей «TCP», чтобы гарантировать доставку данных, используются управление потоком и коррекция ошибок, что чаще всего применяется для безошибочного трафика. В общем, протокол дейтаграмм пользователя «UDP» быстрее протокола управления передачей «TCP», и поскольку в нем не предусмотрены ни управление потоком, ни коррекция ошибок, то он обычно используется для передачи потоковых аудио- и видеоданных.

[47] Поскольку связь между исходной и целевой базовыми станциями осуществляется по IP-сети, при реализации возможностей, предложенных в настоящем изобретении, могут возникнуть некоторые проблемы с сигнализацией. В отличие от сетей 3GPP, в которых для поддержки последовательной доставки блоков данных используются технологии «ATM» (асинхронного режима передачи), для IP-сетей может оказаться необходимым переупорядочивание блоков данных. Например, для поддержки функции переупорядочивания могут использоваться таймеры или другие элементы и методы обработки данных. Кроме того, из-за того, что возможности, предложенные в настоящем изобретении, предусматривают отчеты о состоянии, то при отправке или получении таких отчетов будет отсутствовать возможность передачи других данных. Однако несмотря на указанные определенные проблемы, оптимизация эстафетной передачи, в результате, приводит к повышению эффективности передачи данных.

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

[49] Например, когда мобильный терминал передает сообщение с подтверждением передачи абонентского соединения (хендовера) на новую базовую станции, вместе с ним передается и отчет о состоянии. Сообщение с отчетом о состоянии может быть включено в сообщение с подтверждением передачи абонентского соединения (хендовера). Отдельно от сообщения с подтверждением передачи абонентского соединения (хендовера) может осуществляться обмен сообщениями (отправка и прием) между объектами управления радиоканалом «RLC». Отдельно от сообщения с подтверждением эстафетной передачи может осуществляться обмен сообщениями (отправка и прием) между объектами управления доступом к среде «MAC». Сообщение с отчетом о состоянии может содержать информацию, связанную с надлежащим приемом мобильным терминалом пользовательских данных. Сообщение с отчетом о состоянии может содержать информацию, связанную с ненадлежащим приемом мобильным терминалом пользовательских данных. Сообщение с отчетом о состоянии может содержать информацию, связанную с пользовательскими данными с наивысшим порядковым номером среди пользовательских данных с последовательными порядковыми номерами, которые были приняты надлежащим образом мобильным терминалом по нисходящему каналу от базовой станции, последней из тех, к которой он был подключен перед подключением к новой базовой станции. Сообщение с отчетом о состоянии может содержать порядковый номер пользовательских данных, последних из переданных мобильным терминалом на вышерасположенный уровень, среди пользовательских данных с базовой станции, последней из тех, к которой он был подключен перед подключением к новой базовой станции.

[50] Когда предыдущая базовая станция, то есть исходная базовая станция, посылает команду передачи абонентского соединения (хендовера) на мобильный терминал, вместе с ней передается отчет о состоянии. Сообщение с отчетом о состоянии может содержать сообщение с командой передачи абонентского соединения (хендовера). Отдельно от сообщения с командой передачи абонентского соединения (хендовера) может осуществляться обмен сообщениями (отправка и прием) между объектами управления радиоканалом «RLC». Отдельно от сообщения с командой передачи абонентского соединения (хендовера) может осуществляться обмен сообщениями (отправка и прием) между объектами управления доступом к среде «MAC». Сообщение с отчетом о состоянии может содержать информацию, связанную с надлежащим приемом исходной базовой станцией пользовательских данных. Сообщение с отчетом о состоянии может содержать информацию, связанную с ненадлежащим приемом исходной базовой станцией пользовательских данных. Сообщение с отчетом о состоянии может содержать информацию, связанную с пользовательскими данными с наивысшим порядковым номером среди пользовательских данных, которые приняты по восходящему каналу исходной базовой станцией. Сообщение с отчетом о состоянии может содержать порядковый номер пользовательских данных, последних из доставленных исходной базовой станцией на вышерасположенный уровень среди пользовательских данных, принятых исходной базовой станцией по восходящему каналу. Сообщение с отчетом о состоянии может содержать все порядковые номера пользовательских данных, доставленных исходной базовой станцией на вышерасположенный уровень, среди пользовательских данных, принятых исходной базовой станцией по восходящему каналу. Сообщение с отчетом о состоянии может содержать все порядковые номера пользовательских данных, доставленных на вышерасположенный уровень исходной базовой станцией после передачи на мобильный терминал команды передачи абонентского соединения (хендовера), среди пользовательских данных, принятых исходной базовой станцией по восходящему каналу. Вышерасположенный уровень может быть базовой сетью. Сообщение с отчетом о состоянии может быть создано на основе пользовательских данных, передаваемых и принимаемых до момента отправки исходной базовой станцией команды передачи абонентского соединения (хендовера) на мобильный терминал.

[51] Кроме того, в настоящем изобретении предполагается, что когда мобильный терминал получает доступ к новой базовой станции (то есть целевой базовой станции), то новая базовая станция передает отчет о состоянии, когда мобильный терминал получает доступ к базовой станции уже в области или зоне, управляемой этой новой базовой станцией.

[52] Когда сообщение с подтверждением передачи абонентского соединения (хендовера) принимается с мобильного терминала, целевая базовая станция в свое ответное сообщение может включить сообщение с отчетом о состоянии. Когда сообщение с подтверждением передачи абонентского соединения (хендовера) принимается с мобильного терминала, целевая базовая станция в качестве своего ответа может передать сообщение с отчетом о состоянии. Отдельно от сообщения, используемого для ответа на сообщение с подтверждением передачи абонентского соединения (хендовера), может осуществляться обмен (отправка и прием) сообщениями с отчетом о состоянии между объектами управления радиоканалом «RLC». Отдельно от сообщения, используемого для ответа на сообщение с подтверждением передачи абонентского соединения (хендовера), может осуществляться обмен (отправка и прием) сообщениями с отчетом о состоянии между объектами управления доступом к среде «MAC». Сообщение с отчетом о состоянии может содержать информацию, связанную с надлежащим приемом сетью пользовательских данных. Сообщение с отчетом о состоянии может содержать информацию, связанную с ненадлежащим приемом сетью пользовательских данных. Сообщение с отчетом о состоянии может содержать информацию, связанную с пользовательскими данными с наивысшим порядковым номером среди пользовательских данных, принятых сетью по восходящему каналу. Сообщение с отчетом о состоянии может содержать порядковый номер пользовательских данных, последних из доставленных на вышерасположенный уровень сетью, среди пользовательских данных, принятых сетью по восходящему каналу. Сообщение с отчетом о состоянии может содержать все порядковые номера пользовательских данных, доставленных сетью на вышерасположенный уровень, из пользовательских данных, принятых сетью по восходящему каналу. Сообщение с отчетом о состоянии может содержать все порядковые номера пользовательских данных, доставленных исходной базовой станцией на вышерасположенный уровень после передачи на мобильный терминал команды передачи абонентского соединения (хендовера), из пользовательских данных, принятых исходной базовой станцией по восходящему каналу. Вышерасположенный уровень может быть базовой сетью. Сеть может быть исходной базовой станцией, целевой базовой станцией или обеими станциями. Сообщение с отчетом о состоянии может быть создано на основе пользовательских данных, передаваемых и принимаемых до момента отправки исходной базовой станцией команды передачи абонентского соединения (хендовера) на мобильный терминал.

[53] После передачи команды передачи абонентского соединения (хендовера) исходная базовая станция передает по нисходящему каналу данные, хранящиеся в ее буфере, на целевую базовую станцию. В этом процессе из всех данных, передаваемых по нисходящему каналу, исходная базовая станция передает на целевую базовую станцию только пользовательские данные, для которых подтверждение приема с мобильного терминала не получено до момента времени передачи ею команды передачи абонентского соединения (хендовера).

[54] После передачи команды на выполнение хендовера исходная базовая станция передает по нисходящему каналу данные, хранящиеся в ее буфере, на целевую базовую станцию. В этом процессе из всех данных, передаваемых по нисходящему каналу, исходная базовая станция передает на целевую базовую станцию только пользовательские данные, для которых с мобильного терминала не было получено подтверждение приема, до момента приема с мобильного терминала подтверждения приема команды на выполнение хендовера, направленной мобильному терминалу. Исходная базовая станция может информировать целевую базовую станцию об информации, связанной с пользовательскими да