СПОСОБ И УСТРОЙСТВО ДЛЯ УЛУЧШЕНИЯ ПОИСКОВЫХ ВЫЗОВОВ Российский патент 2014 года по МПК H04W68/00 

По настоящей заявке испрашивается приоритет по заявке на патент США серийный номер 60/795675, озаглавленной "Method and Apparatus for Enhanced Paging", зарегистрированной 28 апреля 2006 года, и заявке на патент США серийный номер 60/863217, озаглавленной "Composed Message Authentication Code", зарегистрированной 27 октября 2006 года, переуступленных правопреемнику настоящей заявки и содержащихся в данном документе по ссылке.

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

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

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

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

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

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

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

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

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

Далее более подробно описаны различные аспекты и признаки изобретения.

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

Фиг.1 иллюстрирует систему беспроводной связи.

Фиг.2 иллюстрирует структуру формата кадра.

Фиг.3 иллюстрирует временную шкалу для UE в режиме работы DRX.

Фиг.4 иллюстрирует структуру логических, транспортных и физических каналов нисходящей линии связи.

Фиг.5 иллюстрирует структуру логических, транспортных и физических каналов восходящей линии связи.

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

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

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

Фиг.9 иллюстрирует структуру для восстановления неявного индикатора поискового вызова.

Фиг.10 иллюстрирует процесс, выполняемый сотой для того, чтобы опросить поисковым вызовом UE.

Фиг.11 иллюстрирует устройство для поискового вызова UE.

Фиг.12 иллюстрирует процесс, выполняемый UE для того, чтобы принять поисковый вызов.

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

Фиг.14 иллюстрирует другой процесс, выполняемый сотой для того, чтобы опросить поисковым вызовом UE.

Фиг.15 иллюстрирует другое устройство для поискового вызова UE.

Фиг.16 иллюстрирует процесс, выполняемый сетевым объектом для поискового вызова.

Фиг.17 иллюстрирует устройство для поискового вызова.

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

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

Фиг.20 иллюстрирует блок-схему UE, узла B и системного контроллера.

Подробное описание изобретения

Методики поискового вызова, описанные в данном документе, могут быть использованы для различных систем связи, таких как системы множественного доступа с кодовым разделением каналов (CDMA), системы множественного доступа с частотным разделением каналов (FDMA), системы множественного доступа с временным разделением каналов (TDMA), системы с ортогональным FDMA (OFDMA), системы с FDMA на одной несущей (SC-FDMA) и т.д. Термины "системы" и "сети" зачастую используются взаимозаменяемо. CDMA-система может использовать такую технологию радиосвязи, как широкополосная CDMA (W-CDMA), cdma2000 и т.д. Cdma2000 покрывает стандарты IS-95, IS-2000 и IS-856. TDMA-система может использовать такую технологию радиосвязи, как глобальная система мобильной связи (GSM). Эти различные технологии, стандарты и системы радиосвязи известны в данной области техники. OFDMA-система использует мультиплексирование с ортогональным частотным разделением каналов (OFDM) и отправляет символы модуляции в частотной области по ортогональным поднесущим. SC-FDMA-система использует мультиплексирование с частотным разделением каналов на одной несущей (SC-FDM) и отправляет символы модуляции во временной области по ортогональным поднесущим. Для простоты методики поискового вызова описываются ниже для системы беспроводной связи, которая использует Долгосрочное развитие (LTE), которая является разрабатываемой технологией радиосвязи. Тем не менее, методики поискового вызова также могут быть использованы для различных других систем беспроводной связи.

Фиг.1 иллюстрирует систему 100 беспроводной связи с несколькими узлами B 110. Узел B - это, в общем, стационарная станция, которая обменивается данными с UE, и он также может упоминаться как базовая станция, усовершенствованный узел B (eNode B), точка доступа и т.д. Каждый узел B 110 предоставляет покрытие связи для конкретной географической области. Термин "сота" может относиться к узлу B и/или его зоне покрытия, в зависимости от контекста, в котором используется термин. Чтобы повысить пропускную способность системы, зона покрытия узла B может быть секционирована на несколько (к примеру, три) меньших зон. Каждая меньшая зона может обслуживаться соответствующей базовой приемо-передающей подсистемой (BTS). Термин "сектор" может относиться к BTS и/или ее зоне покрытия, в зависимости от контекста, в котором используется термин. Для разбитой на секторы соты, BTS для всех секторов этой соты типично совместно расположены в пределах узла B соты.

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

Системный контроллер 130 может подключаться к узлам B 110 и предоставлять координацию и управление для этих узлов B. Системный контроллер 130 может быть одним сетевым объектом или набором сетевых объектов. Системный контроллер 130 также может упоминаться как контроллер радиосети (RNC), центр коммутации мобильной связи (MSC) и т.д.

Фиг.2 иллюстрирует формат 200 кадра для системы 100. Временная шкала передачи может быть разделена на радиокадры. Каждый радиокадр может быть идентифицирован посредством системного номера кадра (SFN) и может иметь предварительно определенную продолжительность, к примеру 10 миллисекунд (мс). Каждый радиокадр может быть сегментирован на несколько (N) субкадров, к примеру N=20 или какое-либо другое значение. В общем, радиокадры и субкадры могут иметь любую продолжительность и также могут упоминаться каким-либо другим термином, к примеру кадры, временные интервалы и т.д.

