Идентификация однонаправленного радиоканала для транзитного автосоединения и ретрансляции в расширенном lte

Идентификация однонаправленного радиоканала для транзитного автосоединения и ретрансляции в расширенном lte

Иллюстрации

Показать все

Реферат

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

Принятие связи с множеством скачков предложено для систем стандарта Long Term Evolution (долгосрочное развитие, LTE) для улучшения зоны охвата и емкости сетей LTE. В системах сотовой связи с множеством скачков передача информации между базовой станцией и терминалом пользователя (UT) может осуществляться с множеством скачков с помощью дополнительных промежуточных узлов. Существуют разные типы промежуточных узлов. Повторители функционируют на Уровне 1, усиливая принятый сигнал. Ретрансляторы декодируют принятый транспортный блок перед пересылкой и запрашивают повторные передачи HARQ в случае необходимости, соответственно, функционируют на Уровне 2. Транзитное автосоединение является технологией ретрансляции Уровня 3 для улучшения зоны охвата и скоростей передачи данных сети LTE. Термины "ретранслятор" и "ретрансляция", используемые в этом описании, относятся к ретрансляции и уровня 2, и уровня 3, если не указано иное.

При использовании ретрансляции пакеты из множества терминалов пользователя отображаются в общий однонаправленный радиоканал транзитного соединения, который переносит трафик для множества терминалов пользователя между базовой станцией (eNB) и ретранслятором. Для обеспечения возможности мультиплексирования пользователей на канале транзитного соединения между базовой станцией и ретранслятором необходимо, чтобы ретранслятор, после приема пакета, доставлял принятые пакеты надлежащему пользователю в направлении нисходящего канала. При использовании туннелирования между базовой станцией и ретранслятором однонаправленный канал пользователя идентифицируется по заголовку GTP-u пакета. Недостатком этого подхода является то, что заголовок должен передаваться по каналу транзитного соединения с созданием излишней служебной информации на радиоресурсе. Кроме того, существующие механизмы уплотнения заголовка, например, механизм Robust Header Compression (Надежное уплотнение заголовка, RoHC), не могут быть использованы для сокращения служебной информации из-за туннелирования GTP. Служебная информация из заголовка GTP-u и связанных заголовков UDP/IP приводит к излишней растрате дефицитных радиоресурсов.

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

Настоящее изобретение относится к способу и устройству для идентификации однонаправленного канала и терминала пользователя, которые сокращают служебную информацию для ретрансляции в LTE (уровень 2 и уровень 3), что экономит радиоресурсы на канале транзитного соединения. Сокращение служебной информации достигается посредством предоставления более эффективного механизма идентификации однонаправленного канала и терминала пользователя по сравнению с использованием заголовков GTP-u и связанных заголовков UDP/IP.

В одном из вариантов осуществления посредством сигнализации идентификатора однонаправленного радиоканала и терминала пользователя на уровнях протокола UP (PDCP, RLC и MAC) радиоканала обеспечена возможность идентификации однонаправленного канала и терминала пользователя. В этом варианте осуществления можно полностью удалять заголовки GTP-u и связанные заголовки UDP/IP и обеспечивать возможность уплотнения заголовка пакетов IP конечного пользователя непосредственно на канале транзитного соединения.

Во втором варианте осуществления посредством введения дополнительного уровня протокола UP на радиоканале выше уровня Протокола конвергенции пакетных данных (PDCP), который заменяет излишние заголовки GTP и связанные заголовки UDP/IP специальным полем идентификационного номера однонаправленного канала для сокращения служебной информации, связанной с этими заголовками, обеспечена возможность идентификации однонаправленного канала и терминала пользователя. На этом уровне протокола также можно уплотнять заголовки пакетов конечного пользователя, или они могут быть уплотнены на уровне PDCP канала транзитного соединения с предположением о том, что поле идентификационного номера однонаправленного канала может быть прозрачно передано через уплотнение заголовка.

