Способы и системы для уменьшения времени получения системной информации (si)
Изобретение относится к способам и устройствам для уменьшения времени получения системной информации. Техническим результатом является улучшение времени доступа к системе и времени работы оборудования пользователя (UE) от батареи. Способ для уменьшения времени получения системной информации, SI, выполняемый оборудованием пользователя, UE, содержит следующие этапы: принимают основной блок информации, MIB, содержащий однобитный флаг для указания, изменилась или нет определенная SI с конкретного времени в прошлом; получают блок системной информации, SIB, который содержит определенную SI, при этом UE получает SIB независимо от значения, в которое установлен флаг; принимают последующий MIB, содержащий однобитный флаг, который установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась с конкретного момента времени в прошлом; определяют, может ли быть пропущено получение последующего SIB; и после этапа, на котором определяют, что получение последующего SIB может быть пропущено, пропускают получение последующего SIB, который содержит определенную SI. 5 н. и 20 з.п. ф-лы, 11 ил.
ОБЛАСТЬ ТЕХНИКИ
[0001] Раскрываются варианты осуществления, которые относятся к уменьшению времени получения системной информации оборудованием пользователя (UE) (например, устройством Интернета Вещей (IoT), устройством связи машинного типа (MTC) или другим устройством связи) таким как, например, UE, которое пробуждается из состояния глубокого сна.
УРОВЕНЬ ТЕХНИКИ
[0002] Как правило для того, чтобы UE имело возможность осуществления связи с сетью, UE должно получить некоторую системную информацию (SI). Обычно базовая станция периодически осуществляет широковещательную передачу Основного Блока Информации (MIB), который содержит SI, которая требуется UE. Базовая станция также передает другие Блоки Системной Информации (SIB), которые также могут содержать дополнительную SI, которая требуется UE. Например, базовая станция LTE–M1 передает, например, конкретный SIB, который упоминается как «SIB1–BR».
[0003] В последнее время в 3GPP было проделано много работы по подробному описанию технологий, чтобы охватывать случаи использования, связанные со связью типа Машина–с–Машиной (M2M) и/или Интернетом Вещей (IoT). Самая последняя работа в отношении 3GPP Редакции 13 включает в себя улучшения, чтобы поддерживать Связь Машинного Типа (MTC) с новым UE категории M1 (Cat–M1), которое поддерживает уменьшенную максимальному полосу пропускания вплоть до 6 блоков физических ресурсов (PRB), и рабочий вопрос по Узкополосному IoT (NB–IoT), который подробно описывает новый радиоинтерфейс (и UE категории NB1, Cat–NB1).
[0004] Мы будет обращаться к улучшениям LTE, которые введены в 3GPP Редакции 13 для MTC, как «eMTC», а дальнейшим улучшениям, которые введены в 3GPP Редакции 14, как «FeMTC», включая (не ограничиваясь) поддержку UE с ограниченной полосой пропускания, Cat–M1, Cat–M2 и поддержку улучшений покрытия. Это для того, чтобы отделить обсуждение от NB–IoT, несмотря на то, что поддерживаемые признаки похожи на общем уровне.
[0005] Существует несколько отличий между «унаследованным» LTE и процедурами, и каналами, которые определены для работы eMTC или FeMTC (подобно NB–IoT). Некоторые важные отличия включают в себя новые физические каналы, такие как физические каналы управления нисходящей линии связи (PDCCH), именуемые MPDCCH в eMTC и NPDCCH в NB–IoT, и новый физический канал произвольного доступа NPRACH для NB–IoT.
[0006] Применительно к системной информации (SI) (как eMTC, так и NB–IoT), отсутствует динамическое планирование либо SIB1–BR/SIB1–NB (информация планирования включена в MIB/MIB–NB), либо сообщений системной информации (фиксированное планирование внутри окна системной информации предусмотрено в SIB1–BR/SIB1–NB). Как eMTC, так и NB–IoT поддерживают улучшения покрытия, и UE возможно придется накапливать несколько повторений широковещательной передачи системной информации для того, чтобы иметь возможность ее успешного декодирования. Это означает, что время получения системной информации на практике тем продолжительнее, чем в худшем покрытие находится UE. Для борьбы с этим в eMTC и NB–IoT Редакции 13 были введены более плотные повторения для некоторых физических каналов и системной информации. Недостатком этого является увеличение потерь системы (т.е. больше радиоресурсов расходуется непрерывной («постоянной») широковещательной передачей сигнализации управления). Процедура получения системы для eMTC и NB–IoT является в целом точно такой же, как для LTE: UE сначала добивается синхронизации нисходящей линии связи посредством считывания PSS/SSS, затем UE считывает MIB, затем SIB1 (например, SIB1–BR) и в заключение получаются SI–сообщения (каждое возможно содержащее несколько SIB).
[0007] На заседании 3GPP RAN#70 был одобрен новый рабочий вопрос Редакции 13, названный Узкополосным IoT (NB–IoT). Цель состоит в подробном описании радиодоступа для сотового интернета вещей (IoT) в отношении улучшенного покрытия внутри помещений, поддержки огромного числа устройств с низкой пропускной способностью, не чувствительных к задержке, сверхнизкой стоимости устройства, низкого энергопотребления устройства и (оптимизированной) сетевой архитектуры.
[0008] Применительно к NB–IoT определены три разных режима работы, т.е. автономный, в защитной полосе и внутриполосный. В автономном режиме система NB–IoT работает в выделенных полосах частот. Применительно к внутриполосной работе система NB–IoT может быть помещена в полосы частот, которые используются текущей системой LTE, тогда как в режиме в защитной полосе система NB–IoT может работать в защитной полосе, которая используется текущей (унаследованной) системой LTE. NB–IoT может работать с системной полосой пропускания в 180кГц. Когда сконфигурировано несколько несущих, может быть использовано несколько 180кГц несущих, например, для увеличения емкости системы, координации меж–сотовых помех, балансировки нагрузки и т.д.
[0009] Для того, чтобы адаптироваться к определенным случаям использования, которые требуют больше емкости, чем обычно, например, обновление программного обеспечения или встроенного программного обеспечения, используются операции с несколькими несущими. Устройство NB–IoT прослушивает системную информацию по несущей привязки, но когда присутствуют данные, связь может быть перемещена на вторичную несущую.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0010] Во время работы над Редакцией 14, RAN4 идентифицировала некоторые потенциальные проблемы, связанные с длительным временем получения системной информации. Уменьшение времени получения системы также является одной из согласованных целей рабочего вопроса применительно к Редакции 15 для eMTC. В частности, RAN1 в целом выделяет некоторые области, в которых RAN2 может обеспечивать улучшения (в дополнение к рассмотренным улучшениям RAN1). В принципе, это всего лишь поднимает вопрос в RAN в отношении того, могут ли в некоторых ситуациях некоторые сообщения широковещательной SI быть пропущены UE, и здесь наиболее интересен случай пропуска считывания SIB1–BR). Для обращения содержимое LTE–M MIB показано ниже в Таблице 1:
Таблица 1
| MasterInformationBlock ::= SEQUENCE { dl–Bandwidth ENUMERATED { n6, n15, n25, n50, n75, n100}, phich–Config PHICH–Config, systemFrameNumber BIT STRING (SIZE (8)), schedulingInfoSIB1–BR–r13 INTEGER (0..31), spare BIT STRING (SIZE (5)) } |
[0011] Наиболее заметное отличие от NB–IoT состоит в том, что в NB–IoT значение valueTag не присутствует в MIB, а вместо этого располагается в SIB1–BR.
[0012] В настоящее время существует определенная проблема(ы). SIB1–BR содержит следующее: i) информацию доступа, ii) velueTag системной информации, iii) гипер системный номер кадра (H–SFN), iv) битовую карту, которая указывает действительные субкадры, v) начальный OFDM–символ для MPDCCH и PDSCH (по сути замещающего PCFICH), и vi) информацию планирования прочих сообщений SI.
[0013] Из–за связанной с доступом информации, указания действительного субкадра и т.д. UE очень сложно или даже невозможно пропускать считывание SIB1–BR применительно к первоначальному получению. Тем не менее, применительно к повторному получению SI это может быть жизнеспособной опцией, например, применительно к UE, которые пробуждаются из eDRX или PSM. В большинстве случаев SI не изменилась в соте, но UE по–прежнему должно убедиться в этом посредством считывания valueTag системной информации. Вследствие этого один подход может состоять в том, чтобы помещать valueTag непосредственно в MIB. Тем не менее это проблематично по нескольким причинам. Во–первых, valueTag составляет 5 битов, но в MIB осталось только 5 резервных битов. Маловероятно, что 3GPP разрешит eMTC использовать все оставшиеся резервные биты, которые предназначены в целом для любого будущего использования применительно к LTE. Более того, некоторые из резервных битов MIB будут вероятно использованы для других целей, по–прежнему связанных с ‘уменьшенным временем получения системы’, например, для наличия флага задействованного запрета доступа (ab–Enabled) в MIB, как применительно к NB–IoT. Другой проблемой включения valueTag в MIB является то, что это приведет к широковещательной передаче избыточной информации, в худшем случае 5 битов, увеличивая потери системы. Другой подход состоит в использовании меньшего числа битов для valueTag (например, 2 битов вместо 5). С помощью 5 битов сеть может обновлять системную информацию вплоть до 32 раз в течение времени действия SI из 3 часов или 24 часов (это зависит от конфигурации). Если вместо этого используется valueTag с числом битов меньше 5, то это означает, что сеть будет ограничена до изменения SI меньше 32 раз (например, 2 или 4 раза) в течение времени действия SI. Это довольно навязчивое изменение для унаследованной работы, например, 2–битный valueTag будет означать, что сеть может обновлять SI только 4 раза в течение данного периода.
[0014] Некоторые аспекты настоящего изобретения и их варианты осуществления предоставляют решения для этих и прочих проблем. Например, некоторые варианты осуществления, представленные в данном документе, используют указание (например, однобитный флаг) в MIB, который установлен в конкретное значение, если UE необходимо считать SIB1–BR, в противном случае указание MIB установлено в другое значение. Данное указание MIB непохоже на valueTag в том смысле, что при любом изменении SIB1–BR и systemlnfoValueTag в нем, в самом простом случае использования 1 бита, флаг меняется с ‘0’ на ‘1’, указывая то, что UE не могут более опускать считывание SIB1–BR, но при последующем изменении SIB1–BR флаг по–прежнему устанавливается в ‘1’ на оставшуюся часть определенного периода времени, например, цикл HSFN. Использование только 1 бита (или некоторого другого небольшого числа) из резервных битов MIB обеспечивает четкое преимущество для всех UE, когда SIB1–BR/systemInfoValueTag не обновляется, что чаще всего и бывает. Если SI была обновлена, UE будут просто следовать процедурам Редакции 13. (Варианты осуществления с несколькими битами могут иметь дополнительные преимущества, как видно в подробном описании). Описанное выше решение, которое уменьшает потребность UE в получении SIB1–BR (чтобы проверять системный ValueTag и т.д.) в значительной степени улучшает время доступа к системе и время работы UE от батареи.
[0015] В данном документе предлагаются различные варианты осуществления, которые решают одну или более проблемы, описанные в данном документе. Определенные варианты осуществления могут обеспечивать одно или более из следующих технических преимуществ. UE может пропускать считывание SIB1–BR для повторного получения SI, тем самым улучшая время получения/доступа к системе у UE и продлевая время работы UE от батареи; и решение использует только 1 (или несколько) из резервных битов MIB, тем самым эффективно используя дефицитные ресурсы.
[0016] Эти и прочие варианты осуществления дополнительно описаны в данном документе.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
[0017] Сопроводительные чертежи, которые включены в данный документ и формируют часть технического описания, иллюстрируют различные варианты осуществления.
[0018] Фиг. 1 иллюстрирует вид архитектуры в соответствии с некоторыми вариантами осуществления.
[0019] Фиг. 2 является блок–схемой, иллюстрирующей процесс в соответствии с некоторыми вариантами осуществления.
[0020] Фиг. 3 является блок–схемой, иллюстрирующей процесс в соответствии с некоторыми вариантами осуществления.
[0021] Фиг. 4 является блок–схемой, иллюстрирующей процесс в соответствии с некоторыми вариантами осуществления.
[0022] Фиг. 5 иллюстрирует вариант осуществления для пропуска SIB1–BR.
[0023] Фиг. 6 является блок–схемой, иллюстрирующей процесс в соответствии с некоторыми вариантами осуществления.
[0024] Фиг. 7 является блок–схемой, иллюстрирующей процесс в соответствии с некоторыми вариантами осуществления.
[0025] Фиг. 8 является структурной схемой UE в соответствии с некоторыми вариантами осуществления.
[0026] Фиг. 9 является структурной схемой сетевого узла в соответствии с некоторыми вариантами осуществления.
[0027] Фиг. 10 иллюстрирует процесс кодирования в соответствии с некоторыми вариантами осуществления.
[0028] Фиг. 11 иллюстрирует процесс кодирования в соответствии с некоторыми вариантами осуществления.
ПОДРОБНОЕ ОПИСАНИЕ
[0029] Cat–M1, Cat–M2, Cat–N1 и Cat–N2 UE в плохом покрытии могут сталкиваться с длительным временем получения системы. В документах [3][4] установлено, что в некоторых случаях как для NB–IoT, так и для LTE–M (eMTC) получение системной информации может занимать длительное время. Вследствие этого одной целью дальнейших улучшений как для LTE–M, так и NB–IoT в Rel–15 является уменьшение времени получения системы.
[0030] В данном изобретении мы предлагаем способы и системы, которые позволяют NB–IoT UE пропускать получение определенной основной информации (MI) в основном блоке информации (MIB) и/или определенной системной информации (SI) в некоторых блоках системной информации (SIB). Предложенные способы включают в себя следующие варианты осуществления.
[0031] (1) Сигнализация интервала действия или времени истечения MIB/SIB в новом блоке системной информации (SIB). Мы будет обращаться к данному новому SIB как SIB–X, чтобы отличать его от тех блоков системной информации, которые уже определены для NB–IoT.
[0032] (2) Механизм для обеспечения пропуска UE получения MI/SI, чтобы получать одно или более из флага Запрета Доступа, Номера Системной Информации и номера Гипер Системной информации.
[0033] UE может пропускать считывание основного блока информации (MIB) (или его частей), который переносится в Узкополосном Физическом Широковещательном Канале (NPBCH), или определенных Блоков Системной Информации (SIB) (или их частей), которые переносятся в Узкополосных Физических Совместно Используемых Каналах Нисходящей Линии Связи (PDSCH), когда существенная основная информация или системная информация не изменилась с того момента, когда UE получала ее последний раз. Не пытаясь повторно получать актуальную MI/SI, UE уменьшает энергопотребление и вследствие этого пользуется более длительной работой от батареи. Кроме того, уменьшается время ожидания для UE, создающего доступ к сети, когда оно имеет данные для отправки.
[0034] Ниже изложена системная информация NB–IoT:
[0035] Основной блок информации NB–IoT (MIB–NB) состоит из следующей информации:
– Четыре старших бита, MSB, у SFN.
– Два младших бита, LSB, у H–SFN.
– Флаг запрета доступа (AB), который указывает, задействован ли запрет доступа.
– Режим работы (автономный, внутриполосный, в защитной полосе).
– В случае внутриполосной работы и работы в защитной полосе смещение растра частоты (±2.5, ±7.5кГц).
– Информация о планировании Блока 1 Системной Информации (SIB1–NB).
– Метка значения системной информации, которая по сути является номером версии системной информации.
[0036] NB–IoT дополнительно определяет следующе типы системной информации:
– SIB1–NB: 8 MSB у H–SFN, информация планирования другого типа системной информации, битовая карта недействительных субкадров, плюс прочая информация.
– SIB2: Информация конфигурации радиоресурсов (RRC).
– SIB3: Информация о повторном выборе соты.
– SIB4 и SIB5: Информация, связанная с соседней сотой.
– SIB14–NB: Информации о запрете классов доступа из расчета на PLMN.
– SIB16: Информация, связанная с временем GPS и Всеобщим Скоординированным Временем (UTC).
[0037] Ниже изложена системная информация LTE–M:
[0038] Основной блок информации LTE–M (MIB–NB) состоит из следующей информации:
– Полоса пропускания нисходящей линии связи
– Конфигурация PHICH
– Биты SFN
– Информация планирования для SIB1–BR
– 5 резервных битов
[0039] LTE–M дополнительно определяет следующие типы системной информации:
– SIB1–BR: Связанная с доступом информация, включающая в себя информацию о запрете классов доступа (ACB), информацию планирования для сообщений SI, гипер–SFN, действительные битовые кадры, информацию о скачкообразном изменении частоты MPDCCH и т.д.
– SIB2: Информация о конфигурации радиоресурсов (RRC).
– SIB3: Информация о повторном выборе соты.
– SIB4 и SIB5: Информация, связанная с соседней сотой.
– SIB15: Информация о запрете классов доступа из расчета на PLMN.
– SIB16: Информация, связанная с временем GPS и Всеобщим Скоординированным Временем (UTC).
[0040] Среди этих разных типов основной и системной информации, как правило более динамично меняется только SFN, H–SFN, ACB (LTE–M) и флаг AB (NB–IoT), SIB14(–NB) и SIB16. Прочая информация меняется редко. SIB16 не требуется, когда UE осуществляет доступ к сети. SIB14(–NB) не требуется, если флаг AB не установлен для NB–IoT, или если SIB14 не планируется в SIB1–BR для LTE–M. Таким образом, в большинстве случаев требуется получение только SFN, H–SFN и флага AB (или ACB плюс планирование SIB–14 для LTE–M).
[0041] Поскольку большая часть MIB и SI меняется редко, то один способ, чтобы позволить UE пропускать повторное получение MIB(–NB) и SI, которые будут оставаться неизменными, состоит в том, чтобы позволить eNB заранее указывать интервал действия или время истечения для информации MIB(–NB) и SI. (В нижеследующем описании мы будет предполагать, что изменения флага AB, SIB14(–NB), SIB 16, SFN и H–SFN не используются, чтобы определять интервал действия или время истечения MI/SI). С помощью такого указания, если UE пробуждается в рамках интервала действия MI/SI для версии, которая была получена ранее, то нет необходимости в повторном получении той же самой информации. В таких сценариях UE только требуется получать только флаг AB, SFN и H–SFN (или ACB плюс планирование SIB–14 в SIB1–BR для LTE–M), и не обязательно все прочие элементы информации, которые содержатся в MIB–NB и SIB1–NB. Для поддержки данного способа требуют решения две проблемы.
[0042] Каким образом сеть сигнализирует интервал действия или время истечения MI/SI?
[0043] Каким образом UE получает флаг AB (или ACB плюс планирование SIB–14 в SIB1–BR для LTE–M), SFN и H–SFN, если оно знает, что вся прочая информация MI/SI остается той же самой?
[0044] Способы для решения этих проблем описаны ниже.
[0045] Сигнализация интервала действия или времени истечения MI/SI:
[0046] Новый тип системной информации может быть определен, чтобы указывать интервал действия или время истечения MI/SI. Одним возможным форматом является использование времени GPS или Всеобщего Скоординированного Времени (UTC). UE может получать время GPS и UTC из SIB16, чтобы устанавливать свой генератор импульсов реального времени. Тогда новый SIB–X может быть использован, чтобы указывать время GPS или UTC, в которое истечет текущая MI/SI. Формат SIB–X может быть аналогичен формату UTC, который используется в SIB16. Тем не менее, в SIB16 разрешение времени составляет 10мс. Применительно к SIB–X может быть использовано много более грубое разрешение времени, чтобы уменьшить число битов, требуемых для представления времени UTC. Одной возможностью является квантование времени UTC с помощью разрешения эквивалентного одному или нескольким циклам SFN. Также информация о времени UTC в SIB16 включает в себя информацию о годе и месяце. Применительно к SIB–X может не требоваться включение информации о годе и месяце.
[0047] UE может быть уведомлено об обновлении SIB–X через уведомление об обновлении SI. Такое уведомление об обновлении может быть особым для SIB–X.
[0048] UE получает флаг AB, SFN и H–SFN:
[0049] Требуется, чтобы уменьшение времени получения системы обеспечивало определенные конфигурации, чтобы поддерживать случаи использования, которые требуют длительного времени работы от батареи (например, 10–15 лет) и 10с времени ожидания для отправки отчета об исключении, такого как сигнал тревоги. Тем не менее не обязательно, чтобы решение учитывало случаи использования, при которых данные передаются только режем, чем раз в три дня, поскольку мы считаем, что для таких случаев использование время работы от батареи в 15 лет уже может быть достигнуто, без дальнейшего уменьшения времени получения системы. С учетом точности гетеродина в 20 миллионных долей, генератор импульсов UE может уходить примерно на ±5120мс за 3 дня. Таким образом, если UE возвращается в сеть через 3 дня, оно должно разрешить данную погрешность измерения времени. Это неопределенное окно совпадает с продолжительностью одного цикла SFN и, таким образом для разрешения погрешности измерения времени требуется 10 битов представления SFN. UE будет проходить через этапы синхронизации NPSS и NSSS и после этих двух этапов оно достигает синхронизации с кадрированием в 80–мс в структуре кадра системы, т.е. оно получает 3 LSB у SFN. Таким образом, если UE пропускает считывание MIB–NB, ему требуется получить 7 MSB битов для SFN, чтобы разрешить погрешность измерения времени. Добавляя флаг AB, в целом требуется, чтобы UE была предоставлена 8–битная информация.
[0050] Существует две альтернативы того, каким образом UE может получить такую информацию. Ниже мы предлагаем две альтернативы.
[0051] С использованием NPBCH
[0052] SFN и флаг AB предоставлены в MIB, который переносится к NPBCH. UE может считать все прочие элементы информации известными и концентрироваться только на декодировании SFN и флага AB. Известные биты информации могут быть использованы, чтобы отсекать решетку декодера Витерби и ожидается, что эффективность может быть значительно улучшена с помощью отсечения решетки. В действительность, UE также может проверять метку значения SI, если информация об интервале действия или времени истечения MI/SI, как обсуждалось в Разделе 5.1, не предоставлена.
[0053] Использование сигнала пробуждения или перехода в спящий режим
[0054] Сигнал «перехода в спящий режим» используется, чтобы указывать, что никакая информация управления нисходящей линии связи (DCI) не будет отправлена в течение следующего пространства поиска NPDCCH/MPDCCH. По приему такого сигнала UE переходит обратно в спящий режим. Тем не менее, если сигнал «перехода в спящий режим» не обнаружен, UE должно оставаться пробужденным, чтобы пытаться декодировать DCI, которая переносится в NPDCCH/MPDCCH.
[0055] С другой стороны сигнал «пробуждения» используется, чтобы указывать, что будет отправлена одна или более DCI в течение будущего пространства поиска NPDCCH/MPDCCH. По приему такого сигнала UE должно оставаться пробужденным, чтобы пытаться декодировать DCI, которая переносится в NPDCCH/MPDCCH. Тем не менее, если сигнал «пробуждения» не присутствует, UE может переходит в спящий режим. Сигнал «пробуждения» может быть отправлен в субкадре(ах) перед началом пространства поиска NPDCCH/MPDCCH или в начале пространства поиска NPDCCH/MPDCCH. Также не обязательно, чтобы сигнал «пробуждения» занимал один или несколько полных субкадров. Сигнал может использовать часть субкадров либо во временной, либо в частотной области, например, первые несколько символов в слоте или сочетание временной или частотной области.
[0056] На момент написания этого документа в 3GPP отсутствует решение в отношении того, будут ли использованы подходы сигнала «перехода в спящий режим» и/или сигнала «пробуждения». Тем не менее подход, описанный в данном документе, применяется несмотря на то, используется ли один или оба из этих подходов с сигналами.
[0057] Один случай использования сигнала «перехода в спящий режим» и/или сигнала «пробуждения» состоит в предоставлении указания UE того, поступит ли в следующей возможности поискового вызова DCI поискового вызова, в отношении которой UE должно осуществлять мониторинг. Вследствие этого ожидается, что сигнал «перехода в спящий режим» и/или сигнал «пробуждения» должен быть периодическим. В дополнение к указанию того, поступит ли в следующей возможности поискового вызова DCI поискового вызова, в отношении которой UE должно осуществлять мониторинг, мы может воспользоваться преимуществом периодичности сигнала «перехода в спящий режим» и/или сигнала «пробуждения», чтобы либо часть из 8 битов, либо все 8 битов были предоставлены в сигнале «перехода в спящий режим» и/или сигнале «пробуждения».
[0058] Альтернатива 1:
[0059] Вся 8–битная информация предоставляется всем UE вместе с указанием того, поступит ли в следующей возможности поискового вызова DCI поискового вызова, в отношении которой группа UE должна осуществлять мониторинг. Все UE могут прослушивать данный периодический сигнал «перехода в спящий режим» и/или сигнал «пробуждения» в отношении информации, в которой они заинтересованы, т.е. 8–битной информации, предоставленной выше. Применительно к UE, в отношении которых не осуществляется поисковый вызов в ближайшей возможности поискового вызова, они могут просто игнорировать указание связанной с поисковым вызовом информации.
[0060] Альтернатива 2:
[0061] Часть 8–битной информации предоставляется UE вместе с указанием, поступит ли в следующей возможности поискового вызова DCI поискового вызова, в отношении которой UE должно осуществлять мониторинг. Это может быть флаг AB или информация о временной привязке.
[0062] Альтернатива 3:
[0063] В дополнение к информации о флаге AB и временной привязке, метка значения SI, которая используется, чтобы указывать, изменились ли SIB, также может быть включена в сигнал «перехода в спящий режим» и/или сигнал «пробуждения». Обратите внимание, что также существует возможность включения только метки значения SI в сигнал «перехода в спящий режим» и/или сигнал «пробуждения».
[0064] Альтернатива 4:
[0065] В сигнал «перехода в спящий режим» и/или сигнал «пробуждения» мы может дополнительно включить указания для UE того, может ли оно пропустить считывание некоторых из SIB и/или MIB, когда в отношении него осуществляется поисковый вызов.
[0066] Альтернатива 5:
[0067] В сигнал «перехода в спящий режим» и/или сигнал «пробуждения» мы может дополнительно включить указания для UE того, когда в прошлый раз изменился MIB, например, используя отметку времени или номер версии других механизмов. Если UE имеет последнюю версию MIB, оно может пропустить считывание MIB.
[0068] Обратите внимание, что некоторые из вышеупомянутых альтернатив могут быть объединены вместе, чтобы также уменьшать время получения системы.
[0069] Расширить период модификации MIB и/или SIB:
[0070] В NB–IoT блок MasterInformationBlock–NB (MIB–NB) является фиксированным с периодичностью в 640мс и с L1 повторениями между ними, т.е. в каждом субкадре 0. MIB–NB отправляется по NPBCH. MIB–NB содержит:
– SFN (4 MSB бита)
– H–SFN (2 LSB бита)
– schedulingInfoSIB1
– systemInfoValueTag (изменение любого SIB отличного от MIB–NB/SIB14–NB/SIB16–NB)
– ab–Enabled (активированный/деактивированный запрет доступа, получение SIB14)
– operationModelnfo
[0071] Из–за 4 MSB битов у SFN в MIB–NB содержимое MIB–NB меняется каждые 640мс. Исключая SFN период модификации равен 40.96с.
[0072] Планирование SIB1–NB является фиксированным с периодичностью в 2.56с. Широковещательная передача SIB1–NB осуществляется в каждом втором субкадре 4. SIB1–NB отправляется по DL–SCH. Число повторений NPDSCH указывается в MIB–NB (schedulingInfoSIB1). SIB1–NB имеет период модификации в 40.96с, т.е. только после 40,96с содержимое SIB1–NB может меняться.
[0073] SIB отличные от SIB1–NB отправляются в SI–сообщениях, которые отправляются по DLSCH. Сообщение SI может содержать один или более SIB, как указывается в информации планирования в SIB1–NB.
[0074] Содержимое этих других SIB может меняться после периода модификации BCCH. Период модификации BCCH больше или равен 40.96с и указывается в SIB2–NB (modificationPeriodCoeff * defaultPagingCycle). Изменение SIB (содержимого и/или планирования) указывается посредством systemInfoValueTag в MasterInformationBlock–NB или systemInfoValueTagSI в SystemInformationBlockType1–NB.
[0075] Параметры Запрета Доступа в SIB14–NB могут меняться в любой момент времени (раздел 5.2.1.7 в TS 36.331 [6]), и такое изменение не вызывает последствий для systemInfoValueTag в MasterInformationBlock–NB или systemInfoValueTagSI в SystemInformationBlockType1–NB.
[0076] Не ожидается, что содержимое в других SIB часто меняется, за исключением SIB14–NB в течение периодов перегрузки.
[0077] Поскольку проблема, указанная в [3], состоит в том, что в некоторых случаях получение некоторых из SIB может занимать больше, чем 40.96с, то UE может столкнуться трудностями выполнения эффективного объединения по границе периода модификации.
[0078] Вследствие этого сеть будет основываться на потребностях в обеспечении более длительного периода модификации, чем 40.96с, который UE может предположить при декодировании MIB–NB, SIB1–NB и SIB2–NB. Напомним, что период модификации BCCH указывается в SIB2–NB. Конечно новые значения могут быть определены и просигнализированы UE. С учетом проблем обратной совместимости сеть может конфигурировать новые значения в нескольких из 40.96с. Это не будет иметь последствий для унаследованных NB–IoT UE, которые по–прежнему будут предполагать период модификации в 40.96с для MIB–NB и SIB1–NB.
[0079] Альтернатива 1:
[0080] Поскольку существует несколько резервных битов в MIB–NB, то мы может использовать некоторые из резервных битов, чтобы указывать, расширен ли период модификации в 40.96с, например, на несколько из 40.96с или другие значения, которые предпочитает сеть.
[0081] Альтернатива 2:
[0082] Мы может использовать один из SIB, чтобы указывать, расширен ли период модификации из 40.96с, например, на несколько из 40.96с или другие значения, которые предпочитает сеть.
[0083] Альтернатива 3:
[0084] Мы можем использовать одну из выделенной сигнализации для особой группы UE, чтобы указывать, расширен ли период модификации из 40.96с, например, на несколько из 40.96с или другие значения, которые предпочитает сеть.
[0085] Альтернатива 4:
[0086] Другие способы, чтобы указывать, расширен ли период модификации из 40.96с, например, на несколько из 40.96с или другие значения, которые предпочитает сеть.
[0087] В дополнение к альтернативе, перечисленной выше, для обеспечения гибкости в сети, сеть также будет информировать UE о том, является или нет активным расширенный период модификации.
[0088] Обратите внимание, что подход, перечисленный выше, обсуждался в контексте NB–IoT, но также может быть применен к LTE–M, который имеет отличный период модификации.
[0089] Как показано на Фиг. 1, UE 102 может находиться на связи с сетевым узлом 104 (например, базовой станцией, такой как, например, базовая станция LTE («eNB») или базовая станция 5G («gNB»). Например, UE 102 может осуществлять связь с сетевым узлом 104, используя шаблоны связи типа M2M, MTC или IoT. UE 102 может переходить в спящий режим, в котором оно активно не осуществляет связь с сетевым узлом 104, и может, по приглашению сетевого узла 104 или по своей собственной инициативе пробуждаться из его спящего режима и еще раз начинает осуществлять связь с сетевым узлом 104.
[0090] Фиг. 2 иллюстрирует способ 200, который может быть реализован в UE 102. UE 102 принимает основной блок информации (MIB) и/или блок системной информации (SIB) (этап 202). UE 102 принимает указание действия по меньшей мере фрагмента принятого MIB и/или SIB (этап 204). MIB переносится в Узкополосном Физическом Широковещательном Канале (NPBCH), SIB переносится в Узкополосном Физическом Совместно Используемом Канале Нисходящей Линии Связи (PDSCH) и указание указывает интервал действия или время истечения.
[0091] В соответствии с некоторыми вариантами осуществления указание находится в формате времени GPS или UTC и/или указание квантовано с разрешением, эквивалентным нескольким циклам Системного Номера Кадра (SFN). В некоторых вариантах осуществления способ дополнительно включает в себя прием уведомления об обновлении. В некоторых вариантах осуществления прием указания, содержит прием блока системной информации (SIB), содержащего указание.
[0092] В некоторых вариантах осуществления способ дополнительно включает в себя сохранение упомянутого по меньшей мере фрагмента MIB; после сохранения упомянутого по меньшей мере фрагмента MIB, переход в спящее состояние; после перехода в спящее состояние, пробуждение из спящего состояния; и в результате пробуждения из спящего состояния, определение на основании указания действия, является ли по–прежнему действительным сохраненный фрагмент MIB.
[0093] В некоторых вариантах осуществления способ дополнительно включает в себя, в результате определения того, что сохраненный фрагмент MIB является по–прежнему действительным, прием второго MIB, который переносится по NPBCH, и пропуск декодирования одного или более фрагментов принятого второго MIB, но декодирование одного или более других фрагментов принятого второго MIB. В некоторых вариантах осуществления, второй MIB содержит кодированную информацию о режиме работы, указывающую режим работы, и кодированный флаг запрета доступа (AB), UE декодирует кодированный флаг AB, и UE пропускает декодирование информации о режиме работы.
[0094] Фиг. 3 иллюстрирует способ 300, который может быть реализован в UE 102. UE 102 пробуждается из спящего состояния (этап 302). UE 102 определяет, требуется ли повторное получение фрагмента основного блока информации (MIB) и/или блока системной информации (SIB) (этап 304). UE 102 в ответ на определение того, что не требуется повторное получение фрагмента информации MIB и/или SIB, получает только оставшийся фрагмент информации MIB и/или SIB (этап 306).
[0095] В некоторых вариантах осуществления оставшийся фрагмент включает в себя информацию Системного Номера Кадра (SFN) и флага Запрета Доступа (AB). В некоторых вариантах осуществление получение только оставшегося фрагмента информации MI и/или SI включает в себя декодирование Основного Блока Информации (MIB), который переносится в Узкополосном Физическом Широковещательном Канале (NPBCH), и может дополнительно включать в себя использование фрагмента MI и/или SI, которые не требуется повторно получать, чтобы отсекать решетку, используемую в декодере Витерби.
[0096] В некоторых вариантах осуществления сигнал «пробуждения» и/или сигнал «перехода в спящий режим» используется, чтобы указывать, будет ли отправлена Информация Управления Нисходящей Линии Связи (DCI).
[0097] Фиг. 4 иллюстрирует способ 400, который может быть реализован в сетевом узле 104. Сетевой узел 104 передает MIB по NPBCH (этап 402). Сетевой узел 104 передает SIB по PDSCH (этап 404). Сетевой узел 104 передает указание действия по меньшей мере фрагмента переданного MIB и/или SIB. Указание действия указывает интервал или время истечения. В некоторых вариантах осуществления указание действия находится в формате времени GPS или UTC. В некоторых вариантах осуществления указание действия квантовано с разрешением равным нескольким циклам Системного Номера Кадра (SFN).
[0098] Пропуск получения SIB1–BR:
[0099] Применительно к LTE–M метка значения системы, в отличие от NB–IoT, располагается в SIB1–BR. UE, которое пробуждается из eDRX или PSM, вследствие этого, должно будет считать SIB–BR для того, чтобы выяснить, была ли обновлена SI, и должно ли оно повторно получать SI (либо полную информацию, либо SIB, как указано особыми для SI–сообщения valueTag в systemInfoValueTagList). Кроме того, UE возможно придется проверить, подвергается оно или нет запрету доступа. В LTE–M, доступ для UE не должен запрещаться в соответствии как с информацией ACB в SIB2, так и информацией расширенного запрета классов доступа (EAB) в SIB14. Обычно планирование и широковещательная передача SIB14 осуществляется только когда разрешен EAB, так что если это не так в соответствии с информацией планирования в SIB1–BR, то UE может интерпретировать это, как то, что доступ разрешен в соответствии с EAB. В большинстве случаев SI не обновлялась и UE не запрещено, тем не менее, UE по–прежнему должно осуществлять проверку, чтобы убедиться в том, что это так. При работе в соответствии с Редакцией 13 это означает, что UE должно считывать SIB1–BR и SIB2. Резервные биты в MIB могут быть использованы, тем не менее, чтобы сигнализировать UE о том, что UE может пропустить получение SIB1–BR.
[0100] Как описано выше маловероятно, что 3GPP согласует использование всех 5 резервных битов MIB на все будущее LTE для systemInfoValueTag, который уже присутствует в SIB1–BR. Вследствие этого решение применительно к eMTC по пропуску считывания SIB1–BR состоит в наличие короткого указания в MIB (например, однобитного флага). Данное коротко указание в MIB упоминается в данном документе как «указание MIB». Как правило UE должно пропускать считывание SIB1–BR во время повторного получения SI, поскольку SIB1–BR во многих случаях является существенным для доступа и, следовательно, требуется для первоначального доступа.
[0101] Так как SIB1–BR (и systemInfoValueTag в нем) обновляется редко, то выгодным является наличие указания MIB (например, флага), который установлен в 1, чтобы указывать, что SIB1–BR/systemInfoValueTag были обновлены в некоторый момент в течение определенного периода времени (например, в течение текущего периода времени или периода времени, непосредственно предшествующего текущему периоду), и установки указания MIB в 0, чтобы указывать иное (т.е. UE может пропускать считывание SIB1–BR, когда указание MIB установлено в 0, в противном случае UE не должно пропускать считывание SIB1–BR). Т.е., если SIB1–BR не был обновлен в течение определенного периода времени, что чаще всего и бывает, то указание MIB установлено в ‘0’ и UE может пропускать считывание SIB1–BR и systemInfoValueTag. Если присутствует последующее изменение SIB1–BR в течение периода времени, то указание MIB остается установленным в ‘1’ и не переключается обратно в ‘0’ (т.е. не так как valueTag). Указание MIB может быть сброшено в ‘0’ в границах периода времени (например, если отсутствовало изменение SIB1–BR в рамках последних X единиц времени (т.е. определенного периода времени)). Отметим, что поскольку valueTag системы и информация планирования SI–сообщений располагаются в SIB1–BR, то SIB1–BR будет обновлен, если обновляется любое из сообщений SI.
[0102] В некоторых вариантах осуществления, использующих указание MIB, UE требуется проверять указание MIB один раз за период времени указания MIB (например, в последний период модификации BCCH у периода времени). Т.е., если UE пропускает период времени, то SIB1–BR возможно был обновлен в течение того периода и это тогда не будет обнаружено UE. Период времени указания MIB может, например, быть любым из следующего, без ограничения:
[0103] 1) Период модификации BCCH. Период SIB1–BR тогда будет совпадать с периодом модификации для SI (отметим, что SI может быть обновлена 32 раза в течение данного периода, как задается valueTag системной информации, тогда как новый SIB1–BR не накладывает какого–либо ограничения на число обновлений, но с другой стороны выгодно, если только не было обновления). Эта временная привязка будет общей для всех UE.
[0104] 2) Период действия системной информации 3ч или 24ч. Поскольку UE требуется проверять MIB один раз в предварительно определенный период времени (например, по меньшей мере раз каждые 3 или 24 часа), если используется 1–битное указание, то преимущество этого состоит в том, что это значительно более длительный период, чем период модификации BCCH и, следовательно, UE требуется делать это гораздо реже.
[0105] 3) Период HSFN. Период времени основан на системном номере кадра (SFN) и/или гипер системном номере кадра (HSFN). Последнее более вероятно, поскольку более длительный период времени является более эффективным. 10 битов используется для SFN, что дает зацикливание SFN через 10.24 секунды. 10 битов используются для HSFN, что дает 1025 периодов SFN, что равно ~ 2.9 часа. Вероятным вариантом осуществления является использование 2n периодов SFN в качестве периода времени, где n является HSFN. Эта временная привязка будет общей для всех UE.
[0106] 4) На основании времени GPS или UTC, как предоставлено в SIB16. Эта временная привязка будет общей для всех UE.
[0107] UE в DRX или eDRX, которое находится в покрытии, будет полагаться на уведомление в поисковом вызове всякий раз, когда присутствует обновление SI, т.е. посредством проверки systemInfoModification или, если цикл eDRX длиннее периода модификации BCCH, то systemInfoModification–eDRX в сообщении поискового вызова. С помощью решений, описанных в данном документе, UE может потенциально вместо этого проверять указание MIB один раз за период времени (поскольку SIB1–BR содержит valueTag системы, то это потенциально менее энергоемко, чем попытка найти указание systemInfoModification по меньшей мере modificationPeriodCoeff раз в течение периода модификации (см. раздел 5.2.1.3 в 3GPP TS 36.331 v 14.2.2)). Кроме того, как объяснено в 3GPP TS 36.311, для UE с eDRX длиннее периода модификации BCCH, UE требуется считывать SIB1–BR перед доступом: «Когда для RRC_IDLE UE сконфигурирован цикл DRX, который длиннее периода модификации и по меньшей мере одна граница периода модификации прошла с того момента, когда UE последний раз верифицировало действие системной информации, то UE верифицирует, что сохраненная системная информация остается действительной, посредством проверки systemInfoValueTag до создания или возобновления соединения RRC».
[0108] В случае, когда не было обновления SI, UE, применяющему решения, описанные в данном документе, преимущественно требуется только получать MIB и проверять указание MIB и пропускать получение SIB1–BR.
[0109] Для UE в энергосберегающем режиме (PSM), UE будет находиться в энергосберегающем состоянии (суб–состояние для RRC_IDLE) и перед сигнализацией «проверки активности»/проверкой для данных нисходящей линии связи посредством периодического Обновления Зоны Отслеживания (TAU) или перед передачей данных восходящей линии связи, UE должно убедиться в том, что у него актуальная SI. При работе в соответствии с Редакцией 13 и 14 UE будет проверять, что оно уже получило актуальную SI посредством проверки valueTag (т.е. systemInfoValueTag) в SIB1–BR. С помощью решений, описанных в данном документе, UE может получать только MIB, чтобы проверять указание MIB и пропускать считывание SIB1–BR, если и только если время с момента последней передачи данных восходящей линии связи или периодического–TAU не превысило периода времени указания MIB (например, 3ч или 24ч) и указание MIB установлено в конкретное значение, которое может быть 0 или 1. Например, если период времени, выбранный для описанных решений, составляет зацикливание HSFN в 2.9ч, то UE не должно будет считывать SIB1–BR (в предположении, что его содержимое не было конечно обновлено), если для него сконфигурировано периодическое–TAU, которое короче 2.9ч. Вновь, в редком случае, когда SI была обновлена, UE будет просто продолжать считывать SIB1–BR как при работе в соответствии с Редакцией 13.
[0110] Пример функциональной возможности указания MIB приведен на Фиг. 5. В данном случае период времени основан на HSFN, использующем 2 HSFN бита, которые делают его длиной в 4096 радиокадров. Период модификации BCCH составляет здесь 1024 радиокадров. Как при работе в соответствии с Редакцией 13, UE уведомляются при поисковом вызове о том, когда SI должна быть обновлена, и широковещательная передача новой SI будет начинаться в последующем периоде модификации BCCH.
[0111] В целом указание MIB будет установлено в первое конкретное значение (например, 1) всякий раз, когда UE требуется считывать SIB1–BR, и установлено во второе конкретное значение (например, 0) в другом случае. Существуют альтернативные варианты осуществления того, каким образом это может быть выполнено. В варианте осуществления, показанном на Фиг. 5, указание устанавливается в 1, когда valueTag (т.е. systemInfoValueTag) меняется, и остается установленным в 1 в течение периодов времени, после которых SIB1–BR и SI были обновлены. В качестве альтернативы указание MIB может быть установлено в 1 даже до того, как SI обновляется, например, уже в предшествующем периоде модификации BCCH, в котором UE уведомляются при поисковом вызове о предстоящем обновлении SI (не показано на Фиг. 5). В вышеприведенном варианте осуществления, в котором указание MIB устанавливается в 1 в течение всего последующего периода времени, достаточно того, что UE проверяет указание MIB один раз за период времени и может делать это в любое время (т.е. если SI обновляется в конце периода времени после того, как UE проверило это, это все равно не останется незамеченным, так как UE заметит это в последующий период времени).
[0112] В одном альтернативном варианте осуществления от UE может потребоваться проверка указания MIB в течение последнего периода модификации BCCH (и конечно перед доступом, как всегда) и в этом случае указание MIB может всегда сбрасываться в ‘0’ на границах периода времени. Тем самым гарантируя то, что UE будет по–прежнему уведомляться об обновлении SIB1–BR, если он обновляется, в конце периода времени. Тем не менее, поскольку SI обновляется редко, преимущество данного варианта осуществления, вероятно, незначительно по сравнению с предыдущим и в целом будет лучше, чтобы указание MIB было установлено в ‘1’ на более длинный срок, чтобы избежать случаев ошибки (поскольку установка его в ‘1’ означает, что UE будут возвращаться к работе в соответствии с Редакцией 13). Вследствие этого в еще одном другом варианте осуществления указание MIB может быть установлено в ‘1’ более широко по времени до и после обновления SI и SIB1–BR. Например, указание MIB может быть установлено в ‘1’ в течение всего периода времени, предшествующего обновлению SI, и/или установлено в ‘1’ в течение всего периода времени во время обновления SI, и/или установлено в ‘1’ в течение всего периода времени после обновления SI.
[0113] Вышеупомянутые варианты осуществления используют 1–битное указание MIB, но возможны дополнительные варианты осуществления, использующие больше битов. Например, 2 бита могут быть использованы, чтобы указывать следующее:
Таблица 2
| Указание в MIB: | Интерпретация: |
| 00 | SIB1–BR не обновлялся за последний период времени (например, за последние 24 часа). |
| 01 | SIB1–BR не обновлялся за последние N1 периоды времени. |
| 10 | SIB1–BR не обновлялся за последние N2 периоды времени. |
| 11 | SIB1–BR не обновлялся за последние N3 периоды времени. |
[0114] В одном варианте осуществления период времени является периодом HSFN. Кроме того, Ni может быть линейным, например, N1=2, N2=3 и N3=4. В альтернативном варианте осуществления Ni может быть нелинейным, например, логарифмическим, таким как N1=2, N2=4 и N3=8, или N1=10, N2=100 и N3=1000. Это будет обеспечивать более тонкую степень разбиения информации, которая сообщается UE (UE будет сравнивать, когда оно в последний раз получало SI) и это может быть использовано для извлечения пользы за пределами периода HSFN в 2.9ч. Т.е., если согласовано базировать период времени на SFN, то UE будет обязано проверять указание в MIB по меньшей мере один раз каждые 2.9ч, но при использовании нескольких битов указания, как выше, это может быть расширено так, что UE, использующие PSM с очень длинным периодическим TAU (может быть сконфигурирован почти на 14 дней), могут поучать выгоду от решений, описанных в данном документе, и им будет требоваться получать MIB только при пробуждении, если обновление SI отсутствовало.
[0115] В некоторых дополнительных вариантах осуществления сам период времени, ассоциированный с 1–битным указанием, может быть установлен/модифицирован в сообщении системной информации. Аналогичным образом значение по меньшей мере одного из N1, N2 и N3 в примерном варианте осуществления 2–битного указания выше может быть модифицировано. Значения по умолчанию могут быть заданы стандартом и эти значения будут использоваться, если соответствующее модифицированное значение не предоставлено как часть широковещательной системной информации. Это увеличивает гибкость в сети для использования разных сценариев развертывания, конфигураций eDRX и PSM и т.д.
[0116] Отметим, что указание MIB является systemInfoValueTag–указанием в том смысле, что если меняется любое содержимое SIB1–BR, то обновляется systemInfoValueTag. Тем не менее, в еще одном другом варианте осуществления UE может по–прежнему пропускать получение SIB1–BR, несмотря на то, что systemInfoValueTag была обновлена. Т.е. первый бит, как указано выше, используется, чтобы указывать, что UE требуется получить SIB1–BR или оно может пропустить его, тогда как дополнительные биты указывают, что изменилось в SIB1–BR.
[0117] Дополнительные биты могут, например, указывать: (1) относится ли обновление к SI, отличной от SI, в отношении которой требуется поисковый вызов мониторинга (UE в eDRX, пробуждающиеся для проверки поискового вызова, тогда могут по–прежнему пропускать получение SIB1–BR); (2) относится ли обновление к SI, отличной от SI, которая требуется для доступа (UE, предпринимающие попытку произвольного доступа и Установки Соединения RRC и т.д., тогда могут по–прежнему пропускать получение SIB1–BR); (3) любые указанные (группа из) SIB. И если UE не требуется любое из этого, то оно может по–прежнему опускать считывание SIB1–BR.
[0118] Примерный процесс 600 для работы UE показан на Фиг. 6. Процесс 600 начинается, когда UE определяет, установлено ли указание MIB в конкретное значение (например, 0 или 1) (этап s602). Данное указание MIB может быть 1–битным указанием MIB, но также может включать в себя дополнительные биты, как описано более подробно выше. Если UE определяет, что указание MIB установлено в конкретное значение (например, 0), то UE может пропускать получение SIB1–BR (этап s604). Тем не менее, если UE определяет, что указание MIB не установлено в конкретное значение (например, установлено в 1), тогда UE будет получать SIB1–BR (этап s606).
[0119] Примерный процесс 700 для работы сетевого узла (например, eNB) показан на Фиг. 7. Примерный процесс 700 начинается, когда сетевой узел определяет, произошло ли обновление SIB1–BR в течение предыдущего или текущего периода времени (этап s702). Если не произошло, то не устанавливается указание MIB (этап s704). Если произошло, то сетевой узел устанавливает указание MIB (этап s706). В случае 1–битного указания MIB «установка указания MIB» будет соответствовать, например, установки его в значение ‘1’, а то, что оно не устанавливается будет соответствовать значению ‘0’. Отметим также, что логика того, когда оно должно быть установлено в ‘1’ посредством eNB, будет зависеть от вариантов осуществления, как обсуждалось выше. После этих этапов сетевой узел определяет, закончился ли период времени указания MIB (этап s708). Если не закончился, сетевой узел повторяет предыдущие этапы, определяя, произошло ли обновление SIB1–BR. Если период времени указания MIB закончился, указание MIB может быть сброшено сетевым узлом (этап s710). В соответствии с определенными вариантами осуществления этот сброс может зависеть от других факторов, включая прошлые и/или предстоящие обновления SIB1–BR.
[0120] Последствием для стандарта применительно к предложенным решениям будет текст процедуры для UE и обновленного содержимого MIB, для которых пример показан ниже (изменения представлены жирным шрифтом)
Таблица 3
|
MasterInformationBlock
–– ASN1START MasterInformationBlock ::= SEQUENCE { dl–Bandwidth ENUMERATED { n6, n15, n25, n50, n75, n100}, phich–Config PHICH–Config, systemFrameNumber BIT STRING (SIZE (8)), schedulingInfoSIB1–BR–r13 INTEGER (0..31), SIB1–indication BOOLEAN, Spare BIT STRING (SIZE (4)) } –– ASN1STOP |
[0121] Предложения, которые сделаны в данном документе, описаны применительно к eMTC, но будут в целом также применимы к другим системам, таким как LTE или NR (но не требуются для NB–IoT, поскольку там valueTag системы располагается непосредственно в MIB–NB).
[0122] В другом варианте осуществления однобитный флаг MIB может быть использован со следующим значением:
[0123] Бит, установленный в ‘0’=SI не обновлялась с последней границы периода модификации BCCH и запрет доступа (ACB или EAB) в настоящий момент не разрешен в соте.
[0124] Бит, установленный в ‘1’=SI обновилась с последней границы периода модификации BCCH и запрет доступа (ACB или EAB) в настоящий момент разрешен в соте.
[0125] Отметим, что это не valueTag и, если SI меняется второй раз, то бит не переключается обратно в значение ‘0’. В альтернативном варианте осуществления период времени для обновления SI отличается от периода модификации BCCH, например, несколько периодов модификации BCCH, период модификации SIB1–BR или время действия SI в 3ч/24ч.
[0126] В альтернативных вариантах осуществления несколько битов может быть использовано, чтобы указывать больше опций, например, в соответствии со следующим:
| Индекс: | Указание: |
| 00 | SI не обновляется и запрет доступ не разрешен. |
| 01 | SI обновляется, но запрет доступа не разрешен. |
| 10 | SI не обновляется, но запрет доступа разрешен. |
| 11 | SI обновляется и запрет доступа разрешен. |
[0127] В качестве альтернативы либо обновление SI, либо Запрет Доступа может быть опущен, или они могут быть указаны отдельными битами.
[0128] В качестве альтернативы данное указание может быть добавлено в сигнал пробуждения и сигнала перехода в спящий режим, как описано выше.
[0129] В соответствии с вышеупомянутым в одном аспекте предоставляется способ, который выполняется сетевым узлом (например, сетевым узлом 104) для уменьшения времени получения SI. В одном варианте осуществления способ включает в себя следующие этапы: (1) формирование MIB, содержащего однобитный флаг для указания того, изменилась или нет определенная SI (например, valueTag) с конкретного времени в прошлом (например, 24 часа назад, 3 часа назад и т.д.) и (2) передача MIB. В некоторых вариантах осуществления конкретное время в прошлом основано на текущем времени и периоде времени указания MIB (например, 3 или 24 часа). В некоторых вариантах осуществления конкретное время в прошлом является текущим временем минус период времени указания MIB. В других вариантах осуществления конкретное время в прошлом является определенной абсолютной границей периода времени.
[0130] В некоторых вариантах осуществления способ также включает в себя выполнение сетевым узлом следующих этапов: обновление определенной SI; установка флага изменения SI в первое значение, чтобы указать, что определенная SI изменилась; активация таймера, который истечет, когда истечет период времени указания MIB (например, 24 часа) с момента, когда был активирован таймер; если таймер истек, установка флага изменения SI во второе значение, чтобы указать, что определенная SI не изменилась в рамках периода времени указания MIB (например, в рамках прошлых 24 часов); и если определенная SI дополнительно обновляется в то время, пока таймер по–прежнему запущен, сброс таймера так, что таймер истечет, когда истечет период времени указания MIB с момента, когда таймер был сброшен. В данном варианте осуществления однобитный флаг, включенный в MIB, устанавливается равным значению флага изменения SI.
[0131] В другом аспекте предоставляется способ, который выполняется UE 102, для уменьшения времени получения SI. В одном варианте осуществления способ включает в себя прием UE MIB, содержащего однобитный флаг для указания, изменилась или нет определенная SI с конкретного времени в прошлом. Способ может дополнительно включать получение UE, после приема MIB, SIB, который содержит определенную SI (например, получение SIB1–BR), при этом UE получает SIB независимо от значения, в которое установлен флаг. Например, UE может получать SIB независимо от установки флага после того, как UE пробуждается из спящего режима и последний раз, когда UE получало конкретный SIB, был более X часов назад (например, X=3 или 24).
[0132] Способ может дополнительно включать в себя UE, принимающее, после получения SIB, последующего MIB, содержащего указание MIB, которое установлено в значение, которое указывает, что определенна SI не изменилась с конкретного момента времени в прошлом (например, указывающее, что SI не изменилась за последние X часов); UE, определяющее, может ли быть пропущено получение последующей SIB, при этом определение содержит UE, определяющее, что флаг установлен в конкретное значение; и после определения того, что получение последующего SIB может быть пропущено, UE, пропускающее получение последующего SIB, который содержит определенную SI. В некоторых вариантах осуществления конкретное время в прошлом основано на текущем времени и периоде времени указания MIB. В некоторых вариантах осуществления этап определения, может ли получение последующей SIB быть пропущено, включает в себя UE, определяющее, является ли текущая SI актуальной. В некоторых вариантах осуществления UE определяет, что SI является актуальной посредством определения того, что оно последний раз получало SI в рамках периода времени указания MIB.
[0133] Фиг. 8 является структурной схемой UE 102 в соответствии с некоторыми вариантами осуществления. Как показано на Фиг. 8, UE 102 может содержать: устройство 802 обработки данных (DPA), которое может включать в себя один или более процессоры 855 (P) (например, микропроцессор общего назначения и/или один или более другие процессоры, такие как проблемно–ориентированная интегральная микросхема (ASIC), программируемые вентильные матрицы (FPGA) и аналогичное); передатчик 805 и приемник 804, связанные с антенной 822, чтобы позволять UE 102 осуществлять передачу данных у и прием данных от узла AN (например, базовой станции); и локальный запоминающий блок 808 (также известный как «система хранения данных»), который может включать в себя одно или более энергонезависимые запоминающие устройства и/или одно или более энергозависимые запоминающие устройства (например, память с произвольным доступом (RAM)). В вариантах осуществления, где UE 102 включает в себя микропроцессор общего назначения, может быть предоставлен компьютерный программный продукт 841 (CPP). CPP 841 включает в себя машиночитаемый носитель 842 информации (CRM), хранящий компьютерную программу 843 (CP), содержащую машиночитаемые инструкции 844 (CRI). CRM 842 может быть не временным машиночитаемым носителем информации, таким как, но не ограничиваясь, магнитные носители информации (например, жесткий диск), оптические носители информации, устройства памяти (например, память с произвольным доступом) и аналогичное. В некоторых вариантах осуществления CRI 844 компьютерных программ 843 сконфигурированы так, что когда исполняются устройством 802 обработки данных, CRI предписывают UE 102 выполнять этапы, описанные выше (например, этапы, описанные выше при обращении к блок–схемам). В других вариантах осуществления UE 102 может быть выполнено с возможностью выполнения этапов, описанных в данном документе, без необходимости в коде. Т.е., например, устройство 802 обработки данных может состоять лишь из одной или более ASIC. Следовательно, признаки вариантов осуществления, описанных в данном документе, могут быть реализованы в аппаратном обеспечении и/или программном обеспечении.
[0134] Фиг. 9 является структурной схемой сетевого узла 104 в соответствии с некоторыми вариантами осуществления. Как показано на Фиг. 9 узел 104 может содержать: устройство 902 обработки данных (DPA), которое может включать в себя один или более процессоры 955 (P) (например, микропроцессор общего назначения и/или один или более другие процессоры, такие как проблемно–ориентированная интегральная микросхема (ASIC), программируемые вентильные матрицы (FPGA) и аналогичное); сетевой интерфейс 948, содержащий передатчик 945 (Tx) и приемник 947 (Rx), чтобы позволять узлу 104 осуществлять передачу данных к и прием данных от других узлов, соединенных с сетью 110 (например, сетью Интернет Протокола (IP)), с которой соединен сетевой интерфейс 948; схему 903 (например, радиосхему приемопередатчика), связанную с антенной системой 904 для беспроводной связи с UE); и локальный запоминающий блок 908 (также известный как «система хранения данных», который может включать в себя одно или более энергонезависимые запоминающие устройства и/или одно или более энергозависимые запоминающие устройства (например, память с произвольным доступом (RAM)). В вариантах осуществления, где узел 104 включает в себя микропроцессор общего назначения, может быть предоставлен компьютерный программный продукт 941 (CPP). CPP 941 включает в себя машиночитаемый носитель 942 информации (CRM), хранящий компьютерную программу 943 (CP), содержащую машиночитаемые инструкции 944 (CRI). CRM 942 может быть не временным машиночитаемым носителем информации, таким как, но не ограничиваясь, магнитные носители информации (например, жесткий диск), оптические носители информации, устройства памяти (например, память с произвольным доступом) и аналогичное. В некоторых вариантах осуществления CRI 944 компьютерной программы 943 сконфигурированы так, что когда исполняются устройством 902 обработки данных, CRI предписывают узлу 104 выполнять этапы, описанные выше (например, этапы, описанные выше при обращении к блок–схемам). В других вариантах осуществления узел 104 может быть выполнен с возможностью выполнения этапов, описанных в данном документе, без необходимости в коде. Т.е., например, устройство 902 обработки данных может состоять лишь из одной или более ASIC. Следовательно, признаки вариантов осуществления, описанных в данном документе, могут быть реализованы в аппаратном обеспечении и/или программном обеспечении.
[0135] Дополнительные варианты осуществления:
[0136] A1. Способ, который выполняется оборудованием пользователя (UE), содержащий этапы, на которых: принимают основной блок информации (MIB) и/или блок системной информации (SIB); принимают указание действия по меньшей мере фрагмента принятого MIB и/или SIB, при этом упомянутый MIB переносится в Узкополосном Физическом Широковещательном Канале (NPBCH), при этом упомянутый SIB переносится в Узкополосном Физическом Совместно Используемом Канале Нисходящей Линии Связи (PDSCH), и при этом упомянутое указание указывает интервал действия или время истечения.
[0137] A2. Способ по варианту A1 осуществления, в котором указание находится в формате времени GPS или UTC.
[0138] A3. Способ по любому из вариантов A1–A2 осуществления, в котором указание квантовано с разрешением, эквивалентным нескольким циклам Системного Номера Кадра (SFN).
[0139] A4. Способ по любому из вариантов A1–A3 осуществления, дополнительно содержащий этап, на котором принимают уведомление об обновлении.
[0140] A5. Способ по любому из вариантов A1–A4 осуществления, в котором этап, на котором принимают указание, содержит этап, на котором принимают блок системной информации (SIB), содержащий указание.
[0141] A6. Способ по любому из вариантов A1–A5 осуществления, дополнительно содержащий этапы, на которых: сохраняют упомянуты по меньшей мере фрагмент MIB; после сохранения упомянутого по меньшей мере фрагмента MIB, входят в спящее состояние; после входа в спящее состояние, пробуждаются из спящего состояния; и в результате пробуждения из спящего состояния, определяют на основании указания действия, является ли по–прежнему действительным сохраненный фрагмент MIB.
[0142] A7. Способ варианта A6 осуществления, дополнительно содержащий этапы, на которых: в результате определения того, что сохраненный фрагмент MIB по–прежнему является действительным, принимают второй MIB, который переносится по NPBCH, и пропускают декодирование одного или более фрагментов принятого второго MIB, но декодируют один или более другие фрагменты принятого второго MIB.
[0143] A8. Способ по пункту A7, в котором второй MIB содержит кодированную информацию о режиме работы, указывающую режим работы, и кодированный флаг запрета доступа (AB), UE декодирует закодированный флаг AB, и UE пропускает декодирование информации о режиме работы.
[0144] B1. Способ, который выполняется оборудованием пользователя (UE), содержащий этапы, на которых: пробуждаются из спящего состояния; определяют, требуется ли повторное получение фрагмента основного блока информации (MIB) и/или блока системной информации (SIB); в ответ на определение того, что не требуется повторное получение фрагмента информации MIB и/или SIB, получают только оставшийся фрагмент информации MIB и/или SIB.
[0145] B2. Способ варианта B1 осуществления, в котором оставшийся фрагмент включает в себя информацию Системного Номера Кадра (SFN) и флаг Запрета Доступа (AB).
[0146] B3. Способ по любому из вариантов B1–B2 осуществления, в котором этап, на котором получают только оставшийся фрагмент информации MI и/или SI, включает в себя этап, на котором декодируют Основной Блок Информации (MIB), который переносится по Узкополосному Физическому Широковещательному Каналу (NPBCH).
[0147] B4. Способ варианта B3 осуществления, в котором этап, на котором декодируют, дополнительно включает в себя этап, на котором используют фрагмент MI и/или SI, который не требуется повторно получать, чтобы отсекать решетку, используемую в декодере Витерби.
[0148] B5. Способ по любому из вариантов B1–B2 осуществления, в котором сигнал «пробуждения» и/или сигнал «перехода в спящий режим» используется, чтобы указывать, будет ли отправлена Информация Управления Нисходящей Линии Связи (DCI).
[0149] C1. Оборудование пользователя, UE, при этом UE выполнено с возможностью: приема основного блока информации (MIB), который переносится в Узкополосном Физическом Широковещательном Канале (NPBCH), и/или блока системной информации (SIB), который переносится в Узкополосном Физическом Совместно Используемом Канале Нисходящей Линии Связи (PDSCH); и приема указания действия по меньшей мере фрагмента принятого MIB и/или SIB, при этом упомянутое указание указывает интервал действия или время истечения.
[0150] D1. Оборудование пользователя, UE, причем UE, содержащее: первый принимающий модуль, выполненный с возможностью использования приемника, чтобы принимать, по меньшей мере одно из следующего: (1) основной блок информации (MIB), который переносится в Узкополосном Физическом Широковещательном Канале (NPBCH) и/или блок системной информации (SIB), который переносится в Узкополосном Физическом Совместно Используемом Канале Нисходящей Линии Связи (PDSCH) и; второй принимающий модуль, выполненный с возможностью использования приемника, чтобы принимать указание действия по меньшей мере фрагмента принятого MIB и/или SIB, при этом упомянутое указание указывает интервал действия или время истечения.
[0151] E1. Оборудование пользователя, UE, причем UE, содержащее: приемник; передатчик; систему хранения данных; и устройство обработки данных, содержащее процессор, при этом устройство обработки данных связано с системой хранения данных, передатчиком и приемником, и устройство обработки данных выполнено с возможностью: использования приемника, чтобы принимать, по меньшей мере одно из следующего: (1) основной блок информации (MIB), который переносится в Узкополосном Физическом Широковещательном Канале (NPBCH) и/или блок системной информации (SIB), который переносится в Узкополосном Физическом Совместно Используемом Канале Нисходящей Линии Связи (PDSCH) и; использования приемника, чтобы принимать указание действия по меньшей мере фрагмента принятого MIB и/или SIB, при этом упомянутое указание указывает интервал действия или время истечения.
[0152] F1. Оборудование пользователя, UE, при этом UE выполнено с возможностью: пробуждения из спящего состояния; определения, требуется ли повторное получение фрагмента основного блока информации (MIB) и/или блока системной информации (SIB); и в ответ на определение того, что не требуется повторное получение фрагмента информации MIB и/или SIB, получения только оставшегося фрагмента информации MIB и/или SIB.
[0153] G1. Оборудование пользователя, UE, причем UE, содержащее: модуль пробуждения для пробуждения из спящего состояния; модуль определения для определения, требуется ли повторное получение фрагмента основного блока информации (MIB) и/или блока системной информации (SIB); и модуль декодирования, для декодирования только оставшегося фрагмента информации MIB и/или SIB в ответ на определение того, что не требуется повторное получение фрагмента информации MIB и/или SIB.
[0154] H1. Оборудование пользователя, UE, причем UE, содержащее: приемник; передатчик; систему хранения данных; и устройство обработки данных, содержащее процессор, при этом устройство обработки данных связано с системой хранения данных, передатчиком и приемником, и устройство обработки данных выполнено с возможностью: пробуждения из спящего состояния; определения, требуется ли повторное получение фрагмента основного блока информации (MIB) и/или блока системной информации (SIB); и в ответ на определение того, что не требуется повторное получение фрагмента информации MIB и/или SIB, получения только оставшегося фрагмента информации MIB и/или SIB.
[0155] I1. Способ, который выполняется сетевым узлом (например, базовой станцией), причем способ, содержащий этапы, на которых: передают MIB по NPBCH; передают SIB по PDSCH; передают указание действия по меньшей мере фрагмента переданного MIB и/или SIB, при этом указание действия указывает интервал действия или время истечения.
[0156] I2. Способ варианта I1 осуществления, в котором указание находится в формате времени GPS или UTC.
[0157] I3. Способ по любому из вариантов I1–I2 осуществления, в котором указание действия квантовано с разрешением, эквивалентным нескольким циклам Системного Номера Кадра (SFN).
[0158] J1. Сетевой узел, при этом сетевой узел выполнен с возможностью: передачи MIB по NPBCH; передачи SIB по PDSCH; передачи указания действия по меньшей мере фрагмента переданного MIB и/или SIB, при этом указание действия указывает интервал действия или время истечения.
[0159] K1. Сетевой узел, причем сетевой узел, содержащий: первый передающий модуль для использования передатчика, чтобы передавать MIB по NPBCH; второй передающий модуль для использования передатчика, чтобы передавать SIB по PDSCH; первый передающий модуль для использования передатчика, чтобы передавать указание действия по меньшей мере фрагмента переданного MIB и/или SIB, при этом указание действия указывает интервал действия или время истечения.
[0160] L1. Сетевой узел, причем сетевой узел, содержащий: приемник; передатчик; систему хранения данных; и устройство обработки данных, содержащее процессор, при этом устройство обработки данных связано с системой хранения данных, передатчиком и приемником, и устройство обработки данных выполнено с возможностью: передачи MIB по NPBCH; передачи SIB по PDSCH; передачи указания действия по меньшей мере фрагмента переданного MIB и/или SIB, при этом указание действия указывает интервал действия или время истечения.
[0161] Несмотря на то, что различные варианты осуществления настоящего изобретения описаны в данном документе (включая приложения, если таковые имеются), следует понимать, что они были представлены только в качестве примера, а не ограничения. Таким образом степень прав или притязаний и объем настоящего изобретения не должны ограничиваться любым из описанных выше примерных вариантов осуществления. Например, тогда как многие из вышеупомянутых вариантов осуществления описаны с использованием NB–IoT или LTE–M в качестве примеров, варианты осуществления не ограничиваются любой конкретной технологией или стандартом и, таким образом, вариант осуществления может быть применен к другой технологии, как, впрочем, и любым другим стандартам связи, таким как, например, NR. Более того, любое сочетание описанных выше вариантов осуществления во всех их возможных вариациях охватывается изобретением, если иное не указано в данном документе или явно не противоречит контексту.
[0162] Дополнительно, в то время как процессы, описанные выше и проиллюстрированные на чертежах, показаны как последовательность этапов, это было сделано исключительно ради иллюстрации. Соответственно предполагается, что некоторые этапы могут быть добавлены, некоторые этапы могут быть опущены, очередность этапов может быть переупорядочена и некоторые этапы могут быть выполнены параллельно.
[0163] По данной заявке испрашивается приоритет на основании предварительной заявки № 62/502,423, поданной 05 мая 2017 г., причем заявка включает в себя приложение, содержащее текст статьи для публикации 3GPP. Определенные фрагменты данной статьи для публикации воспроизводятся ниже:
[0164] 1. Введение
[0165] В Rel–15 согласован рабочий вопрос (WI) в отношении улучшения NB–IoT. Цель состоит в дальнейшем улучшении эффективности NB–IoT посредством дальнейшего уменьшения времени ожидания и энергопотребления, повышения точности измерения, улучшения надежности и диапазона NPRACH, уменьшения времени получения системы и т.д. [00206]. Посредством уменьшения времени получения системы могут быть дополнительно улучшены время ожидания и эффективность NB–IoT.
[0166] На заседании RAN1#88bis, касательно уменьшения времени получения системы, было достигнуто соглашение о том, что могут быть рассмотрены по меньшей мере следующие кандидаты.
– Улучшение(ия) NPSS/NSSS
– Улучшение(ия) MIB–NB
– Накопление SIB1–NB по нескольким SIB1–NB TTI (с или без последствий для спецификации)
– Новый механизм, позволяющий пропускать считывание SIB1–NB и/или сообщения SI и/или MIB–NB
– Дополнительный SIB1–NB передается по другим субкадрам в дополнение к существующей передаче SIB1–NB
– Использование физического сигнала/канала в пункте повестки 7.2.7.1.1 (если введен). Примечание: Это рассматривается сигнал пробуждения или сигнал перехода в спящий режим.
– FFS по другим SIBx–NB
– Подробности всех решений FFS
– Решения должны быть обратно совместимы и учитывать последствия для сетей Rel–13/Rel–14:
[0167] 2. Общее обсуждение
[0168] Среди трех режимов развертывания NB–IoT, внутриполосное развертывание требует более длительного времени получения системы из–за более низкого уровня мощности передачи и выкалывания, которое может происходить по ресурсам NPSS и NSSS. Дополнительно, при внутриполосном режиме, NPDSCH, который несет SIB1–NB или сообщения SI, обладает меньшим числом элементов ресурсов в субкадре из–за ресурсов, взятых LTE CRS, или зарезервированных для области управления нисходящей линии связи LTE, в сравнении с автономным режимом и режимом в защитной полосе. Это приводит к более высокой скорости кодирования и таким образом более низкой эффективности кодирования. Таким образом улучшение в отношении уменьшения времени получения системы в первую очередь следует направить на внутриполосный режим. Решения, которые могут уменьшить время получение системы для внутриполосного режима, могут быть непосредственно применены к режиму в защитной полосе и автономному режиму.
[0169] Наблюдение 1: Улучшение в отношении уменьшения времени получения системы в первую очередь следует направить на внутриполосный режим. Решения, которые могут уменьшить время получение системы для внутриполосного режима, могут быть непосредственно применены к режиму в защитной полосе и автономному режиму.
[0170] Процесс получения системы после того, как UE пробуждается из глубокого сна, включает в себя следующие этапы: (1) Синхронизация с NPSS; (2) Синхронизация с NSSS; (3) Получение MIB–NB посредством приема NPBCH. UE может проверять метку значения системной информации (SI) и флаг запрета доступа (AB) в MIB–NB. Если метка значения SI не изменилась и флаг AB не задействован, то UE завершает процесс получения системы.
[0171] Поскольку MIB–NB и SI редко меняются (за исключением SIB–14 и SIB–16), и несмотря на то, что флаг AB может переключаться динамически, он установлен в значение ложь чаще, чем в значение истина, то в большинстве случаев UE требуется только пройти через эти три этапа в большинстве случаев после того, как оно пробуждается из глубокого сна. Одной из возможных оставшихся неопределенностей является номер гипер–SFN (H–SFN). Несмотря на то, MIB–NB содержит два LSB у H–SFN, полный H–SFN получается только когда получается SIB1–NB. С учетом отклонения частоты в 20 миллионных долей, когда UE находится в глубоком сне, у генератора импульсов UE отклонение на один цикл SFN займет 50000 циклов SFN (т.е. 1024 SFN или 1 H–SFN), или эквивалентно 200000 циклов SFN в спящем режиме для отклонения генератора импульсов UE на 4 цикла SFN (т.е. 4 H–SFN). Если отклонение составляет более 4 циклов SFN, то UE требуется получить больше двух LSB у H–SFN и, вследствие этого, требуется получить SIB1–NB. Тем не менее, 200000 циклов SFN составляют приблизительно 23.7 дня. Если время ожидания является важным для любого из случаев использования, которые поддерживает UE, то чтобы избежать потребность в получении SIB1–NB только ради разрешения неопределенности временной привязки, для UE должен быть сконфигурирован PSM с интервалом TAU, установленным меньше чем 23.7 дня. Таким образом, Rel–15 должна быть сконцентрирована на улучшении получения NPSS, NSSS и NPBCH. Среди этих трех этапов, самым простым является получение NSSS. Между NPSS и NPBCH, NPBCH является относительно очевидным и оказывает меньшее воздействие на сложность UE и обратную совместимость. Мы предлагаем, чтобы Rel–15 сначала сконцентрировалась на улучшении эффективности NPBCH.
[0172] Предложение 1: Rel–15 должна сначала сфокусироваться на улучшении эффективности NPBCH.
[0173] Применительно к внутриполосному развертыванию, суммарные потери по несущей привязки Rel–13 NB–IoT могут быть очень высокими, как иллюстрируется в примере в Таблице 4. Как видно, процент элементов ресурсов доступных для символов NPDCCH/NPDSCH, за исключением тех, что несут SIB1–NB, может быть всего 42% в сценарии наихудшего случая (внутриполосное, 3 OFDM– символа для LTE PDCCH и 4 порта CRS). Использование большего числа повторений NPBCH дополнительно уменьшит процент элементов ресурсов, доступных для NPDCCH/NPDSCH.
Таблица 4
Потери и процент элементов ресурсов, доступных для NPDCCH/NPDSCH по несущей привязки Rel–13. (внутриполосное, 3 OFDM– символа для LTE PDCCH и 4 порта CRS)
| потери из–за LTE | 31.0% |
| потери из–за NPBCH | 6.0% |
| потери из–за NPSS | 6.9% |
| потери из–за NSSS | 3.5% |
| потери из–за NRS | 8.1% |
| SIB1–NB | 3.0% |
| суммарные потери | 58.3% |
| процент элементов ресурсов доступных для NPDSCH/NPDCCH | 41.7% |
[0174] Наблюдение 2: По несущей привязки Rel–13 NB–IoT процент элементов ресурсов доступных для символов NPDCCH/NPDSCH, за исключением тех, что несут SIB1–NB, составляет только 42% в сценарии наихудшего случая (внутриполосное, 3 OFDM– символа для LTE PDCCH и 4 порта CRS). Использование большего числа повторений NPBCH дополнительно уменьшит процент элементов ресурсов, доступных для NPDCCH/NPDSCH.
[0175] В оставшейся части данного документа мы концентрируемся на решениях для уменьшения времени получения NPBCH, которые (1) не несут значительных дополнительных потерь по несущей привязки NB–IoT (2) является преимущественными для внутриполосного режима. Рассмотренные решения включают в себя (1) более сложные приемники и (2) Новый механизм, позволяющий пропускать считывание MIB–NB и SIB1–NB.
[0176] 3. Более сложные приемники
[0177] В [2] были рассмотрены меж–субкадровая оценка канала и усовершенствованная методика декодирования MIB–NB. В то время как меж–субкадровая оценка канала и ее преимущества хорошо понятны, методика усовершенствованного декодирования MIB–NB [3] может потребовать дополнительного обсуждения. В данном разделе мы обсуждает методику усовершенствованного декодирования MIB–NB, которая позволяет UE совместно декодировать принятые сигналы NPBCH по нескольким 640–мс NPBCH TTI.
[0178] Процесс кодирования MIB–NB иллюстрируется на Фиг. 10. MIB–NB составляет 34 бита в длину и первые 6 битов состоят из 4 MSB у SFN и 2 LSB у H–SFN. Кодер CRC добавляет 16 битов CRC, к которым позже применяются маска, которая зависит от числа портов антенны, используемых для передачи NPBCH. После кодирования и маскирования CRC 50–битная последовательность кодируется с помощью TBCC, чтобы создать кодовое слово из 150 битов, которые на основании алгоритма согласования скорости LTE формируют 1600–битное кодовое слово NPBCH. На стороне приемника UE может сначала отменять согласование скорости и таким образом основной проблемой является использование декодера TBCC, чтобы обрабатывать 150 битные мягкие значения и создавать декодированную битовую последовательность.
[0179] Важным свойством кода для использования является то, что как CRC код, так и TBCC код являются линейными кодами. Напомним, что если x1 и x2 являются двумя векторами информации по GF(2) и C является линейным кодом так, что C(xi)=wi, тогда C(x1+x2)=w1+w2. При использовании такого свойства линейного кода, совместное декодирование по нескольким NPBCH TTI может быть легко выполнено, в предположении, что содержимое информации MIB–NB, которое меняется по TTI, является 6 битами информации SFN и H–SFN. Мы иллюстрируем то, как это работает, ниже.
[0180] Предположим, что 6 битами информации SFN и H–SFN в первом TTI являются (s6,s7,s8,s9,h0,h1) = (0,0,0,0,0,0), и вследствие этого в последующем TTI она соответствует (1,0,0,0,0,0). Здесь мы используем (s6,s7,s8,s9) и (h0,h1) для представления 4 MSB у SFN и 2 LSB у H–SFN, соответственно. Разность между двумя векторами информации MIB–NB (34 бита каждый) в двух последовательных TTI соответствует xΔ=(1,0,0, … 0). С использованием свойств линейного кода разница в кодовых словах TBCC, обозначенная как wΔ, может быть вычислена с использованием процесса, проиллюстрированного на Фиг. 11. Отметим здесь, что в сравнении с Фиг. 10, маскирование CRC не требуется, поскольку оно исчезает после получения разницы между двумя кодовыми словами. wΔ можно рассматривать как дополнительную маску скремблирования, которая применяется к кодовому слову во 2–ом TTI, по отношению к кодовому слову в первом TTI. Таким образом, чтобы использовать два принятых кодовых слова для совместного декодирования, приемник может дескремблировать второе принятое кодовое слово, используя wΔ, и мягко объединять с первым кодовым словом. Отметим, что такая методика может быть расширена на использование более двух TTI для совместного декодирования за счет увеличения требований к мягкому буферу.
[0181] Применительно к MIB–NB, шесть битов счетчика кадра (s6,s7,s8,s9,h0,h1) имеют 64 комбинации, но приводят только к шести разным векторам xΔ, и вследствие этого к шести разным векторам wΔ. Это иллюстрируется в Таблице 5. В Таблице 5 мы выделили синим первый раз, когда появляется новый вектор xΔ. Как видно, много значений счетчика кадра совместно используют один и тот же вектор xΔ.
[0182] Шесть разных векторов wΔ требует, чтобы принятые кодовые слова по двум TTI объединялись 6 разными способами. Таким образом, память декодера увеличивается со 150 бит мягких значений до 900 бит мягких значений при объединении по двум TTI. Тем не менее сложность декодера является точно такой же как у нормального декодера TBCC в том, что число состояний решетки остается равным 64 и каждое состояние имеет две исходящие ветви и две входящие ветви. Единственное отклонение заключается в том, что вычисление метрики ветвления должно быть основано на надлежащем образом выбранной версии объединенного принятого кодового слова. Для конкретного состояния процесс определения того, какую версию объединенного принятого кодового слова использовать, тем не менее, является детерминистическим и не включает дополнительные гипотезы.
Таблица 5
Отношение между значением счетчика кадров и xΔ. Несмотря на то, что присутствует 64 возможных значения счетчика кадров, существует только 6 возможных векторов xΔ.
| (s6,s7,s8,s9,h0,h1) в первом TTI | (s6,s7,s8,s9,h0,h1) во втором TTI | xΔ (вектор 34 длина) |
| (0,0,0,0,0,0) | (1,0,0,0,0,0) | (1,0,…,0) |
| (1,0,0,0,0,0) | (0,1,0,0,0,0) | (1,1,0,…,0) |
| (0,1,0,0,0,0) | (1,1,0,0,0,0) | (1,0,…,0) |
| (1,1,0,0,0,0) | (0,0,1,0,0,0) | (1,1,1,0,…,0) |
| (0,0,1,0,0,0) | (1,0,1,0,0,0) | (1,0,0,…,0) |
| (1,0,1,0,0,0) | (0,1,1,0,0,0) | (1,1,0,…,0) |
| (0,1,1,0,0,0) | (1,1,1,0,0,0) | (1,0,…,0) |
| (1,1,1,0,0,0) | (0,0,0,1,0,0) | (1,1,1,1,0, …,0) |
| ........ | ........ | ........ |
| (1,1,1,1,0,0) | (0,0,0,0,1,0) | (1,1,1,1,1,0, …,0) |
| ........ | ........ | ........ |
| (1,1,1,1,1,0) | (0,0,0,0,0,1) | (1,1,1,1,1,1,1, …,0) |
[0183] Наблюдение 3: Используя свойства линейного кода у CRC и TBCC, совместное декодирование по нескольким NPBCH TTI может быть выполнено посредством простого применения надлежащей маски дескремблирования к битовым мягким значениям перед объединением кодовых слов TBCC по нескольким TTI.
[0184] Использование более сложных приемников NPBCH является наиболее привлекательным решением, поскольку оно не требует дополнительной сигнализации и таким образом не вызывает каких–либо дополнительных потерь на сигнализацию.
[0185] 4. Механизм, позволяющий пропускать считывание MIB–NB и SIB1–NB
[0186] Поскольку MIB–NB и SI меняются редко (за исключением SIB14–NB и SIB16), то один способ обеспечения пропуска повторного получения MIB–NB и SI, которые останутся неизменными, состоит в том, чтобы eNB указывал интервал действия или время истечения информации MIB–NB и SI. В нижеследующем обсуждении мы будет предполагать, что изменения флага AB, SIB14–NB, SIB16, SFN и H–SFN не используются, чтобы определять интервал действия или время истечения MI/SI. С помощью такого указания, если UE пробуждается в рамках периода действия MI/SI с версией, которая была получена ранее, то отсутствует необходимость повторного получения той же самой информации. В таких сценариях UE требуется только получать флаг AB, SFN и H–SFN. Чтобы поддерживать данный способ существует две проблемы, которые должны быть решены: 1) Каким образом сеть сигнализирует интервал действия или время истечения MI/SI? и 2) Каким образом UE получает флаг AB, SFN и H–SFN без получения полного MIB–NB и SIB1–NB?
[0187] 4.1 Сигнализация интервала действия или времени истечения MI/SI
[0188] Возможно есть много способов, которые могут быть использованы, чтобы сигнализировать интервал действия или время истечения MI/SI. Вот некоторые возможные решения.
[0189] 4.1.1 Новый тип системной информации может быть определен, чтобы указывать интервал действия или время истечения MI/SI. Одним возможным форматом является использование времени GPS или Всеобщего Скоординированного Времени (UTC). UE может получать время GPS и UTC из SIB16, чтобы устанавливать свой генератор импульсов реального времени. Тогда новый SIB–X может быть использован, чтобы указывать время GPS или UTC, в которое истечет текущая MI/SI. Формат SIB–X может быть аналогичен формату UTC, который используется в SIB16. Тем не менее, в SIB16 разрешение времени составляет 10мс. Применительно к SIB–X может быть использовано много более грубое разрешение времени, чтобы уменьшить число битов, требуемых для представления времени UTC. Одной возможностью является квантование времени UTC с помощью разрешения эквивалентного одному или нескольким циклам SFN. Также информация о времени UTC в SIB16 включает в себя информацию о годе и месяце. Применительно к SIB–X может не требоваться включение информации о годе и месяце.
[0190] 4.1.2 UE может быть уведомлено об обновлении SIB–X через уведомление об обновлении SI. Такое уведомление об обновлении может быть особым для SIB–X.
[0191] Предложение 2: Рассматривается сигнализация посредством eNB интервала действия или времени истечения MI/SI. Действие или время истечения MI/SI не затрагивается изменениями флага AB, SFN и H–SFN. Точным способом сигнализации является FFS.
[0192] 4.2 UE получает флаг AB, SFN и H–SFN
[0193] Требуется, чтобы уменьшение времени получения системы обеспечивало определенные конфигурации, чтобы поддерживать случаи использования, которые требуют длительного времени работы от батареи (например, 10–15 лет) и 10с время ожидания для отчета об Исключении [4]. Тем не менее не обязательно, чтобы решение учитывало случаи использования, при которых данные передаются только режем, чем раз в три дня. Для случаев использования сочень редкими передачами данных время работы от батареи в 15 лет уже может быть достигнуто, без дальнейшего уменьшения времени получения системы. С учетом точности гетеродина в 20 миллионных долей, генератор импульсов UE может уходить примерно на ±5120мс за 3 дня. Таким образом, если UE возвращается в сеть через 3 дня, оно должно разрешить данную погрешность измерения времени. Это неопределенное окно совпадает с продолжительностью одного цикла SFN и, таким образом для разрешения погрешности измерения времени требуется 10 битов представления SFN. UE будет проходить через этапы синхронизации NPSS и NSSS и после этих двух этапов оно достигает синхронизации с кадрированием в 80–мс в структуре кадра системы, т.е. оно получает 3 LSB у SFN. Таким образом, если UE пропускает считывание MIB–NB, ему требуется получить 7 MSB битов для SFN, чтобы разрешить погрешность измерения времени. Добавляя флаг AB, в целом требуется, чтобы UE была предоставлена 8–битная информация.
[0194] Существует две альтернативы того, каким образом UE может получить такую информацию, которые описываются ниже.
[0195] 4.2.1 С использованием NPBCH
[0196] SFN и флаг AB предоставлены в NPBCH. UE может считать все прочие элементы информации известными и концентрироваться только на декодировании SFN и флага AB. Известные биты информации могут быть использованы, чтобы отсекать решетку и ожидается, что эффективность может быть значительно улучшена с помощью отсечения решетки. В действительность, UE также может проверять метку значения SI, если информация об интервале действия или времени истечения MI/SI, как обсуждалось в Разделе 4.1, не предоставлена. С помощью более сложного декодера NPBCH, который использует преимущество известных битов MIB–NB, UE может декодировать элементы информации, которые ему нужны (например, SFN и флаг AB) с помощью меньшего числа повторений. Это помогает уменьшить время получения системы.
[0197] 4.2.2 Использование сигнала пробуждения или перехода в спящий режим
[0198] Сигнал пробуждения и сигнал перехода в спящий режим обсуждались как потенциальное решение для достижения уменьшения энергопотребления. Требуемая информация о временной привязке и флаг AB может быть привязана к сигналу пробуждения или сигналу перехода в спящий режим. Если информация об интервале действия или времени истечения MI/SI, как обсуждалось в Разделе 4.1, не предоставляется, то метка значения SI также может быть привязана. Тем не менее данный подход работает для UE, которые осуществляют мониторинг сигнала пробуждения или сигнала перехода в спящий режим.
[0199] 5. Заключение
[0200] В данном документе мы обсудили потенциальные решения, которые могут уменьшить время получения системы. На основании обсуждений, представленных в данном документе, выполнены нижеследующие наблюдения и предложения.
[0201] Наблюдение 1: Улучшение в отношении уменьшения времени получения системы в первую очередь следует направить на внутриполосный режим. Решения, которые могут уменьшить время получение системы для внутриполосного режима, могут быть непосредственно применены к режиму в защитной полосе и автономному режиму.
[0202] Предложение 1: Rel–15 должна сначала сфокусироваться на улучшении эффективности NPBCH.
[0203] Наблюдение 2: По несущей привязки Rel–13 NB–IoT процент элементов ресурсов доступных для символов NPDCCH/NPDSCH, за исключением тех, что несут SIB1–NB, составляет только 42% в сценарии наихудшего случая (внутриполосное, 3 OFDM– символа для LTE PDCCH и 4 порта CRS). Использование большего числа повторений NPBCH дополнительно уменьшит процент элементов ресурсов, доступных для NPDCCH/NPDSCH.
[0204] Наблюдение 3: Используя свойства линейного кода у CRC и TBCC, совместное декодирование по нескольким NPBCH TTI может быть выполнено посредством простого применения надлежащей маски дескремблирования к битовым мягким значениям перед объединением кодовых слов TBCC по нескольким TTI.
[0205] Предложение 2: Рассматривается сигнализация посредством eNB интервала действия или времени истечения MI/SI. Действие или время истечения MI/SI не затрагивается изменениями флага AB, SFN и H–SFN. Точным способом сигнализации является FFS.
[0206] 6. Библиографический список
[0207] [1] RP–170852, «Further NB–IoT enhancements», RAN#75, источник Huawei, HiSilicon, Neul, 06–09 март 2017 г.
[0208] [2] R1–1705188, «On system acquisition time reduction», RAN1#88b, источник Ericsson, 03–07 апрель 2017 г.
[0209] [3] R1–152190, PBCH repetition for MTC, Ericsson, RANl#80bis.
[0210] [4] 3GPP TR45.820 Cellular system support for ultra–low complexity and low throughput Internet of Things (CIoT).
1. Способ для уменьшения времени получения системной информации, SI, причем способ выполняется сетевым узлом и содержит этапы, на которых:
формируют основной блок информации, MIB, содержащий однобитный флаг для указания того, изменилась или нет определенная SI с момента конкретного времени в прошлом; и
передают MIB;
получают блок системной информации, SIB, который содержит определенную SI, при этом UE получает SIB независимо от значения, в которое установлен флаг;
принимают последующий MIB, содержащий однобитный флаг, который установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась с конкретного момента времени в прошлом;
определяют, может ли быть пропущено получение последующего SIB, при этом этап, на котором определяют, содержит этап, на котором определяют, что флаг, включенный в последующий MIB, установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась; и
после этапа, на котором определяют, что получение последующего SIB может быть пропущено, пропускают получение последующего SIB, который содержит определенную SI.
2. Способ по п. 1, в котором
конкретное время в прошлом основано на текущем времени и периоде времени указания MIB.
3. Способ по п. 2, в котором период времени указания MIB составляет X часов, при этом X является одним из: 3 и 24.
4. Способ по п. 3, в котором
конкретное время в прошлом является текущим временем минус X.
5. Способ по любому из пп. 1–4, дополнительно содержащий этапы, на которых:
обновляют определенную SI;
устанавливают флаг изменения SI в первое значение, чтобы указать, что определенная SI изменилась;
активируют таймер, который истечет, когда истечет период времени указания MIB с момента, когда был активирован таймер;
если таймер истек, устанавливают флаг изменения SI во второе значение, чтобы указать, что определенная SI не изменилась в рамках периода времени указания MIB; и
если определенная SI дополнительно обновляется в то время, пока таймер по–прежнему запущен, сбрасывают таймер так, что таймер истечет, когда истечет период времени указания MIB с момента, когда таймер был сброшен, при этом
однобитный флаг, включенный в MIB, устанавливается равным значению флага изменения SI.
6. Способ по п. 1, в котором конкретное время в прошлом является определенной абсолютной границей периода времени.
7. Способ для уменьшения времени получения системной информации, SI, причем способ, выполняемый оборудованием пользователя, UE, и содержащий этап, на котором:
принимают основной блок информации, MIB, содержащий однобитный флаг для указания, изменилась или нет определенная SI с конкретного времени в прошлом;
получают блок системной информации, SIB, который содержит определенную SI, при этом UE получает SIB независимо от значения, в которое установлен флаг;
принимают последующий MIB, содержащий однобитный флаг, который установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась с конкретного момента времени в прошлом;
определяют, может ли быть пропущено получение последующего SIB, при этом этап, на котором определяют, содержит этап, на котором определяют, что флаг, включенный в последующий MIB, установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась; и
после этапа, на котором определяют, что получение последующего SIB может быть пропущено, пропускают получение последующего SIB, который содержит определенную SI.
8. Способ по п. 7, в котором конкретное время в прошлом основано на текущем времени и периоде времени указания MIB.
9. Способ по п. 8, в котором этап, на котором определяют, может ли быть пропущено получение последующего SIB, дополнительно содержит этап, на котором UE определяет, имеет ли оно в настоящее время актуальную SI.
10. Способ по п. 8 или 9, в котором период времени указания MIB составляет X часов, при этом X является одним из: 3 и 24.
11. Способ по п. 10, в котором
конкретное время в прошлом является текущим временем минус X.
12. Способ по любому из пп. 7–11, в котором определенная SI является systemInfoValueTag.
13. Сетевой узел для уменьшения времени получения системной информации, SI, причем сетевой узел выполнен с возможностью:
формирования основного блока информации, MIB, содержащего однобитный флаг для указания того, изменилась или нет определенная SI с момента конкретного времени в прошлом;
передачи MIB;
получения блока системной информации, SIB, который содержит определенную SI, при этом UE получает SIB независимо от значения, в которое установлен флаг;
приема последующего MIB, содержащего однобитный флаг, который установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась с конкретного момента времени в прошлом;
определения, может ли быть пропущено получение последующего SIB, при этом определение содержит этап, на котором определяют, что флаг, включенный в последующий MIB, установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась; и
после этапа, на котором определяют, что получение последующего SIB может быть пропущено, пропуска получения последующего SIB, который содержит определенную SI.
14. Сетевой узел по п. 13, в котором
конкретное время в прошлом основано на текущем времени и периоде времени указания MIB.
15. Сетевой узел по п. 14, в котором период времени указания MIB составляет X часов, при этом X является одним из: 3 и 24.
16. Сетевой узел по п. 15, в котором
конкретное время в прошлом является текущим временем минус X.
17. Сетевой узел по любому из пп. 13–16, дополнительно выполненный с возможностью:
обновления определенной SI;
установки флага изменения SI в первое значение, чтобы указать, что определенная SI изменилась;
активации таймера, который истечет, когда истечет период времени указания MIB с момента, когда был активирован таймер;
если таймер истек, установки флага изменения SI во второе значение, чтобы указать, что определенная SI не изменилась в рамках периода времени указания MIB;
если определенная SI дополнительно обновляется в то время, пока таймер по–прежнему запущен, сброса таймера так, что таймер истечет, когда истечет период времени указания MIB с момента, когда таймер был сброшен; и
установки однобитного флага, включенного в MIB, равным значению флага изменения SI.
18. Сетевой узел по п. 13, в котором конкретное время в прошлом является определенной абсолютной границей периода времени.
19. Оборудование пользователя, UE, для уменьшения времени получения системной информации, SI, причем UE выполнено с возможностью:
приема основного блока информации, MIB, содержащего однобитный флаг для указания, изменилась или нет определенная SI с конкретного времени в прошлом;
получения блока системной информации, SIB, который содержит определенную SI, при этом UE получает SIB независимо от значения, в которое установлен флаг;
приема последующего MIB, содержащего однобитный флаг, который установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась с конкретного момента времени в прошлом;
определения, может ли быть пропущено получение последующего SIB, при этом определение содержит этап, на котором определяют, что флаг, включенный в последующий MIB, установлен в конкретное значение, которое указывает на то, что определенная SI не изменилась; и
после этапа, на котором определяют, что получение последующего SIB может быть пропущено, пропуска получения последующего SIB, который содержит определенную SI.
20. UE по п. 19, в котором конкретное время в прошлом основано на текущем времени и периоде времени указания MIB.
21. UE по п. 20, в котором определение того, может ли быть пропущено получение последующего SIB, дополнительно содержит определение посредством UE того, имеет ли оно в настоящее время актуальную SI.
22. UE по п. 20 или 21, в котором период времени указания MIB составляет X часов, при этом X является одним из: 3 и 24.
23. UE по п. 22, в котором
конкретное время в прошлом является текущим временем минус X.
24. UE по любому из пп. 19–23, в котором определенная SI является systemInfoValueTag.
25. Невременный машиночитаемый запоминающий носитель информации, содержащий компьютерную программу, содержащую инструкции, которые, когда исполняются по меньшей мере одним процессором, предписывают по меньшей мере одному процессору выполнить способ по любому из пп. 1–12.