Фиг.3 иллюстрирует временную шкалу 300 для UE в режиме работы с дискретным приемом (DRX). DRX-режим также может упоминаться как поисковый вызов в режиме с выделением временных интервалов. В DRX-режиме UE назначаются периоды поискового вызова, которые являются периодами времени, в которые UE может принимать поисковые вызовы. Каждый период поискового вызова может соответствовать конкретному радиокадру, конкретному субкадру конкретного радиокадра и т.д. Периоды поискового вызова также могут упоминаться как промежутки времени поискового вызова, кадры поискового вызова, субкадры поискового вызова и т.д. Периоды поискового вызова для UE могут быть разделены временным интервалом, упоминаемым как DRX-цикл. DRX-цикл может быть конфигурируемым для UE. Периоды поискового вызова для UE могут определяться на основе таких параметров, как, к примеру, конкретный для UE идентификатор (UE ID) для UE.

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

Система 100 может использовать логические каналы, транспортные каналы и физические каналы, чтобы поддерживать различные услуги. Уровень управления доступом к среде (MAC) может предоставлять услуги передачи данных по логическим каналам. Различные типы логических каналов могут задавать для различных типов услуг передачи данных, и каждый тип логического канала может переносить различный тип информации. MAC-уровень может преобразовывать логические каналы в транспортные каналы и может обрабатывать (к примеру, кодировать и модулировать) данные логического канала, чтобы формировать модули данных протокола (PDU) MAC. Физический уровень (PHY) может преобразовывать транспортные каналы в физические каналы и может обрабатывать (к примеру, канализировать и скремблировать) MAC PDU, чтобы формировать выходные данные для физических каналов.

Фиг.4 иллюстрирует структуру логического, транспортного и физического каналов нисходящей линии связи (DL). В этой структуре логические каналы нисходящей линии связи включают в себя:

- канал управления широковещанием (BCCH) - переносит системную управляющую информацию,

- выделенный канал трафика (DTCH) - переносит пользовательскую информацию для конкретного UE,

- выделенный канал управления (DCCH) - переносит управляющую информацию для конкретного UE,

- канал трафика MBMS (MTCH) - переносит данные трафика для нескольких UE, и

- канал управления MBMS (MCCH) - переносит информацию диспетчеризации и управления для MTCH, где MBMS означает услуги мультимедийного широковещания/мультивещания.

Транспортные каналы нисходящей линии связи включают в себя:

- широковещательный канал (BCH) - переносит часть BCCH, и

- совместно используемый канал DL (DL-SDCH) - переносит DCCH, DTCH, MCCH, MTCH и часть BCCH.

Различные транспортные каналы для трафика и управления MBMS могут существовать в канале MBMS (MCH).

Физические каналы нисходящей линии связи включают в себя:

- общий канал управления (CCCH) - переносит параметры системы и сот, чтобы демодулировать другие физические каналы и переносить BCH,

- канал подтверждения приема (ACKCH) - переносит подтверждение приема (ACK)/отрицание приема (NAK) для UL-SDCH,

- физический совместно используемый канал данных DL (DL-PSDCH) - переносит DL-SDCH,

- совместно используемый канал управления DL (SDCCH) - переносит управляющую информацию для DL-PSDCH, и

- совместно используемый канал назначения UL (SUACH) - переносит назначения ресурсов UL PHY.

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

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

Фиг.5 иллюстрирует структуру логических, транспортных и физических каналов восходящей линии связи (UL). В этой структуре логические каналы восходящей линии связи включают в себя DCCH и DTCH.

Транспортные каналы восходящей линии связи включают в себя:

- канал произвольного доступа (RACH) - переносит запросы на доступ и, возможно, другую информацию, и

- совместно используемый канал данных UL (UL-SDCH) - переносит DCCH и DTCH.

В зависимости от информации, переносимой посредством RACH, RACH может рассматриваться только как физический канал.

Физические каналы восходящей линии связи включают в себя:

- физический канал произвольного доступа (PRACH) - переносит RACH,

- физический совместно используемый канал данных UL (UL-PSDCH) - переносит UL-SDCH,

- канал подтверждения приема (ACKCH) - переносит ACK/NAK для DL-SDCH, и

- канал индикатора качества канала (CQICH) - переносит CQI для качества сигнала DL.

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

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

UE может регистрироваться в системе и может "закрепляться" в обслуживающей соте, когда не находится в режиме активной связи. Во время регистрации UE находится в пределах покрытия обслуживаемой соты, а также в пределах области поисковых вызовов, которая охватывает обслуживающую соту и соседние соты. Обращаясь снова к фиг.1, обслуживающей сотой для UE 120x может быть узел B 110x, а область поисковых вызовов UE 120x может включать в себя семь сот, ограниченных жирной пунктирной линией. В зависимости от своей конфигурации UE может выполнять обновление соты каждый раз, когда UE перемещается в новую соту, или обновление области поисковых вызовов каждый раз, когда UE перемещается в новую область поисковых вызовов.

