Способ и устройство для передачи сообщения по общему каналу управления для произвольного доступа в сети беспроводной связи

Способ и устройство для передачи сообщения по общему каналу управления для произвольного доступа в сети беспроводной связи

Иллюстрации

Показать все

Реферат

Заявление об установлении приоритета по 35 U.S.C. §119

Настоящая заявка притязает на приоритет предварительной заявки США № 61/015159, озаглавленной «METHOD AND APPARATUSES FOR TRANSFER OF FIRST SCHEDULED TRANSMISSION USING CONTROL CHANNEL» поданной 19 декабря 2007 года, правообладателем которой является заявитель настоящей заявки и которая включена в данную заявку посредством ссылки.

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

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

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

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

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

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

В этом документе описаны технологии отправки сообщения для произвольного доступа UE. В одном аспекте зарезервированный идентификатор канала может быть использован для указания, что сообщение отправляется по каналу управления для произвольного доступа. В одном конструктивном исполнении UE может отправлять сообщение по каналу управления для произвольного доступа и может также отправлять зарезервированный идентификатор канала для указания, что сообщение отправляется по каналу управления. Сообщение, отправляемое по каналу управления, может содержать сообщение управления радиоресурсами (RRC), отправляемое по общему каналу управления (CCCH), который может быть отображен на совместно используемый канал восходящей линии связи (UL-SCH). Зарезервированный идентификатор канала может содержать зарезервированный идентификатор логического канала (LCID).

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

В еще одном аспекте короткий код проверки подлинности сообщения для защиты целостности (MAC-I) может быть отправлен в сообщении для произвольного доступа. В одном конструктивном исполнении UE может генерировать короткий MAC-I для сообщения, отправленного по каналу управления для произвольного доступа. Короткий MAC-I может иметь меньший размер, чем полный MAC-I используемый для защиты целостности сообщений отправляемых по плоскости управления. Короткий MAC-I может быть отправлен для сообщения RRC по CCCH для повторного установления соединения RRC и может быть использован для проверки подлинности UE.

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

Различные аспекты и признаки настоящего изобретения описаны более подробно ниже.

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

На фиг.1 изображена сеть беспроводной связи.

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

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

На фиг.4 изображен поток сообщения для процедуры произвольного доступа в LTE.

На фиг.5 изображена обработка для генерирования Message 3 в процедуре произвольного доступа.

На фиг.6 изображен PDU управления доступа к среде (MAC) для Message 3.

На фиг.7A-7C изображены три MAC подзаголовка.

На фиг.8A-8D изображены четыре MAC PDU, переносящих сообщение для произвольного доступа.

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

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

На фиг.11 изображен процесс отправки сообщения с коротким MAC-I для произвольного доступа.

На фиг.12 изображен процесс отправки UE ID для произвольного доступа.

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

На фиг.14 изображена блок-схема eNB/базовой станции и UE.

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