В третьем варианте осуществления обеспечена возможность идентификации однонаправленного канала и терминала пользователя посредством введения уровня уплотнения заголовка в туннеле GTP, в котором уплотняются пакеты IP конечного пользователя. В этом варианте осуществления могут использоваться заголовки GTP-u и связанные заголовки UDP/IP, и общая протокольная служебная информация, тем не менее, будет на низком уровне, особенно если на канале транзитного соединения используется уплотнение заголовка уровней UDP/IP.

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

На фиг.1 изображена примерная система связи с множеством скачков.

На фиг.2 изображена примерная архитектура протокола для системы связи с множеством скачков.

На фиг.3 изображена примерная архитектура протокола для системы связи с множеством скачков, в которой информация о специфичном для пользователя однонаправленном канале вмещается в уровне протокола радиоканала, например, уровне PDCP, RLC или MAC.

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

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

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

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

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

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

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

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

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

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

На фиг.14 изображена примерная донорная базовая станция и ретранслятор для системы связи с множеством скачков.

Подробное описание

На фиг.1 изображена примерная сеть 10 связи, обозначенная в целом ссылочной позицией 10, в которой используется ретрансляция с транзитным автосоединением. Сеть 10 связи содержит базовую 14 сеть и сеть 16 радиодоступа. Базовая 14 сеть включает в себя узел обслуживающего шлюза (S-GW) 15, предоставляет соединение с сетью передачи пакетных данных, например, с сетью Internet. S-GW 15 маршрутизирует трафик в терминалы 20 пользователя и из них и функционирует внутри сети 10 связи. Сеть 16 радиодоступа содержит множество базовых станций 18, предоставляющих зону радиоохвата в соответствующих сотах 12 сети 10 связи. На фигурах изображены две базовые станции 18: базовая станция с транзитным автосоединением или некоторый другой тип ретрансляционного устройства, называемого в этом описании ретранслятором 18a, и донорная базовая станция 18b. Ретранслятор 18a беспроводным способом соединен с базовой сетью 14 через донорную базовую станцию 18b. Радиотехнология, используемая для канала транзитного автосоединения между ретранслятором 18a и донорной базовой станцией 18b, основана на идентичной радиотехнологии, используемой для связи с терминалами 20 пользователя, возможно, с некоторыми дополнительными оптимизирующими расширениями для применения транзитного соединения. В качестве примера, когда донорная базовая станция 18b и ретранслятор 18a используют радиодоступ LTE для связи с терминалами 20 пользователя внутри соты, для канала транзитного автосоединения также должен использоваться радиоканал на основе LTE или, по меньшей мере, LTE-подобный радиоканал.

Настоящее изобретение предоставляет способ идентификации терминала 20 пользователя, обслуживаемого ретранслятором 18a через донорную базовую станцию 18b как для связи по восходящему каналу, так и для связи по нисходящему каналу. Для понимания настоящего изобретения ниже приведен краткий обзор архитектуры стека протоколов. На фиг.2 изображена одна примерная архитектура стека протоколов сквозной передачи, где донорная базовая станция 18b скрывает ретранслятор 18a от базовой сети 14. Соответственно, терминал 20 пользователя, обслуживаемый ретранслятором 18a, виден из остальной части сети 10 как обслуживаемый непосредственно через донорную базовую станцию 18b. Передача по нисходящему каналу (DL) может следовать справа налево на фиг.2. Можно видеть, что пакеты нисходящего канала для терминала 20 пользователя сначала туннелируются из обслуживающего шлюза (S-GW) 15 в базовой сети 14 в донорную базовую станцию 18b (нисходящий канал), поскольку S-GW 15 полагает, что терминал 20 пользователя соединен с базовой станцией 18b. Существует один туннель GTP для каждого однонаправленного канала терминала пользователя.