Фиг.6 иллюстрирует структуру процедуры 600 поискового вызова, которая использует совместно используемые каналы для поисковых вызовов. UE может быть закреплено в обслуживающей соте и может периодически пробуждаться, чтобы отслеживать поисковые вызовы, к примеру, как показано на фиг. 3. В любой данный момент точное местоположение UE может быть неизвестно. Например, UE, возможно, переместилось в новую соту, будучи в режиме пониженного энергопотребления между периодами поискового вызова. Таким образом, когда система имеет поисковый вызов для UE, обслуживающая сота и другие соты в области поисковых вызовов UE могут отправить индикатор поискового вызова (Paging ind) и, возможно, идентификационную информацию UE (UE ID info) в UE (этап 612). Идентификационная информация UE идентифицирует опрашиваемые поисковым вызовом UE и может содержать полный или частичный UE ID и/или другую информацию. UE ID может быть временным идентификатором радиосети (RNTI), международным идентификатором абонента мобильной связи (IMSI), MAC ID и т.д. RNTI - это уникальный UE ID для UE в системе. Индикатор поискового вызова и идентификационная информация UE могут быть отправлены по SDCCH, как описано ниже. Обслуживающая сота и другие соты в области поискового вызова также могут отправлять сообщение поискового вызова по DL-SDCH в UE (этап 614). Отправка индикатора поискового вызова и сообщения поискового вызова из всех сот в области поискового вызова UE увеличивает вероятность того, что UE может принимать сообщение поискового вызова, когда местоположение UE неизвестно с определенностью.

Соты могут отправлять индикатор поискового вызова и сообщение поискового вызова способом, который известен априори, так что при приеме индикатора поискового вызова UE знает, где сообщение поискового вызова отправлено по DL-SDCH, и как декодировать сообщение поискового вызова. Например, каждый индикатор поискового вызова, отправленный по SDCCH, может быть ассоциативно связан с сообщением поискового вызова, отправленным по DL-SDCH, с помощью предварительно определенной схемы модуляции и кодирования (MCS) и предварительно определенных PHY-ресурсов. В этом случае управляющая информация может не отправляться по SDCCH для сообщения поискового вызова, отправляемого по DL-SDCH. Альтернативно, управляющая информация может быть отправлена по SDCCH, чтобы указать, где и/или как восстанавливать сообщение поискового вызова по DL-SDCH.

UE принимает сообщение поискового вызова от DL-SDCH и может ответить на сообщение поискового вызова посредством осуществления произвольного доступа и отправки передачи по RACH (этап 616). Передача RACH может включать в себя подтверждение приема сообщения поискового вызова, информацию качества канала, указывающую качество канала нисходящей линии связи, запрос PHY-ресурсов восходящей линии связи и т.д. В общем, любая сота в области поискового вызова UE может принимать передачу RACH в зависимости от текущего местоположения UE. В одной структуре сота, которая принимает передачу RACH, может отвечать UE и выполнять обработку, описанную ниже. В другой структуре UE может направлять передачу RACH к конкретной соте, к примеру, посредством использования подписи или базовой последовательности, соответствующей выбранной соте. Выбранная сота затем должна выполнить обработку, описанную ниже, если она может успешно принять передачу RACH. Нижеследующее описание предполагает, что обслуживающая сота принимает передачу RACH.

Обслуживающая сота принимает передачу RACH и может отвечать посредством отправки назначения по SUACH (этап 618). Передача SUACH может включать в себя MAC ID для UE, корректировку синхронизации, чтобы корректировать синхронизацию передачи UE, назначение PHY-ресурсов для ACKCH, CQICH и/или UL-SDCH и т.д. MAC ID может быть назначен UE в ходе обмена после начального поискового вызова и может быть использован для того, чтобы идентифицировать передачу по DL-SDCH. Назначение ACKCH и/или CQICH также может быть неявным и не отправляться по SUACH. Например, PHY-ресурсы для ACKCH могут быть неявными из передачи по DL-SDCH. UE затем может отправить информацию качества канала по CQICH и/или подтверждения приема по ACKCH (этап 620).

Для передачи по нисходящей линии связи обслуживающая сота может отправить управляющую информацию по SDCCH (этап 622) и может отправить данные по DL-SDCH (этап 624) обычным/стандартным способом. Управляющая информация, отправляемая по SDCCH, может содержать любые типы информации, такие как, к примеру, MAC ID целевой UE для передачи данных по DL-SDCH, MCS, назначение ресурсов и интервал времени передачи (TTI) для передачи данных и т.д. Передача данных может отправляться с помощью гибридного запроса на автоматическую повторную передачу (HARQ), адаптации линии связи и т.д. При HARQ передающее устройство отправляет передачу для пакета и может отправить одну или более повторных передач, если требуется, до тех пор, пока пакет не будет корректно декодирован посредством приемного устройства или не отправлено максимальное число повторных передач, или другое условие завершения не произошло. HARQ позволяет повысить надежность передачи данных. Адаптация линии связи может включать в себя управление скоростью, управление мощностью и т.д. Управление скоростью означает выбор схемы модуляции и кодирования так, чтобы пакет мог достигнуть требуемого показателя производительности. Показатель может быть количественно оценен, к примеру, посредством целевой вероятности корректного декодирования после целевого числа повторных передач с помощью HARQ. Управление мощностью относится к регулированию мощности передачи так, чтобы достичь требуемого качества сигнала при уменьшении мощности передачи и помех. Обслуживающая сота может использовать информацию качества канала, принятую на этапе 620, для адаптации линии связи и может выбирать MCS и/или уровень мощности передачи на основе принятой информации.

