УЛУЧШЕННОЕ ПОЛУПОСТОЯННОЕ РАСПРЕДЕЛЕНИЕ РЕСУРСОВ ДЛЯ ТРАФИКА V2V Российский патент 2019 года по МПК H04W72/04 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ НАСТОЯЩЕЕ РАСКРЫТИЕ

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

ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ

Долгосрочное Развитие (LTE)

Мобильные системы третьего поколения (3G), основанные на технологии радиодоступа WCDMA, развернуты в широком масштабе по всему миру. Первый этап улучшения или развития данной технологии влечет за собой введения Высокоскоростного Пакетного Доступа Нисходящей Линии Связи (HSDPA) и улучшенную восходящую линию связи, также именуемую Высокоскоростным Пакетным Доступом Восходящей Линии Связи (HSUPA), представляя технологию радиодоступа, которая является высококонкурентной.

Для того, чтобы быть подготовленными к дальнейшим растущим потребностям пользователя и быть конкурентными по отношению к новым технологиям радиодоступа, 3GPP ввел новую систему мобильной связи, которая именуется Долгосрочным Развитием (LTE). LTE разработано, чтобы отвечать потребностям несущей в отношении высокоскоростных данных и транспортировки мультимедиа, как, впрочем, и голосовой поддержки высокой емкости на следующее десятилетие. Возможность обеспечения высоких скоростей передачи данных является ключевым показателем для LTE.

Техническое описание рабочего вопроса (WI) по Долгосрочному Развитию (LTE), именуемое Развитый Наземный Радиодоступ UMTS (UTRA) и Наземная Сеть Радиодоступа UMTS (UTRAN), закончено в качестве Редакции 8 (LTE Rel. 8). Система LTE представляет собой эффективный основанный на пакете радиодоступ и сети радиодоступа, которые обеспечивают полную основанную на IP функциональность с низким временем ожидания и низкими затратами. В LTE, указаны масштабируемые несколько полос пропускания передачи, такие как 1.4, 3.0, 5.0, 10.0, 15.0, и 20МГц, для того, чтобы достигать гибкого развертывания системы, используя заданный спектр. В нисходящей линии связи, основанный на Мультиплексировании с Ортогональным Частотным Разделением (OFDM) радиодоступ был использован из-за присущего ему иммунитета к многолучевой интерференции (MPI) благодаря низкой скорости передачи символов, использованию циклического префикса (CP) и его совместимости с разными компоновками полосы пропускания передачи. Основанный на множественном доступе с частотным разделением и одной несущей (SC-FDMA) радиодоступ был использован в восходящей линии связи, поскольку обеспечение широкой зоны покрытия было приоритетным над улучшением в пиковой скорости передачи данных, рассматривая ограниченную мощность передачи оборудования пользователя (UE). Используется много ключевых методик пакетного радиодоступа, включая методику канальной передачи с несколькими входами и несколькими выходами (MIMO) и высокоэффективная структура сигнализации управления достигается в LTE Rel. 8/9.

Архитектура LTE

Общая архитектура LTE показана на Фиг. 1. E-UTRAN состоит из eNodeB, обеспечивая завершения протокола плоскости пользователя E-UTRA (PDCP/RLC/MAC/PHY) и плоскости управления (RRC) в направлении оборудования пользователя (UE). eNodeB (eNB) размещает Физический (PHY), Управления Доступа к Среде (MAC), Управления Линей Радиосвязи (RLC) и Протокола Управления Пакетных Данных (PDCP) слои, которые включают в себя функциональность сжатия и шифрования заголовка плоскости пользователя. Он также предлагает функциональность Управления Ресурсами Радиосвязи (RRC), соответствующую плоскости управления. Он выполняет много функций, включая администрирование ресурсов радиосвязи, управление допущением, планирование, осуществление обговоренного Качества Услуги (QoS) восходящей линии связи, широковещательную передачу информации соты, шифрование/дешифрование данные плоскости пользователя и управления, сжатие/распаковку заголовков пакета плоскости пользователя нисходящей/восходящей линии связи. eNodeB взаимно-соединены друг с другом посредством интерфейса X2.

eNodeB также соединены посредством интерфейса S1 с EPC (Развитое Пакетное Ядро), в частности, MME (Объект Управления Мобильностью) посредством S1-MME и с Обслуживающим Шлюзом (SGW) посредством S1-U. Интерфейс S1 поддерживает отношение многих-со-многими между MME/Обслуживающими Шлюзами и eNodeB. SGW осуществляет маршрутизацию и переадресовывает пакеты данных пользователя, при этом также действуя в качестве привязки мобильности для плоскости пользователя в течение меж-eNodeB передач обслуживания и в качестве привязки для мобильности между LTE и другими технологиями 3GPP (завершая интерфейс S4 и ретранслируя трафик между системами 2G/3G и PDN GW). Применительно к состоянию ожидания оборудований пользователя, SGW завершает путь данных нисходящей линии связи и инициирует поисковый вызов, когда данные нисходящей линии связи поступают для оборудования пользователя. Он осуществляет администрирование и хранит контексты оборудования пользователя, например, параметры услуги носителя IP, или сетевую внутреннюю информацию маршрутизации. Он также выполняет тиражирование трафика пользователя в случае правомерного перехвата.

MME является ключевым узлом управления для сети доступа LTE. Он отвечает за отслеживание оборудования пользователя в режиме ожидания и процедуру поискового вызова, включая повторные передачи. Он задействован в процессе активации/деактивации носителя и также отвечает за выбор SGW для оборудования пользователя при исходном прикреплении и в момент интра-LTE передачи обслуживания, которая задействует перемещение узла Базовой Сети (CN). Он отвечает за аутентификацию пользователя (посредством взаимодействия с HSS). Сигнализация Слоя Без-Доступа завершается в MME, и он также отвечает за генерирование и распределение временных идентификационных данных для оборудований пользователя. Он проверяет авторизацию оборудования пользователя, чтобы закрепляться в Наземной Сети Мобильной Связи Общего Пользования (PLMN) поставщика услуги и осуществляет ограничения роуминга оборудования пользователя. MME является точкой завершения в сети для шифрования/защиты целостности применительно к сигнализации NAS и осуществляет администрирование ключа безопасности. Правомерный перехват сигнализации также поддерживается посредством MME. MME также предоставляет функцию плоскости управления для мобильности между сетями доступа LTE и 2G/3G, с интерфейсом S3, завершающимся в MME от SGSN. MME также завершает интерфейс S6a к домашнему HSS применительно к роумингу оборудований пользователя.

Структура Составляющей Несущей в LTE

Составляющая несущая нисходящей линии связи системы 3GPP LTE подразделена в частотно-временной области на так называемые субкадры. В 3GPP LTE каждый субкадр разделен на два слота нисходящей линии связи, как показано на Фиг. 2, при этом первый слот нисходящей линии связи содержит область канала управления (область PDCCH) в первых OFDM-символах. Каждый субкадр состоит из заданного числа OFDM-символов во временной области (12 или 14 OFDM-символов в 3GPP LTE (Редакция 8)), при этом каждый OFDM-символ охватывает всю полосу пропускания составляющей несущей. OFDM-символы, таким образом, каждый состоит из некоторого числа символов модуляции, передаваемых по соответствующим поднесущим. В LTE, передаваемый сигнал в каждом слоте описывается сеткой ресурсов из поднесущих и OFDM-символов. является числом блоков ресурсов в полосе пропускания. Количество зависит от полосы пропускания передачи нисходящей линии связи, сконфигурированной в соте и должно удовлетворять , где =6 и =110 являются соответственно наименьшими и наибольшими полосами пропускания нисходящей линии связи, поддерживаемыми текущей версией технического описания. является числом поднесущих в одном блоке ресурсов. Применительно к структуре субкадра нормального циклического префикса =12 и =7.

Предполагая систему связи с несколькими несущими, например, используя OFDM, как например используемая в 3GPP Долгосрочном Развитие (LTE), наименьшей единицей ресурсов, которая может быть назначена планировщиком, является один «блок ресурсов». Физический блок ресурсов (PRB) определяется как последовательные OFDM-символы во временной области (например, 7 OFDM-символов) и последовательные поднесущие в частотной области, как приведено в качестве примера на Фиг. 2 (например, 12 поднесущих для составляющей несущей). В 3GPP LTE (Редакция 8), физический блок ресурсов, таким образом, состоит из элементов ресурсов, соответствующих одному слоту во временной области и 180кГц в частотной области (в отношении дополнительных подробностей по сетке ресурсов нисходящей линии связи, см., например, документ 3GPP TS 36.211, «Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)», текущая версия 13.0.0, раздел 6.2, доступный по адресу http://www.3gpp.org и включенный в настоящее описание посредством ссылки).

Один субкадр состоит из двух слотов, так что присутствует 14 OFDM-символов в субкадре, когда используется так называемый «нормальный» CP (циклический префикс), и 12 OFDM-символов в субкадре, когда используется так называемый «расширенный» CP. В целях терминологии, в нижеследующем частотно-временные ресурсы эквивалентные тем же самым поднесущим, охватывающим полный субкадр, именуются «парой блоков ресурсов», или эквивалентно «пара RB» или «пара PRB».

Понятие «составляющая несущая» относится к сочетанию нескольких блоков ресурсов в частотной области. В будущей редакции LTE, понятие «составляющая несущая» более не используется; вместо этого, терминология изменена на «соту», которая относится к сочетанию ресурсов нисходящей линии связи и опционально восходящей линии связи. Сцепление между частотой несущей ресурсов нисходящей линии связи и частотой несущей ресурсов восходящей линии связи указывается в информации системы, передаваемой по ресурсам нисходящей линии связи.

Сходные допущения для структуры составляющей несущей будут применяться также к более поздним редакциям.

Агрегация Несущих в LTE-A для обеспечения более широкой полосы пропускания

Решение в отношении частотного спектра для Усовершенствованного-IMT было принято на Мировой Конференции по Радиосвязи 2007 (WRC-07). Несмотря на то, что было принято решение о всем частотном спектре для Усовершенствованного-IMT, фактическая доступная полоса пропускания частоты отличается в соответствии с каждой областью или страной. Вслед за решением о доступной структуре частотного спектра, тем не менее, в Проекте Партнерства 3-его Поколения (3GPP) началась стандартизация радиоинтерфейса. На конференции 3GPP TSG RAN #39 было согласовано описание Предмета Исследования по «Further Advancements for EUTRA (LTE-Advanced). Предмет исследования охватывает технологические компоненты, которые должны быть рассмотрены для развития E-UTRA, например, чтобы удовлетворять требования Усовершенствованного-IMT.

Полоса пропускания, которую способна обеспечивать система Усовершенствованного-LTE, составляет 100МГц, тогда как система LTE может обеспечивать только 20МГц. В настоящее время, отсутствие спектра радиосвязи стало узким местом развития беспроводных сетей, и, как результат, сложно найти полосу спектра, которая является достаточно широкой для системы Усовершенствованного-LTE. Конечно, необходимо срочно найти способ для получения более широкой полосы спектра радиосвязи, при этом возможным ответом является функциональность агрегации несущих.

При агрегации несущих, осуществляют агрегацию двух или более составляющих несущих для того, чтобы обеспечивать более широкие полосы пропускания передачи вплоть до 100МГц. Осуществляют агрегацию нескольких сот в системе LTE в один более широкий канал в системе Усовершенствованного LTE, который является достаточно широким для 10МГц даже несмотря на то, что эти соты в LTE могут быть в разных полосах частот.

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

Оборудование пользователя может одновременно осуществлять прием или передачу по одной или нескольким составляющим несущим (соответствующим нескольким обслуживающим сотам) в зависимости от его возможностей. Оборудование пользователя LTE-A Rel. 10 с возможностями приема и/или передачи применительно к агрегации несущих может одновременно принимать и/или передавать по нескольким обслуживающим сотам, тогда как оборудование пользователя LTE Rel. 8/9 может принимать и передавать только по одной обслуживающей соте, при условии, что структура составляющей несущей следует техническим описания Rel. 8/9.