Самым очевидным способом пересылки пакетов донорной базовой станцией 18b в терминал 20 пользователя является преобразование входящего туннеля GTP в исходящий туннель GTP по направлению к ретранслятору 18a посредством взаимно однозначного отображения, то есть на канале транзитного соединения также существует один туннель GTP для каждого однонаправленного канала терминала пользователя. Базовая станция 18b отображает пакеты в общий однонаправленный радиоканал транзитного соединения, то есть пакеты множества терминалов 20 пользователя отправляются на идентичном однонаправленном радиоканале на канале транзитного соединения. Может существовать множество однонаправленных радиоканалов транзитного соединения для разных классов QoS. После получения пакетов в ретрансляторе 18a ретранслятор 18a отображает пакеты в соответствующие однонаправленные радиоканалы терминала пользователя на канале между ретранслятором 18a и терминалом 20 пользователя на основе ID туннеля GTP (TEID).

Несмотря на то, что архитектура протокола, показанная на фиг.2, предоставляет основу для понимания настоящего изобретения, специалистам в данной области техники будет понятно, что описанные принципы применимы к другим реализациям архитектуры протокола транзитного автосоединения. Настоящее изобретение, в общем, применимо к любым альтернативам, где донорная базовая станция 18b может идентифицировать однонаправленные каналы терминала пользователя, к которым относятся входящие пакеты. Для выполнения этой идентификации не обязательно требуется, чтобы туннели GTP, исходящие из SGW 15 и относящиеся к индивидуальным однонаправленным каналам терминала пользователя, заканчивались в донорной базовой станции 18b, как показано выше на фиг.2. Например, в реализациях протокола, где туннель проходит прозрачно через донорную базовую станцию 18b, базовая станция 18b может идентифицировать однонаправленные каналы терминала пользователя посредством мониторинга ID проходящих через нее туннелей.

Во время обычной передачи данных из базовой станции 18b в терминал 20 пользователя терминал 20 пользователя адресуется через PDCCH (физический канал управления нисходящего канала) как для передач по DL, так и для передач по UL. Когда данные передаются между донорной базовой станцией 18b и ретранслятором 18a, удобно адресовать ретранслятор 18a вместо индивидуальных терминалов 20 пользователя на PDCCH. В противном случае распределение PDCCH должно передаваться отдельно для каждого терминала 20 пользователя, что не приемлемо, потому что предполагается, что в системе LTE PDCCH является ограниченным ресурсом.

Для решения по пересылке, показанного на фиг.2, базовая станция 18b отображает пакеты из множества терминалов 20 пользователя в общий однонаправленный радиоканал транзитного соединения. Ретранслятор 18a должен быть способен доставлять принятые пакеты в терминал 20 надлежащего пользователя. Терминал пользователя и соответствующий однонаправленный радиоканал могут быть идентифицированы на основе ID туннеля GTP. Для обеспечения возможности мультиплексирования терминалов 20 пользователей на канале транзитного соединения между базовой станцией 18b и ретранслятором 18a необходимо, чтобы ретранслятор 18a, после приема пакета, связывал принятые пакеты с надлежащим терминалом 20 пользователя. Одним решением является определение идентификационного номера терминала пользователя из заголовка GTP-u пакетов, принятых из S-GW 15. Недостатком этого подхода является то, что заголовок должен передаваться по каналу транзитного соединения и, соответственно, создавать излишнюю служебную информацию на радиоресурсе. Кроме того, механизм устойчивого к ошибкам уплотнения заголовка (RoHC) не применим к битам служебной информации. Служебная информация из заголовка GTP-u и связанных заголовков UDP/IP, следовательно, приводит к излишней растрате дефицитных радиоресурсов.

Настоящее изобретение посредством предоставления более эффективного механизма идентификации однонаправленного канала и терминала пользователя по сравнению с использованием заголовков GTP-u и связанных заголовков UDP/IP сокращает служебную информацию для ретрансляции в сетях LTE (уровень 2 и уровень 3). Получающееся в результате сокращение служебной информации экономит радиоресурсы на канале транзитного соединения.