В структуре, показанной на фиг.6, поисковые вызовы поддерживаются с помощью совместно используемого канала управления и совместно используемого канала данных, которые совместно используются посредством UE и также используются для различных типов данных. Например, DL-SDCH может переносить данные пользовательского трафика (DTCH) и пользовательскую управляющую информацию (DCCH) для конкретных UE, широковещательные данные (MTCH) и широковещательную управляющую информацию (MCCH) для нескольких UE и т.д. Эта структура исключает использование отдельного канала индикатора поискового вызова (PICH) и отдельного канала поискового вызова (PCH), чтобы поддерживать поисковый вызов. Применение совместно используемых каналов управления и данных для поисковых вызовов позволяет предоставлять определенные преимущества, такие как, к примеру, более простая реализация в UE и/или в сотах, улучшенное использование PHY-ресурсов через мультиплексирование, отсутствие фиксированной дополнительной служебной информации (к примеру, для канала индикатора поискового вызова, который используется в W-CDMA и cdma2000) и т.д.

Фиг.7 иллюстрирует структуру процедуры 700 поискового вызова, которая отправляет сообщение поискового вызова из конкретной соты. UE может быть закреплено в обслуживающей соте и может периодически пробуждаться, чтобы отслеживать поисковые вызовы. Когда система имеет поисковый вызов для UE, обслуживающая сота и другие соты в области поисковых вызовов UE отправляют индикатор поискового вызова и, возможно, идентификационную информацию UE по SDCCH в UE (этап 712). UE принимает индикатор поискового вызова и может ответить на индикатор поискового вызова посредством осуществления произвольного доступа и отправки передачи по RACH (этап 714). Передача RACH может включать в себя подтверждение приема индикатора поискового вызова, информацию качества канала. Передача RACH может включать или не включать в себя запрос PHY-ресурсов восходящей линии связи по UL-SDCH. Передача RACH служит для того, чтобы подтверждать прием индикатора поискового вызова и предоставлять текущее местоположение UE. В частности, текущее местоположение UE может быть обнаружено на основе сот, которые принимают передачу RACH. В общем, любая сота в области поискового вызова может принимать передачу RACH, и сота, которая принимает передачу RACH, или сота, выбранная посредством UE, может отвечать на UE. Нижеследующее описание предполагает, что обслуживающая сота принимает передачу RACH.

Обслуживающая сота отвечает на передачу RACH посредством отправки назначения по SUACH (этап 716). Передача SUACH может включать в себя MAC ID UE, корректировку синхронизации для UE, назначение PHY-ресурсов для ACKCH и/или CQICH и т.д. MAC ID, отправленный на этапе 716, может быть использован как UE ID в активном состоянии. UE ID на этапе 712 может быть извлечен из RNTI или IMSI и может быть использован как UE ID в неактивном состоянии. Назначение ACK и/или CQI также может быть неявным и не отправляться по SUACH. UE затем может отправить информацию качества канала по CQICH (этап 718). Этап 718 может быть опущен, если информация качества канала отправляется по RACH на этапе 714. Обслуживающая сота может использовать информацию качества канала для адаптации линии связи и может выбирать MCS и/или уровень мощности передачи для передачи в UE на основе принятой информации. Обслуживающая сота отправляет управляющую информацию по SDCCH (этап 720) и отправляет сообщение поискового вызова по DL-SDCH в UE (этап 722). Обслуживающая сота может отправить сообщение поискового вызова таким же образом, что и другие типы данных, отправляемые по DL-SDCH. Управляющая информация может указывать то, где и/или как сообщение поискового вызова отправляется по DL-SDCH. UE может отправить информацию качества канала по CQICH и/или подтверждение приема по ACKCH для сообщения поискового вызова (этап 724). Обслуживающая сота может отправить одну или более повторных передач для сообщения поискового вызова, при необходимости, по DL-SDCH до тех пор, пока сообщение поискового вызова не будет корректно декодировано посредством UE (этап 726).

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