Агрегация несущих поддерживается как для смежных, так и несмежных составляющих несущих, с каждой составляющей несущей ограниченной максимум 110 Блоками Ресурсов в частотной области (используя нумерологию 3GPP LTE (Редакция 8/9).

Можно сконфигурировать 3GPP LTE-A (Редакция 10)-совместимое оборудование пользователя, чтобы осуществлялась агрегация разного числа составляющих несущих, происходящих от одного и того же eNodeB (базовой станции) и возможно разных полос пропускания в восходящей линии связи и нисходящей линии связи. Число составляющих несущих нисходящей линии связи, которые могут быть сконфигурированы, зависит от возможности агрегации нисходящей линии связи у UE. И наоборот, число составляющих несущих восходящей линии связи, которые могут быть сконфигурированы, зависит от возможности агрегации восходящей линии связи у UE. В настоящий момент может быть невозможным конфигурировать мобильный терминал большим числом составляющих несущих восходящей линии связи, чем составляющие несущие нисходящей линии связи. В типичном развертывании TDD число составляющих несущих и полоса пропускания каждой составляющей несущей в восходящей линии связи и нисходящей линии связи является одинаковым. Не требуется, чтобы составляющие несущие, происходящие от одного и того же eNodeB, обеспечивали одинаковое покрытие.

Интервал между центральными частотами смежных агрегированных составляющих несущих должен быть кратным 300кГц. Это для того, чтобы быть совместимым с 100кГц частотным растром у 3GPP LTE (Редакция 8/9) и в тоже самое время сохранять ортогональность поднесущих с 15кГц интервалом. В зависимости от сценария агрегации, n × 300кГц интервал может быть облегчен посредством вставки низкого числа неиспользуемых поднесущих между смежными составляющими несущими.

Сущность агрегации нескольких несущих раскрывается только вплоть до слоя MAC. Как для восходящей линии связи, так и нисходящей линии связи существует один объект HARQ, требуемый в MAC для каждой агрегированной составляющей несущей. Существует (в отсутствие SU-MIMO для восходящей линии связи) не больше одного транспортного блока на составляющую несущую. Транспортный блок и его потенциальные повторные передачи HARQ, должны быть отображены в одной и той же составляющей несущей.

Когда конфигурируется агрегация несущих, мобильный терминал имеет только одно соединение RRC с сетью. При создании/повторном создании соединения RRC, одна сота обеспечивает безопасный ввод (одну ECGI, одну PCI и одну ARFCN) и информацию мобильности слоя без доступа (например, TAI) сходно с тем, как в LTE Rel. 8/9. После создания/повторного создания соединения RRC, составляющая несущая соответствующая той соте именуется как Первичная Сота (PCell) нисходящей линии связи. Всегда присутствует одна и только одна PCell нисходящей линии связи (DL PCell) и одна PCell восходящей линии связи (UL PCell), сконфигурированные из расчета на оборудование пользователя в соединенном состоянии. В рамках сконфигурированного набора составляющих несущих, другие соты именуются Вторичными Сотами (SCell); с несущими SCell являющимися Вторичной Составляющей Несущей Нисходящей Линии Связи (DL SCC) и Вторичной Составляющей Несущей Восходящей Линии Связи (UL SCC). Максимум пять обслуживающих сот, включая PCell, может быть сконфигурировано для одного UE.

Слой/объект MAC, слой RRC, Физический слой

Стек протоколов плоскости пользователя/плоскости управления LTE слоя 2 содержит четыре подслоя, RRC, PDCP, RLC и MAC. Слой Управления Доступом к Среде (MAC) является самым нижним подслоем в архитектуре Слоя 2 у стека протоколов радиосвязи LTE и определяется посредством, например, технического стандарта 3GPP TS 36.321, текущая версия 13.0.0. Соединение с физическим слоем ниже осуществляется через транспортные каналы, а соединение со слоем RLC выше осуществляется через логические каналы. Вследствие этого слой MAC выполняет мультиплексирование и демультиплексирование между логическими каналами и транспортными каналами: слой MAC на передающей стороне создает MAC PDU, известные как транспортные блоки, из MAC SDU, принятых через логические каналы, и слой MAC на принимающей стороне восстанавливает MAC SDU из MAC PDU, принятые через транспортные каналы.

Слой MAC предоставляет услугу переноса данных (см. подстатьи 5.4 и 5.3 TS 36.321 включенные в настоящее описание посредством ссылки) для слоя RLC через логические каналы, которые являются либо логическими каналами управления, которые несут данные управления (например, сигнализацию RRC), либо логическими каналами трафика, которые несут данные плоскости пользователя. С другой стороны, обмен данными из слоя MAC осуществляется с физическим слоем через транспортные каналы, которые классифицируются как нисходящая линия связи или восходящая линия связи. Данные мультиплексируются в транспортные каналы в зависимости от того, каким образом они передаются по воздуху.

Физический слой отвечает за фактическую передачу данных и информации управления через радиоинтерфейс, т.е., Физический Слой несет всю информацию из транспортных каналов MAC через радиоинтерфейс на стороне передачи. Некоторые из важных функций, выполняемых Физическим слоем, включают в себя кодирование и модуляцию, адаптацию линии связи (AMC), управление мощностью, поиск соты (для исходной синхронизации и в целях передачи обслуживания) и другие меры (внутри системы LTE и между системами) для слоя RRC. Физический слой выполняет передачи, основанные на параметрах передачи, таких как схема модуляции, скорость кодирования (т.е. схема модуляции и кодирования, MCS), число физических блоков ресурсов и т.д. Больше информации о функционировании физического слоя можно найти в техническом стандарте 3GPP 16.213, текущая версия 13.0.0, включенном в настоящее описание посредством ссылки.

Слой Управления Ресурсами Радиосвязи (RRC) управляет связью между UE и eNB на радиоинтерфейсе и мобильностью UE, перемещающегося по нескольким сотам. Протокол RRC также поддерживает перенос информации NAS. Применительно к UE в RRC_IDLE, RRC поддерживает уведомление из сети о входящих вызовах. Управление соединением RRC охватывает все процедуры, относящиеся к созданию, модификации и высвобождению соединения RRC, включая поисковый вызов, конфигурацию измерения и представление отчета, конфигурацию ресурса радиосвязи, исходную активацию безопасности, и создание Носителя Радиосвязи Сигнализации (SRB) и носителей радиосвязи, несущих данные пользователя (Носители Радиосвязи Данных, DRB).

Подслой управления линией радиосвязи (RLC) содержит главным образом функциональность ARQ и поддерживает сегментацию и сочленение данных, т.е., слой RLC выполняет организацию кадра из RLC SDU, чтобы помещать их в размер, указанный слоем MAC. Последние два минимизируют служебные данные протокола независимо от скорости передачи данных. Слой RLC соединен со слоем MAC через логические каналы. Каждый логический канал транспортирует разные типы трафика. Слой над слоем RLC является, как правило, слоем PDCP, но в некоторых случаях он является слоем RRC, т.е. сообщения RRC передаются по логическим каналам BCCH (Широковещательный Канал Управления), PCCH (Канал Управления Поискового Вызова) и CCCH (Общий Канал Управления), не требующим обеспечение безопасности и, следовательно, идут непосредственно к слою RLC, обходя слой PDCP. Основные услуги и функции подслоя RLC включают в себя:

- Перенос PDU верхнего слоя поддерживающих AM, UM или TM перенос данных;

- Коррекция Ошибок через ARQ;

- Сегментация в соответствии с размером TB;

- Повторная сегментация при необходимости (например, когда качество радиосвязи, т.е., поддерживаемый размер TB, меняется)

- Сочленение SDU для одного и того же носителя радиосвязи является FFS;

- доставка в-последовательности верхнего слоя PDU;

- Обнаружение Дубликатов;

- Обнаружение ошибок протокола и восстановление;

- Игнорирование SDU;

- Сброс

Функциональность ARQ, обеспечиваемая слоем RLC, будет обсуждаться более подробно в более поздней части.

Схема Доступа Восходящей Линии Связи для LTE

Применительно к передачи восходящей линии связи, эффективная по мощности передача терминала пользователя необходима, чтобы максимально увеличивать покрытие. Передача с одной несущей, объединенная с FDMA с динамическим распределением полосы пропускания была выбрана в качестве развитой схемы передачи восходящей линии связи UTRA. Основная причина предпочтения передачи с одной несущей состоит в более низком отношении пиковой-к-средней мощности (PAPR), в сравнении с сигналами с несколькими несущими (OFDMA), и соответствующей улучшенной эффективности усилителя мощности, и улучшенном покрытии (более высокие скорости передачи данных для заданной пиковой мощности терминала). В течение каждого интервала времени, eNodeB назначает пользователям уникальный временной/частотный ресурс для передачи данных пользователя, тем самым гарантируя ортогональности внутри соты. Ортогональный доступ в восходящей линии связи обещает увеличенную спектральную эффективность посредством исключения помех внутри соты. Помехи из-за многолучевого распространения обрабатываются на базовой станции (eNodeB), с использованием вставки циклического префикса в передаваемый сигнал.

Основной физический ресурс, используемый для передачи данных, состоит из частотного ресурса размера BWgrant в течение одного интервала времени, например, субкадра, в котором отображены биты кодированной информации. Следует отметить, что субкадр, также именуемый интервалом времени передачи (TTI), является наименьшим интервалом времени для передачи данных пользователя. Тем не менее, можно назначить частотный ресурс BWgrant по более длинному периоду времени, чем один TTI пользователю, посредством сочленения субкадров.

Сигнализация Управления Слоя 1/Слоя 2

Для того, чтобы информировать запланированных пользователей о их статусе распределения, транспортном формате, и другой относящейся к передаче информации (например, информации HARQ, командах управления мощностью передачи (TPC)), сигнализация управления L1/L2 передается по нисходящей линии связи наряду с данными. Сигнализация управления L1/L2 мультиплексируется с данными нисходящей линии связи в субкадре, предполагая, что распределение пользователя может быть изменено от субкадра к субкадру. Следует отметить, что распределение пользователя также может быть выполнено на базе TTI (Интервала Времени передачи), где длина TTI может быть кратной субкадрам. Длина TTI может быть фиксированной в зоне услуги для всех пользователей, может быть разной для разных пользователей, или даже может быть динамической для каждого пользователя. В целом, сигнализация управления L1/L2 должна передаваться только единожды за TTI. Без потери универсальности, нижеследующее предполагает, что TTI является эквивалентным одному субкадру.

Сигнализация управления L1/L2 передается по Физическому Каналу Управления Нисходящей Линии Связи (PDCCH). PDCCH несет сообщение в качестве Информации Управления Нисходящей Линии Связи (DCI), которая в большинстве случаев включает в себя назначения ресурсов и другую информацию управления для мобильного терминала или групп UE. Несколько PDCCH может быть передано в одном субкадре.

В целом, информация, отправляемая в сигнализации управления L1/L2 для назначения ресурсов радиосвязи восходящей линии связи или нисходящей линии связи (в частности LTE(-A) Редакции 10) может быть классифицирована на следующие элементы:

- Идентификационные данные пользователя, указывающие пользователя, который распределяется. Это, как правило, включает в себя контрольную сумму посредством маскирования CRC с идентификационными данными пользователя;

- Информация распределения ресурсов, указывающая ресурсы (например, Блоки Ресурсов, RB) по которым пользователь распределяется. В качестве альтернативы, данная информация называется назначением блока ресурсов (RBA). Отметим, что число RB, по которым пользователь распределяется, может быть динамическим;

- Индикатор несущей, который используется, если канал управления, передаваемый по первой несущей, назначает ресурсы, которые затрагивают вторую несущую, т.е. ресурсы на второй несущей или ресурсы, относящиеся к второй несущей; (планирование между несущими);

- Схема модуляции и кодирования, которая определяет используемую схему модуляции и скорость кодирования;

- Информация HARQ, такая как индикатор новых данных (NDI) и/или версия избыточности (RV), которая, в частности, полезна при повторных передачах пакетов данных или их частей;

- Команды управления мощностью, чтобы регулировать мощность передачи назначенных данных восходящей линии связи или передачи информации управления;

- Информация опорного сигнала, такая как применяемый циклический сдвиг и/или индекс ортогонального кода покрытия, которые должны быть использованы для передачи или приема опорных сигналов, относящихся к назначению;

- Индекс назначения восходящей линии связи или нисходящей линии связи, который используется, чтобы идентифицировать очередность назначений, которая, в частности, полезна в системах TDD;

- Информация скачкообразного изменения, например, указание, применять ли и как скачкообразное изменение ресурсов для того, чтобы увеличить частотное разнесение;

- Запрос CSI, который используется, чтобы инициировать передачу информации о состоянии канала в назначенном ресурсе; и

- Информация мульти-кластера, которая является флагом, используемым, чтобы указывать и управлять тем, происходит ли передача в едином кластере (смежном наборе RB) или в нескольких кластерах (по меньшей мере, двух несмежных наборах смежных RB). Распределение мульти-кластера было введено посредством 3GPP LTE-(A) Редакция 10.

Следует отметить, что вышеприведенное перечисление не является исчерпывающим, и не требуется присутствие всех упомянутых элементов информации в каждой передаче PDCCH в зависимости от формата DCI, который используется.

Информация управления нисходящей линии связи имеет место в нескольких форматах, которые отличаются по общему размеру и также по информации, содержащейся в их полях, как упомянуто выше. Разные форматы DCI, которые в настоящий момент определены для LTE, являются следующими и описаны подробно в документе 3GPP TS 36.212, «Multiplexing and channel coding», раздел 5.3.3.1 (текущая версия v13.0.0, доступен по адресу http://www.3gpp.org и включен в настоящее описание посредством ссылки). Например, следующие DCI Форматы могут быть использованы, чтобы нести разрешение ресурса для восходящей линии связи.

- Формат 0: DCI Формат 0 используется для передачи разрешений ресурса для PUSCH, используя передачи порта одной антенны в режиме 1 или 2 передачи восходящей линии связи.

- Формат 4: DCI формат 4 используется для планирования PUSCH, используя передачи замкнутого пространственного мультиплексирования в режиме 2 передачи восходящей линии связи.

Технический стандарт 3GPP TS 36.212, текущая версия 13.0.0, определяет в подстатье 5.4.3, включенной в настоящий документ посредством ссылки, информацию управления для побочной линии связи (sidelink).

Полупостоянное Планирование (SPS)

В нисходящей линии связи и восходящей линии связи, планирующий eNodeB динамически распределяет ресурсы оборудованиям пользователя в каждый интервал времени передачи через канал(ы) управления L1/L2 (PDCCH), где адресация к оборудованиям пользователя осуществляется через их особые C-RNTI. Как уже упомянуто до этого, CRC у PDCCH маскирована с помощью C-RNTI адресуемого оборудования пользователя (так называемый динамический PDCCH). Только оборудование пользователя с совпадающим C-RNTI может декодировать контент PDCCH корректно, т.е., проверка CRC является положительной. Данный вид сигнализации PDCCH также именуется динамическим (планированием) разрешением. Оборудование пользователя осуществляет мониторинг в каждый интервал времени передачи канала(ов) управления L1/L2 в отношении динамического разрешения для того, чтобы найти возможное распределение (нисходящей линии связи или восходящей линии связи), которое ему назначено.

В дополнение, E-UTRAN может распределять ресурсы восходящей линии связи/нисходящей линии связи для исходных передач HARQ постоянным образом. Когда требуется, передачи явным образом сигнализируются через канал(ы) управления L1/L2. Поскольку повторные передачи планируются динамически, данный вид работы именуется полупостоянным планированием (SPS), т.е., ресурсы выделяются оборудованию пользователя на полупостоянной основе (полупостоянное выделение ресурсов). Преимущество состоит в том, что экономятся ресурсы PDCCH для исходных передач HARQ. Полупостоянное планирование может быть использовано в PCell в Редакции 10, но не в SCell.

Одним примером для услуги, которая может планироваться, используя полупостоянное планирование, является Голос по IP (VoIP). Каждые 20мс пакет VoIP генерируется в кодеке во время речевого потока. Вследствие этого, eNodeB может выделять ресурсы восходящей линии связи или соответственно нисходящей линии связи постоянным образом каждые 20мс, которые затем могут быть использованы для передачи пакетов Голоса через IP. В целом, полупостоянное планирование обеспечивает преимущество для услуг с предсказуемым поведением трафика, т.е. постоянная скорость передачи битов, время прибытия пакта является периодическим.

Оборудование пользователя также осуществляет мониторинг PDCCH в субкадре, где ему были выделены ресурсы для исходной передачи постоянно. Динамическое (планирование) разрешение, т.е. PDCCH с C-RNTI-маскированной CRC, может замещать полупостоянное выделение ресурсов. В случае, когда оборудование пользователя находит свой C-RNTI по каналу(ам) управления L1/L2 в субкадрах, где оборудование пользователя имеет полупостоянный назначенный ресурс, данное выделение канала управления L1/L2 замещает постоянное выделение ресурсов для того интервала времени передачи, и оборудование пользователя следует динамическому разрешению. Когда оборудование пользователя не находит динамического разрешения, оно будет передавать/принимать в соответствии с полупостоянным выделением ресурсов.

Конфигурация полупостоянного планирования выполняется посредством сигнализации RRC. Например, периодичность, например, PS_PERIOD, у постоянного выделения сигнализируется в сигнализации Управления Ресурсами Радиосвязи (RRC). Активация постоянного выделения, а также точный хронометраж, как, впрочем, и физические ресурсы и параметры формата транспортировки отправляются через сигнализацию PDCCH. Как только полупостоянное планирование активируется, оборудование пользователя следует полупостоянному выделению ресурсов в соответствии с PDCCH активации SPS каждый PS_PERIOD. По существу, оборудование пользователя сохраняет контент PDCCH активации SPS и следует PDCCH с просигнализированной периодичностью.

Для того, чтобы отличать динамический PDCCH от PDCCH, который активируется полупостоянным планированием (также именуемый PDCCH активации SPS), вводятся отдельные идентификационные данные. Главным образом, CRC у PDCCH активации SPS маскируется с помощью этих дополнительных идентификационных данных, которые в нижеследующем именуются SPS C-RNTI. Размер SPS C-RNTI также составляет 16 битов, точно также как у нормального C-RNTI. Кроме того, SPS C-RNTI также является особым для оборудования пользователя, т.е. каждому оборудованию пользователя, сконфигурированному для полупостоянного планирования, выделяется уникальный SPS C-RNTI.

В случае, когда оборудование пользователя обнаруживает, что полупостоянное выделение ресурсов активируется посредством соответствующего PDCCH активации SPS, оборудование пользователя будет сохранять контент PDCCH (т.е. полупостоянное назначение ресурсов) и применять его каждый интервал полупостоянного планирования, т.е., периодичность сигнализируется через RRC. Как уже упоминалось, динамическое выделение, т.е., сигнализируемое по динамическому PDCCH, является только «единовременным выделением». Повторные передачи выделения SPS также сигнализируются, используя SPS C-RNTI. Для того, чтобы отличать активацию SPS от повторной передачи SPS, используется бит NDI (индикатор новых данных). Активация SPS указывается посредством установки бита NDI в 0. SPS PDCCH с NDI-битом установленным в 1 указывает повторную передачу для полупостоянным образом запланированной исходной передачи.

Сходно с активацией полупостоянного планирования, eNodeB также может деактивировать полупостоянное планирование, также именуемое высвобождением ресурса SPS. Существует несколько опций в отношении того, каким образом может быть просигнализирована отмена выделения полупостоянного планирования. Одной опцией будет использование сигнализации PDCCH с некоторыми полями PDCCH установленными в некоторые предварительно определенные значения, т.е. SPS PDCCH, указывающий выделение ресурсов нулевого размера. Другой опцией будет использование сигнализации управления MAC.

В нижеследующем, дополнительная информация предоставляется в отношении того, каким образом eNB узнает о том, передаются ли периодические данные посредством UE и когда возможно настраивать конфигурацию SPS.

Когда создается новый носитель, в соответствии с предназначенной процедурой активации носителя в TS 23.401, MME сигнализирует сообщение Запроса Настройки Носителя (Идентификационные Данные Носителя EPS, QoS Носителя EPS, Запрос Администрирования Сеанса, S1-TEID) к eNodeB. eNodeB отображает QoS Носителя EPS в QoS Носителя Радиосвязи. Затем он сигнализирует сообщение Реконфигурации Соединения RRC (QoS Носителя Радиосвязи, Запрос Администрирования Сеанса, Идентификационные данные RB EPS) к UE.

Профиль QoS носителя EPS включает в себя параметры QCI, ARP, GBR и MBR. Каждый носитель EPS (GBR и Не-GBR) ассоциирован со следующими параметрами QoS уровня носителя:

- Идентификатор Класса QoS (QCI);

- Приоритет Удержания и Распределения (ARP).

QCI является скалярной величиной, которая используется в качестве ссылки на особые для узла доступа параметры, которые управляют обработкой переадресации пакета на уровне носителя (например, весовые коэффициенты планирования, пороговые значения допущения, пороговые значения администрирования очереди, конфигурация протокола слоя линии связи и т.д.), и которые были предварительно сконфигурированы посредством оператора, владеющего узлом доступа (например, eNodeB). Взаимно-однозначное отображение стандартизованных значений QCI в стандартизованных характеристиках, зафиксировано в TS 23.203, как иллюстрируется в таблице ниже, которая основана на той, что в TS 23.203.

QCI Тип ресурса Уровень приоритета Бюджет задержки пакета Частота потери ошибки пакета (примечание 2) Примерные услуги 1 GBR 2 100мс 10^-2 Разговорный голос 2 4 150мс 10^-3 Разговорное видео (эфирная потоковая передача) 3 3 50мс 10^-3 Игра в режиме реального времени 4 5 300мс 10^-6 Неразговорное видео (потоковая передача с буферизацией) 65 0.7 75мс 10^-2 Критичный для выполнения миссии плоскости пользователя Нажми чтобы Говорить голос (например, MCPTT) 66 2 100мс 10^-2 Некритичный для выполнения миссии плоскости пользователя Нажми чтобы Говорить голос 5 Не-GBR 1 100мс 10^-6 Сигнализация IMS 6 6 300мс 10^-6 Видео (потоковая передача с буферизацией)
основанное на TCP (например, www, электронная почта, чат, ftp, p2p обмен файлами, прогрессивное видео, и т.д.) 7 7 100мс 10^-3 Голос,
Видео (эфирная потоковая передача)
Интерактивная игра 8 8 300мс 10^-6 Видео (потоковая передача с буферизацией)
основанное на TCP (например, www, электронная почта, чат, ftp, p2p обмен файлами, прогрессивное видео, и т.д.) 9 9 69 0.5 60мс 10^-6 Критичное для выполнения миссии чувствительная к задержке сигнализация (например, сигнализация MC-PTT) 70 5.5 200мс 10^-6 Критичные для Выполнения миссии данные (например, примерные услуги являются точно такими же как QCI 6/8/9)

Как видно из таблицы, значение 1 QCI соответствует «Разговорному Голосу», т.е. Голосу через IP (VoIP). Когда eNB принимает сообщение «Запрос Настройки Носителя» со значением 1 QCI, eNB знает, что данный носитель создается для VoIP и конфигурация SPS может быть применена, чтобы распределять периодические ресурсы для UE, чтобы передавать данные VoIP.

Услуги Близости (ProSe) связи Устройство с Устройством (D2D) LTE

Основанные на близости приложения и услуги представляют собой возникающую социально-технологическую тенденцию. Идентифицированные зоны включают в себя услуги, относящиеся к коммерческим услугам и Общественной Безопасности, которые будут интересны операторам и пользователям. Введение возможности Услуги Близости (ProSe) в LTE позволит отрасли промышленности 3GPP обслуживать данный развивающийся рынок, и будет, в то же самое время, обслуживать неотложные потребности нескольких сообществ Общественной Безопасности, которые совместно привержены LTE.

Связь Устройство-с-Устройством (D2D) является технологическим компонентом, введенным посредством LTE-Rel.12, который обеспечивает D2D в качестве основания сотовой сети, чтобы увеличивать спектральную эффективность. Например, если сотовая сеть является LTE, все несущие данные физические каналы используют SC-FDMA для сигнализации D2D. В связи D2D, оборудования пользователя передают сигналы данных друг другу через прямую линию связи, используя сотовые ресурсы вместо через базовую станцию радиосвязи. На всем протяжении изобретения понятия «D2D», «ProSe» и «побочная линия связи» являются взаимозаменяемыми.

Связь D2D в LTE фокусируется на двух зонах: Обнаружение и Связь.

Непосредственное Обнаружение ProSe (Основанные на Близости Услуги) определяется как процедура, используемая UE с поддержкой ProSe, чтобы обнаруживать другие UE с поддержкой ProSe в его близости, используя прямые сигналы радиосвязи E-UTRA через интерфейс PC5.

В связи D2D, UE передают сигналы данных друг другу чрез прямую линию связи, используя сотовые ресурсы вместо того, чтобы через базовую станцию (BS). D2D пользователи осуществляют связь напрямую при этом оставаясь под управлением BS, т.е., по меньшей мере, находясь в покрытии eNB. Вследствие этого, D2D может улучшить производительность системы посредством повторного использования сотовых ресурсов.

Предполагается, что D2D работает в спектре LTE восходящей линии связи (в случае FDD) или субкадрах восходящей линии связи соты, дающей покрытие (в случае TDD, за исключением, когда вне покрытия). Кроме того, передача/прием D2D не используют полный дуплекс по заданной несущей. С точки зрения индивидуального UE, по заданной несущей прием сигнала D2D и передача восходящей линии связи LTE не используют полный дуплекс, т.е., невозможен одновременный прием сигнала D2D и передачи UL LTE.

В связи D2D, когда одно конкретное UE 1 играет роль передачи (передающее оборудование пользователя или передающий терминал), UE1 отправляет данные, а другое UE2 (принимающее оборудование пользователя) принимает их. UE1 и UE2 могут менять их роль передачи и приема. Передача от UE1 может быть принята посредством одного или более UE, подобных UE2.

Линия слоя 2 прямой связи ProSe

Кратко, прямая связь ProSe типа один-с-одним реализуется посредством создания безопасной линии связи слоя-2 через PC5 между двумя UE. Каждое UE имеет ID Слоя-2 для одноадресной связи, который включен в поле ID Слоя-2 Источника каждого кадра, который отправляется по линии связи слоя-2 и в ID Слоя-2 Получателя каждого кадра, который оно принимает по линии связи слоя-2. UE требуется гарантировать то, что ID Слоя-2 для одноадресной связи является, по меньшей мере, локально уникальным. Таким образом UE должно быть подготовлено, чтобы обрабатывать конфликты ID Слоя-2 со смежными UE, используя неуказанные механизмы (например, само-назначение нового ID Слоя-2 для одноадресной связи, когда обнаруживается конфликт). Линия связи слоя-2 для прямой связи ProSe типа один-с-одним идентифицируется посредством сочетания ID Слоя-2 двух UE. Это означает, что UE может вовлекаться в несколько линий связи слоя-2 применительно к прямой связи ProSe типа один-с-одним, используя один и тот-же ID Слоя-2.

Прямая связь ProSe типа один-с-одним составлена из следующих процедур, как объясняется подробно в TR 23.713 текущая версия v13.0.0 раздел 7.1.2, включенный в настоящее описание посредством ссылки:

- Создание безопасной линии связи слоя-2 через PC5.

- Назначение IP-адреса/префикса.

- Поддержание линии связи слоя-2 через PC5.

- Высвобождение линии связи слоя-2 через PC5.

Фиг. 3 иллюстрирует каким образом создавать безопасную линию связи слоя-2 через интерфейс PC5.

1. UE-1 отправляет сообщение Запроса Прямой Связи к UE-2 для того, чтобы инициировать взаимную аутентификацию. Инициатору линии связи (UE-1) требуется знать ID Слоя-2 однорангового узла (UE-2) для того, чтобы выполнить этап 1. В качестве примера, инициатор линии связи может узнать ID Слоя-2 у однорангового узла посредством исполнения сначала процедуры обнаружения или участвуя в связи ProSe типа один-с-множеством, включающей одноранговый узел.

2. UE-2 инициирует процедуру взаимной аутентификации. Успешное выполнение процедуры аутентификации завершает создание безопасной линии связи слоя-2 через PC5.

UE вовлеченные в изолированную (не-ретранслируемую) связь типа один-с-одним также могут использовать локальные для линии связи адреса. Протокол Сигнализации PC5 должен поддерживать функциональность проверки активности, которая используется, чтобы обнаруживать, когда UE находятся не в диапазоне Связи ProSe, так, чтобы они могли продолжать с помощью неявного высвобождения линии связи слоя-2. Высвобождение линии связи Слоя-2 через PC5 может быть выполнено посредством использования сообщения Запроса Разъединения, переданного другому UE, которое также удаляет все ассоциированные данные контекста. По приему сообщения Запроса Разъединения, другое UE отвечает сообщением Ответа Разъединения и удаляет все данные контекста, ассоциированные с линией связи слоя-2.

Идентификационные данные Относящиеся к Прямой Связи ProSe

3GPP TS 36.300, текущая версия 13.2.0, определяет в подстатье 8.3 следующие идентификационные данные для использования применительно к Прямой Связи ProSe:

- SL-RNTI: Уникальная идентификация, используемая для Планирования Прямой Связи ProSe;

- ID Слоя-2 Источника: Идентифицирует отправителя данных в Прямой Связи ProSe типа побочная линия связи. ID Слоя-2 Источника составляет в длину 24 бита и используется вместе с ID Слоя-2 Получателя ProSe и LCID для идентификации объекта RLC UM и объекта PDCP в приемнике;

- ID Слоя-2 Получателя: Идентифицирует цель данных Прямой Связи ProSe типа побочная линия связи. ID Слоя-2 Получателя составляет в длину 24 бита и разбит в слое MAC на две битовые строки:

-- Одна битовая строка является частью LSB (8 битов) у ID Слоя-2 Получателя и переадресовывается физическому слою как ID Слоя-1 Управления Побочной Линии Связи. Это идентифицирует цель предназначенных данных в Управлении Побочной Линия Связи и используется для фильтрации пакетов на физическом слое.

-- Вторая битовая строка является частью MSB (16 битов) у ID Слоя-2 Получателя и переносится в заголовке MAC. Это используется для фильтрации пакетов на слое MAC.

Сигнализация Слоя без Доступа требуется для формирования группы, и чтобы конфигурировать ID Слоя-2 Источника, ID Слоя-2 Получателя и ID L1 Управления Побочной Линии Связи в UE. Эти идентификационные данные либо предоставляются более высоким слоем, либо извлекаются из идентификационных данных предоставленных более высоким слоем. В случае групповой передачи или широковещательной передачи, ID UE ProSe предоставленный более высоким слоем используется непосредственно в качестве ID Слоя-2 Источника, и ID Группы Слоя-2 ProSe, предоставленный посредством более высокого слоя, используется непосредственно в качестве ID Слоя-2 Получателя в слое MAC. В случае связи типа один-с-одним, более высокий слой предоставляет ID Слоя-2 Источника и ID Слоя-2 Получателя.

Распределение Ресурсов Радиосвязи для Услуг Близости

С точки зрения передающего UE, UE с поддержкой Услуг Близости (UE с поддержкой ProSe) может работать в двух режимах применительно к распределению ресурсов:

Режим 1 относится к eNB-планируемому распределению ресурсов, где UE запрашивает ресурсы передачи у eNB (или узла ретрансляции Редакции-10), и eNodeB (или узел ретрансляции Редакции-10) в свою очередь планирует ресурсы, используемые UE, чтобы передавать непосредственные данные и непосредственную информацию управления (например, Назначение Планирования). UE требуется быть в состоянии RRC_CONNECTED для того, чтобы передавать данные. В частности, UE отправляет запрос планирования (D-SR или Произвольный Доступ) к eNB, сопровождаемый отчетом о статусе буфера (BSR) обычным образом (см. также следующую главу «Процедура передачи для связи D2D»). На основе BSR, eNB может определять, что UE имеет данные для передачи Прямой Связи ProSe, и может оценивать ресурсы, требуемые для передачи.

С другой стороны, Режим 2 относится к UE-автономному выбору ресурса, где UE само выбирает ресурсы (время и частоту) из пула(ов) ресурсов, чтобы передавать непосредственные данные и непосредственную информацию управления (т.е., SA). Один пул ресурсов определяется, например, посредством контента SIB18, а именно посредством поля commTxPoolNormalCommon, широковещательная передача данного конкретного пула ресурсов осуществлялась в соте и затем он становится обычно доступен всем UE в соте по-прежнему в состоянии RRC_Idle. Фактически, eNB может определять вплоть до четырех разных экземпляров упомянутого пула, соответственно четыре пула ресурсов для передачи сообщения SA и непосредственных данных. Тем не менее, в Rel-12 UE должно всегда использовать первый пул ресурсов, определенный в списке, даже если оно было сконфигурировано с несколькими пулами ресурсов. Данное ограничение было снято для Rel-13, т.е., UE может передавать по нескольким из сконфигурированных пулов ресурсов в одном периоде SC. Каким образом UE выбирает пулы ресурсов для передачи дополнительно излагается в общих чертах ниже (дополнительно указывается в TS36.321).

В качестве альтернативы, другой пул ресурсов может быть определен посредством eNB и просигнализирован в SIB18, а именно посредством использования поля commTxPoolExceptional, которое может быть использовано UE в исключительных случаях.

Какой режим распределения ресурсов собирается использовать UE является конфигурируемым посредством eNB. Кроме того, какой режим распределения ресурсов UE собирается использовать для связи данных D2D, также может зависеть от состояния RRC, т.е., RRC_IDLE или RRC_CONNECTED, и состояния покрытия UE, т.е., в-покрытие, вне-покрытия. UE рассматривается в-покрытие, если оно имеет обслуживающую соту (т.е., UE находится в состоянии RRC_CONNECTED или является закрепленным в соте в состоянии RRC_IDLE).

Следующие правила в отношении режима распределения ресурсов применяются для UE:

- Если UE находится вне-покрытия, оно может использовать только Режим 2;

- Если UE находится в-покрытие, оно может использовать Режим 1, если eNB конфигурирует его соответственно;

- Если UE находится в-покрытие, оно может использовать Режим 2, если eNB конфигурирует его соответственно;

- Когда отсутствуют исключительные условия, UE может осуществлять смену с Режима 1 на Режим 2 или наоборот только если оно сконфигурировано посредством eNB, чтобы делать это. Если UE находится в-покрытие, оно должно использовать только режим, указанный посредством конфигурации eNB при условии, что не возникает один из исключительных случаев;

-- UE рассматривает само себя, как находящееся в исключительных случаях, например, в то время как запущены T311 или T301;

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

Находясь в зоне покрытия соты E-UTRA, UE должно выполнять Передачу Прямой Связи ProSe по несущей UL только по ресурсам, назначенным посредством той соты, даже если ресурсы той несущей были предварительно сконфигурированы, например, в UICC (Универсальная Карта на Интегральной Микросхеме).

Применительно к UE в состоянии RRC_IDLE, eNB может выбирать одну из следующих опций:

- eNB может предоставлять пул ресурсов передачи Режима 2 в SIB. UE, которые авторизованы для Прямой Связи ProSe, используют эти ресурсы для Прямой Связи ProSe в RRC_IDLE;

- eNB может указывать в SIB, что он поддерживает D2D но не предоставляет ресурсов для Прямой Связи ProSe. UE требуется войти в состояние RRC_CONNECTED, чтобы выполнять передачу Прямой Связи ProSe.

Применительно к UE в состоянии RRC_CONNECTED:

- UE в состоянии RRC_CONNECTED, которое является авторизованным, чтобы выполнять передачу Прямой Связи ProSe, указывает eNB, что оно желает выполнять передачи Прямой Связи ProSe, когда ему требуется выполнять передачу Прямой Связи ProSe;

- eNB подтверждает, является ли UE в состоянии RRC_CONNECTED авторизованным для передачи Прямой Связи ProSe, используя контекст UE, принятый от MME;

- eNB может конфигурировать UE в состоянии RRC_CONNECTED посредством предназначенной сигнализации пулом ресурсов передачи распределения ресурсов Режима-2, который может быть использован без ограничений, пока UE находится в состоянии RRC_CONNECTED. В качестве альтернативы, eNB может конфигурировать UE в состоянии RRC_CONNECTED посредством предназначенной сигнализации пулом ресурсов передачи распределения ресурсов Режима 2, который UE разрешено использовать только в исключительных случаях и в противном случае полагаться на Режим 1.

Пул ресурсов для Назначения Планирования, когда UE находится вне покрытия, может быть сконфигурирован как ниже:

- Пул ресурсов, используемый для приема, является предварительно сконфигурированным.

- Пул ресурсов, используемый для передачи, является предварительно сконфигурированным.

Пул ресурсов для Назначения Планирования, когда UE находится в покрытии, может быть сконфигурирован как ниже:

- Пул ресурсов, используемый для приема, конфигурируется посредством eNB через RRC, в предназначенной или широковещательной сигнализации.

- Пул ресурсов, используемый для передачи, конфигурируется посредством eNB через RRC, если используется распределение ресурсов Режима 2.

- Пул ресурсов SCI (Информация Управления Побочной Линии Связи) (также именуемый пулом ресурсов Назначения Планирования, SA), используемый для передачи, неизвестен UE, если используется распределение ресурсов Режима 1.

- eNB планирует особый ресурс(ы), чтобы использовать для передачи Информации Управления Побочной Линии Связи (Назначения Планирования), если используется распределение ресурсов Режима 1. Особый ресурс, назначенный посредством eNB, находится в пуле ресурсов для приема SCI, который предоставляется UE.

Фиг. 4 иллюстрирует использование ресурсов передачи/приема для системы наложения (LTE) и подложки (D2D).

В основном, eNodeB управляет тем, может ли UE применять передачу Режима 1 или Режима 2. Как только UE знает свои ресурсы, по которым оно может передавать (или принимать) связь D2D, оно использует соответствующие ресурсы только для соответствующей передачи/приема. Например, на Фиг. 4 субкадры D2D будут использоваться только чтобы принимать или передавать сигналы D2D. Поскольку UE как устройство D2D будет работать в режиме Полудуплекса, оно может либо принимать, либо предавать сигналы D2D в любой момент времени. Сходным образом, другие субкадры, иллюстрируемые на Фиг. 4, могут быть использованы для передач и/или приема LTE (наложения).

Процедура передачи для связи D2D

Процедура передачи данных D2D отличается в зависимости от режима распределения ресурсов. Как описано выше для Режима 1, eNB явным образом планирует ресурсы для Назначения Планирования и связи данных D2D после соответствующего запроса от UE. В частности, UE может быть проинформировано посредством eNB о том, что связь D2D в основном разрешена, но что не предоставляются ресурсы Режима 2 (т.е. пул ресурсов); это может быть выполнено, например, с помощью обмена Указаниями Заинтересованности связи D2D посредством UE и соответствующего ответа, Ответ Связи D2D, где соответствующий примерный элемент информации ProseCommConfig не будет включать в себя commTxPoolNormalCommon, означая то, что UE, которое желает начать прямую связь, включающую передачи, должно запросить у E-UTRAN назначение ресурсов для каждой индивидуальной передачи. Таким образом, в таком случае, UE должно запросить ресурсы для каждой индивидуальной передачи, и в нижеследующем разные этапы процедуры запроса/разрешения в качестве примера перечисляются для данного распределения ресурсов Режима 1:

- Этап 1: UE отправляет SR (Запрос Планирования) к eNB через PUCCH;

- Этап 2: eNB разрешает ресурс UL (для UE, чтобы отправлять BSR) через PDCCH, зашифрованный посредством C-RNTI;

- Этап 3: UE отправляет D2D BSR, указывающий статус буфера через PUSCH;

- Этап 4: eNB разрешает ресурс D2D (для UE, чтобы отправлять данные) через PDCCH, зашифрованный посредством D2D-RNTI;

- Этап 5: D2D Tx UE передает SA/ данные D2D в соответствии с разрешением, принятым на этапе 4.

Назначение Планирования (SA), также называемое SCI (Информация Управления Побочной Линии Связи), является компактным (с низкой полезной нагрузкой) сообщением, содержащим информацию управления, например, указатель(и) на частотно-временные ресурсы, схему модуляции и кодирования и ID Получателя Группы для соответствующей передачи данных D2D. SCI транспортирует информацию планирования побочной линии связи для одного ID получателя (ProSe). Контент SA (SCI) является, главным образом, в соответствии с разрешением, принятым на Этапе 4 выше. Разрешение D2D и контент SA (т.е. контент SCI) определяются в техническом стандарте 3GPP 36.212, текущая версия 13.0.0, подстатья 5.4.3, включенная в настоящее описание посредством ссылки, оправляющем, в частности, SCI формат 0 (см. контент SCI формата 0 выше).

С другой стороны, для распределения ресурсов Режима 2, вышеприведенные этапы 1-4 главным образом не обязательны, и UE автономно выбирает ресурсы для SA и передачи данных D2D из пула(ов) ресурсов передачи, сконфигурированного и предоставленного посредством eNB.

Фиг. 5 в качестве примера иллюстрирует передачу Назначения Планирования и данных D2D для двух UE, UE1 и UE2, где ресурсы для отправки назначений планирования являются периодическими, а ресурсы, используемые для передачи данных D2D, указываются посредством соответствующего Назначения Планирования.

Фиг. 6 иллюстрирует хронометраж связи D2D для Режима 2, автономное планирование, в течение одного периода SA/данных, также известного как период SC, период Управления Побочной Линии Связи. Фиг. 7 иллюстрирует хронометраж связи D2D для Режима 1, eNB-планируемое распределение в течение одного периода SA/данных. Период SC является периодом времени, состоящим из передачи Назначения Планирования и его соответствующих данных. Как может быть видно из Фиг. 6, UE передает после SA-времени смещения, Назначение Планирования, используя ресурсы пула передачи для назначений планирования для Режима 2, SA_Mode2_Tx_pool. 1-ая передача у SA сопровождается, например, тремя повторными передачами того же самого сообщения SA. Затем, UE начинает передачу данных D2D, т.е., больше в частности битовая карта/шаблон T-RPT, с некоторым сконфигурированным смещением (Mode2data_offset) после первого субкадра пула ресурсов SA (заданного посредством SA offset). Одна передача данных D2D у MAC PDU (т.е., транспортного блока) состоит из ее 1-ой передачи и нескольких повторных передач. Для иллюстрации Фиг. 7 (или Фиг. 7), предполагается, что выполняется три повторные передачи (т.е. 2-ая, 3-ья, и 4-ая передача одной и той же MAC PDU). Битовая карта T-RPT Режима 2 (шаблон временного ресурса передачи, T-RPT) главным образом определяет хронометраж передачи MAC PDU (1-ая передача) и ее повторных передач (2^ая, 3^ья, и 4^ая передача). Шаблон SA главным образом определяет хронометраж исходной передачи SA и ее повторных передач (2^ая, 3^ья, и 4^ая передача).

Как в настоящий момент указано в стандарте, для одного разрешения побочной линии связи, например, либо отправленного посредством eNB, либо выбранного самим UE, UE может передавать несколько транспортных блоков, MAC PDU, (только на субкадр (TTI), т.е. один после другого), тем не менее, только одной группе получателей ProSe. Также, повторные передачи одного транспортного блока должны быть закончены до того, как начинается первая передача следующего транспортного блока, т.е., только один процесс HARQ используется из расчета на разрешение побочной линии связи для передачи нескольких транспортных блоков. Кроме того, UE может иметь и использовать несколько разрешений побочной линии связи из расчета на период SC, но разные получатели ProSe выбираются для каждого из них. Таким образом, в одном периоде SC UE может передавать данные одному получателю ProSe только один раз.

Как очевидно из Фиг. 7, применительно к eNB-планируемому режиму распределения ресурсов (Режим 1), передача данных D2D, т.е., больше в частности шаблон/битовая карта T-RPT, начинается в следующем субкадре UL после последнего повторения передачи SA в пуле ресурсов SA. Как уже объяснено для Фиг. 6, Битовая карта T-RPT Режима1 (шаблон временного ресурса передачи, T-RPT) главным образом определяет хронометраж передачи MAC PDU (1ая передача) и ее повторных передач (2ая, 3ья, и 4ая передача).

Процедуру передачи данных побочной линии связи можно найти в документе стандарта 3GPP TS 36.321 v13.0.0, раздел 5.14, включенный в настоящее описание посредством ссылки. В нем, подробно описывается автономный выбор ресурсов Режима-2, с различием между будучи сконфигурированным с одним пулом ресурсов радиосвязи или с несколькими пулами ресурсов радиосвязи. Следующие этапы взяты из упомянутого раздела TS 36/321, предполагая автономный выбор ресурсов Режима-2:

Для того, чтобы осуществлять передачу по SL-SCH (совместно используемый канал побочной линии связи) объект MAC должен иметь, по меньшей мере, одно разрешение побочной линии связи. Разрешения побочной линии связи выбираются следующим образом:

Если объект MAC конфигурируется посредством верхних слоев, чтобы осуществлять передачу, используя один или несколько пул(ов) ресурсов и еще данные доступны в STCH (канал трафика побочной линии связи), которые могут быть переданы в текущем периоде SC, объект MAC должен быть выбран для каждого разрешения побочной линии связи:

- если конфигурируется верхними слоями, чтобы использовать один пул ресурсов:

-- выбирают тот пул ресурсов для использования;

- иначе, если конфигурируется верхними слоями, чтобы использовать несколько пулов ресурсов:

-- выбирают пул ресурсов для использования из пулов ресурсов, сконфигурированных верхними слоями, чей ассоциированный список приоритета включает приоритет наивысшего приоритета у логического канала побочной линии связи в MAC PDU, которая должна быть передана;

Примечание: Если более чем один пул ресурсов имеет ассоциированный список приоритетов, который включает в себя приоритет логического канала побочной линии связи с наивысшим приоритетом в MAC PDU, которая должна быть передана, то на реализацию UE остановлено то, какой один из этих пулов ресурсов выбирать.

- произвольно выбирают временные и частотные ресурсы для SL-SCH и SCI у разрешения побочной линии связи из выбранного пула ресурсов. Произвольная функция должна быть такой, что каждый из разрешенных выборов может быть выбран с равной вероятностью;

- используют выбранное разрешение побочной линии связи, чтобы определить набор субкадров, в которых передача SCI и передача первого транспортного блока происходит в соответствии с подстатьей 14.2.1 у TS 36.213, включенной в настоящее описание посредством ссылки (данный этап относится к выбору T-RPT и шаблону SA, как объясняется в связи с Фиг. 7);

- рассматривают выбранное разрешение побочной линии связи, в качестве сконфигурированного разрешения побочной линии связи, происходящего в тех субкадрах начинающихся в начале первого доступного Периода SC, который начинается, по меньшей мере, через 4 субкадра после субкадра, в котором было выбрано разрешение побочной линии связи;

- обнуляют сконфигурированное разрешение побочной линии связи в конце соответствующего Периода SC;

Примечание: Повторные передачи по SL-SCH могут происходить после того, как сконфигурированное разрешение побочной линии связи обнулено.

Примечание: Если объект MAC сконфигурирован посредством верхних слоев чтобы осуществлять передачу используя один или несколько пул(ов) ресурсов, то на реализацию UE оставляется то, сколько разрешений побочной линии связи выбирать в одном периоде SC, учитывая число процессов побочной линии связи.

Объект MAC должен для каждого субкадра:

- если объект MAC имеет сконфигурированное разрешение побочной линии связи, возникающее в данном субкадре;

-- если сконфигурированное разрешение побочной линии связи соответствует передаче SCI:

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

-- иначе, если сконфигурированное разрешение побочной линии связи соответствует передаче первого транспортного блока:

--- доставлять сконфигурированное разрешение побочной линии связи и ассоциированную информацию HARQ Объекту HARQ Побочной Линии Связи для данного субкадра.

Примечание: Если объект MAC имеет несколько сконфигурированных разрешений, возникающих в одном субкадре и если не все из них могут быть обработаны из-за ограничения одного кластера SC-FDM, то на реализацию UE оставляется то, какое одно из них обрабатывать в соответствии с процедурой выше.

Вышеприведенный текст, взятый из технического стандарта 3GPP, может быть дополнительно пояснен. Например, этап произвольного выбора временных и частотных ресурсов является произвольным относительно того, какие конкретные временные/частотные ресурсы выбираются, но не является, например, произвольным относительно объема суммарно выбранных временных/частотных ресурсов. Объем ресурсов, выбираемых из пула ресурсов, зависит от величины данных, которые должны быть переданы с упомянутым разрешением побочной линии связи, которое должно быть выбрано автономно. В свою очередь, объем данных, который должен быть передан, зависит от предыдущего этапа выбора группы получателей ProSe и соответствующего объема данных, готового для передачи, предназначенной для упомянутой группы получателей ProSe. Как описывается позже, в процедуре LCP побочной линии связи, сначала выбирается получатель ProSe.

Кроме того, процесс побочной линии связи, ассоциированный с объектом HARQ побочной линии связи, отвечает за выдачу инструкции физическому слою на генерирование и выполнение передачи соответственно, как очевидно из раздела 5.14.1.2.2 документа 3GPP TS 36.321 v13.0.0, включенного в настоящее описание посредством ссылки. Вкратце, после определения разрешения побочной линии связи и данных побочной линии связи для передачи, физический слой заботится о том, что данные побочной линии связи фактически передаются, на основе разрешения побочной линии связи и необходимых параметрах передачи.

То, что обсуждалось выше, является текущим статусом стандарта 3GPP для связи D2D. Тем не менее, следует отметить, что продолжается обсуждение того, как дополнительно улучшить и усилить связь D2D, что вероятно приведет к тому, что некоторые изменения будут введены в связь D2D в будущих редакциях. Настоящее изобретение, как будет описано позже, также должно быть применимо к этим более поздним редакциям.

Архитектура сети ProSe и объекты ProSe

Фиг. 8 иллюстрирует высокоуровневую примерную архитектуру для случая без роуминга, включающую в себя разные приложения ProSe в соответствующих UE A и B, как, впрочем, и Сервер Приложений ProSe и функцию ProSe в сети. Примерная архитектура Фиг. 8 взята из документа TS 23.303 v13.2.0 глава 4.2 «Architectural Reference Model», включенного в настоящее описание посредством ссылки.

Функциональные объекты представлены и объяснены подробно в документе TS 23.303 подстатья 4.4 «Functional Entities», включенная в настоящее описание посредством ссылки. Функция ProSe является логической функцией, которая используется для относящихся к сети действий, требуемых для ProSe, и играет разные роли для каждого из признаков ProSe. Функция ProSe является частью 3GPP EPC и обеспечивает все соответствующие сетевые услуги, подобные авторизации, аутентификации, обработки данных, и т.д., которые относятся к услугам близости. Применительно к прямому обнаружению и связи ProSe, UE может получать особые идентификационные данные UE ProSe, другую информацию конфигурации, как, впрочем, и авторизацию от функции ProSe через опорную точку PC3. Может быть несколько функций ProSe, развернутых в сети, несмотря на то, что для простоты иллюстрации представлена одна функция ProSe. Функция ProSe состоит из трех основных субфункций, которые выполняют разные роли в зависимости от признака ProSe: Функция Прямого Предоставления (DPF), Функция Прямого Администрирования Имени Обнаружения, и Функция Обнаружения EPC-уровня. DPF используется чтобы предоставлять UE необходимые параметры, чтобы использовать Прямое Обнаружение ProSe и Прямую Связь ProSe.

Понятие «UE», используемое в упомянутом соединении, относится к UE с поддержкой ProSe, которое поддерживает функциональность ProSe, такую как:

- Обмен информацией управления ProSe между UE с поддержкой ProSe и Функцией ProSe через опорную точку PC3.

- Процедуры для отрытого Прямого Обнаружения ProSe других UE с поддержкой ProSe через опорную точку PC5.

- Процедуры Прямой Связи ProSe типа один-с-множеством через опорную точку PC5.

- Процедуры, чтобы действовать в качестве Ретранслятора UE-к-Сети ProSe. Удаленное UE осуществляет связь с Ретранслятором UE-к-Сети ProSe через опорную точку PC5. Ретранслятор UE-к-Сети ProSe использует переадресацию пакетов слоя-3.

- Обмен информацией управления между UE ProSe через опорную точку PC5, например, для обнаружения Ретранслятора UE-к-Сети и Прямого Обнаружения ProSe.

- Обмен информацией управления ProSe между другим UE с поддержкой ProSe и Функцией ProSe через опорную точку PC3. В случае Ретранслятора UE-к-Сети ProSe, Удаленное UE будет отправлять данную информацию управления через плоскость пользователя PC5, чтобы она ретранслировалась через интерфейс LTE-Uu к Функции ProSe.

- Конфигурация параметров (например, включая IP-адреса, ID Группы Слоя-2 ProSe, материалы обеспечения безопасности Группы, параметры ресурса радиосвязи). Эти параметры могут быть предварительно сконфигурированы в UE, или, если находится в покрытии, предоставлены посредством сигнализации через опорную точку PC3 Функции ProSe в сети.

Сервер Приложений ProSe поддерживает Хранение ID Пользователя ProSe EPC, и ID Функции ProSe, и отображение ID

Пользователя Слоя Приложений и ID Пользователя ProSe EPC. Сервер Приложений (AS) ProSe является объектом вне области 3GPP. Приложение ProSe в UE осуществляет связь с AS ProSe через опорную точку PC1 слоя приложений. AS ProSe соединен с сетью 3GPP через опорную точку PC2.

Связь Транспортных Средств - услуги V2X

В 3GPP был создан новый предмет исследования для рассмотрения полезности новых признаков LTE для автомобильной отрасли - включая Услугу Близости (ProSe) и основанные на LTE услуги широковещательной передачи. Функциональность ProSe, таким образом, рассматривается как предлагающая хороший фундамент для услуг V2X. Соединенные технологии транспортного средства нацелены на решение некоторых из самых больших проблем в отрасли наземного транспорта, таких как безопасность, мобильность, и эффективность дорожного движения.

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

LTE поддержка для услуг V2X содержит 3 типа разных случаев использования, которые являются следующими:

- V2V: охватывающий основанную на LTE связь между транспортными средствами.

- V2P: охватывающий основанную на LTE связь между транспортным средством и устройством, которое переносит индивид (например, переносной терминал, который переносит пешеход, велосипедист, водитель или пассажир).

- V2I: охватывающий основанную на LTE связь между транспортным средством и блоком стороны дороги.

Эти три типа V2X могут использовать «совместную осведомленность», чтобы предоставлять более интеллектуальные услуги конечным пользователям. Это означает, что транспортные объекты, такие как транспортные средства, инфраструктура края дороги, и пешеходы, могут собирать знания их локальной среды (например, информацию, принимаемую от других транспортных средств или оборудования датчика поблизости), чтобы обрабатывать и совместно использовать эти знания для того, чтобы предоставлять более интеллектуальные услуги, такие как совместное предупреждение о столкновении или автономное вождение.

Касательно связи V2V, E-UTRAN позволяет таким UE, которые находятся вблизи друг друга, осуществлять обмен относящейся к V2V информацией, используя E-UTRA(N), когда удовлетворяется разрешение, авторизация и критерии близости. Критерии близости могут быть сконфигурированы посредством MNO (Оператор Мобильной Сети). Тем не менее, UE, поддерживающие Услугу V2V, могут осуществлять обмен такой информацией, когда обслуживаются посредством или не обслуживаются посредством E-UTRAN, которая поддерживает Услугу V2V.

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

V2V является преимущественно основанной на широковещательной передаче; V2V включает в себя обмен относящейся к V2V информацией приложения между отличными UE напрямую и/или, из-за ограниченного диапазона прямой связи у V2V, обмен относящейся к V2V информацией приложения между отличными UE через инфраструктуру, поддерживающую V2X Услугу, например, RSU, сервер приложений, и т.д.

Касательно связи V2I, UE, поддерживающее приложения V2I, отправляет информацию слоя приложений Блоку Стороны Дороги, который в свою очередь может отправлять информацию слоя приложений группе UE или UE, поддерживающему приложения V2I.

V2N (Транспортное средство с Сетью, eNB/CN) также вводится где одной стороной является UE, а другой стороной является обслуживающий объект, оба поддерживающие приложения V2N и осуществляющие связь друг с другом через сеть LTE.

Касательно связи V2P, E-UTRAN позволяет таким UE, которые находятся вблизи друг друга, осуществлять обмен относящейся к V2P информацией, используя E-UTRAN, когда удовлетворяется разрешение, авторизация и критерии близости. Критерии близости могут быть сконфигурированы посредством MNO. Тем не менее, UE, поддерживающие Услугу V2P, могут осуществлять обмен такой информацией даже когда не обслуживаются посредством E-UTRAN, которая поддерживает Услугу V2X.

UE, поддерживающее приложения V2P, передает информацию слоя приложений. Такая информация может передаваться посредством широковещательной передачи транспортным средством с UE, поддерживающим Услугу V2X (например, предупреждение пешеходу), и/или посредством пешехода с UE, поддерживающим Услугу V2X (например, предупреждение транспортному средству).

V2P включает в себя обмен относящейся к V2P информацией приложения между отличными UE (одно для транспортного средства, а другое для пешехода) напрямую и/или, из-за ограниченного диапазона прямой связи у V2P, обмен относящейся к V2P информацией приложения между отличными UE через инфраструктуру, поддерживающую Услугу V2X, например, RSU, сервер приложений, и т.д.

Для данного нового предмета исследования V2X, 3GPP предоставило конкретные понятия и определения в TR 21.905, текущая версия 13.0.0, которые могут быть повторно использованы для данной заявки.

Блок Стороны Дороги (RSU): Объект, поддерживающий Услугу V2I, который может осуществлять передачу к, и прием от UE, используя приложение V2I. RSU может быть реализован в eNB или стационарном UE.

Услуга V2I: Тип Услуги V2X, где одной стороной является UE, а другой стороной является RSU, причем обе стороны используют приложение V2I.

Услуга V2N: Тип Услуги V2X, где одной стороной является UE, а другой стороной является обслуживающий объект, причем обе стороны используют приложения V2N и осуществляют связь друг с другом через объекты сети LTE.

Услуга V2P: Тип Услуги V2X, где обе стороны связи являются UE, использующими приложение V2P.

Услуга V2V: Тип Услуги V2X, где обе стороны связи являются UE, использующими приложение V2V.

Услуга V2X: Тип услуги связи, которая включает передающее или принимающее UE, использующее приложение V2V через транспорт 3GPP. На основе другой стороны, включенной в связь, она может быть дополнительно разделена на Услугу V2V, Услугу V2I, и Услугу V2N.

Разные типы сообщений являются и будут определены для связи V2V. Два разных типа сообщений уже были определены посредством ETSI для Интеллектуальных Транспортных Систем (ITS), см. соответствующие Европейские Стандарты ETSI EN 302 637-2 v1.3.1 и ETSI EN 302 637-3 v 1.2.1:

- Сообщения Совместной Осведомленности (CAM), которые непрерывно инициируются динамикой транспортного средства, чтобы отражать статус транспортного средства.

- Децентрализованные Сообщения Уведомления Окружающей Среды (DENM), которые инициируются только когда происходят относящиеся к транспортному средству события безопасности.

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

CAM являются непрерывной широковещательной передачей посредством ITS-Станций (ITS-S), чтобы осуществлять обмен информацией статуса с другими ITS-S, и, следовательно, имеют большее влияние на нагрузку от трафика, чем инициируемые событием сообщения DENN. По этой причине, характеристики трафика сообщений CAM, как определяется посредством ETSI для ITS, считаются более представительными для трафика V2V.

Сообщения Совместной Осведомленности (CAM) являются сообщениями, обмен которыми осуществляется в сети ITS между ITS-S, чтобы создавать и поддерживать осведомленность друг друга и чтобы поддерживать совместное функционирование транспортных средств, используя сеть дороги. Связь типа точка-многоточка должна быть использована для передачи CAM, так что CAM передаются от ITS-S-источника к принимающим ITS-S, расположенным в диапазоне прямой связи ITS-S-источника. Генерирование CAM должно быть инициировано и его администрирование должно осуществляться посредством базовой услуги Совместной Осведомленности, которая определяет интервал времени между двумя последовательным генерированием CAM. В настоящее время, верхними и нижними границами интервала передачи являются 100мс (т.е., частота генерирования CAM в 10Гц) и 1000мс (т.е., частота генерирования CAM в 1Гц). Лежащая в основе философия ETSI ITS состоит в отправке CAM, когда присутствует новая информация для совместного использования (например, новая позиция, новое ускорение или новые значения курса). Соответственно, когда транспортные средства перемещаются медленно и с постоянным курсом и скоростью, высокая частота генерирования CAM не дает действительных преимуществ, поскольку CAM демонстрируют только минимальные отличия. Частота передачи CAM одного транспортного средства варьируется между 1Гц и 10Гц как функция динамики транспортного средства (например, скорости, ускорения, и курса). Например, чем медленнее движется транспортное соседство, тем меньшее число CAM инициируются и передаются. Скорость транспортного средства является основным оказывающим влияние фактором на генерирование трафика CAM,

Инициирующие условия генерирования CAM в настоящее время определены в ETSI EN 302 637-2 v1.3.1 статья 6.1.3 и показаны ниже:

1) Время, прошедшее с последнего генерирования CAM равно или больше T_GenCam_Dcc (параметр, предоставляющий минимальный интервал времени между двумя последовательными моментами генерирования CAM для того, чтобы сократить генерирование CAM в соответствии с требованиями использования канала децентрализованного управления перегрузкой (DCC) и задается одно из следующих относящихся к динамике ITS-S условий:

- абсолютная разность между текущим курсом ITS-S-источником и курсом, включенным в CAM, ранее переданное ITS-S-источником, превышает 4°;

- расстояние между текущей позицией ITS-S-источника и позицией, включенной в CAM, ранее переданное ITS-S-источником, превышает 4м;

- абсолютная разность между текущей скоростью ITS-S-источника и скоростью, включенной в CAM, ранее переданное ITS-S-источником, превышает 0,5м/с.

2) Время, прошедшее с последнего генерирования CAM равно или больше T_GenCam и равно или больше T_GenCam_Dcc. Параметр T_GenCam представляет собой текущий действительный верхний предел интервала генерирования CAM.

Если удовлетворяется одно из вышеприведенных двух условий, CAM должно генерироваться немедленно.

CAM содержит информацию статуса и атрибутов ITS-S-источника. Контент CAM варьируется в зависимости от типа ITS-S, как будет объяснено более подробно ниже. Для ITS-S транспортного средства информация статуса может включать в себя время, позицию, состояние движения, активированные системы, и т.д., а информация атрибута может включать в себя данные касательно размеров, типа транспортного средства и роли в дорожном трафике, и т.д. По приему CAM, принимающая ITS-S становится осведомлена о присутствии, типе, и статусе ITS-S-источника. Принятая информация может быть использована принимающей ITS-S, чтобы поддерживать несколько приложений ITS. Например, посредством сравнения статуса ITS-S-источника со своим собственным статусом, принимающая ITS-S способна оценивать риск столкновения с ITS-S-источником, и при необходимости может информировать водителя транспортного средства через HMI (Интерфейс Человек-Машина). Как описано подробно в статье 7 документа ETSI EN 302 637-2 v 1.3.1, включенного в настоящее описание посредством ссылки, CAM состоит из одного общего заголовка ITS PDU и нескольких контейнеров, которые вместе составляют CAM. Заголовок ITS PDU является общим заголовком, который включает в себя информацию версии протокола, типе сообщения и ID ITS-S у ITS-S-источника. Применительно к ITS-S транспортного средства, CAM должно содержать один основной контейнер и один высокочастотный контейнер, и также может включать в себя один низкочастотный контейнер и один или более другие особые контейнеры. Основной контейнер включает в себя основную информацию, относящуюся к ITS-S-источнику. Высокочастотный контейнер содержит высоко-динамичную информацию ITS-S источника. Низкочастотный контейнер содержит статичную и не высоко-динамичную информацию ITS-S-источника. Особый контейнер транспортного средства содержит информацию, особую для роли транспортного средства у ITS-S-источника транспортного средства. Общая структура CAM иллюстрируется на Фиг. 9.

Нижеследующая таблица дает общее представление и размеры пакета разных компонентов данных сообщения V2V:

Элементы данных Тип Типичный размер (байты) Описание Заголовок Обязательный 8 Версия протокола, тип сообщения, адрес отправителя, и временная метка Основной контейнер Обязательный 18 Тип станции (например, легкий грузовик, велосипедист, пешеход, и т.д.) и позиция Высокочастотный (HF) контейнер Обязательный 23 Вся быстроменяющаяся информация статуса транспортного средства, т.е., курс, скорость, ускорение, и т.д. Низкочастотный (LF) контейнер Опциональный 60 Статичные или медленноменяющиеся данные транспортного средства, главным образом история пути. История пути состоит из числа точек истории пути. 7 точек истории пути достаточно, чтобы охватить более 90% случаев, на основе обширного тестирования. Каждая точка составляет приблизительно 8 байтов. Особый контейнер транспортного средства Опциональный 2~11 Особая роль транспортных средств в дорожном трафике (например, общественный транспорт, транспортные средства реализующие спасательную операцию, и т.д.).

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

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

Как ETSI ITS, так и IEEE 1609.2 рассматривают основанные на инфраструктуре открытого ключа (PKI) решения обеспечения безопасности для связи V2X, который является основанным на асимметрии решением обеспечения безопасности слоя приложений. Как правило, каждое сообщение V2V должно нести подпись, как, впрочем, либо сертификат, либо дайджест сертификата, чтобы обеспечивать защиту анонимности и целостности. Типичными размерами для подписи, дайджеста, и сертификата являются 64 байта, 8 байтов, и 117 байтов, соответственно.

Как объяснено выше, сообщения CAM могут иметь разные периодичности и/или разные размеры сообщения. Кроме того, периодичности могут даже меняться со временем в зависимости от скорости и других (менее влияющих) факторов, таких как курс или угол. Для того, чтобы обеспечить общее представление, предоставляются нижеследующие таблицы, идентифицирующие разные возможные компоненты сообщения (HF, LF, сертификат) и результирующие периодичности и размеры сообщения в зависимости от трех разных типичных диапазонов скорости.

CAM с основанными на PKI служебными данными обеспечения безопасности (для скорости транспортного средства > 144км/ч):

Компонент Распределение Параметры Частота передачи компонента HF CAM (включая подпись и дайджест) Детерминированное 10Гц (или каждые 100мс) Частота передачи компонента LF CAM Детерминированное 2Гц (или каждые 500мс) Частота передачи сертификата Детерминированное 1Гц (или каждые 1000мс) Размер компонента HF CAM (включая подпись и дайджест) Детерминированное 122 Байта Размер компонента LF CAM Детерминированное 60 Байтов Размер сертификата Детерминированное 117 Байтов

CAM с основанными на PKI служебными данными обеспечения безопасности (скорость ∈ [72, 144]км/ч)

Компонент Распределение Параметры Частота передачи компонента HF CAM (включая подпись и дайджест) Детерминированное 5Гц (или каждые 200мс) Частота передачи компонента LF CAM Детерминированное 1.67Гц (или каждые 600мс) Частота передачи сертификата Детерминированное 1Гц (или каждые 1000мс) Размер компонента HF CAM (включая подпись и дайджест) Детерминированное 122 Байта Размер компонента LF CAM Детерминированное 60 Байтов Размер сертификата Детерминированное 117 Байтов

CAM с основанными на PKI служебными данными обеспечения безопасности (скорость ∈ [48, 72]км/ч)

Компонент Распределение Параметры Частота передачи компонента HF CAM (включая подпись и дайджест) Детерминированное 3.33Гц (или каждые 300мс) Частота передачи компонента LF CAM Детерминированное 1.67Гц (или каждые 600мс) Частота передачи сертификата Детерминированное 0.83Гц (или каждые 1200мс) Размер компонента HF CAM (включая подпись и дайджест) Детерминированное 122 Байта Размер компонента LF CAM Детерминированное 60 Байтов Размер сертификата Детерминированное 117 Байтов

Как очевидно из вышеприведенной таблицы, размер компонентов и, следовательно, CAM остается одним и тем же, но их частота генерирования/передачи меняется с разными диапазонами скорости. Применительно к вышеприведенной таблице, компонент HF CAM предполагается, что должен передаваться вместе с подписью и дайджестом, приводя к размеру сообщения приблизительно в 122 байта (т.е., достаточный, чтобы транспортировать 8 байтов для заголовка, 18 байтов для основного контейнера, 23 байта для высокочастотного контейнера, 64 байта для подписи и 8 байтов для дайджеста). Компонент LF CAM, который объединяется с высокочастотным компонентом, приблизительно имеет размер дополнительных 60 байтов, так что результирующий размер CAM со всеми контейнерами/компонентами составляет 182 байта. Компонент сертификата (также именуемый компонентом безопасности), который объединяется с высокочастотным компонентом, приблизительно имеет размер в дополнительные 117 байтов так, что результирующий размер CAM со всеми контейнерами/компонентами составляет 299 байта или без контейнера/компонента LF CAM составляет 239 байтов.

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

В вышеприведенном, периодические сообщения Совместной Осведомленности были описаны очень подробно, также указывая их отличающийся контент, конкретные периодичности и размеры сообщения. Тем не менее, следует отметить, что несмотря на то, что некоторая из вышеприведенной информации уже была стандартизована, другая информация, такая как периодичности и размеры сообщения, еще не стандартизована и основана на допущениях. Кроме того, стандартизация может измениться в будущем и, следовательно, также может изменить аспекты того, каким образом CAM генерируются и передаются. Кроме того, несмотря на то, что в настоящее время разные компоненты, описанные выше (HF CAM, LF CAM, сертификат) передаются вместе, т.е., в качестве одного сообщения, когда они случаются вместе, это не обязательно так. В будущем также существует возможность того, чтобы передавать эти контейнеры/компоненты отдельно друг от друга, тогда вероятно соответственно включая Заголовок и возможно основной контейнер. Следовательно, вышеприведенное подробное описание CAM следует понимать в качестве примера, сформулированного в целях иллюстрации, несмотря на то, что размеры сообщения и периодичности являются реалистичными и основанными на результатах моделирования. Описанное выше сообщение CAM и его контент, периодичности и размеры сообщения будут использованы на всем протяжении данной заявки для того, чтобы объяснять лежащие в основе принципы изобретения. То, что является важным для изобретения, состоит в том, что связь V2V потребует от UE транспортных средств передавать разные данные периодично, и предсказуемо, что периодичность может быстро меняться, как функция динамики транспортного средства, такой как (относительная) скорость, углы, курс, и возможно другие факторы, такие как расстояние транспортного средства, и т.д. Следовательно, задача состоит в том, что UE транспортных средств должно иметь возможность передачи нескольких периодических пакетов разных размеров сообщения с разными и варьирующимися периодичностями.

Для того, чтобы UE транспортных средств имело ресурсы радиосвязи на побочной линии связи, чтобы передавать CAM, предполагается распределение ресурсов радиосвязи Режима 1 и/или Режима 2, как объяснено выше. Применительно к распределению ресурсов радиосвязи Режима 1, eNB распределяет ресурсы для сообщения SA и данные для каждого периода SA. Тем не менее, когда присутствует много трафика (например, высокочастотный периодический трафик), служебные данные по линии связи Uu от UE к eNB могут быть большими.

Как очевидно из вышеприведенного, большая часть трафика V2V является периодической, так что 3GPP согласился с тем, что применительно к Режиму 1 связи V2V побочной линии связи (т.е., eNB планируемое распределение ресурсов радиосвязи), полупостоянное распределение ресурсов радиосвязи побочной линии связи будет поддерживаться посредством eNB и UE.

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Неограничивающие и примерные варианты осуществления предоставляют улучшенный способ выделения ресурсов для связи транспортных средств мобильному терминалу транспортного средства.

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ФИГУР

В нижеследующем примерные варианты осуществления описываются более подробно со ссылкой на прикрепленные фигуры и чертежи.

Фиг. 1 показывает примерную архитектуру системы 3GPP LTE,

Фиг. 2 показывает примерную сетку ресурсов нисходящей линии связи у слота нисходящей линии связи субкадра, как определено для 3GPP LTE (Редакция 8/9),

Фиг. 3 схематично иллюстрирует то, каким образом создавать линию связи слоя-2 через PC5 для связи ProSe,

Фиг. 4 иллюстрирует использование ресурсов передачи/приема для системы перекрытия (LTE) и подложки (D2D),

Фиг. 5 иллюстрирует передачу Назначения Планирования и данных D2D для двух UE,

Фиг. 6 иллюстрирует хронометраж связи D2D для UE-автономного планирования Режима 2,

Фиг. 7 иллюстрирует хронометраж связи D2D для eNB-планируемого планирования Режима 1,

Фиг. 8 иллюстрирует примерную модель архитектуры для ProSe для сценария не-роуминга,

Фиг. 9 иллюстрирует примерный состав сообщения CAM,

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

Фиг. 11 иллюстрирует передачу трех разных компонентов CAM, как, впрочем, и использование трех конфигураций SPS для передачи CAM в соответствии с примерной реализацией первого варианта осуществления,

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

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

Фиг. 14 также иллюстрирует передачу трех разных компонентов CAM, как, впрочем, и использование девяти разных конфигураций SPS для передачи CAM в соответствии с дополнительной примерной реализацией первого варианта осуществления, в предположении, что UE транспортных средств поддерживает три разных диапазона скорости,

Фиг. 15 также иллюстрирует передачу трех разных компонентов CAM, как, впрочем, и использование десяти разных конфигураций SPS для передачи CAM в соответствии с дополнительной примерной реализацией первого варианта осуществления, в предположении, что UE транспортных средств поддерживает три разных диапазона скорости.

ПОДРОБНОЕ ОПИСАНИЕ

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

Понятие «ресурсы радиосвязи», используемое в наборе пунктов формулы изобретения и в заявке, следует понимать в широком смысле как ссылающееся на физические ресурсы радиосвязи, такие как частотно-временные ресурсы.

Понятие «передача прямой связи», используемое в заявке, следует понимать в широком смысле как передачу напрямую между двумя оборудованиями пользователя, т.е., не через базовую станцию радиосвязи (например, eNB). Соответственно, передача прямой связи выполняется через «прямое соединение побочной линии связи», которое является понятием, используемым для соединения, созданного напрямую между двумя оборудованиями пользователя. Например, в 3GPP используется терминология связи D2D (Устройство-с-Устройством) или связи ProSe, или связи побочной линии связи. Понятие «прямое соединение побочной линии связи» следует понимать в широком смысле и следует понимать в контексте 3GPP как интерфейс PC5, описанный в разделе предпосылок создания изобретения.

Понятие «ProSe» или в его несокращенной форме, «Услуги Близости», используемое в заявке, применяется в контексте основанных на Близости приложений и услуг в системе LTE как в качестве примера объяснено в разделе предпосылок создания изобретения. Другая терминология, такая как «D2D», также используется в данном контексте, чтобы относиться к связи Устройство-с-Устройством, применительно к Услугам Близости.

Понятие «мобильный терминал транспортного средства», используемое на всем протяжении заявки, следует понимать в контексте нового предмета исследования V2X (связь транспортных средств) 3GPP, как объяснено в разделе предпосылок создания изобретения. Соответственно, мобильный терминал транспортного средства следует понимать в широком смысле как мобильный терминал, который в частности инсталлирован в транспортном средстве (например, автомобиле, грузовых автомобилях, мотоциклах, и т.д.), чтобы осуществлять связь транспортных средств, т.е., пропуская информацию, относящуюся к транспортному средству, к другим объектам (таким как транспортные средства, инфраструктура, пешеходы), например, в целях обеспечения безопасности или помощи водителю. Опционально, мобильный терминал транспортного средства может иметь доступ к информации, доступной в навигационной системе (при условии, что она также инсталлирована на автомобиле), такой как информация карты и т.д.

Как объяснено в разделе предпосылок создания изобретения, 3GPP ввел новый предмет исследования для связи транспортных средств при поддержке LTE, которая должна быть основана на процедурах ProSe, чтобы осуществлять обмен трафиком V2V между разнообразными мобильными терминалами транспортных средств и другими станциями. Кроме того, полупостоянное распределение ресурсов радиосвязи должно поддерживаться трафиком V2V для распределения Режима 1 побочной линии связи с тем, чтобы сокращать объем планирования, для выполнения посредством eNB. Тем не менее, настоящие механизмы SPS не адаптированы для трафика V2V и его характеристикам. Например, для обычного полупостоянного планирования по линии связи Uu (т.е., между eNB и UE), eNB принимает информацию QCI (идентификатор класса QoS) от MME (Объекта Управления Мобильностью). Информация QCI указывает, что определенный носитель, сконфигурированный между eNB и UE, конфигурируется для транспортировки трафика VoIP, так что eNB узнает о периодическом трафика, генерируемом посредством UE по носителю. eNB затем может конфигурировать полупостоянное распределение ресурсов радиосвязи для UE, посредством отправки сигнализации RRC к UE, чтобы конфигурировать периодичность SPS. Затем, когда UE требуется фактически передать данные VoIP через носитель и передать соответствующий Отчет о Статусе Буфера, указывающий на то, что присутствуют данные, которые должны быть переданы для трафика VoIP, eNB будет отправлять PDCCH к UE, чтобы активировать конфигурацию SPS, при этом сообщение PDCCH также указывает какие ресурсы радиосвязи UE разрешается периодически использовать (тем самым распределяя конкретный объем ресурсов радиосвязи). Соответственно, UE использует ресурсы SPS для периодической передачи трафика VoIP.

Тем не менее, eNB не обладает знаниями о типе трафика (например, периодичности или размере сообщения), который будет передаваться конкретным UE транспортных средств через соединение побочной линии связи, так что он не может правильно определить ни объем ресурсов для распределения посредством полупостоянного распределения ресурсов радиосвязи, ни периодичность этих полупостоянных ресурсов радиосвязи.

Даже если eNB будет как-то принимать информацию касательно трафика, который должен быть передан посредством UE транспортных средств, следует отметить, что UE транспортных средств должно будет передавать трафик V2V с разными периодичностями и/или разными размерами сообщения, который значительно отличается от типа трафика VoIP, для которого текущий механизм SPS был разработан. Кроме того, периодичность, с которой трафик V2V должен передаваться, является переменной, поскольку она может меняться, например, в зависимости от динамики транспортного средства, такой как скорость, с которой движется транспортное средство. Вследствие этого, текущий стандартизованный механизм SPS недостаточен, чтобы справиться с этими разными сценариями использования V2V.

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

Конкретные реализации разнообразных вариантов осуществления должны быть реализованы в широком техническом описании, как задано стандартами 3GPP и объяснено частично в разделе предпосылок создания изобретения, с конкретными ключевыми признаками, добавленными как, объясняется в нижеследующем, относящемся к разнообразным вариантам осуществления. Следует отметить, что варианты осуществления могут быть преимущественно использованы, например, в системе мобильной связи, такой как системы связи 3GPP LTE-A (Редакция 10/11/12/13), как описано в разделе Технические Предпосылки Создания Изобретения выше (или более поздних редакциях), но варианты осуществления не ограничиваются их использованием в данных конкретных примерных сетях связи.

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

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

Первый вариант осуществления

В нижеследующем первый вариант осуществления для решения упомянутой выше проблем(ы) будет описан подробно. Также будут объяснены разные реализации и варианты первого варианта осуществления.

В качестве примера, предполагается UE транспортных средств, которое инсталлировано в транспортном средстве и выполнено с возможностью выполнения связи транспортных средств на основе инфраструктуры D2D, как объяснено в разделе предпосылок создания изобретения данной заявки. Тем не менее, как будет объяснено более подробно позже, принципы, лежащие в основе изобретения, не ограничиваются тем, чтобы применяться лишь UE транспортных средств, но также могут быть реализованы посредством обычных UE (т.е., не относящихся к транспортным средствам), которые, например, осуществляют передачу периодических данных через интерфейс Uu к eNB или интерфейс PC5 (соединение побочной линии связи) к другому UE. Что бы то ни было, применительно к нижеследующему обсуждению предполагается, что это UE транспортных средств, которому требуется периодически передавать данные V2V.

Дополнительно предполагается, что UE транспортных средств передает (осуществляет широковещательную передачу) периодических данных, предназначенных другим UE (транспортных средств), несмотря на то, что также возможно, что периодические данные передаются другим UE (транспортных средств) (через интерфейс PC5), его eNB (через интерфейс Uu), Блокам Стороны Дороги (возможно через интерфейс PC5) и/или другим подходящим станциям, для которых интересны периодические данные, передаваемые посредством UE транспортных средств; может предполагаться, что передача от UE транспортных средств является типа точка-многоточка, тем самым достигая всех принимающих объектов в его зоне.

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

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

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

Существуют разные компоненты CAM (например, HF CAM, LF CAM, сертификат будут компонентами CAM, на основе которых изобретение будет объяснено в нижеследующем), широковещательная передача которых должна осуществляется периодически посредством UE транспортных средств, но с разными периодичностями. В нижеследующем в основном предполагается, что в конкретный момент времени только одно сообщение CAM передается/осуществляется его широковещательная передача посредством UE транспортных средств, причем упомянутое сообщение CAM, тем не менее, содержит разные компоненты CAM, которые должны быть переданы в тот момент времени (т.е. компоненты CAM, которые совпадают с тем моментом времени, несмотря на то, что имеют разные периодичности). Другими словами, в случае, когда разные компоненты CAM должны передаваться посредством UE транспортных средств в одно и тоже время (период SC в интерфейсе PC5), разные компоненты CAM объединяются вместе, чтобы формировать одно сообщение CAM, которое затем передается. Чтобы объединение фактически работало, периодичности разных компонентов CAM должны быть скоординированы (т.е., быть кратными друг другу) так, что разные компоненты CAM действительно совпадают в конкретных одних и тех же моментах времени. Единые CAM, таким образом, передаются периодическим образом, с единой периодичностью (которая задается наивысшей частотой передачи компонентов CAM, которые должны быть переданы (например, компонентом HF CAM), но с разным контентом и, следовательно, размером сообщения (т.е. разные компоненты CAM содержатся в единых сообщениях CAM в разные моменты времени), где в разных размерах сообщения также варьируются периодически (см., например, Фиг. 10 и связанное описание). Таким образом, механизму распределения ресурсов радиосвязи требуется распределять разный объем ресурсов радиосвязи в разные моменты времени.

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

Следует отметить, что стандартизация 3GPP еще полностью не согласовала частоту передачи разных компонентов CAM, будет или нет объединение опциональным или обязательным, или каким точно образом разные компонент CAM будут передаваться. В любом случае, это может также измениться в будущих редакциях. Принципы, лежащие в основе изобретения, применимы к любому из этих случаев, даже несмотря на то, что может потребоваться применить незначительные адаптации, чтобы учитывать эти изменения.

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

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

Коротко, UE (транспортных средств) будет передавать периодические данные (например, CAM) другим принимающим объектам (например, другим станциям транспортных средств). Для того, чтобы передавать периодические данные, UE транспортных средств требуются ресурсы радиосвязи, которые могут быть, например, распределены посредством eNodeB, например, в соответствии с распределением ресурсов радиосвязи Режима 1 ProSe, как объяснено в разделе предпосылок создания изобретения. В соответствии с первым вариантом осуществления, eNodeB распределяет полупостоянные ресурсы радиосвязи UE транспортных средств, чтобы тем самым позволит UE транспортных средств передавать периодически ожидающие периодические данные.

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

Фаза подготовки теперь будет объяснена более подробно. Для того, чтобы eNodeB был способен настроить подходящую конфигурацию(ии) SPS для периодических данных, поддерживаемых посредством UE, eNodeB требуется знать о периодических данных, которые могут быть переданы UE транспортных средств в будущем. Как правило, конфигурация SPS осуществляет распределение периодическим образом (т.е. с периодическими моментами времени) конкретного объема ресурсов радиосвязи, который в свою очередь зависит от объема данных, которые UE требуется передать (например, размера сообщения CAM). Соответственно, UE транспортных средств передает информацию о периодических данных eNodeB так, что eNodeB способен определить одну или более разные возможные периодичности и/или разные возможные размеры сообщения, которые могут быть переданы UE транспортных средств в будущем. Узнав данную информацию, eNodeB затем способен сконфигурировать множество разных конфигураций SPS таким образом, что посредством активации позже одной или более этих конфигураций SPS для UE транспортных средств, UE транспортных средств обеспечивается возможность фактически передавать одни или более из поддерживаемых периодических данных, используя ресурсы радиосвязи, периодически распределяемые, посредством активированных конфигураций SPS.

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

Теперь более подробно будет объяснена фаза исполнения. Тогда предполагается, что UE транспортных средств в конечном счете захочет передать некоторые или все из компонентов данных CAM, и таким образом ему требуются (полупостоянным образом распределенные) ресурсы радиосвязи, чтобы выполнять передачу. Соответственно, UE транспортных средств будет информировать eNB о том, какие компоненты CAM оно хотело бы передать, и eNB в ответ выбирает, из числа ранее подготовленных конфигураций SPS, одну или более конфигурации SPS, которые будут распределять подходящие ресурсы UE транспортных средств с тем, чтобы передавать все из ожидающих сейчас компонентов CAM. eNB затем будет соответственно активировать выбранные одну или более конфигурации SPS в UE, например, посредством передачи подходящей команды активации.

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

Как объяснено выше, в соответствии с первым вариантом осуществления, можно распределять ресурсы SPS для UE транспортных средств, даже несмотря на то, что данные, которые должны быть переданы посредством UE транспортных средств, могут иметь меняющиеся периодичности и/или меняющиеся размеры сообщения. Вследствие этого, можно сократить служебные данные сигнализации по линии связи Uu между eNodeB и UE, которые иначе необходимы для того, чтобы неоднократно выполнять динамическое распределение ресурсов радиосвязи (например, см. объяснения Режима 1 ProSe в разделе предпосылок создания изобретения) для каждого периода SC. Кроме того, не требуется передача Отчета о Статусе Буфера, используемого UE транспортных средств чтобы указывать на то, что (периодические) данные ожидают передачи, от UE к eNB, чтобы инициировать то, чтобы eNB распределял динамические ресурсы каждый раз, когда поступают периодические данные на стороне UE.

Фиг. 11 в качестве примера иллюстрирует то, что активируются три разных конфигурации SPS, чтобы обеспечить передачу трех разных компонентов CAM (Сертификата, компонента LF CAM, и компонента HF CAM) в соответствии с примерной реализацией первого варианта осуществления. Для данной примерной реализации первого варианта осуществления, предполагается, что одна конфигурация SPS сконфигурирована для одного конкретного компонента данных CAM. Соответственно, UE транспортных средств, которое желает передать три разных компонента CAM, может использовать периодические ресурсы радиосвязи, распределенные посредством конфигурации 1 SPS, чтобы передавать компонент HF CAM, может использовать периодические ресурсы радиосвязи, распределенные посредством конфигурации 2 SPS, чтобы передавать компонент LF CAM, и может использовать периодические ресурсы радиосвязи, распределенные посредством конфигурации 3 SPS, чтобы передавать сертификат.

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

В нижеследующем будут более конкретные реализации первого варианта осуществления.

В широкой реализации первого варианта осуществления, просто предполагалось, не погружаясь в дальнейшие подробности, что UE транспортных средств будет поддерживать передачу периодических данных, которые содержат один или более разные компоненты данных, которые должны быть переданы с разными возможными периодичностями передачи и/или разными возможными размерами сообщения. Как объяснено до этого, задача, поставленная перед механизмом распределения SPS первого варианта осуществления, состоит в том, что передача данных транспортных средств включает разные возможные периодичности и/или разные размеры сообщения. Это будет объяснено более подробно на основе сообщений CAM, представленных в разделе предпосылок создания изобретения.

В соответствии с одним возможным примерным сценарием, UE транспортных средств поддерживает передачу нескольких компонентов CAM, например, компонента HF CAM, компонента LF CAM, и сертификата безопасности. Соответственно, возможный размер сообщения отличается в зависимости от того, какие компоненты CAM передаются в сообщении CAM. Общее представление разных возможных размеров сообщения дано в нижеследующей таблице:

Компонент CAM Размер результирующего сообщения CAM компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта компонент HF CAM+компонент LF CAM 182 байта компонент HF CAM+компонент LF CAM+сертификат безопасности CAM 299 байтов компонент HF CAM+сертификат безопасности CAM 239 байтов

Применительно к вышеприведенной таблице предполагается, что разные компоненты CAM, передаваемые в один и тот же момент времени, формируют одно единое сообщение CAM так, что компонент LF CAM и сертификат безопасности CAM соответственно объединяются с базовым HF компонентом CAM, который передается с наивысшей частотой передачи. Соответственно, размер сообщения будет варьироваться в зависимости от момента времени, как перечислено в правом столбце таблицы и как в качестве примера иллюстрируется на Фиг. 11 (из-за предполагаемых разных периодичностей компонентов CAM, Фиг. 11 не показывает передачу компонента HF CAM+сертификата безопасности CAM; в этом отношении, см. Фиг. 10 среднюю часть).

Разные компоненты CAM, должны быть переданы с разными периодичностями так, что каждое возможное сообщение CAM, которое должно передаваться в конкретный момент времени, будет передаваться с разной периодичностью, как показано в качестве примера в нижеследующей таблице:

Компонент CAM Размер результирующего сообщения CAM Периодичность передачи компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта Каждые 100мс компонент HF CAM + компонент LF CAM 182 байта Каждые 500мс компонент HF CAM + компонент LF CAM+сертификат безопасности CAM 299 байтов Каждые 1000мс компонент HF CAM + сертификат безопасности CAM 239 байтов Каждые 1000мс

Значение периодичности передачи, предполагаемое выше, фактически относится к периодичности того компонента CAM в сообщении CAM с самой низкой частотой передачи (например, 500мс у компонента LF CAM для сообщения CAM, содержащего компоненты HF CAM и LF CAM). Указанную периодичность передачи не следует понимать, как периодичность передачи конкретного сообщения CAM. Например, сообщение CAM, содержащее компоненты HF CAM и LF CAM фактически не передается каждые 500мс (а каждые 1000мс, см. Фиг. 11).

Значения в качестве примера предполагаемые в таблице выше для периодичности передачи, являются тем, что предполагаются для одного диапазона скорости транспортного средства > 144км/ч, который предполагается как только один поддерживаемый UE транспортных средств.

В соответствии с другим возможным примерным сценарием, UE транспортных средств поддерживает передачу только одного компонента CAM, например, компонента HF CAM, таким образом, имея ожидаемый фиксированный размер в 122 байта (см. таблицу выше) и ожидаемую фиксированную периодичность в 100мс (см. таблицу выше). Тем не менее, особая характеристика данных V2V состоит в том, что периодичность разных компонентов CAM может варьироваться с динамикой транспортного средства, например, скоростью, с которой UE транспортных средств перемещается. Вследствие этого, даже несмотря на то, что UE транспортных средство поддерживает передачу только одного компонента CAM, периодичность, с которой один компонент CAM должен передаваться, может варьироваться по времени, вновь приводя к тому, что несколько периодичностей должны учитываться посредством механизма распределения SPS. Это приводится в качестве примера к нижеследующей таблице.

Компонент CAM Размер результирующего CAM Периодичность передачи при скорости > 144км/ч Периодичность передачи при скорости [72, 144]км/ч Периодичность передачи при скорости [48, 72]км/ч компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта Каждые 100мс Каждые 200мс Каждые 300мс

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

Компонент CAM Размер результирующего сообщения CAM Периодичность передачи при скорости > 144км/ч Периодичность передачи при скорости [72, 144]км/ч Периодичность передачи при скорости [48, 72]км/ч компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта Каждые 100мс Каждые 200мс Каждые 300мс компонент HF CAM + компонент LF CAM 182 байта Каждые 500мс Каждые 600мс Каждые 600мс компонент HF CAM + компонент LF CAM + сертификат безопасности CAM 299 байтов Каждые 1000мс Каждые 1000мс Каждые 1200мс компонент HF CAM + сертификат безопасности CAM 239 байтов Каждые 1000мс Каждые 1000мс Каждые 1200мс

Как приведено в качестве примера выше, может быть много разных сочетаний компонентов CAM (левый столбец таблицы выше), приводящих к разным возможным размерам сообщения CAM (например, 122 байта, 182 байта, 299 байтов, или 239 байтов) и приводя к разным возможным периодичностям в зависимости от конкретного компонента CAM и/или возможно поддерживаемых скоростей (диапазонов) для UE транспортных средств (например, 100мс, 200мс, 300мс, 500мс, 600мс, 1000мс, 1200мс). Конфигурации SPS, сконфигурированные посредством eNB на фазе подготовки, должны учитывать это и должны согласовывать результирующие периодичности передачи сообщения CAM и/или результирующие размеры сообщения CAM, поддерживаемые UE транспортных средств так, что подходящие конфигурации SPS могут быть активированы позже, чтобы позволить UE транспортного средства передавать любые (сочетание) из поддерживаемых периодических данных.

Разнообразные разные конфигурации SPS подготавливаются посредством eNodeB, как будет приведено в качестве примера для вышеприведенных выбранных примеров. В частности, сначала предполагается для простоты, что UE транспортных средств поддерживает передачу нескольких компонентов CAM, но поддерживает только один диапазон скорости, например, диапазон наивысшей скорости > 144км/ч так, что несмотря на то, что учитывается несколько разных периодичностей, сами по себе периодичности не меняются по времени (например, из-за изменения скорости).

Компонент CAM Размер результирующего сообщения CAM Периодичность передачи Конфигурации SPS компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта Каждые 100мс Конфигурация 1 SPS (122 байта каждые 100мс) компонент HF CAM + компонент LF CAM 182 байта Каждые 500мс Конфигурация 2 SPS (60 байтов каждые 500мс) компонент HF CAM + компонент LF CAM + сертификат безопасности CAM 299 байтов Каждые 1000мс Конфигурация 3 SPS (117 байтов каждые 1000мс) компонент HF CAM + сертификат безопасности CAM 239 байтов Каждые 1000мс Отдельной конфигурации SPS не требуется

В вышеприведенной примерной реализации первого варианта осуществления, три разные конфигурации 1, 2 и 3 SPS конфигурируются посредством eNodeB так, что присутствует одна отдельная конфигурация SPS, которая согласуется с каждым из возможных компонентов CAM, которые UE транспортных средств поддерживает для передачи. Следует отметить, что для возможного сочетания компонента HF CAM и сертификата безопасности CAM, в данном конкретном примере не требуется отдельной конфигурации SPS, в виду того, что данное конкретное сочетание не происходит из-за примерных периодичностей, предполагаемых для отдельных компонентов CAM.

Конфигурация 1 SPS распределяет особые ресурсы радиосвязи достаточные, чтобы передавать 122 байта базового компонента HF CAM каждые 100мс, что является периодичностью компонента HF CAM. Соответственно, UE будет использовать периодические ресурсы радиосвязи, распределенные посредством конфигурации 1 SPS, для того, чтобы передавать сообщения CAM, содержащие компонент HF CAM.

Более того, конфигурация 2 SPS распределяет особые ресурсы радиосвязи достаточные, чтобы передавать 60 байтов дополнительного (объединяемого) компонента LF CAM каждые 500мс, что является периодичностью компонента LF CAM. Соответственно, UE будет использовать периодические ресурсы радиосвязи, распределенные посредством конфигурации 2 SPS для того, чтобы передавать сообщения CAM, содержащие компонент LF CAM. Кроме того, конфигурация 3 SPS распределяет особые ресурсы радиосвязи достаточные, чтобы передавать 117 байтов дополнительно (объединяемого) сертификат безопасности каждые 1000мс, что соответствует периодичности сертификата безопасности. Соответственно, UE будет использовать периодические ресурсы радиосвязи, распределенные посредством конфигурации 3 SPS для того, чтобы передавать сообщения CAM, содержащие сертификат безопасности.

Фиг. 12 иллюстрирует использование трех конфигураций SPS, как в качестве примера предполагается выше, для передачи сообщений CAM посредством UE транспортных средств в соответствии с примерной реализацией первого варианта осуществления. Как очевидно из Фиг. 12, три конфигурации SPS согласуются с тремя разными компонентами данных, которые должны быть переданы посредством UE транспортных средств. Пунктирные прямоугольники, охватывающие несколько компонентов данных, которые должны быть переданы в один и тот же момент времени, должны указывать на то, что эти разные компоненты данных передаются как одно сообщение CAM, как в качестве примера предполагалось выше. Как очевидно из Фиг. 12, в те моменты времени, где несколько компонентов CAM должны быть переданы в одном сообщении CAM, UE транспортных средств объединяет ресурсы радиосвязи, распределенные посредством нескольких конфигураций SPS с тем, чтобы иметь достаточно доступных ресурсов радиосвязи, чтобы передавать все сообщение CAM (т.е. включающее в себя несколько компонентов CAM). Например, при передаче компонента HF CAM вместе с компонентом LF CAM, ресурсы радиосвязи, распределенные через конфигурации 1 и 2 SPS, объединяются (т.е., суммируются, используются вместе), чтобы таким образом иметь достаточно доступных ресурсов радиосвязи для передачи. Сходным образом, при передаче компонента HF CAM вместе с компонентом LF CAM, как, впрочем, и сертификата безопасности, ресурсы радиосвязи, распределенные через конфигурации 1, 2 и 3 SPS, объединяются, чтобы таким образом иметь достаточно доступных ресурсов радиосвязи, чтобы передавать все объединенное сообщение CAM.

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

Компонент CAM Размер результирующего сообщения CAM Периодичность передачи Конфигурации SPS компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта Каждые 100мс Конфигурация 1 SPS (122 байта каждые 100мс) компонент HF CAM + компонент LF CAM 182 байта Каждые 500мс Конфигурация 2 SPS (182 байта каждые 500мс) компонент HF CAM + компонент LF CAM + сертификат безопасности CAM 299 байтов Каждые 1000мс Конфигурация 3 SPS (299 байтов каждые 1000мс) компонент HF CAM + сертификат безопасности CAM 239 байтов Каждые 1000мс Отдельной конфигурации SPS не требуется

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

В соответствии с Фиг. 12, Фиг. 13 иллюстрирует то, каким образом разные конфигурации используются UE транспортных средств, чтобы передавать периодические данные (компоненты) CAM. В те моменты времени, в которые UE транспортных средств должно передавать несколько компонентов CAM в одном сообщении CAM, UE транспортного средства должно выбирать ту конфигурацию SPS, из числа активированных, обеспечивающую достаточно ресурсов радиосвязи, чтобы передавать большее сообщение CAM. Как в предыдущей примерной реализации первого варианта осуществления, UE транспортных средств будет выбирать конфигурацию 1 SPS для того, чтобы передавать сообщение CAM, содержащее только компонент HF CAM. С другой стороны, при передаче компонента HF CAM вместе с компонентом LF CAM, требуются ресурсы радиосвязи, чтобы передавать суммарно 182 байта, так что UE транспортных средств должно выбирать конфигурацию 2 SPS и должно использовать особые ресурсы радиосвязи, распределенные посредством конфигурации 2 SPS для того, чтобы передавать упомянутое сообщение CAM, содержащее компонента HF CAM, как, впрочем, и компонент LF CAM. Соответственно, при передаче компонента HF CAM вместе с компонентом LF CAM, как, впрочем, и сертификата безопасности, требуются ресурсы радиосвязи, чтобы передавать суммарно 299 байтов так, что UE транспортных средств должно выбирать конфигурацию 3 SPS. UE транспортных средств будет, таким образом, использовать особые ресурсы радиосвязи, распределенные посредством конфигурации 3 SPS для того, чтобы передавать упомянутое сообщение CAM, содержащее три компонента.

Реализации, которые обсуждались выше, первого варианта осуществления в соответствии с Фиг. 12 и Фиг. 13 также могут быть применены к более сложным случаям, где UE транспортных средств также поддерживает несколько диапазонов скорости, например, три предполагаемых диапазона скорости в виде > 144, между 72 и 144, и между 48 72, приводя к дополнительным отличным периодичностям, которые должны поддерживаться для соответствующих составляющих CAM.

Нижеследующая таблица предполагает, что ресурсы радиосвязи, распределяемые посредством разных конфигураций SPS, могут быть объединены UE транспортных средств, чтобы собирать достаточно ресурсов радиосвязи, чтобы иметь возможность передачи объединенных сообщений CAM, содержащих несколько компонентов данных (см. обсуждение для Фиг. 12).

Компонент CAM Размер результирующего сообщения CAM Периодичность передачи Конфигурации SPS для скорости > 144км/ч Конфигурации SPS для скорости [72, 144]км/ч Конфигурации SPS для скорости [48, 72]км/ч компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта Каждые 100мс
Каждые 200мс
Каждые 300мс Конфигурация 1 SPS (122 байта каждые 100мс) Конфигурация 4 SPS (122 байта каждые 200мс) Конфигурация 7 SPS (122 байта каждые 300мс) компонент HF CAM + компонент LF CAM 182 байта Каждые 500мс
Каждые 600мс Конфигурация 2 SPS (60 байта каждые 500мс) Конфигурация 5 SPS (60 байта каждые 600мс) Конфигурация 8 SPS (60 байта каждые 600мс) компонент HF CAM + компонент LF CAM + сертификат безопасности CAM 299 байтов Каждые 1000мс
Каждые 1200мс Конфигурация 3 SPS (117 байта каждые 1000мс) Конфигурация 6 SPS (117 байта каждые 1000мс) Конфигурация 9 SPS (117 байта каждые 1200мс) компонент HF CAM + сертификат безопасности CAM 239 байтов Каждые 1000мс
Каждые 1200мс Отдельная конфигурация SPS не требуется Отдельная конфигурация SPS не требуется Отдельная конфигурация SPS не требуется

Как очевидно из вышеприведенной таблицы, предполагается, что eNodeB на фазе подготовки конфигурирует 9 отдельных конфигураций SPS соответственно, распределяя ресурсы радиосвязи с подходящей периодичностью так, чтобы позволит UE транспортных средств, после активации позже одной или более конфигураций SPS, передавать соответствующие компоненты CAM периодическим образом.

В зависимости от текущей скорости UE транспортных средств, eNodeB будет конфигурировать UE транспортных средств, чтобы либо активировать конфигурации 1, 2 и 3 SPS, когда скорость является > 144км/ч, либо активировать конфигурации 4, 5 и 6 SPS, когда скорость находится между 72 и 144км/ч, либо активировать конфигурации 7, 8 и 9 SPS, когда скорость находится между 48 и 72 км/ч.

Фиг. 14 иллюстрирует то, каким образом 9 отдельных конфигураций SPS могут быть использованы посредством UE транспортных средств, чтобы периодически передавать сообщения CAM разных размеров. Верхняя часть Фиг. 14 (т.е., относящаяся к скорости > 144км/ч) главным образом соответствует Фиг. 12 и, следовательно, вновь не будет объяснена. Для диапазона скорости между 72 и 144 км/ч, Фиг. 14 иллюстрирует то, каким образом UE транспортных средств объединяет ресурсы радиосвязи, распределенные посредством активированной конфигурации 4, 5, и 6 с тем, чтобы иметь возможность передачи сообщений CAM разных размеров. В частности, сообщение CAM, составленное из компонента HF CAM, как, впрочем, и компонента LF CAM может быть передано посредством UE транспортных средств посредством объединения ресурсов радиосвязи, распределенных посредством конфигураций 4 и 5 SPS. Сообщение CAM, составленное из всех трех компонентов (HF CAM, LF CAM, сертификата безопасности) может быть передано посредством UE транспортных средств посредством объединения и использования ресурсов радиосвязи, распределенных посредством конфигураций 4, 5 и 6 SPS. Сообщение CAM, составленное из компонента HF CAM, как, впрочем, и сертификата безопасности может быть передано UE транспортных средств посредством объединения и использования ресурсов радиосвязи, распределенных посредством конфигураций 4 и 6 SPS.

Для диапазона скорости между 48 и 72км/ч, Фиг. 14 иллюстрирует то, каким образом UE транспортных средств объединяет ресурсы радиосвязи, распределенные посредством активированных конфигураций 7, 8, и 9 SPS, чтобы иметь возможность передачи сообщений CAM разных размеров. В частности, сообщение CAM, составленное из компонента HF CAM, как, впрочем, и компонента LF CAM может быть передано посредством UE транспортных средств посредством объединения ресурсов радиосвязи, распределенных посредством конфигураций 7 и 8 SPS. Сообщение CAM, составленное из всех трех компонентов (HF CAM, LF CAM, сертификата безопасности) может быть передано посредством UE транспортных средств посредством объединения и использования ресурсов радиосвязи, распределенных посредством конфигураций 7, 8 и 9 SPS.

В нижеследующем, альтернативная реализация первого варианта осуществления, которая объяснялась в связи с Фиг. 13, теперь будет также расширена на UE транспортных средств, которое поддерживает несколько диапазонов скорости.

Компонент CAM Размер результирующего сообщения CAM Периодичность передачи Конфигурации SPS для скорости > 144км/ч Конфигурации SPS для скорости [72, 144]км/ч Конфигурации SPS для скорости [48, 72]км/ч компонент HF CAM (включая заголовок, основной контейнер, подпись и дайджест) 122 байта Каждые 100мс
Каждые 200мс
Каждые 300мс Конфигурация 1 SPS (122 байта каждые 100мс) Конфигурация 4 SPS (122 байта каждые 200мс) Конфигурация 8 SPS (122 байта каждые 300мс) компонент HF CAM + компонент LF CAM 182 байта Каждые 500мс
Каждые 600мс Конфигурация 2 SPS (182 байта каждые 500мс) Конфигурация 5 SPS (182 байта каждые 600мс) Конфигурация 9 SPS (182 байта каждые 600мс) компонент HF CAM + компонент LF CAM + сертификат безопасности CAM 299 байтов Каждые 1000мс
Каждые 1200мс Конфигурация 3 SPS (299 байта каждые 1000мс) Конфигурация 6 SPS (299 байта каждые 1000мс) Конфигурация 10 SPS (299 байта каждые 1200мс) компонент HF CAM + сертификат безопасности CAM 239 байтов Каждые 1000мс
Каждые 1200мс Отдельная конфигурация SPS не требуется Конфигурация 7 SPS (239 байта каждые 1000мс) Отдельная конфигурация SPS не требуется

Фиг. 15 иллюстрирует соответствующее использование разных конфигураций SPS посредством UE транспортных средств для того, чтобы передавать разнообразные возможные сообщения CAM. Верхняя часть Фиг. 15 (относящаяся к скорости > 144км/ч) главным образом соответствует Фиг. 13 и, следовательно, не будет объясняться вновь. Для того, чтобы поддерживать передачу всех возможных компонентов CAM для диапазона скорости между 72 и 144км/ч, четыре разные конфигурации SPS конфигурируются посредством eNodeB. В отличие от сценария для диапазона скорости > 144км/ч, UE транспортных средств требуется передавать сообщение CAM, составленное из компонента HF CAM и сертификата безопасности CAM. В данной альтернативной реализации первого варианта осуществления, eNodeB должен таким образом конфигурировать отдельную конфигурацию SPS для данного возможного сообщения CAM, т.е. конфигурацию 7 SPS, распределяющую особые ресурсы радиосвязи, достаточные чтобы транспортировать 239 байтов каждые 1000мс. Данная конфигурация 7 SPS была необязательной в предыдущей реализации первого варианта осуществления, поскольку ресурсы радиосвязи конфигураций 4 и 6 SPS могли быть гибко объединены с тем, чтобы распределять достаточно (но не так много) ресурсов для передачи сообщения CAM, составленного из компонента HF CAM, как, впрочем, и сертификата безопасности (см. Фиг. 14).

Как неоднократно упоминалось, несколько конфигураций SPS подготавливаются посредством eNodeB, чтобы поддерживать разные возможные диапазоны скорости, на которых UE может перемещаться (в качестве примера динамики транспортного средства, которая влияет на периодичность разнообразных компонентов данных CAM). В таком сценарии, eNB также требуется быть информированным о возможных диапазонах скорости посредством UE транспортных средств, поскольку это будет оказывать влияние на разные периодичности, которые должны учитываться при подготовке множества конфигурации SPS. Одна опция состоит в передаче явной информации о диапазонах скорости, которые поддерживаются посредством UE транспортных средств, к eNB, например, вместе или отдельно от информации о периодических данных с тем, чтобы позволить eNB определять из них результирующие разные периодичности у периодических компонентов данных, которые должны быть рассмотрены при подготовке множества конфигураций SPS. Другая опция состоит в том, что UE транспортных средств передает уже разнообразные возможные периодичности, которые содержат также периодичности в поддерживаемых диапазонах скорости, так что является необязательным для UE дополнительно информировать eNB о поддерживаемых диапазонах скорости; eNB может выводить поддерживаемые диапазоны скорости из представленных в отчетах разных периодичностей, предполагая, что eNB имеет доступ к конкретной информации, позволяющей сделать данную ассоциацию, такой как стандартизованные определения для периодичностей сообщений и компонентов CAM в разных диапазонах скорости.

Кроме того, когда UE захочет фактически начать передачу периодических данных, UE должно проинформировать eNB о текущей скорости (или о диапазоне скорости, в котором оно находится), так что eNB может выбрать и активировать те конфигурации SPS, подготовленные для того указанного диапазона скорости, который в настоящий момент испытывается UE транспортных средств. Информация о текущей скорости может, например, быть передана посредством транспортного средства вместе с или отдельно от указания того, какие компоненты данных UE транспортных средств хотело бы передать. Например, примерная реализация первого варианта осуществления обеспечивает, что данное указание является отчетом о статусе буфера, указывающим, что для конкретных групп логического канала данные являются ожидающими в соответствующем буфере в UE. Соответственно, информация о текущей скорости UE транспортных средств может быть также передана в отчете о статусе буфера.

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

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

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

Как объяснено выше, UE транспортных средств передает информацию eNB о поддерживаемых периодических данных, которые UE транспортных средств возможно будет передавать в будущем. Как будет объяснено подробно со ссылкой на нижеследующие реализации первого варианта осуществления, это может быть реализовано разнообразными путями. В соответствии с примерной реализацией первого варианта осуществления, UE транспортных средств может информировать eNodeB явным образом о разных возможных периодичностях и/или разных возможных размерах сообщения у сообщений/компонентов CAM, которые UE транспортных средств поддерживает и, таким образом, возможно будет фактически передавать в будущем. Например, информация о периодических данных может, таким образом, включать в себя список возможных периодичностей и/или возможных размеров сообщения CAM, которые поддерживаются UE транспортных средств. eNodeB таким образом способен подготавливать подходящие конфигурации SPS для разнообразных разных поддерживаемых периодичностей и/или размеров сообщения.

В соответствии с вариантами данной реализации первого варианта осуществления, информация о периодических данных может быть передана в одном сообщении или в, по меньшей мере, двух отдельных сообщениях, в частности, информация о возможных периодичностях и возможных размерах сообщения может быть передана в одном сообщении, например, сообщении, которое основано на сообщении SidelinkUEInformation, которое в настоящее время указано в стандартах, чтобы указывать информацию побочной линии связи eNodeB (например, частоту, на которой UE заинтересовано передавать связь побочной линии связи, как, впрочем, и получателей передачи связи побочной линии связи, для которых UE запрашивает, назначение предназначенных ресурсов) (см. стандарт 3GPP TS 36.331 v13.0.0 раздел 6.2.2, включенный в настоящее описание посредством ссылки). В нижеследующем, определяется примерное расширенное сообщение SidelinkUEInformation в соответствии с данной реализацией первого варианта осуществления.

Сообщение SidelinkUEInformation

-- ASN1START

SidelinkUEInformation-r12::= SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE {

sidelinkUEInformation-r12 SidelinkUEInformation-r12-IEs,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

SidelinkUEInformation-r12-IEs::= SEQUENCE {

commRxInterestedFreq-r12 ARFCN-ValueEUTRA-r9

OPTIONAL,

commTxResourceReq-r12 SL-CommTxResourceReq-r12

OPTIONAL,

discRxInterest-r12 ENUMERATED {true}

OPTIONAL,

discTxResourceReq-r12 INTEGER (1..63)

OPTIONAL,

lateNonCriticalExtension OCTET STRING

OPTIONAL,

nonCriticalExtension SidelinkUEInformation-v13×0-IEs

OPTIONAL,

}

SidelinkUEInformation-v13×0-IEs::= SEQUENCE {

commTxResourceReq121-r13 SL-CommTxResourceReqUC-r13

OPTIONAL,

commTxResourceInfoReqRelay-r13 SEQUENCE {

commTxResourceReqRelay-r13 SL-CommTxResourceReqUC-r13,

ue-Type-r13 ENUMERATED {relayUE, remoteUE}

}

OPTIONAL,

discTxResourceReq-v13×0 SEQUENCE {

carrierFreqDiscTx-r13 INTEGER (1..maxFreq),

discTxResourceReqAddFreq-r13 SL-DiscTxResourceReqPerFreqList-r13

OPTIONAL

}

OPTIONAL,

discTxResourceReqPS-r13 SL-DiscTxResourceReq-r13

OPTIONAL,

discRxGapReq-r13 SL-GapRequest-r13

OPTIONAL,

discTxGapReq-r13 SL-GapRequest-r13

OPTIONAL,

discSysInfoReportList-r13 SL-SysInfoReportList-r13

OPTIONAL,

nonCriticalExtension SEQUENCE {}

OPTIONAL,

}

SL-CommTxResourceReq-r12::= SEQUENCE {

carrierFreq-r12 ARFCN-ValueEUTRA-r9

OPTIONAL,

destinationInfoList-r12 SL-DestinationInfoList-r12

}

SL-CommTxResourceReqUC-r13::= SEQUENCE {

carrierFreq-r13 ARFCN-ValueEUTRA-r9

OPTIONAL,

destinationInfoListUC-r13 SL-DestinationInfoListUC-r13

}

SL-DiscTxResourceReqPerFreqList-r13::= SEQUENCE (SIZE (1..maxFreq)) OF SL-DiscTxResourceReq-r13

SL-DiscTxResourceReq-r13::= SEQUENCE {

carrierFreq-r13 ARFCN-ValueEUTRA-r9

OPTIONAL,

discTxResourceReq-r13 INTEGER (1..63)

}

SL-DestinationInfoList-r12::= SEQUENCE (SIZE (1..maxSL-Dest-r12)) OF SL-DestinationIdentity-r12

SL-DestinationIdentity-r12::= BIT STRING (SIZE (24))

SL-DestinationInfoListUC-r13::= SL-DestinationInfoList-r12

SL-SysInfoReportList-r13::= SEQUENCE (SIZE (1.. maxSL-DiscSysInfoReportFreq-r13)) OF SL-SysInfoReport-r13

SidelinkUEInformation-v14×0-IEs::= SEQUENCE {
commTXResourceReq121-r14 SL-CommTxResourceReq-14 OPTIONAL,
…..}
SL-CommTxResourceReq-r14::= SEQUENCE {
carrierFreq-r14 ARFCN-ValueEUTRA-r9 Optional
destinationInfoListUC-r14 SL-DestinationInfoList-r14
SL-Traffic-r14 SL-TrafficList-r14 Optional
} SL-TrafficList-r14::= SEQUENCE (SIZE (1..maxSL-Traffic-r14)) OF
SL-TrafficType-r14 SL-TrafficType-r14::= SEQUENCE {
trafficType ENUMERATED {periodic, non-periodic}
periodicity ENUMERATED {
sf100, sf200, sf300, sf500,
sf600, sf1000, sf1200, spare10,
spare9, spare8, spare7, spare6,
spare5, spare4, spare3, spare2,
spare1},
messageSize INTEGER (1…300)

Дополнительные элементы, в качестве примера введенные в сообщение SidelinkUEInformation данной реализации первого варианта осуществления выделены жирным шрифтом и также заключены в рамку выше. Как очевидно из этого, присутствует поле периодичности, позволяющее указывать разнообразные разные периодичности, такие как те, что упомянуты выше для сообщений CAM. Сходным образом, предоставляется поле размера сообщения, которое позволяет указывать разнообразные разные размеры сообщения, соответственно со значением между 1 и 300 байтов. Опционально, поле типа трафика позволяет UE информировать eNodeB о том, являются ли данные периодическими или непериодическими.

В качестве альтернативы, вместо указания размера(ов) сообщения вместе с возможными периодичностями, в соответствии с дополнительным вариантом первого варианта осуществления, размер сообщения (т.е., объем данных, который UE желает передать) передается вместе с Отчетом о Статусе Буфера, который указывает, что данные являются ожидающими, чтобы быть отправленными посредством UE транспортных средств. В данном случае, в одном примере, на фазе подготовки eNodeB будет принимать только информацию о возможных разных периодичностях, но не информацию о возможных разных размерах, и будет таким образом переходить к подготовке разных конфигураций SPS на основе информации о возможных разных периодичностях. Например, множество конфигураций SPS, подготовленных посредством eNodeB, будут разными что касается периодичностей, но не будут особыми что касается того, какие и в каком количестве ресурсы радиосвязи будут распределены посредством конфигурации SPS. Затем, в момент, в который UE транспортных средств фактически желает начать передачу одного или более возможных компонентов данных, соответствующий буфер(ы) будет заполнен, тем самым инициируя то, что должен быть передан отчет о статусе буфера к eNodeB и, на основе которого eNodeB может фактически определять объем данных, которые UE хотело бы передать в отношении одного или более возможных компонентов данных. В ответ, eNodeB будет выбирать и активировать соответствующие подходящие конфигурации SPS (с соответствующими подходящими периодичностями), и затем будет активировать выбранную конфигурацию(ии) SPS для UE транспортных средств, при этом в то же самое время указывая, для каждой активированной конфигурации SPS, какие ресурсы распределяются соответствующей активированной конфигурацией SPS.

Иными словами, в отличие от объясненного ранее в связи с Фиг. с 11 по 15, в данном конкретном варианте первого варианта осуществления eNodeB еще не указывает ресурсы радиосвязи (например, конфигурацию 1 SPS, определяющую ресурсы радиосвязи, достаточные для того, чтобы передавать 122 байта), а лишь указывает периодичности. Например, eNodeB может подготавливать конфигурацию 1 SPS для поддержки передачи компонента HF CAM посредством UE транспортных средств с периодичностью 100мс (предполагая диапазон скорости > 144км/ч); сходным образом также для других конфигураций SPS. Применительно к сценарию, который предполагается для Фиг. 12, eNodeB, таким образом, будет также подготавливать три отличных конфигурации SPS, а именно соответственно для трех периодичностей каждых из 100мс, 500мс, и 1000мс. Применительно к сценарию, который предполагается для Фиг. 14, eNodeB будет подготавливать девять отличных конфигураций SPS, соответственно три для каждого диапазона скорости.

В соответствии с другой примерной реализацией первого варианта осуществления, UE транспортных средств может информировать eNodeB о конкретных компонентах данных, которые UE транспортных средств поддерживает, чтобы передавать в дополнение или вместо передачи информации о разных возможных периодичностях передачи и/или разных возможных размерах сообщения. Например, информация о периодических данных может, таким образом, включать в себя список, идентифицирующий компоненты данных, которые UE транспортных средств поддерживает, чтобы передавать в будущем. eNodeB имеет доступ к информации о возможных периодичностях и размерах сообщения, которые ассоциированы с этими идентифицированными компонентами данных; например, стандартизация 3GPP может явно указывать размеры и периодичности для разных возможных CAM и их компонентов. Таким образом, eNodeB, следовательно, способен подготовить подходящие конфигурации SPS для разнообразных разных поддерживаемых периодичностей и/или размеров сообщения.

Несмотря на то, что не указано подробно выше, команда активации, передаваемая посредством eNodeB к UE транспортных средств, чтобы активировать выбранные конфигурации, может быть в качестве примера реализована как сообщение, передаваемое через PDCCH, физический канал управления нисходящей линии связи. Например, сходным образом как для текущего указанного механизма SPS, eNodeB может передавать одну или более DCI, чтобы активировать одну или более из ранее сконфигурированных конфигураций SPS. В одном примере, новый C-RNTI может быть использован для DCI применительно к активации/деактивации побочной линии связи, поскольку UE требуется знать, что DCI являются для SPS побочной линии связи, а не для Uu SPS или динамического распределения линии связи Uu. Как упомянуто выше, применительно к конкретным реализациям первого варианта осуществления, сообщение PDCCH также может идентифицировать конкретные ресурсы радиосвязи, которое UR поддерживает, чтобы использовать для активированной конфигурации(ий) SPS.

Несмотря на то, что не указано подробно выше, eNodeB, после того как определил множество конфигураций SPS, должен информировать UE о множестве конфигураций SPS. Это может, например, быть реализовано в качестве сообщения RRC, такого как sps-ConfigSidelink в сообщении radioResourceConfigDedicated. Текущая конфигурация SPS для линии связи Uu передается в сообщении radioResourceConfigDedicated. Чтобы указывать конфигурации SPS для побочной линии связи, новый элемент может быть создан как sps-ConfigSidelink, который также может быть передан в сообщении radioResourceConfigDedicated. Как объяснено выше, множество конфигураций SPS, сконфигурированных посредством eNodeB на фазе подготовки, могут, например, идентифицировать как периодичность, так и ресурсы радиосвязи, или могут идентифицировать только периодичность (где ресурсы радиосвязи могут быть затем идентифицированы вместе с командой активации, передаваемой от eNodeB к UE).

Несмотря на то, что реализации первого варианта осуществления были объяснены на основе V2V и UE транспортных средств на связи с другими UE транспортного средства через соединение побочной линии связи, лежащие в основе принципы первого варианта осуществления также могут быть применены для передачи данных транспортных средств между UE транспортных средств и, например, eNodeB через интерфейс Uu или между UE транспортных средств и Блоком Стороны Дороги через, например, интерфейс PC5.

Кроме того, несмотря на то, что реализации первого варианта осуществления были объяснены на основе UE транспортных средств, лежащие в основе принципы первого варианта осуществления также могут быть выполнены посредством «нормальных» UE, которые находятся на связи с eNB или с другими «нормальными» UE или UE транспортных средств через соединение(ия) побочной линии связи.

Реализация в Аппаратном Обеспечении и Программном Обеспечении настоящего раскрытия

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

Дополнительно следует иметь в виду, что разнообразные варианты осуществления могут быть реализованы или выполнены используя вычислительные устройства (процессоры). Вычислительное устройство или процессор может, например, быть процессорами общего назначения, цифровыми сигнальными процессорами (DSP), проблемно-ориентированными интегральными микросхемами (ASIC), программируемыми вентильными матрицами (FPGA) или другими программируемыми логическими устройствами, и т.д. Разнообразные варианты осуществления также могут быть выполнены или воплощены посредством сочетания этих устройств. В частности, каждый функциональный блок, используемый в описании каждого варианта осуществления, описанного выше, может быть реализован посредством LSI в качестве интегральной микросхемы. Они могут быть индивидуально сформированы в качестве чипов, или один чип может быть сформирован так, чтобы включать в себя часть или все из функциональных блоков. Они могут включать в себя средства ввода и вывода данных, связанные с ними. LSI в данном документе может называться как IC, LSI системы, супер LSI, или ультра LSI в зависимости от отличия в степени интеграции. Тем не менее, методика реализации интегральной микросхемы не ограничивается LSI и может быть реализована посредством использования выделенной цепи или процессора общего назначения. В дополнение, может быть использована FPGA (Программируемая Вентильная Матрица), которая может быть запрограммирована после изготовления LSI, или реконфигурируемый процессор, в котором могут быть реконфигурированы соединения и установки ячеек цепей, расположенных внутри LSI.

Кроме того, разнообразные варианты осуществления также могут быть реализованы посредством модулей программного обеспечения, которые исполняются посредством процессора или непосредственно в аппаратном обеспечении. Также, возможно сочетание модулей программного обеспечения и реализации в аппаратном обеспечении. Модули программного обеспечения могут быть сохранены на любом виде машиночитаемых запоминающих носителей информации, например, RAM, EPROM, EEPROM, флэш-памяти, регистрах, жестких дисках, CD-ROM, DVD, и т.д. Дополнительно следует отметить, что индивидуальные признаки разных вариантов осуществления могут индивидуально или в произвольном сочетании быть предметом другого варианта осуществления.

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

Изобретение относится к области вычислительной техники. Технический результат заключается в повышении эффективности выделения ресурсов. Мобильный терминал транспортного средства содержит: передатчик, выполненный с возможностью передавать информацию о периодических данных в базовую станцию радиосвязи; приемник, выполненный с возможностью принимать от базовой станции радиосвязи множество конфигураций полупостоянных ресурсов радиосвязи; при этом передатчик дополнительно выполнен с возможностью указывать базовой станции радиосвязи, что один или более из компонентов данных будут передаваться мобильным терминалом транспортного средства. 2 н. и 13 з.п. ф-лы, 15 ил., 13 табл.

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

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

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

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

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

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

2. Мобильный терминал транспортного средства по п.1, при этом передаваемая информация о периодических данных содержит:

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

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

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

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

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

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

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

при этом в необязательном порядке дополнительная команда активации принимается в сообщении через Физический Канал Управления Нисходящей Линии Связи (PDCCH).

5. Мобильный терминал транспортного средства по п.1, при этом информация о периодических данных передается в одном сообщении, или

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

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

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

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

7. Мобильный терминал транспортного средства по п.1, при этом компоненты данных, которые должны быть переданы в один и тот же момент времени, передаются либо как одно сообщение, либо как отдельные сообщения.

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

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

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

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

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

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

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

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

при этом приемник дополнительно выполнен с возможностью принимать от мобильного терминала транспортного средства указание того, что один или более из компонентов данных должны быть переданы мобильным терминалом транспортного средства,

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

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

11. Базовая станция радиосвязи по п.10, при этом принятая информация о периодических данных содержит:

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

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

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

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

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

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

при этом в необязательном порядке дополнительная команда активации передается в сообщении через Физический Канал Управления Нисходящей Линии Связи (PDCCH).

14. Базовая станция радиосвязи по п.10, при этом каждое из сконфигурированного и переданного множества конфигураций полупостоянных ресурсов связи идентифицирует:

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

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

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

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