В первом варианте осуществления, изображенном на фиг.3, посредством включения идентификатора однонаправленного канала и терминала пользователя в один из уровней (PDCP, RLC и MAC) протокола плоскости пользователя (UP) на радиоканале между донорной базовой станцией 18b и ретранслятором 18a обеспечена возможность идентификации однонаправленного канала и терминала пользователя. Для удобства уровни протокола UP на радиоканале в этом описании называются уровнями протокола радиоканала, поскольку эти уровни задаются применимой спецификацией радиоинтерфейса. В первом варианте осуществления туннель GTP заканчивается в донорной базовой станции 18b. Донорная базовая станция 18b полностью удаляет заголовки GTP-u и связанные заголовки UDP/IP для обеспечения возможности уплотнения заголовка пакетов IP конечного пользователя непосредственно на канале транзитного соединения. Донорная базовая станция 18b включает в себя идентификатор однонаправленного канала и терминала пользователя внутри одного из уровней протокола плоскости пользователя радиоинтерфейса для обеспечения возможности отображения в нисходящем канале в ретрансляторе 18a из входящего однонаправленного радиоканала транзитного соединения в специфичный для терминала пользователя однонаправленный радиоканал и в восходящем канале в базовой станции 18b из однонаправленного радиоканала транзитного соединения в специфичный для терминала пользователя туннель GTP.

Для вставки идентификатора однонаправленного канала и терминала пользователя на уровне PDCP могут использоваться два разных подхода. В первом подходе в заголовке PDCP вводится отдельное поле для идентификации однонаправленного канала терминала пользователя. В этом поле указывается то, по какому однонаправленному радиоканалу терминала пользователя должен быть передан пакет ретранслятором 18a для связи по нисходящему каналу, и по какому туннелю GTP пакет должен быть передан базовой станцией 18b для связи по восходящему каналу. В этом подходе можно или исполнять отдельный PDCP-механизм (т.е. механизмы (раз)уплотнения и (де)шифрования заголовка) для каждого однонаправленного канала терминала пользователя (мультиплексирование ниже PDCP), или, в качестве альтернативы, исполнять один механизм PDCP для каждого однонаправленного канала транзитного соединения (мультиплексирование выше PDCP). При этом подходе могут потребоваться изменения стандартизации для протокола PDCP.

Второй подход для вставки идентификатора однонаправленного канала и терминала пользователя в уровень PDCP заключается в повторном использовании, в канале транзитного соединения, существующего поля CID (контекстный идентификатор) в протоколе уплотнения заголовка как поля идентификации однонаправленного канала терминала пользователя для указания того, в какие специфичные для терминала пользователя туннель GTP (восходящий канал) и однонаправленный радиоканал (нисходящий канал) должен быть отображен пакет, принятый по каналу транзитного соединения. Поле CID в протоколе уплотнения заголовка обычно используется для идентификации потоков приложения. В этом подходе поле CID используется в протоколе уплотнения заголовка на канале транзитного соединения для идентификации однонаправленного радиоканала терминала пользователя, в котором требуется, чтобы разным туннелям GTP/однонаправленным радиоканалам терминала пользователя всегда назначались разные значения CID (возможно ~65000 значений). Отображение между туннелями GTP/однонаправленными радиоканалами терминала пользователя и CID может или быть жестко закодировано, например, RB id 1 использует CID 1-20, или оно может явно сигнализироваться между ретранслятором 18a и базовой станцией 18b, или оно может конфигурироваться с использованием системы эксплуатации и обслуживания. Возможные протоколы сигнализации включают в себя сигнализацию RRC и S1/X2. Альтернативой жесткого кодирования и явной сигнализации является неявное назначение отображения CID <-> RB/GTP, например, на основе порядка, в котором однонаправленные каналы устанавливаются, или некоторой другой схемы. Преимуществом этого подхода является то, что он не предписывает изменения стандартизации для протокола PDCP.

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