Фиг.6 и 7 иллюстрируют две конкретные структуры для двух процедур поискового вызова, которые используют транспортные и физические каналы, описанные выше. Индикаторы поисковых вызовов и сообщения поисковых вызовов также могут отправляться другими способами и/или с помощью других транспортных и физических каналов. Например, на фиг. 6 первая передача сообщения поискового вызова может быть отправлена по DL-SDCH параллельно с индикатором поискового вызова по SDCCH. Одна или более повторных передач сообщения поискового вызова затем могут быть отправлены при необходимости. В качестве еще одного примера, на фиг. 7 индикаторы поискового вызова могут быть отправлены по каналу индикатора поискового вызова из всех сот в области поискового вызова, и сообщения поискового вызова могут быть отправлены по совместно используемому каналу из одной соты. Другие структуры поискового вызова и процедуры поискового вызова также могут быть реализованы.

UE могут быть привязаны к периоду поискового вызова различными способами. В одной структуре UE привязываются к конкретным периодам поискового вызова, к примеру, на основе хэша их UE ID. Различные UE могут быть привязаны псевдослучайным способом к различным временным интервалам на временной шкале передачи. Каждый UE может пробуждаться до назначенных периодов поискового вызова и отслеживать индикаторы поискового вызова. Один или несколько SDCCH могут быть использованы для того, чтобы отправлять индикаторы поискового вызова. Если SDCCH доступны, то UE могут быть привязаны к различным SDCCH, к примеру, на основе их UE ID. В этом случае период поискового вызова для UE может соответствовать конкретному SDCCH в конкретном временном интервале. В общем, UE могут хэшироваться в различные SDCCH во времени и/или в различные PHY-ресурсы в течение одного времени. Цель хэширования заключается в том, чтобы иметь UE с одинаковой частью самого младшего бита (LSB) UE ID, которые должны быть хэшированы в различные SDCCH, с тем, чтобы индикатор поискового вызова в данное время мог достигать одного UE или небольшого числа UE.

Идентификационная информация UE может быть отправлена с помощью индикатора поискового вызова, чтобы идентифицировать опрашиваемое поисковым вызовом UE. В одной структуре идентификационная информация UE содержит полный UE ID, к примеру, полный RNTI и т.д. Эта структура позволяет каждому UE определять без неопределенности то, отправлен ли индикатор поискового вызова для этого UE. Данная структура может быть использована для процедур поискового вызова, показанных на фиг. 6 и 7.

В другой структуре идентификационная информация UE содержит частичный UE ID, к примеру предварительно определенное число LSB для UE ID, к примеру, RNTI. В общем, любая часть UE и любое число битов может быть использовано для частичного UE ID. LSB могут быть более произвольными, чем самые старшие биты (MSB), и могут быть использованы для частичного UE ID. Число битов, чтобы использовать, может быть фиксируемым или конфигурируемым значением и может зависеть от числа битов, доступных по SDCCH для идентификационной информации UE. Эта структура уменьшает число битов, чтобы отправить, для идентификационной информации UE. UE могут быть привязаны к периодам поискового вызова так, чтобы два UE с одинаковым частичным UE ID не были привязаны к одному периоду поискового вызова. В этом случае все UE, которые привязаны к каждому периоду поискового вызова, могут быть уникально идентифицированы на основе их частичных UE ID. Эта привязка обеспечивает то, что частичный UE ID, отправленный в периоде поискового вызова, может однозначно идентифицировать опрашиваемое поисковым вызовом UE. Привязка UE к периоду поискового вызова может выполняться различными способами. Например, функция хэширования может привязывать UE к периодам поискового вызова на основе их UE ID, но не допускать привязки двух UE с одним частичным UE ID к одному периоду поискового вызова. Данная структура также может быть использована для процедур поискового вызова, показанных на фиг.6 и 7.

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

Индикаторы поискового вызова могут быть отправлены различными способами. В одной структуре индикатор поискового вызова явно отправляется через заданное поле. Например, бит может быть назначен в каждом периоде поискового вызова и может быть задан равным либо единице (1), чтобы указать отправку индикатора, либо нулю (0), чтобы указать отсутствие отправки индикатора. Каждое UE может обнаруживать то, отправлен ли индикатор поискового вызова, посредством проверки этого бита. В другой структуре индикатор поискового вызова явно отправляется посредством конкретного индекса или значения для заданного поля. Например, управляющая информация для каждой передачи по DL-SDCH может включать в себя поле, которое переносит тип данных, отправляемый в передаче. Конкретный индекс может быть назначен для поискового вызова, и поле может быть задано равным этому индексу каждый раз, когда отправляется сообщение поискового вызова. В еще одной структуре индикатор поискового вызова отправляется неявно. Эта неявная передача сигнала индикатора поискового вызова может выполняться различными способами.

Фиг.8 иллюстрирует структуру 800 для неявной отправки индикатора поискового вызова. В этой структуре формирователь 810 контроля избыточным циклическим кодом (CRC) принимает управляющую информацию для DL-SDCH и формирует CRC-значение. Блок 812 маскировки маскирует (к примеру, скремблирует) CRC-значение с идентификатором поискового вызова и предоставляет маскированное CRC-значение. Идентификатор поискового вызова - это специальная последовательность, используемая для поискового вызова, и она известна сотам и UE. Управляющая информация и маскированное CRC-значение отправляются по SDCCH. Индикатор поискового вызова неявно отправляется посредством маскированного CRC-значения.