Технологии, описанные в данном документе, могут быть использованы для различных сетей беспроводной связи, таких как CDMA, TDMA, FDMA, OFDMA, SC-FDMA и других сетей. Термины «система» и «сеть» часто используются взаимозаменяемо. Сеть CDMA может реализовывать технологии радиосвязи, такие как Универсальный Наземный Радиодоступ (UTRA), cdma2000 и т.д. UTRA включает в себя широкополосный CDMA (WCDMA) и другие варианты CDMA. Cdma2000 охватывает стандарты IS-2000, IS-95 и IS-856. Сеть TDMA может реализовывать технологии радиосвязи, такие как Глобальная Система Мобильной Связи (GSM). Сеть OFDMA может реализовывать технологии радиосвязи, такие как Усовершенствованный Универсальный Наземный Радиодоступ (E-UTRA), Сверхподвижная широкополосная передача (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM® и т.д. E-UTRA использует OFDMA в нисходящей линии связи и SC-FDMA в восходящей линии связи. 3GPP долгосрочного развития (LTE) использует радиоинтерфейс, определенный E-UTRA, и сетевую архитектуру, определенную E-UTRAN. UTRA, E-UTRA, E-UTRAN, LTE и GSM описаны в документах организации, названной «Проект партнерства третьего поколения» (3GPP). Cdma2000 и UMB описаны в документах организации, названной «Проект партнерства третьего поколения 2» (3GPP2). Для ясности, конкретные аспекты методик описаны ниже для LTE, и LTE терминологии используется в большей части описания ниже.

На фиг.1 изображена сеть 100 беспроводной связи, которая может быть сетью LTE. Сеть 100 может включать в себя усовершенствованные узлы В (eNB) и другие сетевые объекты, описанные 3GPP. eNB может быть стационарной станцией, которая связывается с UE и может быть также обозначена как Узел В, базовая станция, точка доступа и т.д. Каждый eNB может предоставлять покрытие связи для определенной географической зоны. Для улучшения пропускной способности сети полная зона покрытия eNB может быть разделена на множество (например, три) меньших зон. Каждая меньшая зона может быть обслужена соответствующей подсистемой eNB. В 3GPP, термин «сота» может обозначать самую маленькую зону покрытия eNB и/или подсистему eNB, обслуживающую эту зону покрытия.

Элемент управления мобильностью (MME)/обслуживающий шлюз (S-GW) 130 может соединяться с множеством eNB и предоставлять координацию и управление этими eNB. Обслуживающий шлюз 130 может поддерживать информационные службы, такие как передача голоса по IP-протоколу (VoIP), видео, передача сообщений и т.д. MME 130 может быть ответственен за коммутацию путей между исходным eNB и целевым eNB при передачи обслуживания. MME/обслуживающий шлюз 130 может соединяться с базовой сетью и/или сетью передачи данных (например, Интернет) и может связываться с другими объектами (например, удаленными серверами и терминалами) которые соединены с базовой сетью и/или сетью передачи данных.

UE 120 могут быть распределены по сети, и каждое UE может быть стационарным или мобильным. UE может быть также обозначено как мобильная станция, терминал, терминал доступа, блок абонента, станция и т.д. UE может быть сотовым телефоном, персональным цифровым секретарем (PDA), беспроводным модемом, устройством беспроводной связи, портативным устройством, портативным персональным компьютером, радиотелефоном, станцией местной линии радиосвязи (WLL) и т.д. UE может связываться с eNB посредством нисходящей линии связи и восходящей линии связи. Нисходящая линия связи (или прямая линия связи) обозначает линию связи от eNB к UE, и восходящая линия связи (или обратная линия связи) обозначает линию связи от UE к eNB. На фиг.1 сплошная линия с двумя стрелками указывает активную связь между eNB и UE. Пунктирная линия с двумя стрелками указывает UE осуществляющий произвольный доступ.

На Фиг.2 изображен стек 200 протоколов для плоскости управления в LTE. Плоскость управления переносит сигнализацию между UE 120 и MME 130 посредством eNB 110. UE 120 может связываться с MME 130 посредством протокола управления без осуществления доступа (NAS). NAS может осуществлять различные функции, такие как расширенная пакетная система (EPS) управления радиоканалом, аутентификацию, поддержку мобильности, начало поисковой связи, контроль безопасности и т.д. UE 120 может обмениваться сообщениями сигнализации с eNB 110 посредством управления радиоресурсами (RRC). RRC может осуществлять функции, такие как управление соединением RRC, контроль и отчет измерений UE, контроль радиоканала (RB), функции мобильности, широковещание, поисковая связь и т.д.

Сообщения RRC могут быть обменены между UE 120 и eNB 110 посредством протокола конвергенции пакетных данных (PDCP), управления радиоканалом (RLC) и управления доступом к среде (MAC) которые являются подуровнями Уровня 2 (L2). Каждый протокол принимает блоки служебных данных (SDU) от высших подуровней/уровней и предоставляет блоки служебных данных (PDU) на низшие подуровни/уровни. PDCP могут осуществлять различные функции, такие как шифрование (то есть, зашифровывание) и защиту целостности для плоскости управления, шифрование и уплотнение заголовков для плоскости пользователя и т.д. RLC может осуществлять различные функции, такие как (i) сегментация и конкатенация RLC SDU и исправление ошибок через автоматический запрос на повторение (ARQ) на передающий объект и (ii) дублировать определение SDU нижнего уровня, переупорядочивание RLC SDU и упорядоченную доставку PDU верхнего уровня на принимающий объект. MAC может осуществлять различные функции, такие как отображение между логическими каналами и транспортными каналами, мультиплексирование и демультиплексирование RLC PDU для логических каналов в/от транспортные модули для транспортных каналов, отчет об измерении объема трафика, исправление ошибок через гибридный ARQ (HARQ), распределение приоритета между логическими каналами UE, распределение приоритета между UE посредством динамического планирования, выбор формата транспортировки, заполнение и т.д. Функции, осуществляемые RRC, PDCP, RLC и MAC в LTE могут быть предоставлены эквивалентными протоколами в других технологиях радиосвязи. UE 120 дополнительно связывается с eNB 110 посредством интерфейса радиосвязи E-UTRA на физическом уровне (PHY).

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

Таблица 1 дает перечень некоторых логических и транспортных каналов в LTE. LTE поддерживает другие логические и транспортные каналы, которые не изображены в таблице 1 для простоты.

Таблица 1Логические и транспортные каналы в LTE
Тип	Канал	Название канала	Описание
Логический	CCCH	Общий канал управления	Переносит данные управления к/от UE, не известному сети
Логический	DCCH	Выделенный канал управления	Переносит данные управления к/от UE, известному сети
Логический	DTCH	Выделенный канал трафика	Переносит пользовательские данные к/от UE
Транспортный	RACH	Канал произвольного доступа	Переносит преамбулу произвольного доступа по восходящей линии связи от UE
Транспортный	UL-SCH	Совместно используемый канал восходящей линии связи	Переносит пользовательские данные и данные управления по восходящей линии связи от UE
Транспортный	DL-SCH	Совместно используемый канал нисходящей линии связи	Переносит пользовательские данные и данные управления по восходящей линии связи к UE

На Фиг.3 изображено отображение логических каналов на транспортные каналы для восходящей линии связи в LTE. На восходящей линии связи CCCH, DCCH и DTCH могут быть отображены на UL-SCH. UE может использовать CCCH, когда сеть не знает принадлежность UE, и может использовать DCCH, когда сеть знает принадлежность UE. На нисходящей линии связи CCCH может быть отображен на DL-SCH (не изображено на фиг.3)

UE может осуществлять процедуру произвольного доступа для того, чтобы получить доступ к сети и/или для других целей. Термины «произвольный доступ», «доступ в систему» и «доступ» могут быть использованы взаимозаменяемо. Например, UE может осуществлять процедуру произвольного доступа по следующим сценариям произвольного доступа:

- повторное установление соединения RRC,

- подсоединение к сети, например, на основе международного идентификатора подвижного абонента (IMSI), или

- последующий доступ к сети для перехода от режима ожидания к активному режиму, например, на основе ESP временного идентификатора подвижного абонента (S-TMSI).

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

На Фиг.4 изображен поток 400 сообщения для процедуры произвольного доступа в LTE. UE может передавать преамбулу произвольного доступа (RA) по RACH всякий раз, когда UE желает получить доступ к сети и ресурсам, являющимся доступными (этап 1). Преамбула RA может быть также обозначена как Сообщение 1. Преамбула RA может быть опознана идентификатором преамбулы (ID) RA, используемым как временный ID для UE во время процедуры произвольного доступа. eNB может принимать преамбулу RA от UE и возможно преамбулы RA от других UE. ГУ может отправлять ответ произвольного доступа по DL-SCH для ответа на одну или несколько преамбул RA (этап 2). Ответ произвольного доступа может быть также обозначен как Message 2 и может включать в себя различные типы информации, такие как ID преамбулы RA, информацию настройки тайминга, начальное предоставление восходящей линии связи, назначение временного UE ID и т.д.

UE может принимать ответ произвольного доступа от eNB и может отправлять первую запланированную передачу по UL-SCH. Первая запланированная передача может также быть обозначена как Message 3 и может включать в себя разную информацию для разных типов произвольного доступа, как будет описано ниже. Размер первой запланированной передачи может зависеть от предоставления восходящей линии связи переносимого в Message 2. eNB может принимать первую запланированную передачу и может отправлять сообщение по DL-SCH для разрешения конфликтов, если это необходимо (этап 4). Конфликт может возникнуть когда множественные UE отправляют одну и ту же преамбулу RA по RACH. Разрешение конфликтов может быть осуществлено для решения того, какому UE предоставить доступ.

Процедура произвольного доступа для LTE описана в 3GPP TS 36.213, TS 36.300, TS 36.321 и TS 36.331, которые находятся в открытом доступе.

Первая запланированная передача на этапе 3 обозначена как Message 3 в большей части описания ниже. Таблица 2 дает перечень разных типов информации, которая может быть отправлена в Message 3 для разных сценариев/типов произвольного доступа, в соответствии с одним конструктивным исполнением. IMSI является идентификацией (ID) UE, которая является в целом уникальной. S-TMSI является UE ID, который является уникальным в сети. Временный идентификатор сотовой радиосети (C-RNTI) является UE ID, который является уникальным в соте. Разные типы UE ID могут быть применимы для разных зон и могут иметь разные длины. MAC-I является кодом аутентификации сообщения для защиты целостности и может быть использован для аутентификации отправителя сообщения. Таблица 2 также изображает количество битов для каждого типа информации в соответствии с одним конструктивным исполнением. Другие типы информации могут также быть отправлены для каждого типа произвольного доступа.

Таблица 2Начальное число бит для Message 3
	Тип произвольного доступа
Уровень	Повторное установление соединения RRC	Присоединение	Последующий доступ
RRC	- старый ID соты: 9 бит,- старый C-RNTI: 16 бит,- MAC-I: 32 бита,- информация о частоте: 14 бит	- Начальный идентификатор UE (IMSI): 84 бита,- Причина установления: 3 бита	- начальный идентификатор UE (S-TMSI): 40 бит,- причина установления: 3 бита
PDCP	PDCP без MAC-I: 8 бит
RLC	RLC-TM: 0 бит
MAC	заголовок MAC: 16 бит
PHY	Физический уровень CRC: 24 бита
RRC биты	71	87	43
Другие биты	48	48	48
Всего битов	119	135	91

UE может быть выделено предоставление восходящей линии связи для отправки Message 3. В одном конструктивном исполнении предоставление восходящей линии связи может быть по меньшей мере 80 бит и может быть дан кратным 8 битам, например, 80 бит, 88 бит, 96 бит и т.д. Минимальное предоставление восходящей линии связи в 80 бит может быть выбрано на основе различных факторов, таких как количество информации для отправки в Message 3, желаемая производительность на границе соты и т.д. Меньшее число битов (например, 72 бита) или большее число битов может также поддерживаться для минимального предоставления восходящей линии связи.

Как изображено в таблице 2, общее число битов для Message 3 для каждого типа произвольного доступа превышает минимальное предоставление восходящей линии связи в 80 бит. Может быть желаемо уменьшить общее число битов для Message 3 так, чтобы Message 3 можно было отправить с минимальным предоставлением восходящей линии связи. Также может быть желаемо определить единый формат для PDCP, RLC и MAC для Message 3. Общее число битов для Message 3 может быть уменьшено способом, описанным ниже.

Для RRC, одно из ограниченного числа размеров сообщения RRC может быть поддержано для сообщения RRC, отправленного по CCCH для Message 3. В одном конструктивном исполнении могут поддерживаться размеры сообщения RRC в 48 бит и 96 бит. 48-битовое сообщение RRC или 96-битовое сообщение RRC может быть отправлено в Message 3 в зависимости от размера предоставления восходящей линии связи.

Для повторного установления соединения RRC Message 3 может содержать сообщение запрос на повторное установление соединения RRC или другое сообщение RRC. В одном конструктивном исполнении число битов для сообщения RRC для повторного установления Соединения RRC может быть уменьшено исключением 32-битового MAC-I так же, как и информация о частоте. MAC-I может быть использован для проверки UE, отправляющего сообщение RRC, и может действовать как триггер для коммутации пути данных S1 для UE на сетевой стороне. Исключение MAC-I из сообщения запрос на повторное установление соединения RRC может задержать коммутацию пути до отправки сообщения, завершение реконфигурации соединения RRC (целостность которого может быть защищена) посредством UE в процедуре повторного установления соединения RRC. В другом конструктивном исполнении короткий MAC-I меньшего размера может быть сгенерирован на основе 16 наиболее значащих битов (MSB) полного MAC-I и может быть отправлен в сообщении RRC. В еще одном конструктивном исполнении короткий MAC-I может иметь переменный размер, который может зависеть от размера предоставления восходящей линии связи. Для всех конструктивных исполнений 48-битовое сообщение RRC может быть отправлено для повторного установления Соединения RRC и может быть заполнено значительным числом заполняющих битов, если это требуется.

Для присоединения Message 3 может содержать сообщение запрос на соединение RRC или другое сообщение RRC. В одном конструктивном исполнении размер начального UE ID (например, IMSI) может быть уменьшен, если требуется, так что сообщение RRC подойдет под один из поддерживаемых размеров сообщения RRC. IMSI может быть составлено из 3-значного кода страны в мобильной сети (MCC), 2-значного или 3-значного кода сети мобильной связи (MNC) и идентификационного номера мобильной станции (MSIN), который является уникальным в сети. IMSI может иметь длину 6-21 десятичный знак, и 15 знаков может быть обычной длиной IMSI в LTE.

В одном конструктивном исполнении IMSI может переноситься с использованием двоичного представления (вместо шестнадцатеричного представления) для того, чтобы увеличить количество IMSI информации, которая может быть отправлена в сообщении RRC данного размера. Каждый десятичный знак IMSI может быть перенесен с одним 4-битовым шестнадцатеричным (например, как в UTRAN). 21-значный IMSI может быть перенесен с 84 битами с использованием шестнадцатеричного представления или 70 битами с использованием двоичного представления.

В одном конструктивном исполнении предварительно определенное число наименее значащих битов (LSB) IMSI может быть отправлено в поле фиксированного размера сообщения RRC. Например, частичный UE ID может быть сформирован с 44 LSB IMSI и может быть отправлен в 48-битовом сообщении RRC. Хотя IMSI является в целом уникальным для каждого UE, использование части IMSI представляет (очень маленькую) вероятность конфликта из-за того, что множественные UE имеют в целом уникальные IMSI, но потенциально один и тот же частичный IMSI. Так как MCC и MNC обычно являются одинаковыми для данной сети, использование LSB IMSI может уменьшить вероятность конфликта. Может быть возможно обнаружить и разрешить конфликт частичных IMSI на уровне радиосвязи. Вместо этого, ошибка процедуры верхнего уровня (например, проблема аутентификации) может быть использована для обнаружения и разрешения конфликта частичных IMSI.

Частичный IMSI может быть составлен из части IMSI и может быть перенесен с использованием двоичного представления. Например, 13 наименее значащих знаков IMSI могут быть перенесены с 44 битами с использованием двоичного представления против 52 битов с использованием шестнадцатеричного представления. 44-битовый частичный IMSI может быть отправлен в 48-битовом сообщении RRC. Если IMSI короче 13 знаков, тогда сообщение RRC может быть заполнено нулями. Сообщение RRC может включать в себя 1-битовое поле формата, которое может быть установлено на «0» для указания 43-битового частичного IMSI или на «1» для указания полного IMSI.

В другом конструктивном исполнении различное количество UE ID информации может быть отправлено в сообщении RRC в зависимости от размера предоставления восходящей линии связи. UE может быть выделено минимальное предоставление восходящей линии связи в редких плохих ситуациях и может отправлять минимальное число битов для IMSI. UE может быть выделено более чем минимальное предоставление восходящей линии связи в большинстве ситуаций, и может быть возможно отправлять больше битов IMSI в сообщении RRC, когда позволено большее предоставление восходящей линии связи. В одном конструктивном исполнении 1-битовое поле формата сообщения RRC может быть установлено на «1» для указания переменного размера сообщения RRC или на «0» для указания предварительно определенного размера сообщения RRC. Переменный размер сообщения RRC может включать в себя поле длины IMSI и поле IMSI. Поле длины IMSI может указывать длину поля IMSI, которое может переносить частичный или полный IMSI. MAC может принимать предоставление восходящей линии связи для UE и может переносить предоставление восходящей линии связи к RRC. RRC может затем включать в себя так много знаков или битов IMSI, сколько возможно в сообщении RRC.

Таблица 3 дает перечень разных типов информации, которая может быть отправлена по CCCH для Message 3 для разных типов произвольного доступа, в соответствии с одним конструктивным исполнением. Таблица 3 подразумевает минимальное предоставление восходящей линии связи в 80 бит. Информация для RRC может быть уменьшена, как описано выше. Для повторного установления соединения RRC сообщение запрос на повторное установление соединения RRC может включать в себя старый ID соты (9 бит), старый C-RNTI (16 бит), короткий MAC-I, и заполняющие и/или зарезервированные биты для минимального предоставления восходящей линии связи. Сообщение RRC может включать в себя 16-битовый MAC-I и 7 заполняющих битов (как изображено в таблице 3), или 23-битовый MAC-I без заполняющих битов, или некоторую другую комбинацию битов MAC-I и заполняющих битов. Сообщение RRC может также включать в себя больший MAC-I (например, 32-битовый полный MAC-I обычно генерируется PDCP для сообщений на плоскости управления) для большего предоставления восходящей линии связи. Короткий MAC-I может иметь переменный размер, определенный на основе предоставления восходящей линии связи UE. Для подсоединения сообщение запрос на установление соединения RRC может включать в себя (i) частичный 44-битовый IMSI, когда поле формата установлено на «0» или (ii) IMSI переменной длины (например, кратной 8 битам, и максимум до 96 битов) когда поле формата установлено на «1». Информация для PDCP и MAC может быть уменьшена, как описано ниже.

Таблица 3Пересчитанное число бит для запланированнойпередачи (Message 3)
	Тип произвольного доступа
Уровень	Повторное установление соединения RRC	Присоединение	Последующий доступ
RRC	- старый ID соты: 9 бит,- старый C-RNTI: 16 бит,- MAC-I: 16 бит,- заполнение: 7 бит	- формат: 1 бит,- начальный идентификатор UE (IMSI): 44 бита (когда бит формата установлен на «0»),- причина установления: 3 бита	- формат: 1 бит,- начальный идентификатор UE (S-TMSI): 40 бит,- причина установления: 3 бита,- заполнение: 4 бита
PDCP	прозрачная операция PDCP: 0 бит
RLC	RLC-TM: 0 бит
MAC	заголовок MAC: 8 бит
PHY	Физический уровень CRC: 24 бита
RRC биты	48	48	48
Другие биты	24	24	24
Всего битов	80	80	80

В другом конструктивном исполнении, не изображенном в таблице 3, произвольный ID может быть отправлен вместо частичного IMSI для подсоединения. Произвольный ID может быть псевдопроизвольным значением, выбранным UE, значение хеш-функции сгенерированной хешированием ISMI или некоторым другим UE ID, или значением, полученным другим образом. Произвольный ID может иметь фиксированный размер (например, 40 бит для совпадения с размером S-TMSI) или переменный размер (например, в зависимости от предоставления восходящей линии связи).

В другом конструктивном исполнении поле Формат может указывать один или множество типов UE ID, отправленных в сообщении RRC. Например, поле Формат может быть установлено (i) на «0» для указания, что S-TMSI был отправлен в сообщении RRC для последующего доступа или (ii) на «1» для указания того, что частичный IMSI или произвольный ID был отправлен в сообщении RCC для присоединения.

На Фиг.5 изображена обработка для генерирования Message 3 в LTE. Message 3 может включать в себя всю информацию для RRC, изображенную в таблице 3. В одном конструктивном исполнении Message 3 может иметь фиксированную длину (например, 80 битов) для всех типов произвольного доступа. В другом конструктивном исполнении Message 3 может иметь разные длины для разных типов произвольного доступа, разных размеров предоставления восходящей линии связи и т.д.

В одном конструктивном исполнении прозрачный режим операции может быть определен для PDCP для поддержки передачи сообщения RRC по CCCH для произвольного доступа. В прозрачном режиме PDCP не может осуществлять защиту целостности и шифрование для CCCH, переносящего сообщение RRC, и заголовок PDCP может быть исключен в передаче CCCH. PDCP может быть проинформирован для работы в прозрачном режиме и может затем не осуществлять операции для CCCH. PDCP может принимать сообщение RRC как PDCP SDU и может предоставлять это сообщение RRC как PDCP PDU. В качестве альтернативы, RRC может пропускать сообщение RRC напрямую к RLC, и PDCP может быть вообще обойден для передачи сообщения RRC по CCCH. В любом случае исключение заголовка PDCP может охранить 8 бит и может позволить уменьшить размер Message 3 до 80 бит, как изображено в таблице 3.

RLC может работать в прозрачном режиме (TM) для СССН. В этом случае RLC может принимать PDCP PDU как RLC SDU и может просто передавать PDCP SDU как RLC PDU.

MAC может принимать RLC PDU как MAC SDU и может так же принимать указание MAC SDU, содержащее сообщение RRC, отправленное по CCCH. MAC может генерировать MAC PDU, содержащий заголовок MAC и полезную нагрузку MAC. Заголовок MAC может иметь формат, описанный ниже. Полезная нагрузка MAC может включать в себя (i) MAC SDU, переносящий сообщение RRC, и (ii), возможно, другую информацию и/или заполнение. Физический уровень может генерировать 24-битовую циклическую проверку по избыточности (CRC) для MAC PDU, присоединять CRC в конец MAC PDU и предоставлять PHY PDU. PHY PDU может быть отправлен как Message 3.

На Фиг.6 изображен проект MAC PDU 600, который может быть использован для Message 3. MAC PDU 600 включает в себя заголовок 610 MAC и полезную нагрузку 620 MAC. Заголовок 610 MAC включает в себя N подзаголовков от 612а до 612n MAC, где N может быть целым значением, равным одному или больше. Каждый подзаголовок 612 MAC может иметь формат, описанный ниже. Заголовок 610 MAC может также включать в себя заполняющие подзаголовки 614, если полезная нагрузка 620 MAC включает в себя поле 624 заполнения. Полезная нагрузка 620 MAC включает в себя N блоков от 622а до 622n полезной нагрузки MAC. Каждый блок 622 полезной нагрузки MAC может быть элементом управления (СЕ) MAC или MAC SDU. n-й подзаголовок 612 MAC связан с n-м блоком 622 полезной нагрузки MAC, где 1≤n≤N.

На фиг.7A изображен 8-битовый подзаголовок 710 MAC, который может быть использован для MAC SDU для Message 3. В этом конструктивном исполнении подзаголовок 710 MAC включает в себя подзаголовки R/R/E/LCID, составленные из двух 1-битовых зарезервированных (R) полей, 1-битового поля расширения (E) и 5-битового поля ID логического канала (LCID). Зарезервированные поля зарезервированы для будущего использования. Поле расширения указывает то, будет ли другой подзаголовок MAC следовать в заголовке MAC. Поле LCID переносит LCID логического канала, имеющего данные, отправленные в соответствующем MAC SDU. Данные для одного или нескольких логических каналов могут быть отправлены в потоке MAC SDU. Каждый логический канал может быть присвоен разным LCID. MAC PDU может переносить (i) LCID логического канала в поле LCID подзаголовка MAC и (ii) данные логического канала в MAC SDU.

В одном конструктивном исполнении конкретный LCID может быть зарезервирован и использован для указания того, что MAC SDU переносит сообщение RRC, отправленное по CCCH для Message 3. В одном конструктивном исполнении зарезервированный LCID имеет значение «00000» (двоичное). Другие значения могут быть также использованы для зарезервированного LCID. UE может отправлять сообщение RRC по CCCH для любого из типов произвольного доступа, изображенных в таблице 2 или по DCCH для доступа к передаче обслуживания. Зарезервированный LCID может позволить MAC на UE обрабатывать CCCH для Message 3 тем же образом, что и другие логические каналы отображенные на UL-SCH, что может упростить обработку на UE. Зарезервированный LCID может также позволить eNB определять различия между данными для CCCH и данными для других логических каналов.

Подзаголовки 710 MAC не включают в себя поле длины. Подзаголовки 710 MAC могут быть использованы для MAC SDU фиксированной длины и также для последнего подзаголовка MAC в заголовке MAC, например, для подзаголовка 612n MAC по фиг.6, с заполняющим подзаголовком 614, который не представлен.

На фиг.7В изображен 16-битовый подзаголовок 720 MAC, который может быть использован для MAC SDU. Подзаголовок 720 MAC включает в себя подзаголовки R/R/E/LCID/F/L, составленные из двух 1-битовых зарезервированных полей, 1-битового поля расширения, 5-битового поля ID логического канала, 1-битового поля формата (F) и 7-битового поля длины (L). Поле формата установлено на «0» когда используется 7-битовое поле длины. Поле длины указывает длину MAC SDU в блоках по восемь.

На Фиг.7С изображен 24-битовый подзаголовок 730 MAC, который также может быть использован для MAC SDU. Подзаголовок 730 MAC включает в себя подзаголовки R/R/E/LCID/F/L, составленные из двух 1-битовых зарезервированных полей, 1-битового поля расширения, 5-битового поля ID логического канала, 1-битового поля формата и 15-битового поля длины. Поле формата установлено на «1», когда используется 15-битовое поле длины. Подзаголовок 730 MAC может быть использован для больших MAC SDU с более чем 127 восьмерками.

В конструктивном исполнении, изображенном на фиг.7A, поле длины может быть исключено из подзаголовка 710 MAC. Заполнение на передающем объекте и удаление заполнения на принимающем объекте могут быть осуществлены различными способами вне поля длины. В одном конструктивном исполнении MAC и/или RRC на передающем объекте могут добавлять заполняющие биты без какого-либо указания в подзаголовке MAC. Удаление заполнения может быть осуществлено в MAC и/или RRC на принимающем объекте. Предоставление восходящей линии связи, отправленное в Message 2, может быть определено MAC и может иметь переменный размер. В этом случае заполнение может быть частью операции планирования в MAC на передающем объекте. На принимающем объекте MAC может просто пропускать MAC SDU для CCCH по RRC, и RRC может считывать только элементы информации в MAC SDU и игнорировать заполнение.

В другом конструктивном исполнении заголовок 610 MAC на фиг.6 может включать в себя флаг, который может указывать, переносит ли или нет полезная нагрузка 620 MAC CCCH. Флаг может быть представлен в заголовке MAC для всех MAC PDU и может затем представлять непроизводительные потери для всех данных, включая пользовательские данные.

В одном конструктивном исполнении 8-битовый подзаголовок 710 MAC может быть использован для MAC SDU, переносящего сообщение RRC, отправленное по CCCH, например, всякий раз, когда возможно, для того, чтобы уменьшить непроизводительные потери. В одном конструктивном исполнении 16-битовый подзаголовок 720 MAC может быть использован для MAC SDU, переносящего сообщение RRC, отправленное по CCCH, когда это требуется (например, из-за присутствия заполнения) или если присвоено (например, для заполнения полезной нагрузки MAC). Заполнение может быть осуществлено MAC с существующим подзаголовком MAC для заполнения, который может быть также обозначен как заполняющий подзаголовок.

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