Как отмечалось ранее, идентификатор однонаправленного канала и терминала пользователя может также быть вставлен в сигнализацию уровня RLC. При этом подходе в заголовке RLC вводится отдельное поле для идентификации однонаправленного канала терминала пользователя. В этом поле указывается то, на каком однонаправленном радиоканале терминала пользователя должен быть передан пакет ретранслятором 18a (нисходящий канал), или по какому туннелю GTP пакет должен быть передан базовой станцией 18b (восходящий канал). При этом подходе предполагается то, что для каждого однонаправленного канала терминала пользователя используется отдельный PDCP-механизм (т.е. механизмы (раз)уплотнения и (де)шифрования заголовка) и возможный механизм RLC (мультиплексирование ниже PDCP или RLC). При этом решении могут потребоваться изменения стандартизации для протокола RLC.

Следует отметить, что один PDU RLC может вмещать в себя пакеты верхнего уровня, сцепленные из разных однонаправленных радиоканалов терминала пользователя. Следовательно, количество полей для идентификации однонаправленного канала терминала пользователя в заголовке RLC должно быть равно количеству единиц PDU верхнего уровня, сцепленных из разных терминалов 20 пользователя в PDU RLC. Чтобы размер заголовка оставался маленьким, следует обеспечить возможность динамической установки размера поля для идентификации однонаправленного канала терминала пользователя в каждом PDU RLC, в зависимости от конкретных сцепленных PDU верхнего уровня.

Идентификатор специфичного для терминала пользователя однонаправленного канала может также быть вставлен в сигнализацию уровня MAC. В этом подходе в заголовке MAC вводится отдельное поле для идентификации однонаправленного радиоканала терминала пользователя. Введение нового поля в заголовке MAC может быть решено посредством расширения существующего поля идентификатора логического канала (LCID) в заголовке MAC посредством специфичного для UE идентификатора терминала. В этом поле указывается то, по какому однонаправленному радиоканалу терминала пользователя должен быть передан пакет ретранслятором 18a (нисходящий канал), и по какому туннелю GTP пакет должен быть передан базовой станцией 18b (восходящий канал). При этом решении предполагается то, что для каждого однонаправленного канала терминала пользователя исполняется отдельный PDCP-механизм (т.е. механизмы (раз)уплотнения и (де)шифрования заголовка) и механизм RLC (мультиплексирование выполняется на уровнях MAC). При этом подходе могут потребоваться изменения стандартизации для протокола MAC.

Следует отметить, что один PDU MAC может вмещать в себя пакеты верхнего уровня, мультиплексированные из разных однонаправленных радиоканалов терминала пользователя. Следовательно, количество полей для идентификации однонаправленного канала терминала пользователя в заголовке MAC должно быть равно количеству единиц PDU верхнего уровня, мультиплексированных из разных терминалов 20 пользователя в данный PDU MAC. Для сохранения области заголовка следует обеспечить возможность динамической установки размера поля для идентификации однонаправленного канала терминала пользователя в каждом PDU MAC, в зависимости от конкретных мультиплексных PDU верхнего уровня.

Во втором варианте осуществления настоящего изобретения, изображенного на фиг.4, посредством введения дополнительного уровня протокола UP выше уровня PDCP, который заменяет заголовки GTP и связанные заголовки UDP/IP специальным полем для идентификации однонаправленного канала для сокращения служебной информации, связанной с этими заголовками, обеспечена возможность идентификации однонаправленного канала и терминала пользователя. Для того чтобы также сократить служебную информацию, полезно обеспечить возможность уплотнения заголовка пакетов конечного пользователя. Уплотнение заголовка может выполняться на новом уровне протокола UP. В качестве альтернативы, уплотнение заголовка может выполняться на уровне PDCP канала транзитного соединения с предположением того, что поле для идентификации однонаправленного канала можно передавать прозрачно через уплотнение заголовка.

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