Фиг.9 иллюстрирует структуру для 900 восстановления неявного индикатора поискового вызова. Управляющая информация и маскированное CRC-значение принимаются из SDCCH. Формирователь 910 CRC формирует CRC-значение на основе принятой управляющей информации и предоставляет сформированное CRC-значение. Блок 912 демаскирования демаскирует (к примеру, дескремблирует) маскированное CRC-значение с тем же идентификатором поискового вызова ID, что и используемый посредством соты, и предоставляет принятое CRC-значение. Блок 914 сравнения сравнивает сформированное CRC-значение с принятым CRC-значением и указывает, что индикатор поискового вызова отправлен, если имеется совпадение.

Неявный индикатор поискового вызова может быть отправлен на фиг.6 посредством маскирования управляющей информации или CRC-значения, отправленного по SDCCH для сообщения поискового вызова, отправленного по DL-SDCH. Каждое UE может демаскировать управляющую информацию или CRC-значение, чтобы определять то, отправлен ли индикатор поискового вызова. Другая информация также может быть маскирована. В любом случае дополнительные PHY-ресурсы не используются для того, чтобы отправлять неявный индикатор поискового вызова.

Фиг.10 иллюстрирует структуру процесса 1000, выполняемого сотой для того, чтобы опросить поисковым вызовом UE. Сота отправляет индикатор поискового вызова в UE (к примеру, по совместно используемому каналу управления) (этап 1012). Сота может отправить идентификационную информацию UE с индикатором поискового вызова. Идентификационная информация UE может идентифицировать UE как заданного получателя индикатора поискового вызова и может содержать весь или часть идентификатора UE, который уникально идентифицирует UE. Сота отслеживает (к примеру, канал произвольного доступа) подтверждение приема для индикатора поискового вызова из UE (этап 1014). Сота может обнаруживать, что она является сотой, предназначенной для того, чтобы обслуживать UE, на основе получения подтверждения приема.

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

Фиг.11 иллюстрирует устройство 1100 для поискового вызова UE. Устройство 1100 включает в себя средство отправки индикатора поискового вызова в UE (модуль 1112), средство мониторинга подтверждения приема индикатора поискового вызова из UE (модуль 1114) и средство отправки сообщения поискового вызова в UE, если подтверждение приема индикатора поискового вызова принято от UE (модуль 1116). Модули 1112-1116 могут содержать процессоры, электронные устройства, аппаратные устройства, электронные компоненты, логические схемы, запоминающие устройства и т.д., либо любую комбинацию вышеозначенного.

Фиг.12 иллюстрирует структуру процесса 1200, выполняемого UE для того, чтобы принять поисковый вызов. UE принимает индикатор поискового вызова для UE, к примеру, по совместно используемому каналу управления (этап 1212). UE может принять идентификационную информацию UE (к примеру, полный или частичный UE ID) с индикатором поискового вызова и может обнаружить, что индикатор поискового вызова предназначен для UE, на основе идентификационной информации UE. UE отправляет подтверждение приема индикатора поискового вызова, к примеру, по каналу произвольного доступа (этап 1214). UE затем принимает сообщение поискового вызова для UE, к примеру, по совместно используемому каналу данных (этап 1216). UE может отправить информацию качества канала и может обрабатывать сообщение поискового вызова в соответствии со схемой модуляции и кодирования, выбранной на основе информации качества канала. UE также может принимать передачу и, возможно, одну или более повторных передач для сообщения поискового вызова.

Фиг.13 иллюстрирует устройство 1300 для приема поискового вызова. Устройство 1300 включает в себя средство приема индикатора поискового вызова для UE (модуль 1312), средство отправки подтверждения приема индикатора поискового вызова (модуль 1314) и средство приема сообщения поискового вызова для UE (модуль 1316). Модули 1312-1316 могут содержать процессоры, электронные устройства, аппаратные устройства, электронные компоненты, логические схемы, запоминающие устройства и т.д., либо любую комбинацию вышеозначенного.

Фиг.14 иллюстрирует структуру процесса 1400, выполняемого сотой для того, чтобы опросить поисковым вызовом UE. Сота отправляет индикатор поискового вызова по совместно используемому каналу управления в UE (этап 1412). Сота отправляет сообщение поискового вызова по совместно используемому каналу данных в UE (этап 1414). Сота может отправить идентификационную информацию UE с индикатором поискового вызова, чтобы идентифицировать UE как заданного получателя индикатора поискового вызова. Совместно используемый канал управления может переносить управляющую информацию для совместно используемого канала данных. Совместно используемый канал данных может переносить данные для различных UE и/или различных типов данных. Индикатор поискового вызова и сообщение поискового вызова могут быть отправлены из нескольких сот в UE, к примеру, как показано на фиг.6. Альтернативно, индикатор поискового вызова может быть отправлен из нескольких сот в UE, а сообщение поискового вызова может быть отправлено из одной соты в UE, к примеру, как показано на фиг.7.

Фиг.15 иллюстрирует устройство 1500 для поискового вызова UE. Устройство 1500 включает в себя средство отправки индикатора поискового вызова по совместно используемому каналу управления в UE (модуль 1512) и средство отправки сообщения поискового вызова по совместно используемому каналу данных в UE (модуль 1514). Модули 1512 и 1514 могут содержать процессоры, электронные устройства, аппаратные устройства, электронные компоненты, логические схемы, запоминающие устройства и т.д., либо любую комбинацию вышеозначенного.

Фиг.16 иллюстрирует структуру процесса 1600, выполняемого сотой и/или системным контроллером для поискового вызова. Каждое UE ассоциативно связано с (1) UE ID, который уникально идентифицирует UE, и (2) частичным UE ID, который извлекается на основе UE ID. UE ID могут быть MAC ID или какие-либо другие конкретные для UE идентификаторы ID. UE привязываются к периодам поискового вызова на основе их UE ID так, что UE с одинаковым частичным UE ID привязываются к различным периодам поискового вызова (этап 1612). Индикатор поискового вызова и частичный UE ID для UE-получателя отправляются в периоде поискового вызова для UE-получателя (этап 1614). Частичный UE ID для UE-получателя может быть определен на основе предварительно определенного числа LSB в UE ID для UE-получателя.

Фиг.17 иллюстрирует устройство 1700 для поискового вызова. Устройство 1700 включает в себя средство привязки UE к периодам поискового вызова на основе их UE ID так, что UE с одним частичным UE ID привязываются к различным периодам поискового вызова (модуль 1712), и средство отправки индикатора поискового вызова и частичного UE ID для UE-получателя в периоде поискового вызова для UE-получателя (модуль 1714). Модули 1712 и 1714 могут содержать процессоры, электронные устройства, аппаратные устройства, электронные компоненты, логические схемы, запоминающие устройства и т.д., либо любую комбинацию вышеозначенного.

Фиг.18 иллюстрирует процесс 1800 отправки неявного индикатора поискового вызова. Сота маскирует информацию с идентификатором поискового вызова, чтобы получить маскированную информацию (этап 1812). Далее сота отправляет маскированную информацию, чтобы передать информацию и неявно передать индикатор поискового вызова (этап 1814). Информация, которая может быть маскирована, может быть управляющей информацией, отправляемой по совместно используемому каналу данных, или каким-либо другим типом информации. Сота может маскировать и отправлять информацию посредством формирования CRC-значения, которое используется в качестве информации, которая должна быть маскирована, маскировки CRC-значения с идентификатором поискового вызова, чтобы сформировать маскированное CRC-значение, и отправки маскированного CRC-значения.

Фиг.19 иллюстрирует устройство 1900 для отправки неявного индикатора поискового вызова. Устройство 1900 включает в себя средство маскирования информации с идентификатором поискового вызова, чтобы получить маскированную информацию (этап 1912), и средство отправки маскированной информации, чтобы передать информацию и неявно передать индикатор поискового вызова (модуль 1914). Модули 1912 и 1914 могут содержать процессоры, электронные устройства, аппаратные устройства, электронные компоненты, логические схемы, запоминающие устройства и т.д., либо любую комбинацию вышеозначенного.

Фиг.20 иллюстрирует блок-схему структуры одного UE 120, одного узла B 110 и системного контроллера 130 по фиг.1. В направлении передачи данные и служебные сигналы, которые должны быть отправлены посредством UE 120, обрабатываются (к примеру, форматируются, кодируются и перемежаются) посредством кодера 2012 и дополнительно обрабатываются (к примеру, модулируются, канализируются и скремблируются) посредством модулятора (Mod) 2014, чтобы сформировать выходные элементарные сигналы. Передающее устройство (TMTR) 2022 приводит к требуемым параметрам (к примеру, преобразует в аналоговую форму, фильтрует, усиливает и преобразует с повышением частоты) выходные элементарные сигналы и формирует сигнал восходящей линии связи, который передается через антенну 2024. В направлении приема сигналы нисходящей линии связи, передаваемые посредством узла B 110, а также других узлов B, принимаются антенной 2024. Приемное устройство (RCVR) 2026 приводит к требуемым параметрам (к примеру, фильтрует, усиливает, преобразует с понижением частоты и оцифровывает) принимаемый сигнал из антенны 2024 и предоставляет выборки. Демодулятор (DEMOD) 2016 обрабатывает (к примеру, дескремблирует, канализирует и демодулирует) выборки и предоставляет оценки символов. Декодер 2018 дополнительно обрабатывает (к примеру, обратно перемежает и декодирует) оценки символов и предоставляет декодированные данные. Кодер 2012, модулятор 2014, демодулятор 2016 и декодер 2018 могут быть реализованы посредством модемного процессора 2010. Эти блоки выполняют обработку в соответствии с технологией радиосвязи, используемой посредством системы беспроводной связи.

Контроллер/процессор 2030 управляет работой различных блоков в UE 120. Контроллер/процессор 2030 может выполнять процесс 1200 на фиг.12 и/или другие процессы, чтобы принимать поисковые вызовы. Запоминающее устройство 2032 сохраняет программные коды и данные для UE 120.