Если уплотнение заголовка выполняется на уровне PDCP, то на уровне PDCP должно игнорироваться поле идентификации однонаправленного канала, добавляемое на более высоком уровне. Одним подходом для решения этой проблемы является явное конфигурирование уровня PDCP для игнорирования первого из последних N байтов, в которых переносится идентификация однонаправленного канала и терминала пользователя. В качестве альтернативы, идентификация однонаправленного канала и терминала пользователя может быть присоединена как концевик (в конце) пакетов IP. В общем, концевик игнорируется алгоритмом уплотнения заголовка, в котором больше внимания обращается на начало пакета. Это предполагает то, что алгоритм уплотнения заголовка не зависит от длины пакета IP. В случае если алгоритм уплотнения заголовка зависит от длины пакета IP, то может потребоваться, чтобы верхний уровень модифицировал поле длины IP (например, посредством добавления фиксированного количества байтов) и другие поля, например, поля длины TCP/UDP и контрольной суммы IP и т.д.

Во втором варианте осуществления все мультиплексирование разных однонаправленных каналов терминала пользователя выполняется выше PDCP, что означает то, что объект PDCP существует для каждого однонаправленного канала транзитного соединения (не для каждого однонаправленного канала терминала пользователя).

В третьем варианте осуществления, изображенном на фиг.5, обеспечена возможность идентификации однонаправленного канала и терминала пользователя посредством введения уровня уплотнения заголовка в туннеле GTP, в котором уплотняются пакеты IP конечного пользователя. Более конкретно, для уплотнения заголовка GTP-u вводится уровень PDCP уплотнения заголовка (HC-PDCP). Было отмечено, что дополнительный уровень уплотнения заголовка не обязательно означает новые заголовки протокола, например, заголовки PDCP. В типичном варианте осуществления это может быть реализовано посредством исполнения обычных устройств уплотнения заголовка IP (например, RoHC) на двух концах канала, которые заменяют поля заголовка IP (или его части) их уплотненной формой. В этом варианте осуществления могут быть сохранены заголовки GTP-u и связанные заголовки UDP/IP, так как объекты HC-PDCP на канале транзитного соединения уплотняют заголовки GTP/UDP/IP. Ретранслятор 18a может зависеть от заголовка GTP-u для определения отображения между туннелями GTP и однонаправленными радиоканалами терминала пользователя. Возможными протоколами для конфигурирования уплотнения заголовка внутри туннеля GTP могут быть сигнализация RRC или GTP-c или сигнализация S1.

Другой потенциальной альтернативой для этого варианта осуществления является отсутствие дополнительного уровня уплотнения заголовка (HC-PDCP) в туннеле GTP и расширение профилей уплотнения заголовка протокола PDCP канала транзитного соединения так, что он может обрабатывать уплотнение заголовков туннеля GTP/UDP/IP и заголовков протокола IP конечного пользователя вместе. Это требует новых профилей уплотнения для алгоритма уплотнения заголовка RoHC (Надежное уплотнение заголовка), который может обрабатывать заголовки TCP/UDP (конечный пользователь) и GTP как заголовки расширения во время уплотнения.

Специалистам в данной области техники будет понятно, что узлы сети 10, изображенные на фиг.2-5, могут содержать специально запрограммированные компьютерные системы, которые запрограммированы для вышеописанного функционирования. Компьютерные системы могут содержать один или более процессоров, микроконтроллеры, аппаратные средства или их комбинации вместе с памятью для хранения данных и команд программирования, необходимых для вышеописанного функционирования.

На фиг.6 и фиг.7 изображено функционирование донорной базовой станции 18b в одном примерном варианте осуществления изобретения. В этом варианте осуществления информация идентификации вставляется в пакеты протокола радиоканала, передаваемые по мультиплексному каналу транзитного соединения между донорной базовой станцией 18b и ретранслятором 18a.

На фиг.6 изображена примерная процедура 100, осуществляемая донорной базовой станцией 18b для пересылки пакетов нисходящего канала, предназначенных для терминала 20 пользователя. Процедура 100 начинается, когда донорная базовая станция 18b принимает пакет данных из обслуживающего шлюза 15 по специфичному для пользователя туннелю для доставки в терминал 20 пользователя (этап 102). Донорная базовая станция 18b отображает идентификатор туннеля для специфичного для пользователя туннеля в специфичный для пользователя идентификатор, используемый на канале между ретранслятором 18a и донорной базовой станцией 18b (этап 104), и пересылает пакет данных в ретранслятор 18a по мультиплексному каналу транзитного соединения в одном или более пакетах протокола радиоканала (этап 106). Базовая станция 18b вставляет специфичный для пользователя идентификатор, по меньшей мере, в один из пакетов протокола радиоканала для обеспечения возможности ретранслятору 18a идентифицировать терминал 20 пользователя, для которого предназначен этот пакет данных (этап 108). Как отмечалось ранее, специфичный для пользователя идентификатор может содержать специфичный для пользователя идентификатор однонаправленного радиоканала, который идентифицирует специфичный однонаправленный радиоканал, назначенный терминалу пользователя. Специфичный для пользователя идентификатор однонаправленного радиоканала может быть вставлен в заголовок PDCP, заголовок RLC или заголовок MAC пакетов протокола радиоканала. Ретранслятор 18a далее пересылает пакет в терминал 20 пользователя по указанному специфичному для пользователя однонаправленному радиоканалу.

На фиг.7 изображена примерная процедура 150, осуществляемая донорной базовой станцией 18b для пересылки пакетов по восходящему каналу, принятых из ретранслятора 18a, в обслуживающий шлюз 15. Процедура 150 начинается, когда донорная базовая станция 18b принимает пакет данных из ретранслятора 18a по мультиплексному каналу транзитного соединения в одном или более пакетах протокола радиоканала (этап 152). Перед передачей пакета данных ретранслятор 18a вставляет специфичный для пользователя идентификатор, по меньшей мере, в один из пакетов протокола радиоканала. Донорная базовая станция 18b определяет терминалы пользователя, отправляющие пакет данных, исходя из специфичного для пользователя идентификатора, вставленного в заголовок, по меньшей мере, одного из пакетов протокола радиоканала (этап 154). Донорная базовая станция 18b определяет идентификатор туннеля для специфичного для пользователя туннеля между донорной базовой станцией 18b и шлюзом 15 на основе специфичного для пользователя идентификатора (этап 156) и пересылает пакет данных в шлюз 15 по специфичному для пользователя туннелю для идентифицированного терминала пользователя (этап 158).

На фиг.8 и фиг.9 изображено функционирование ретранслятора 18a в одном примерном варианте осуществления изобретения. В этом варианте осуществления информация идентификации вставляется в пакеты протокола радиоканала, передаваемые по мультиплексному каналу транзитного соединения между донорной базовой станцией 18b и ретранслятором 18a.

На фиг.8 изображена примерная процедура 200 для пересылки пакетов по нисходящему каналу, принятых из донорной базовой станции 18b, в терминал 20 пользователя. Процедура 200 начинается, когда ретранслятор 18a принимает пакет данных из терминала 20 пользователя (этап 202). Ретранслятор 18a пересылает пакет данных в донорную базовую станцию 18b по мультиплексному каналу транзитного соединения в одном или более пакетах протокола радиоканала (этап 204). Ретранслятор 18a вставляет специфичный для пользователя идентификатор, по меньшей мере, в один из пакетов протокола радиоканала для обеспечения возможности донорной базовой станции 18b идентифицировать терминал пользователя, для которого предназначен этот пакет данных (этап 206). Как отмечалось ранее, специфичный для пользователя идентификатор может содержать специфичный для пользователя идентификатор однонаправленного радиоканала, который идентифицирует специфичный однонаправленный радиоканал, назначенный терминалу пользователя. Специфичный для пользователя идентификатор однонаправленного радиоканала может быть вставлен в заголовок PDCP, заголовок RLC или заголовок MAC пакетов протокола радиоканала.