Узел B 110 включает в себя приемо-передающее устройство 2038, процессор/контроллер 2040, запоминающее устройство (Mem) 2042 и блок 2044 связи (Comm). Приемо-передающее устройство 2038 предоставляет радиосвязь с UE 120 и другими UE. Процессор/контроллер 2040 выполняет различные функции для связи и поискового вызова UE и может реализовывать процесс 1000 на фиг.10, процесс 1400 на фиг. 14, процесс 1600 на фиг.16, процесс 1800 на фиг.18 и/или другие процессы. Запоминающее устройство 2042 сохраняет программные коды и данные для узла B 110. Блок 2044 связи упрощает связь с системным контроллером 130.

Системный контроллер 130 включает в себя процессор/контроллер 2050, запоминающее устройство 2052 и блок 2054 связи. Процессор/контроллер 2050 выполняет различные функции, чтобы поддерживать связь и поисковые вызовы для UE, к примеру, определять, какие соты находятся в зоне поискового вызова UE 120, и отправлять индикаторы поискового вызова и сообщения поискового вызова в эти соты. Процессор/контроллер 2050 может реализовать процесс 1600 на фиг.16 и/или другие процессы. Запоминающее устройство 2052 сохраняет программные коды и данные для системного контроллера 130. Блок 2054 связи упрощает связь с узлом B 110.

Описанные в данном документе методики поисковых вызовов могут быть реализованы различными средствами. Например, эти методики могут быть реализованы в аппаратных средствах, микропрограммном обеспечении, программном обеспечении или их комбинации. При реализации в аппаратных средствах модули обработки, используемые для того, чтобы поддерживать поисковые вызовы в UE, узле B или системном контроллере, могут быть реализованы в одной или нескольких специализированных интегральных схемах (ASIC), процессорах цифровых сигналов (DSP), устройствах цифровой обработки сигналов (DSPD), программируемых логических устройствах (PLD), программируемых пользователем матричных БИС (FPGA), процессорах, контроллерах, микроконтроллерах, микропроцессорах, электронных устройствах, других электронных модулях, предназначенных для того чтобы выполнять описанные в данном документе функции, или в их комбинациях.

При реализации в микропрограммном обеспечении и/или программном обеспечении методики поискового вызова могут быть реализованы с помощью модулей (к примеру, процедур, функций и т.п.), которые выполняют описанные в данном документе функции. Микропрограммные и/или программные коды могут быть сохранены в запоминающем устройстве (к примеру, в запоминающем устройстве 2032, 2042 или 2052 на фиг.20) и приведены в исполнение процессором (к примеру, процессором 2030, 2040 или 2050). Запоминающее устройство может быть реализовано в процессоре или внешне по отношению к процессору.

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

Изобретение относится к беспроводной связи. Описываются методики для эффективного опрашивания поисковыми вызовами абонентских устройств (UE) в системе беспроводной связи. В одном аспекте сота отправляет индикатор поискового вызова в UE, отслеживает подтверждение приема от UE и отправляет сообщение поискового вызова в UE, если подтверждение приема принято от UE. Сота может принимать информацию качества канала от UE и может отправлять сообщение поискового вызова с помощью адаптации линии связи и/или HARQ, чтобы повысить производительность. В другом аспекте сота отправляет индикатор поискового вызова по совместно используемому каналу управления в UE и отправляет сообщение поискового вызова по совместно используемому каналу данных в UE. Индикатор поискового вызова и сообщение поискового вызова может быть отправлено из нескольких сот в UE. Альтернативно, индикатор поискового вызова может быть отправлен из нескольких сот в UE, а сообщение поискового вызова может быть отправлено из одной соты в UE. 2 н. и 4 з.п. ф-лы, 20 ил.

1. Устройство для направления поискового вызова на абонентские устройства (UE) в системе беспроводной связи, содержащее:
- по меньшей мере, один процессор, выполненный с возможностью привязывать UE к периодам поискового вызова на основе идентификаторов (ID) UE так, что UE с одинаковым частичным UE ID привязываются к различным периодам поискового вызова, и отправлять индикатор поискового вызова и частичный UE ID для UE-получателя в периоде поискового вызова по совместно управляемому каналу, отдельно от канала индикатора поискового вызова (PICH), для UE-получателя; и
- запоминающее устройство, соединенное, по меньшей мере, с одним процессором.

2. Устройство по п.1, в котором каждый из UE ассоциативно связан с UE ID, который уникально идентифицирует UE, и частичным UE ID, который извлекается на основе UE ID.

3. Устройство по п.1, в котором, по меньшей мере, один процессор выполнен с возможностью определять частичный UE ID для UE-получателя на основе предварительно определенного числа самых младших битов (LSB) в UE ID для UE-получателя.

4. Устройство по п.1, в котором UE ID - это временные идентификаторы радиосети (RNI), международные идентификаторы абонента мобильной связи (IMSI) или идентификаторы управления доступом к среде (MAC).

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

6. Способ по п.5, содержащий также этап, на котором:
- определяют частичный UE ID для UE-получателя на основе предварительно определенного числа самых младших битов (LSB) в UE ID для UE-получателя.