Донорная базовая станция 18b далее пересылает пакет в обслуживающий шлюз 15. На фиг.9 изображена примерная процедура 250, осуществляемая ретранслятором 18a для пересылки пакетов по нисходящему каналу, принятых из донорной базовой станции 18b, в терминал 20 пользователя. Процедура 250 начинается, когда ретранслятор 18a принимает пакет данных из донорной базовой станции 18b по мультиплексному каналу транзитного соединения в одном или более пакетах протокола радиоканала (этап 252). Перед передачей пакета данных ретранслятор 18a вставляет специфичный для пользователя идентификатор, по меньшей мере, в один из пакетов протокола радиоканала. Ретранслятор 18a определяет терминал пользователя, который должен принять пакет данных, исходя из специфичного для пользователя идентификатора, вставленного в заголовок, по меньшей мере, одного из пакетов протокола радиоканала (этап 254), и пересылает этот пакет данных в идентифицированный терминал пользователя (этап 256).

На фиг.10 и фиг.11 изображено функционирование донорной базовой станции 18b в альтернативном варианте осуществления изобретения. В этом варианте осуществления туннельный заголовок пакетов данных, передаваемых по специфичному для пользователя туннелю из обслуживающего шлюза 15, уплотняется для передачи по каналу транзитного соединения между донорной базовой станцией 18b и ретранслятором 18a.

На фиг.10 изображена примерная процедура 300, осуществляемая донорной базовой станцией 18b для пересылки пакетов, принятых из обслуживающего шлюза 15, в ретранслятор 18a. Процедура 300 начинается, когда донорная базовая станция 18b принимает пакет по туннелю GTP из обслуживающего шлюза 15 (этап 302). Донорная базовая станция 18b декапсулирует пакет данных и уплотняет заголовок (этап 304). Донорная базовая станция определяет терминал пользователя, для которого предназначен этот пакет данных, исходя из ID туннеля заголовка GTP-u, принятого из шлюза 15, и отображает пакет данных, принятый по входящему туннелю из обслуживающего шлюза 15, в исходящий туннель по направлению к ретранслятору 18a (этап 306). Донорная базовая станция 18b инкапсулирует уплотненный пакет данных в туннельном пакете и пересылает пакет данных в ретранслятор 18a (этап 308). Исходящий туннель является специфичным для пользователя туннелем в мультиплексном канале транзитного соединения между донорной базовой станцией 18b и ретранслятором 18a. До передачи в ретранслятор 18a донорная базовая станция 18b вставляет специфичный для пользователя идентификатор в туннельный заголовок для обеспечения возможности ретранслятору идентифицировать терминал 20 пользователя (этап 310).

На фиг.11 изображена примерная процедура 350, осуществляемая донорной базовой станцией 18b для пересылки пакетов по восходящему каналу, принятых из ретранслятора 18a по каналу транзитного соединения, в обслуживающий шлюз 15. Процедура 350 начинается, когда донорная базовая станция 18a принимает пакет данных из ретранслятора 18a по однонаправленному радиоканалу транзитного соединения (этап 352). В этом варианте осуществления предполагается, что для передачи пакетов данных по каналу транзитного соединения используется протокол туннелирования, например GTP, и что заголовок пакета данных уплотняется ретранслятором 18a до передачи. После приема пакета данных донорная базовая станция 18b декапсулирует уплотненный пакет данных (этап 354) и разуплотняет заголовок пакета данных (этап 356). Донорная базовая станция 18b определяет исходящий туннель по направлению к обслуживающему