Method and system for reducing system information (SI) acquisition time

Abstract

To enable a UE to determine whether it can skip acquisition of SIB1-BR. Provide an indication (e.g., a 1-bit flag) in MIB, which is set to a particular value if the UE needs to read SIB1-BR, otherwise, assuming other conditions are met (e.g., assuming the UE's MIB indicates that SIB1-BR has been read within a time period), the indication is set to a different value indicating that the UE can skip reading SIB1-BR.

Description

Technical Field

[0001] The disclosed embodiments relate to the reduced system information (SI) acquisition time by user equipment (UE) (e.g., Internet of Things (IoT) devices, machine-type communication (MTC) devices or other communication devices), such as UEs waking up from deep sleep. Background Technology

[0002] Generally, in order for a UE to communicate with the network, the UE must obtain some system information (SI). Typically, the base station periodically broadcasts a main information block (MIB) containing the SIs required by the UE. The base station also transmits different system information blocks (SIBs) that may contain other SIs required by the UE. For example, an LTE-M1 base station transmits a specific SIB, such as "SIB1-BR".

[0003] Recently, there has been much work in 3GPP regarding the specification of technologies to cover use cases related to Machine-to-Machine (M2M) and / or Internet of Things (IoT). Recent work for 3GPP Release 13 includes enhancements to support Machine Type Communication (MTC) with the new UE category M1 (Cat-M1), reduced maximum bandwidth supporting up to 6 Physical Resource Blocks (PRBs), and narrowband IoT (NB-IoT) work items specifying a new radio interface (and UE category NB1, Cat-NB1).

[0004] We will refer to the LTE enhancements introduced for MTC in 3GPP Release 13 as "eMTC," and the further enhancements introduced in 3GPP Release 14 as "FeMTC," which includes (but is not limited to) support for bandwidth-constrained UEs, Cat-M1, Cat-M2, and coverage enhancements. This discussion is separate from NB-IoT, but the supported features are generally similar.

[0005] There are several differences between the procedures and channels defined for “traditional” LTE and those for eMTC or FeMTC (and similarly for NB-IoT). Some important differences include new physical channels (such as the Physical Downlink Control Channel (PDCCH) called MPDCCH in eMTC and NPDCCH in NB-IoT) and the new Physical Random Access Channel NPRACH for NB-IoT.

[0006] For System Information (SI) (both eMTC and NB-IoT), there is no dynamic scheduling for SIB1-BR / SIB1-NB (scheduling information contained in MIB / MIB-NB) or System Information messages (fixed scheduling within the System Information window provided in SIB1-BR / SIB1-NB). Both eMTC and NB-IoT support coverage enhancement, and the UE may have to accumulate several repetitions of the System Information broadcast in order to successfully decode it. This means that the worse the coverage the UE is in, the longer the System Information acquisition time will actually be. To overcome this, more intensive repetitions for some physical channels and System Information were introduced in eMTC and NB-IoT version 13. The drawback of this introduction is increased system overhead (i.e., more radio resources are consumed by continuous (“always-on”) control signaling broadcasts). The system acquisition process is generally the same for eMTC and NB-IoT as for LTE: the UE first achieves downlink synchronization by reading the PSS / SSS, then the UE reads the MIB, then SIB1 (e.g., SIB1-BR), and finally the SI message is obtained (each may contain multiple SIBs).

[0007] At the 3GPP RAN#70 meeting, a new work item, Release 13, entitled Narrowband IoT (NB-IoT), was approved. Its purpose is to specify radio access for cellular Internet of Things (IoT) that addresses improved indoor coverage, support for a large number of low-throughput devices, insensitivity to latency, ultra-low device cost, low device power consumption, and (optimized) network architecture.

[0008] For NB-IoT, three different operating modes are defined: standalone, guard band, and in-band. In standalone mode, the NB-IoT system operates in a dedicated frequency band. In-band operation allows the NB-IoT system to operate within the frequency band used by the current LTE system, while guard band mode allows the NB-IoT system to operate within the guard band used by the current (legacy) LTE system. NB-IoT can operate using a 180kHz system bandwidth. When multiple carriers are configured, several 180kHz carriers can be used, for example, to increase system capacity, coordinate inter-cell interference, and balance load.

[0009] To accommodate certain use cases requiring more capacity than usual, such as software or firmware upgrades, multi-carrier operation is used. NB-IoT devices listen for system information on the anchor carrier, but communication can be shifted to a subcarrier when data is available. Summary of the Invention

[0010] During Release 14, several potential issues related to long system information acquisition times were identified via RAN4. Reducing system information acquisition time was also one of the work project objectives for Release 15 for eMTC. More specifically, RAN1 generally outlines some areas where RAN2 can provide improvements (in addition to the improvements considered in RAN1). In principle, this simply raises the question to RAN2 whether certain SI broadcast messages can be skipped by the UE in some cases, with the primary concern here being skipping SIB1-BR reads. For ease of reference, the contents of the LTE-M MIB are shown in Table 1 below: Table 1 The most obvious difference from NB-IoT is that in NB-IoT, the value tag does not exist in the MIB, but is instead located in the SIB1-BR.

[0011] There are currently some challenges. SIB1-BR contains the following: i) access information, ii) system information valueTag, iii) supersystem frame number (H-SFN), iv) bitmap indicating valid subframes, v) start OFDM symbol for MPDCCH and PDSCH (essentially replacing PCFICH), and vi) scheduling information for other SI messages.

[0012] Due to access-related information, valid subframe indication, etc., it is extremely difficult, or even impossible, for a UE to skip reading SIB1-BR for initial acquisition. However, for reacquiring the SI, it can be a viable option, for example, for a UE waking up from eDRX or PSM. In most cases, the SI does not change within the cell, but the UE must still ensure this by reading the system information valueTag. One approach would therefore be to place the valueTag directly in the MIB. However, this is problematic for several reasons. First, the valueTag is 5 bits, but only 5 spare bits are reserved in the MIB. It is highly unlikely that 3GPP would allow eMTC to use up all remaining spare bits generally intended for any future use by LTE. Additionally, some of the MIB spare bits might be used for other purposes still related to “reduced system acquisition time,” such as having an access denial enabled flag (ab-Enabled) in the MIB, as is the case for NB-IoT. Another problem related to including the valueTag in the MIB is that this would result in broadcasting redundant information, up to 5 bits in the worst case, increasing system overhead. Another approach is to use fewer bits for the valueTag (e.g., 2 bits instead of 5 bits). With 5 bits, the network can update the system information up to 32 times during the SI validity period, which is either 3 hours or 24 hours (depending on the configuration). If a valueTag of less than 5 bits is used instead, this means the network will be limited to changing the SI fewer than 32 times during the SI validity period (e.g., 2 or 4 times). This is a rather intrusive change to traditional operations; for example, a 2-bit valueTag would mean the network could only update the SI 4 times during this period.

[0013] This disclosure and certain aspects of its embodiments provide solutions to these or other challenges. For example, some embodiments presented herein utilize an indication (e.g., a one-bit flag) in the MIB that is set to a specific value if the UE needs to read SIB1-BR, otherwise the MIB indication is set to a different value. In the simplest case, using 1 bit, the flag changes from "0" to "1" when there are any changes to SIB1-BR and its systemInfoValueTag, indicating that the UE can no longer ignore reading SIB1-BR, but in subsequent changes to SIB1-BR, the flag remains set to "1" for the remainder of a certain time period, such as the HSFN cycle; in this sense, this MIB indication is different from the valueTag. When SIB1-BR / systemInfoValueTag is not updated (which is the most frequent case), using only 1 bit (or some other small number) from the MIB spare bits provides a clear advantage to all UEs. If the SI has been updated, the UE will simply follow the version 13 procedure. (Implementations with multiple bits can have additional benefits as seen in the detailed description.) The above solution reduces the need for the UE to obtain SIB1-BR (to check the system valueTag, etc.), greatly improving system access time and UE battery life.

[0014] This document proposes various embodiments that address one or more of the problems disclosed herein. Some embodiments may provide one or more of the following technical advantages: The UE can skip reading the SIB1-BR for SI reacquisition, thereby improving UE system acquisition / access time and extending UE battery life; and the solution uses only 1 (or a few) bits from the MIB spare bits, thereby making efficient use of scarce resources.

[0015] These and other embodiments are further described herein. Attached Figure Description

[0016] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0017] Figure 1 The illustration shows an architecture view according to some embodiments.

[0018] Figure 2 This is a flowchart illustrating a process according to some embodiments.

[0019] Figure 3 This is a flowchart illustrating a process according to some embodiments.

[0020] Figure 4 This is a flowchart illustrating a process according to some embodiments.

[0021] Figure 5 An embodiment for SIB1-BR skipping is illustrated.

[0022] Figure 6 This is a flowchart illustrating a process according to some embodiments.

[0023] Figure 7 This is a flowchart illustrating a process according to some embodiments.

[0024] Figure 8 This is a block diagram of a UE according to some embodiments.

[0025] Figure 9 This is a block diagram of network nodes according to some embodiments.

[0026] Figure 10 The diagram illustrates the encoding process according to some embodiments.

[0027] Figure 11 The diagram illustrates the encoding process according to some embodiments. Detailed Implementation

[0028] Cat-M1, Cat-M2, Cat-N1, and Cat-N2 UEs can experience long system acquisition times in poor coverage. It was recognized in [3][4] that, in some cases for both NB-IoT and LTE-M (eMTC), it can take a long time to acquire system information. Therefore, one objective of further enhancements to both LTE-M and NB-IoT in Rel-15 is to reduce system acquisition time.

[0029] In this disclosure, we propose methods and systems that enable an NB-IoT UE to skip obtaining certain Master Information (MI) in a Master Information Block (MIB) and / or certain System Information (SI) in a System Information Block (SIB). The proposed methods include the following embodiments.

[0030] (1) The new System Information Block (SIB) signals the validity interval or expiration time of the MIB / SIB. We will call this new SIB SIB-X to distinguish it from the System Information Blocks already defined for NB-IoT.

[0031] (2) A mechanism for allowing a UE to skip MI / SI to obtain one or more of the access denial flag, system information number and supersystem information number.

[0032] If the basic master information or system information has not been changed since the last time the UE obtained it, the UE can skip reading the Master Information Block (MIB) (or a portion thereof) carried in the Narrowband Physical Broadcast Channel (NPBCH) or certain System Information Blocks (SIBs) (or portions thereof) carried in the Narrowband Physical Downlink Shared Channel (PDSCH). Since it no longer needs to obtain the latest MI / SI, the UE reduces power consumption and thus enjoys longer battery life. Furthermore, when the UE has data to transmit, the latency for establishing network access is reduced.

[0033] The following is an overview of NB-IoT system information: The NB-IoT Master Information Block (MIB-NB) consists of the following information: • The four most significant bits (MSB) of the SFN.

[0034] The two least significant bits (LSBs) of H-SFN.

[0035] • Access Denial (AB) flag indicating whether access denial is enabled.

[0036] • Operating modes (standalone, in-band, guard band).

[0037] • Frequency grid offset (±2.5, ±7.5kHz) in both in-band and guard band cases.

[0038] • Information regarding the scheduling of System Information Block 1 (SIB1-NB).

[0039] • Essentially, it is a system information value label that represents the version number of the system information.

[0040] NB-IoT further defines the following system information types: • SIB1-NB: 8 MSBs of H-SFN, scheduling information of other system information types, invalid subframe bitmap plus other information.

[0041] •SIB2: Radio Resource Configuration (RRC) information.

[0042] •SIB3: Cell reselection information.

[0043] • SIB4 and SIB5: Information related to neighboring cells.

[0044] • SIB14-NB: Access class rejection information for each PLMN.

[0045] • SIB16: Information related to GPS time and Coordinated Universal Time (UTC).

[0046] The following is an overview of LTE-M system information: The LTE-M Master Information Block (MIB-NB) consists of the following information: Downlink bandwidth • PHICH configuration ·SFN bits • Scheduling information for SIB1-BR · 5 spare bits LTE-M further defines the following system information types: • SIB1-BR: Access-related information, including Access Class Rejection (ACB) information, scheduling information for SI messages, Super SFN, valid bit frames, MPDCCH frequency hopping information, etc.

[0047] •SIB2: Radio Resource Configuration (RRC) information.

[0048] •SIB3: Cell reselection information.

[0049] • SIB4 and SIB5: Information related to neighboring cells.

[0050] •SIB14: Access class rejection information for each PLMN.

[0051] • SIB16: Information related to GPS time and Coordinated Universal Time (UTC).

[0052] Of these different types of master and system information, only SFN, H-SFN, ACB (LTE-M), AB flag (NB-IoT), SIB14 (-NB), and SIB16 typically change more dynamically. Other information is rarely changed. SIB16 is not required when the UE accesses the network. SIB14 (-NB) is not required if the AB flag is not set for NB-IoT, or if SIB14 is not scheduled for LTE-M in the SIB1-BR. Therefore, in most cases, only SFN, H-SFN, and the AB flag (or SIB-14 plus ACB scheduled for LTE-M) need to be obtained.

[0053] Since most MIBs and SIs rarely change, one way to allow a UE to skip re-obtaining MIB(-NB) and SIs that will remain unchanged is to have the eNB indicate the validity interval or expiration time of the MIB(-NB) and SI information in advance. (In the description below, we will assume that changes to the AB flag, SIB14(-NB), SIB16, SFN, and H-SFN are not used to determine the MI / SI validity interval or expiration time.) With such an indication, if the UE wakes up within the validity interval of the version of MI / SI it previously obtained, it does not need to obtain the same information again. In such a case, the UE only needs to obtain the AB flag, SFN, and H-SFN (or SIB14 plus ACB scheduled for LTE-M in SIB1-BR), and not necessarily all other information elements contained in the MIB-NB and SIB1-NB. To support this approach, two issues need to be addressed.

[0054] How does the network signal the validity interval or expiration time of MI / SI? If the UE knows that all other MI / SI information remains the same, how does it obtain the AB flag (or SIB14 plus ACB scheduled for LTE-M in SIB1-BR), SFN, and H-SFN? The following describes methods for solving these problems.

[0055] Signal notification of MI / SI validity interval or expiration time : The new system information type can be defined to indicate the validity interval or expiration time of the MI / SI. One possible format is to use GPS time or Coordinated Universal Time (UTC). The UE can obtain GPS and UTC time from SIB16 to establish its real-time clock. The new SIB-X can then be used to indicate the GPS or UTC time at which the current MI / SI will expire. The format of SIB-X can be similar to the UTC format used in SIB16. However, the time resolution in SIB16 is 10ms. For SIB-X, a coarser time resolution can be used to reduce the number of bits required to represent UTC time. One possibility is to quantize UTC time with a resolution equivalent to one or more SFN cycles. Also, the UTC time information in SIB16 includes year and month information. For SIB-X, including year and month information may not be necessary.

[0056] The UE can be notified of SIB-X updates via an SI update notification. Such update notifications can be SIB-X specific.

[0057] UE obtains AB mark, SFN and H-SFN : The system gain time reduction needs to allow certain configurations to support use cases requiring long battery life (e.g., 10-15 years) and 10ms latency for sending exception reports such as alarm signals. However, the solution need not meet use cases that only transmit data at a frequency of less than once every three days, as we believe that a 15-year battery life is already achievable for such use cases without further system gain time reduction. Considering an oscillator accuracy of 20ppm, the UE clock can be shut down for approximately ±5120ms over 3 days. Therefore, if the UE returns to the network after 3 days, it needs to resolve this time ambiguity. This uncertainty window matches the duration of an SFN cycle, and therefore it uses a 10-bit SFN representation to resolve the time ambiguity. The UE will perform NPSS and NSSS synchronization steps, and after these two steps, it achieves synchronization with 80-ms framing in the system frame structure, i.e., it obtains 3 LSBs of the SFN. Therefore, if the UE skips reading the MIB-NB, it needs to obtain 7 MSB bits of the SFN to resolve the time ambiguity. Including the AB flag, a total of 8 bits of information need to be provided to the UE.

[0058] There are two alternative solutions for how the UE obtains this information. We propose two alternative solutions below.

[0059] Using NPBCH The SFN and AB flags are provided in the MIB carried in the NPBCH. The UE can treat all other information elements as known and focus only on decoding the SFN and AB flags. The known information bits can be used to trim the grid used in the Viterbi decoder, and performance is expected to be significantly improved through grid pruning. In fact, the UE can also check the SI value tag if the MI / SI validity interval or expiration time information, as discussed in Section 5.1, is not provided.

[0060] Use wake-up or sleep-in signals The "enter sleep" signal is used to indicate that no downlink control information (DCI) will be transmitted during the subsequent NPDCCH / MPDCCH search space. Upon receiving such a signal, the UE returns to sleep mode. However, if the "enter sleep" signal is not detected, the UE must remain active to attempt to decode the DCI carried in the NPDCCH / MPDCCH.

[0061] On the other hand, the "wake-up" signal is used to indicate one or more DCIs that will be transmitted during the upcoming NPDCCH / MPDCCH search space. Upon receiving such a signal, the UE needs to remain active to attempt to decode the DCI carried in the NPDCCH / MPDCCH. However, if the "wake-up" signal is not present, the UE can return to sleep. The "wake-up" signal can be transmitted before the start of the NPDCCH / MPDCCH search space or in one or more subframes at the start of the NPDCCH / MPDCCH search space. Furthermore, the "wake-up" signal does not necessarily occupy one or more complete subframes. The signal can use portions of a subframe in the time or frequency domain (e.g., the first few symbols in a time slot) or a combination of time and frequency domains.

[0062] At the time of writing, 3GPP had not yet decided whether to adopt the "sleep" signaling and / or "wake-up" signaling schemes. However, the scheme described herein will apply regardless of whether one or both of these signaling schemes are adopted.

[0063] One use case for the "Enter Sleep" and / or "Wake Up" signals is to provide the UE with an indication of whether a paging DCI is coming in the next paging opportunity that the UE needs to monitor. Therefore, the "Enter Sleep" and / or "Wake Up" signals are expected to be periodic. In addition to indicating whether a paging DCI is coming in the next paging opportunity that the UE needs to monitor, we can also utilize the periodicity of the "Enter Sleep" and / or "Wake Up" signals to include 8 bits or all 8 bits of what is available in the "Enter Sleep" and / or "Wake Up" signals.

[0064] Alternative Option 1: All 8 bits of information, along with an indication of whether this paging DCI is coming in the next paging opportunity that the group of UEs needs to monitor, are provided to all UEs. All UEs are able to listen for this periodic "go to sleep" and / or "wake up" signal for the information they are interested in, namely, the 8 bits of information provided above. For a UE that has not been paged in the most recent paging opportunity, it is able to simply ignore the indication of paging information.

[0065] Alternative Option 2: Part of the 8-bit information, along with an indication of whether this is a paging DCI that the UE needs to monitor in the next paging opportunity, is provided to the UE. This could be an AB flag or timing information.

[0066] Alternative Option 3: In addition to timing and AB flag information, the SI value label used to indicate whether the SIB has been changed can also be included in the "Enter Sleep" signal and / or "Wake Up" signal. Note that it is also possible to include only the SI value label in the "Enter Sleep" signal and / or "Wake Up" signal.

[0067] Alternative Option 4: In the "go to sleep" signal and / or "wake up" signal, we can further include an indication to the UE whether it can skip some SIB and / or MIB reads when paged.

[0068] Alternative Option 5: In the "go to sleep" and / or "wake up" signals, we can further include an indication to the UE that the MIB has been changed at a previous time, for example, using a timestamp or other mechanism. If the UE has the latest version of the MIB, it can skip reading the MIB.

[0069] Note that some of the alternatives mentioned above can also be combined to reduce system acquisition time.

[0070] Extend the modification period for MIB and / or SIB. : In NB-IoT, the Master Information Block-NB (MIB-NB) scheduler has a fixed period of 640ms and repeats L1 times within each word frame 0. The MIB-NB is transmitted on the NPBCH. The MIB-NB contains: •SFN (4 MSB bits) H-SFN (2 LSB bits) ·schedulingInfoSIB1 • systemInfoValueTag (different from any SIB changes different from MIB-NB / SIB14-NB / SIB16-NB) • ab-Enabled (Access Denied Activated / Deactivated, obtained from SIB14) operationModeInfo Because of the 4 MSB bits of the SFN in the MIB-NB, the MIB-NB content is modified every 640ms. Excluding the SFN, the modification period is equal to 40.96 seconds.

[0071] The SIB1-NB schedule is fixed with a period of 2.56 seconds. The SIB1-NB is broadcast every other word frame. The SIB1-NB is transmitted on the DL SCH. The number of NPDSCH repetitions is indicated in the MIB-NB (schedulingInfoSIB1). The SIB1-NB has a 40.96-second modification period; that is, the SIB1-NB content can only be changed after 40.96 seconds.

[0072] Unlike SIB1-NBs, whose SIBs are sent in SI messages, SI messages are sent on the DL SCH. An SI message may contain one or more SIBs, as indicated in the scheduling information within the SIB1-NB.

[0073] The contents of these other SIBs can be changed after the BCCH modification period. The BCCH modification period is greater than or equal to 40.96 seconds and is indicated in SIB2-NB (modificationPeriodCoeff*defaultPagingCycle). SIB changes (content and / or scheduling) are indicated by the systemInfoValueTag in MasterInformationBlock-NB or the systemInfoValueTagSI in SystemInformationBlockType1-NB.

[0074] The access denial parameter in SIB14-NB can be changed at any point in time (section 5.2.1.7 of TS 36.331[6]), and such changes do not affect systemInfoValueTag in MasterInformationBlock-NB or systemInfoValueTagSI in SystemInformationBlockType1-NB.

[0075] Except for SIB14-NB during congestion periods, the content in other SIBs is not expected to change frequently.

[0076] Since the problem identified in [3] is that for some cases, some SIBs can be longer than 40.96 seconds, the UE may have difficulty effectively performing combinations across modified time period boundaries.

[0077] Therefore, the network will subsequently provide a modification period longer than 40.96 seconds that the UE can use when decoding MIB-NB, SIB1-NB, and SIB2-NB, as needed. Remember, the BCCH modification period is indicated in the SIB2-NB. Of course, the new value can be defined and signaled to the UE. Considering backward compatibility, the network can configure the new value in multiples of 40.96 seconds. This will have no impact on legacy NB-IoT UEs, which will still use a 40.96-second modification period for MIB-NB and SIB1-NB.

[0078] Alternative Option 1: Because there are several spare bits in the MIB-NB, we can use some of these spare bits to indicate whether to extend the modified period of 40.96 seconds, for example, by a multiple of 40.96 seconds or other values ​​preferred by the network.

[0079] Alternative Option 2: We can use one of the SIBs to indicate whether to extend the modified period by 40.96 seconds, for example, by a multiple of 40.96 seconds or other values ​​preferred by the network.

[0080] Alternative Option 3: We can use one of the dedicated signaling protocols for a specific group of UEs to indicate whether to extend the modified period of 40.96 seconds, for example, by a multiple of 40.96 seconds or other values ​​preferred by the network.

[0081] Alternative Option 4: Other methods for indicating whether to extend the modification period by 40.96 seconds, such as multiples of 40.96 seconds or other values ​​preferred by the network.

[0082] In addition to the alternatives listed above, to provide flexibility in the network, the network will also notify the UE whether the extended modification period is active.

[0083] Note that the solutions listed above are discussed in the context of NB-IoT, but can also be applied to LTE-M with different modification periods.

[0084] like Figure 1 As shown, UE 102 can communicate with network node 104 (e.g., a base station, such as an LTE base station (“eNB”) or a 5G base station (“gNB”)). For example, UE 102 can communicate with network node 104 using M2M, MTC, or IoT type communication modes. UE 102 can enter a sleep mode in which it does not actively communicate with network node 104, and can wake up from its sleep mode and resume communication with network node 104 upon prompting by network node 104 or by its own initiative.

[0085] Figure 2 The illustration shows a method 200 that can be implemented on UE 102. UE 102 receives a Master Information Block (MIB) and / or a System Information Block (SIB) (step 202). UE 102 receives an indication of the validity of at least a portion of the received MIB and / or SIB (step 204). The MIB is carried in the Narrowband Physical Broadcast Channel (NPBCH), the SIB is carried in the Narrowband Physical Downlink Shared Channel (PDSCH), and the indication specifies the validity interval or expiration time.

[0086] According to some embodiments, the indication uses a GPS or UTC time format, and / or the indication is quantized at a resolution equivalent to a multiple of the system frame number (SFN) cycle. In some embodiments, the method further includes receiving an update notification. In some embodiments, receiving the indication includes receiving a system information block (SIB) including the indication.

[0087] In some embodiments, the method further includes storing at least a portion of the MIB; entering a sleep state after storing at least a portion of the MIB; waking up from the sleep state after entering the sleep state; and determining, based on a validity indication, whether the stored portion of the MIB is still valid upon waking from the sleep state.

[0088] In some embodiments, the method further includes receiving a second MIB carried on the NPBCH since it is determined that the storage portion of the MIB is still valid, and skipping decoding one or more portions of the received second MIB, but decoding one or more other portions of the received second MIB. In some embodiments, the second MIB includes coded operation mode information indicating an operation mode and a coded access rejection (AB) flag, the UE decodes the coded AB flag, and the UE skips decoding the operation mode information.

[0089] Figure 3 The illustration shows method 300 that can be implemented on UE 102. UE 102 wakes up from sleep state (step 302). UE 102 determines whether it needs to obtain a portion of the Master Information Block (MIB) and / or System Information Block (SIB) again (step 304). In response to determining that it does not need to obtain a portion of the MIB and / or SIB information again, UE 102 obtains only the remaining portion of the MIB and / or SIB information (step 306).

[0090] In some embodiments, the remainder includes system frame number (SFN) and access denied (AB) flag information. In some embodiments, the remainder, which only obtains MI and / or SI information, includes decoding the Master Information Block (MIB) carried on the Narrowband Physical Broadcast Channel (NPBCH), and may further include this portion using MI and / or SI that do not need to be obtained again to trim the mesh used in the Viterbi decoder.

[0091] In some embodiments, a "wake-up" signal and / or a "go to sleep" signal are used to indicate whether downlink control information (DCI) will be sent.

[0092] Figure 4The illustration shows a method 400 that can be implemented on network node 104. Network node 104 transmits a MIB on the NPBCH (step 402). Network node 104 transmits a SIB on the PDSCH (step 404). Network node 104 transmits an indication of the validity of at least a portion of the transmitted MIB and / or SIB. The validity indication indicates a validity interval or expiration time. In some embodiments, the validity indication uses a GPS or UTC time format. In some embodiments, the validity indication is quantized at a resolution equivalent to a multiple of the system frame number (SFN) cycle.

[0093] Skip SIB1-BR : For LTE-M, unlike NB-IoT, the System Value Tag (SVT) is located in SIB1-BR. A UE waking from eDRX or PSM will therefore have to read SIB1-BR to determine if the SI has been updated and whether it needs to obtain that SI again (such as the complete information or SIB indicated by the valueTag specific to the SI message in systemInfoValueTagList). Furthermore, the UE may have to check if it has been denied access. In LTE-M, the UE must not be denied access based on both the ACB information in SIB2 and the Enhanced Access Class Denial (EAB) information in SIB14. Typically, SIB14 is only scheduled and broadcast when EAB is enabled; therefore, if it is not scheduled and broadcast, the UE can interpret this as access being allowed according to EAB based on the scheduling information in SIB1-BR. In most cases, the SI is not updated, and the UE is not denied; however, the UE must still check to ensure this is the case. In version 13 operation, this means the UE must read both SIB1-BR and SIB2. However, the spare bits in the MIB can be used to signal the UE that it can skip obtaining SIB1-BR.

[0094] As stated above, it is highly unlikely that 3GPP will agree to use all 5 spare MIB bits for all future LTEs for the systemInfoValueTag that already exists in SIB1-BR. Therefore, the solution for eMTC that skips reading SIB1-BR is to have a short indication (e.g., a one-bit flag) in the MIB. This short indication in the MIB is referred to herein as the "MIB indication". Generally, the UE should only skip reading SIB1-BR during SI reacquisition, as in many cases, SIB1-BR is necessary for access and therefore necessary for initial access.

[0095] Since SIB1-BR (and its systemInfoValueTag) are rarely updated, it is advantageous to have a MIB indicator (e.g., a flag) set to 1 to indicate that SIB1-BR / systemInfoValueTag has been updated at some point during a certain time period (e.g., during the current time period or the time period immediately preceding the current time period), and to set this MIB indicator to 0 to indicate another situation (i.e., when the MIB indicator is set to 0, the UE can skip reading SIB1-BR; otherwise, the UE should not skip reading SIB1-BR). In other words, if SIB1-BR is not updated during a certain time period, which is the most frequent case, the MIB indicator is set to "0," and the UE can skip reading SIB1-BR and systemInfoValueTag. If there is a subsequent change to SIB1-BR during that time period, the MIB indicator remains set to "1" and is not switched back to "0" (i.e., unlike valueTag). The MIB indicator can be reset to "0" at the boundary of that time period (e.g., if SIB1-BR has not changed within the last X units of time (i.e., a certain time period)). Note that since the scheduling information and system valueTag of SI messages are located in SIB1-BR, SIB1-BR will be updated if any SI message is updated.

[0096] In some embodiments using the MIB indication, the UE is required to check the MIB indication once per MIB indication period (e.g., during the last BCCH modification period of that period). That is, if the UE skips a period, the SIB1-BR may have been updated during that period, and this will not be detected by the UE. The MIB indication period can be, for example, but is not limited to, any of the following: 1) BCCH Modification Period. The SIB1-BR period will subsequently be consistent with the modification period used for SI (note that SI can be updated 32 times during this period as given by the system information valueTag, and the new SIB1-BR does not impose any limit on the number of updates, but on the other hand, it is only beneficial when there are no updates). This time reference will be common to all UEs.

[0097] 2) System information validity period: either 3h or 24h. Since the UE is required to check the MIB once every predefined time period (e.g., at least once every 3 or 24 hours), this has the advantage of being much longer than the BCCH modification period if a 1-bit indication is used, and therefore requires the UE to perform this operation less frequently.

[0098] 3) HSFN Period. This period is based on the System Frame Number (SFN) and / or the Supersystem Frame Number (HSFN). The latter is more likely because a longer timer period is more efficient. 10 bits are used for the SFN, giving it wraparound after 10.24 seconds. 10 bits are used for the HSFN, giving approximately 1025 SFN periods, equivalent to about 2.9 hours. A possible implementation is to use 2 n This time reference is defined as a set of SFN time periods, where n is the HSFN. This time reference will be common to all UEs.

[0099] 4) Based on GPS or UTC time as provided in SIB16. This time reference will be common to all UEs.

[0100] UEs within the coverage area in either DRX or eDRX will be notified in the paging whenever an SI update is available, either by checking systemInfoModification or, if the eDRX cycle is longer than the BCCH modification period, by checking systemInfoModification-eDRX in the paging message. With the solution described herein, the UE can potentially instead check the MIB indicator once per time period (which is potentially less energy-intensive than attempting to find the systemInfoModification indicator at least once during the modification period, since SIB1-BR contains the system valueTag; see section 5.2.1.3 of 3GPP TS 36.331v 14.2.2). Furthermore, as explained in 3GPP TS 36.311, for UEs given an eDRX period longer than the BCCH modification period, the UE is required to read SIB1-BR before access: "When an RRC_IDLEUE is configured with a DRX cycle longer than the modification period, and at least one modification period boundary has passed since the UE last verified the validity of the stored system information, the UE verifies that the stored system information is still valid by checking the systemInfoValueTag before establishing or restoring the RRC connection." Without SI updates, UEs applying the solution described herein advantageously only need to obtain the MIB, check the MIB indication, and skip obtaining the SIB1-BR.

[0101] For a UE in Power Saving Mode (PSM), the UE will reside in a Power Saving State (a sub-state of RRC_IDLE) and must ensure it has the latest SI before "Hold On" signaling / checking downlink data via periodic Tracking Area Update (TAU) or before uplink data transmission. In versions 13 and 14, the UE will check if it has obtained the latest SI by checking the valueTag (i.e., systemInfoValueTag) in SIB1-BR. With the solution described herein, the UE can obtain only the MIB to check the MIB indication and skip reading SIB1-BR only if the time since the last uplink data transmission or periodic TAU does not exceed the MIB indication period (e.g., 3h or 24h) and the MIB indication is set to a specific value that can be 0 or 1. For example, if the period selected for the described solution is a 2.9h HSFN wraparound, the UE will not need to read SIB1-BR if it is configured with a periodic TAU shorter than 2.9h (assuming, of course, that its contents have not been updated). Similarly, in cases where the SI is rarely updated, the UE will simply continue reading SIB1-BR as it did in version 13 operation.

[0102] Figure 5 The documentation provides a functional example of the MIB indication. In this case, the time period is based on an HSFN using 2 HSFN bits, making its length 4096 radio frames. The BCCH modification period here is 1024 radio frames. As in version 13 operation, the UE is notified in the paging when the SI will be updated, and the new SI will begin to be broadcast in the subsequent BCCH modification period.

[0103] Generally, whenever the UE is requested to read SIB1-BR, the MIB indicator will be set to a first specific value (e.g., 1), and in other cases, it will be set to a second specific value (e.g., 0). Alternative embodiments regarding how this operation can be performed are described below. Figure 5 In the embodiment shown, the indication is set to 1 when the valueTag (i.e., systemInfoValueTag) is changed, and remains set to 1 during the SIB1-BR and the time period after the SI has been changed. Alternatively, even before the SI is updated, the MIB indication can be set to 1, for example, during a previous BCCH modification period in which the UE is notified in a paging of the upcoming SI update. Figure 5(Not shown in the image). In the above embodiment, the MIB indicator is set to 1 throughout the subsequent time period. The UE checks the MIB indicator once per time period, and it is sufficient that the check can be performed at any time (i.e., if the SI is updated at the end of the time period after the UE has checked it, it will still not go unnoticed because the UE will notice it in the subsequent time period).

[0104] In an alternative embodiment, the UE can be required to check the MIB indicator during the last BCCH modification period (and, of course, before access), in which case the MIB indicator can always be reset to "0" at the boundary of that period. This ensures that if SIB1-BR is updated at the end of that period, the UE will still be notified of the SIB1-BR update. However, since SIs are rarely updated, the benefit of this embodiment may be negligible compared to the previous embodiment, and generally, it may be better to keep the MIB indicator set to "1" for a longer period to avoid error conditions (because setting it to "1" means the UE will fall back to version 13 operation). Therefore, in another embodiment, the MIB indicator can be set to "1" more broadly before and after the SI and SIB1-BR updates. For example, the MIB indicator can be set to "1" for the entire period before the SI update, and / or for the entire period during the SI update, and / or for the entire period after the SI update.

[0105] The above embodiment uses a 1-bit MIB indication, but other embodiments using larger bits are possible. For example, 2 bits can be used to indicate the following: Table 2 00 The last time period of SIB1-BR (e.g., the last 24 hours) has not been changed. 01 <![CDATA[The last N1 time periods of SIB1-BR are not changed.]]> 10 <![CDATA[The last N2 time periods of SIB1-BR are not changed.]]> 11 <![CDATA[The last N3 time periods of SIB1-BR are not modified.]]> In one embodiment, the time period is an HSFN period. Further, Ni can be linear, for example, N1 = 2, N2 = 3, and N3 = 4. In an alternative embodiment, Ni can be non-linear, for example, logarithmic, such that N1 = 2, N2 = 4, and N3 = 8, or N1 = 10, N2 = 100, and N3 = 1000. This provides finer-grained information to the UE (the UE will compare when it last received the SI), and it can be used to achieve gains outside the 2.9h HSFN period. That is, if the time period is agreed to be based on SFN, the UE would have to check the indication in the MIB at least once every 2.9h, but with multiple indication bits as described above, this can be extended, allowing UEs using PSMs with long periodic TAUs (which can be configured to almost 14 days) to benefit from the solution described herein, and without SI updates, they would only need to receive the MIB upon wake-up.

[0106] In some other embodiments, the time period associated with the 1-bit indication can itself be set / modified in the system information message. Similarly, the value of at least one of N1, N2, and N3 in the example 2-bit indication embodiment above can be modified. Default values ​​can be provided by standards, and these values ​​will be used if the corresponding modified values ​​are not provided as part of the broadcast system information. This increases flexibility in the network to accommodate different deployment scenarios and configurations such as eDRX and PSM.

[0107] Note that, in the sense that if any content of SIB1-BR is changed, the systemInfoValueTag is updated, the MIB indication is a systemInfoValueTag indication. However, in another embodiment, although the systemInfoValueTag has been updated, the UE can still skip obtaining the SIB1-BR. That is, as above, the first bit is used to specify whether the UE needs to obtain the SIB1-BR or can skip it, while the other bits specify what has changed in the SIB1-BR.

[0108] Other bits can indicate, for example: (1) whether the update relates to an SI other than the one required for paging (UEs that wake up in eDRX to check for paging can still skip SIB1-BR); (2) whether the update relates to an SI other than the one required for access (UEs that attempt random access and RRC connection settings can still skip SIB1-BR); (3) any specified SIB (group). Moreover, if the UE does not require any of the above, it can still ignore reading SIB1-BR.

[0109] Figure 6 Example procedure 600 for UE operation is shown. Procedure 600 begins when the UE determines whether the MIB indicator is set to a specific value (e.g., 0 or 1) (step s602). This MIB indicator may be a 1-bit MIB indicator, but may also contain additional bits, as described in more detail above. If the UE determines that the MIB indicator is set to that specific value (e.g., 0), the UE can skip obtaining SIB1-BR (step s604). However, if the UE determines that the MIB indicator is set to that specific value (e.g., set to 1), the UE will obtain SIB1-BR (step s606).

[0110] Figure 7Example procedure 700 for network node (e.g., eNB) operation is shown. Example procedure 700 begins when the network node determines whether a SIB1-BR update occurred during a previous or current time period (step s702). If not, the MIB indicator is not set (step s704). If yes, the network node sets the MIB indicator (step s706). In the case of a 1-bit MIB indicator, "set MIB indicator" would correspond to, for example, setting it to the value "1", and not setting it would correspond to the value "0". Note also that the logic of when it should be set to "1" by the eNB will depend on the embodiments discussed above. After these steps, the network node determines whether the MIB indicator time period has ended (step s708). If not, the network node repeats the preceding steps to determine whether a SIB1-BR update has occurred. If the MIB indicator time period has ended, the MIB indicator can be reset by the network node (step s710). According to some embodiments, this reset may depend on other factors, including past and / or upcoming SIB1-BR updates.

[0111] The standard impact of the proposed solution will be the procedural text used for the UE and updated MIB content, as shown in the example below (changes are shown in bold): Table 3 The proposed solution in this paper is described for eMTC, but will generally also be applicable to other systems such as LTE or NR (but not for NB-IoT, since the system value tag is located directly in the MIB-NB).

[0112] In another embodiment, the MIB one-bit flag can be used with the following meanings: The bit set to "0" = SI has not been updated since the last BCCH modification time boundary and access denial (ACB or EAB) is currently not enabled in the cell.

[0113] The bit set to "1" = SI has been updated since the last BCCH modification time boundary or access denied (ACB or EAB) is currently enabled in the cell.

[0114] Note that this is not the valueTag and the bit is not switched back to the value "0" if the SI changes again. In an alternative embodiment, the time period used for SI updates is different from the BCCH modification period, such as multiple BCCH modification periods, SIB1-BR modification periods, or a 3h / 24h SI validity period.

[0115] In alternative embodiments, multiple bits can be used to indicate more options, for example, as described below: 00 No SI was updated and access denial was not enabled. 01 SI was updated, but access denial was not enabled. 10 No SI was updated, but access was denied and enabled. 11 SI was updated and access denial was enabled. Alternatively, either the SI update or the access rejection can be ignored, or they can be indicated by a single bit.

[0116] Alternatively, this instruction can be added to the wake-up and sleep-in signals as described above.

[0117] Based on the above description, in one aspect, a method is provided to be performed by a network node (e.g., network node 104) to reduce SI acquisition time. In one embodiment, the method includes the steps of: (1) generating a MIB, which includes a one-bit flag indicating whether a certain SI (e.g., valueTag) has changed since a specific time in the past (e.g., 24 hours ago, 3 hours ago, etc.) and (2) transmitting the MIB. In some embodiments, the specific time in the past is based on the current time and the time period indicated by the MIB (e.g., 3 or 24 hours). In some embodiments, the specific time in the past is the current time minus the time period indicated by the MIB. In other embodiments, the specific time in the past is an absolute time period boundary.

[0118] In some embodiments, the method also includes a network node performing the following steps: updating a certain SI; setting an SI change flag to a first value to indicate that the certain SI has changed; activating a timer that will expire when the MIB-indicated time period (e.g., 24 hours) has elapsed since the timer was activated; if the timer expires, setting the SI change flag to a second value to indicate that the certain SI has not changed during the MIB-indicated time period (e.g., in the past 24 hours); and if the certain SI is further updated while the timer is still running, resetting the timer so that the timer will expire when the MIB-indicated time period has elapsed since the timer was reset. In this embodiment, the one-bit flag included in the MIB is set to an value equal to the SI change flag.

[0119] On the other hand, a method is provided, performed by UE 102, to reduce SI acquisition time. In one embodiment, the method includes the UE receiving a MIB, which includes a one-bit flag indicating whether a certain SI has been changed since a specific time in the past. The method may further include the UE acquiring an SIB including said certain SI (e.g., acquiring SIB1-BR) after receiving the MIB, wherein the UE acquires the SIB regardless of the value of the flag being set. For example, the UE may acquire the SIB regardless of the flag setting after the UE wakes from sleep and whether the last time the UE acquired the particular SIB was more than X hours ago (e.g., X = 3 or 24).

[0120] The method may further include, after obtaining the SIB, the UE receiving a subsequent MIB including a MIB indication set to a certain value, indicating that the certain SI has not been changed since a specific point in the past (e.g., indicating that the SI has not changed in the past X hours); the UE determining whether obtaining the subsequent SIB can be skipped, wherein the determination includes the UE determining that the flag is set to the specific value; and after determining that obtaining the subsequent SIB can be skipped, the UE skipping the acquisition of the subsequent SIB including the certain SI. In some embodiments, the specific time in the past is based on the current time and the MIB indication time period. In some embodiments, the step of determining that obtaining the subsequent SIB can be skipped further includes the UE determining whether it currently has a latest SI. In some embodiments, the UE determines that it has a latest SI by determining that it last obtained the SI within the MIB index time period.

[0121] Figure 8 This is a block diagram of UE 102 according to some embodiments. For example... Figure 8 As shown, UE 102 may include: a data processing device (DPA) 802, which may include one or more processors (P) 855 (e.g., a general-purpose microprocessor and / or one or more other processors, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and the like); a transmitter 805 and a receiver 804, coupled to an antenna 822 to enable UE 102 to transmit data to and receive data from an AN node (e.g., a base station); and a local storage unit (also referred to as a “data storage system”) 808, which may include one or more non-volatile storage devices and / or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where UE 102 includes a general-purpose microprocessor, a computer program product (CPP) 841 may be provided. CPP 841 includes a computer-readable medium (CRM) 842 storing a computer program (CP) 843 comprising computer-readable instructions (CRI) 844. CRM 842 may be a non-transitory computer-readable medium, such as, but not limited to, magnetic media (e.g., hard disk), optical media, memory devices (e.g., random access memory), and the like. In some embodiments, CRI 844 of computer program 843 is configured such that, when executed by data processing device 802, CRI causes UE 102 to perform the steps described above (e.g., the steps described above with reference to the flowchart). In other embodiments, UE 102 may be configured to perform the steps described herein without code. That is, for example, data processing device 802 may consist of only one or more ASICs. Therefore, the features of the embodiments described above herein may be implemented in hardware and / or software.

[0122] Figure 9 This is a block diagram of network node 104 according to some embodiments. For example... Figure 9 As shown, node 104 may include: a data processing device (DPA) 902, which may include one or more processors (P) 955 (e.g., a general-purpose microprocessor and / or one or more other processors, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and the like); a network interface 948, including a transmitter (Tx) 945 and a receiver (Rx) 947 to enable node 104 to transmit data to and receive data from other nodes connected to network 110 (e.g., an Internet Protocol (IP) network), network interface 948 being connected to network 110; circuitry 903 (e.g., radio transceiver circuitry), coupled to antenna system 904 for wireless communication with the UE; and a local storage unit (also referred to as a “data storage system”) 908, which may include one or more non-volatile storage devices and / or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where node 104 includes a general-purpose microprocessor, a computer program product (CPP) 941 may be provided. CPP 941 includes a computer-readable medium (CRM) 942 storing a computer program (CP) 943 comprising computer-readable instructions (CRI) 944. CRM 942 may be a non-transitory computer-readable medium, such as, but not limited to, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory), and the like. In some embodiments, the CRI 944 of the computer program 943 is configured such that, when executed by the data processing device 902, the CRI causes node 104 to perform the steps described above (e.g., the steps described above with reference to the flowchart). In other embodiments, node 104 may be configured to perform the steps described herein without code. That is, for example, the data processing device 902 may consist only of one or more ASICs. Therefore, the features of the embodiments described herein may be implemented in hardware and / or software.

[0123] Another embodiment: A1. A method performed by a user equipment (UE), comprising: receiving a master information block (MIB) and / or a system information block (SIB); receiving an indication of the validity of at least a portion of the received MIB and / or SIB, wherein the MIB is carried in a narrowband physical broadcast channel (NPBCH), wherein the SIB is carried in a narrowband physical downlink shared channel (PDSCH), and wherein the indication indicates a validity interval or expiration time.

[0124] A2. The method as described in Example A1, wherein the indication is in GPS or UTC time format.

[0125] A3. The method as described in any of embodiments A1-A2, wherein the indication is quantized at a resolution equivalent to a multiple of the system frame number (SFN) cycle.

[0126] A4. The method as described in any one of embodiments A1-A3 further includes receiving an update notification.

[0127] A5. The method as described in any one of embodiments A1-A4, wherein receiving the instruction includes receiving a system information block (SIB) including the instruction.

[0128] A6. The method as described in any one of embodiments A1-A5, further comprising storing at least a portion of the MIB; entering a sleep state after storing at least a portion of the MIB; waking up from the sleep state after entering the sleep state; and determining, based on a validity indication, whether the stored portion of the MIB is still valid upon waking from the sleep state.

[0129] A7. The method as described in embodiment A6 further includes, since it is determined that the storage portion of the MIB is still valid, receiving a second MIB carried on the NPBCH, and skipping decoding one or more portions of the received second MIB, but decoding one or more other portions of the received second MIB.

[0130] A8. The method as described in embodiment A7, wherein the second MIB includes coded operation mode information indicating an operation mode and a coded access denial (AB) flag, the UE decodes the coded AB flag, and the UE skips the decoding of the operation mode information.

[0131] B1. A method performed by a user equipment (UE) comprising: waking up from a sleep state; determining whether it is necessary to obtain a portion of the Master Information Block (MIB) and / or System Information Block (SIB); and, in response to determining that it is not necessary to obtain a portion of the MIB and / or SIB information, obtaining only the remaining portion of the MIB and / or SIB information.

[0132] B2. The method as described in embodiment B1, wherein the remaining portion includes system frame number (SFN) and access denied (AB) flag information.

[0133] B3. The method as described in any of embodiments B1-B2, wherein obtaining only the remaining portion of the MI and / or SI information comprises decoding the Master Information Block (MIB) carried on the Narrowband Physical Broadcast Channel (NPBCH).

[0134] B4. The method as described in embodiment B3, wherein the decoding further includes using the portion of the MI and / or SI that does not need to be re-obtained to trim the mesh used in the Viterbi decoder.

[0135] B5. The method as described in any of embodiments B1-B2, wherein a “wake-up” signal and / or a “sleep” signal are used to indicate whether downlink control information (DCI) will be sent.

[0136] C1. A user equipment (UE) wherein the UE is adapted to: receive a master information block (MIB) carried in a narrowband physical broadcast channel (NPBCH) and / or a system information block (SIB) carried in a narrowband physical downlink shared channel (PDSCH); and to receive an indication of the validity of at least a portion of the received MIB and / or SIB, wherein the indication indicates a validity interval or expiration time.

[0137] D1. A user equipment (UE) comprising: a first receiving module configured to use a receiver to receive at least one of: (1) a master information block (MIB) carried in a narrowband physical broadcast channel (NPBCH) and / or a system information block (SIB) carried in a narrowband physical downlink shared channel (PDSCH); and a second receiving module configured to use the receiver to receive an indication of the validity of at least a portion of the received MIB and / or SIB, wherein the indication indicates a validity interval or expiration time.

[0138] E1. A user equipment (UE) comprising: a receiver; a transmitter; a data storage system; and a data processing device including a processor, wherein the data processing device is coupled to the data storage system, the transmitter, and the receiver, and the data processing device is configured to: use the receiver to receive at least one of: (1) a Master Information Block (MIB) carried in a Narrowband Physical Broadcast Channel (NPBCH) and / or a System Information Block (SIB) carried in a Narrowband Physical Downlink Shared Channel (PDSCH); and use the receiver to receive an indication of the validity of at least a portion of the received MIB and / or SIB, wherein the indication indicates a validity interval or expiration time.

[0139] F1. A user equipment (UE) wherein the UE is adapted to: wake up from a sleep state; determine whether it is necessary to obtain a portion of the Master Information Block (MIB) and / or System Information Block (SIB); and in response to determining that it is not necessary to obtain a portion of the MIB and / or SIB information, obtain only the remaining portion of the MIB and / or SIB information.

[0140] G1. A user equipment (UE) comprising: a wake-up module for waking up from a sleep state; a determination module for determining whether it is necessary to obtain a portion of the Master Information Block (MIB) and / or System Information Block (SIB); and a decoding module for decoding only the remaining portion of the MIB and / or SIB information in response to determining that it is not necessary to obtain a portion of the MIB and / or SIB information.

[0141] H1. A user equipment (UE) comprising: a receiver; a transmitter; a data storage system; and a data processing device including a processor, wherein the data processing device is coupled to the data storage system, the transmitter, and the receiver, and the data processing device is configured to: wake from a sleep state; determine whether it is necessary to obtain a portion of the Master Information Block (MIB) and / or System Information Block (SIB); and in response to determining that it is not necessary to obtain a portion of the MIB and / or SIB information, obtain only the remaining portion of the MIB and / or SIB information.

[0142] 11. A method performed by a network node (e.g., a base station), the method comprising: transmitting a MIB on an NPBCH; transmitting a SIB on a PDSCH; and transmitting an indication of the validity of at least a portion of the transmitted MIB and / or SIB, wherein the validity indication indicates a validity interval or expiration time.

[0143] I2. The method as described in Example I1, wherein the validity indication is in GPS or UTC time format.

[0144] I3. The method as described in any one of embodiments I1-I2, wherein the validity indication is quantized at a resolution equivalent to a multiple of the system frame number (SFN) cycle.

[0145] J1. A network node, wherein the network node is adapted to: transmit MIBs on NPBCH; transmit SIBs on PDSCH; and transmit an indication of the validity of at least a portion of the transmitted MIBs and / or SIBs, wherein the validity indication indicates a validity interval or expiration time.

[0146] K1. A network node comprising: a first transmission module for transmitting a MIB on an NPBCH using a transmitter; a second transmission module for transmitting a SIB on a PDSCH using a transmitter; and the first transmission module for transmitting an indication of the validity of at least a portion of the transmitted MIB and / or SIB using a transmitter, wherein the validity indication indicates a validity interval or expiration time.

[0147] L1. A network node comprising: a receiver; a transmitter; a data storage system; and a data processing device including a processor, wherein the data processing device is coupled to the data storage system, the transmitter, and the receiver, and the data processing device is configured to: transmit a MIB on the NPBCH; transmit a SIB on the PDSCH; and transmit an indication of the validity of at least a portion of the transmitted MIB and / or SIB, wherein the validity indication indicates a validity interval or expiration time.

[0148] Although various embodiments of this disclosure are described herein (including appendices, if any), it should be understood that they are presented by way of example only and not as limitations. Therefore, the breadth and scope of this disclosure should not be limited to any of the exemplary embodiments described above. For example, although many of the embodiments described above use NB-IoT or LTE-M as examples, the embodiments are not limited to any specific technology or standard, and therefore the embodiments can also be applied to other technologies and any other communication standards, such as, for example, NR. Furthermore, unless otherwise indicated herein or clearly contradicted by the context, this disclosure covers any combination of the foregoing elements in all possible variations.

[0149] Furthermore, although the processes described above and illustrated in the accompanying figures are shown as a sequence of steps, this is merely for illustrative purposes. Accordingly, it is anticipated that some steps may be added, some steps may be omitted, the order of steps may be rearranged, and some steps may be performed in parallel.

[0150] This application claims priority to provisional application No. 62 / 502,423, filed May 5, 2017, which contains an appendix containing the text of a 3GPP document. Certain portions of that document are reproduced below: 1. Introduction In Rel-15, an Enhancement Item (WI) for NB-IoT was approved. The aim is to further enhance NB-IoT performance through further reductions in latency and power consumption, improvements in measurement accuracy, enhanced NPRACH reliability and range, and reduced acquisition time.

[00206] By reducing system acquisition time, the latency and efficiency of NB-IoT can be further improved.

[0151] At the RAN1#88bis meeting, regarding the reduction in system acquisition time, it was agreed that at least the following candidates could be considered.

[0152] • Enhancements to NPSS / NSSS (one or more) • Enhancements to MIB-NB(one or more) • SIB1-NB accumulation across multiple SIB1-NB TTIs (with or without specification effects) The new mechanism allows skipping SIB1-NB and / or SI messages and / or MIB-NB reads. • In addition to the existing SIB1-NB transmissions, transmit additional SIB1-NBs on other subframes. • Use of physical signals / channels in agenda item 7.2.7.1.1 (if introduced). Note: This is in consideration of wake-up or sleep-entry signals.

[0153] • FFS on other SIBx-NBs • All solution details are FFS The solution needs to be backward compatible and take into account the impact on Rel-13 / Rel-14 networks. 2. General Discussion Among the three NB-IoT deployment modes, in-band deployment requires a longer system acquisition time due to lower transmit power levels and punctures that can occur on NPSS and NSSS resources. Additionally, in in-band mode, compared to standalone and guard band modes, the NPDSCH carrying SIB1-NB or SI messages has fewer resource elements in the subframe due to resources being used by LTE CRS or reserved for the LTE downlink control area. This results in a higher coding rate and therefore lower coding gain. Therefore, improvements to reduce system acquisition time should primarily target in-band mode. Solutions that reduce system acquisition time for in-band mode can be directly applied to guard band and standalone modes.

[0154] Recommendation 1: Improvements to reduce system acquisition time should primarily target in-band modes. Solutions that reduce system acquisition time for in-band modes can be directly applied to guard bands and stand-alone modes.

[0155] The system acquisition process after the UE wakes from deep sleep includes the following steps: (1) synchronizing with the NPSS; (2) synchronizing with the NSSS; and (3) acquiring the MIB-NB by receiving the NPBCH. The UE can check the System Information (SI) value label and the Access Denial (AB) flag in the MIB-NB. If the SI value label has not changed and the AB flag is not enabled, the UE has completed the system acquisition process.

[0156] Since MIB-NB and SI are rarely changed (except for SIB-14 and SIB-16), and although the AB flag can be toggled more dynamically, it is more often set to false than true, in most cases, the UE only needs to perform these three steps after waking from deep sleep. One possible remaining uncertainty is the number of super-SFNs (H-SFNs). While MIB-NB contains two LSBs of the H-SFN, the full H-SFN is only acquired when SIB1-NB is obtained. Considering a frequency error of 20 ppm when the UE is in deep sleep, it would take 50,000 SFN cycles in sleep to drift the UE clock by one SFN cycle (i.e., 1024 SFNs or 1 H-SFN), or equivalently 200,000 SFN cycles in sleep to drift the UE clock by 4 SFN cycles (i.e., 4 H-SFNs). If the drift is greater than 4 SFN cycles, the UE needs to acquire two more LSBs than the H-SFN, and therefore needs to acquire the SIB1-NB. However, 200,000 SFN cycles is approximately 23.7 days. If latency is critical for any use case supported by the UE, to avoid requiring the acquisition of the SIB1-NB solely to address timing uncertainties, the UE should have more than 23.7 days of TAU intervals configured in the PSM configuration. Therefore, the focus of Rel-15 should be on improving the acquisition of NPSS, NSSS, and NPBCH. Of these three steps, acquiring NSSS is the easiest. Between NPSS and NPBCH, NPBCH is relatively more straightforward and has less impact on UE complexity and backward compatibility. We propose that Rel-15 should first focus on improving NPBCH performance.

[0157] Proposal 1: Rel-15 should first focus on improving NPBCH performance.

[0158] For in-band deployments, the total overhead on the Rel-13 NB-IoT anchor carrier can be very high, as illustrated in the examples in Table 4. As can be seen, excluding those resource elements carrying the SIB1-NB, the percentage of resource elements available for NPDCCH / NPDSCH symbols can be as low as 42% in the worst-case scenario (in-band, 3 OFDM symbols for LTE PDCCH, and 4 CRS ports). Using more NPBCH repetitions will further reduce the percentage of resource elements available for NPDCCH / NPDSCH.

[0159] Table 4 Overhead on Rel-13 anchor carriers and percentage of resource elements available for NPDCCH / NPDSCH (in-band, 3 OFDM symbols for LTE PDCCH and 4 CRS ports) Due to the overhead of NPBCH 6.0％ Due to the overhead of NPSS 6.9％ Due to the overhead of NSSS 3.5％ Due to the overhead of NRS 8.1％ SIB1-NB 3.0％ Total expenses 58.3％ Sum of percentages of available resource elements for NPDSCH / NPDCCH 41.7％ Opinion 2: On the Rel-13 NB-IoT anchor carrier, excluding those resource elements carrying SIB1-NB, the percentage of resource elements available for NPDCCH / NPDSCH symbols is only 42% in the worst case (in-band, 3 OFDM symbols and 4 CRS ports for LTE PDCCH). Using more NPBCH repetitions will further reduce the percentage of resource elements available for NPDCCH / NPDSCH.

[0160] In the remainder of this document, we focus on solutions for reducing NPBCH acquisition time that (1) do not incur significant additional overhead on the NB-IoT anchor carrier and (2) are beneficial for in-band modes. The solutions considered include (1) a more robust receiver and (2) new mechanisms that allow skipping MIB-NB and SIB1-NB reads.

[0161] 3. A more advanced receiver In [2], cross-subframe channel estimation and advanced MIB-NB decoding techniques were considered. Although cross-subframe channel estimation and its benefits are well understood, advanced MIB-NB decoding techniques [3] require further discussion. In this section, we discuss advanced MIB-NB decoding techniques that allow the UE to jointly decode the signals received by the NPBCH within multiple 640-ms NPBCH TTIs.

[0162] Figure 10 The diagram illustrates the encoding process of MIB-NB. MIB-NB is 34 bits long, with the first 6 bits consisting of 4 MSBs from the SFN and 2 LSBs from the H-SFN. A CRC encoder adds 16 CRC bits, which are subsequently applied using a mask depending on the number of antenna ports used to transmit the NPBCH. After CRC encoding and masking, a 50-bit sequence is encoded by TBCC to produce a 150-bit codeword, which generates a 1600-bit NPBCH codeword based on the LTE rate matching algorithm. On the receiver side, the UE can first cancel rate matching, and therefore the core issue is using the TBCC decoder to process the 150-bit soft value and generate the decoded bit sequence.

[0163] The key code properties to be utilized are that both CRC and TBCC codes are linear codes. Remember, if x1 and x2 are two information vectors over GF(2), and C is a linear code such that C(x... i ) = W iThen C(x1+x2)=W1+W2. Utilizing this linear code property, assuming the MIB-NB information content changed across TTIs is 6 bits of SFN and H-SFN information, joint decoding across multiple NPBCH TTIs can be easily performed. We illustrate how this works below.

[0164] Suppose that the 6-bit SFN and H-SFN information in the first TTI is (s6, s7, s8, s9, h0, h1) = (0, 0, 0, 0, 0, 0), and therefore in the subsequent TTI, it is (1, 0, 0, 0, 0, 0). Here, we use (s6, s7, s8, s9) and (h0, h1) to represent the 4 MSBs of the SFN and the 2 LSBs of the H-SFN, respectively. The difference between the two MIB-NB information vectors (each 34 bits) in two consecutive TTIs is x. Δ = (1, 0, 0, ... 0). Using the linear code attribute, it is possible to use... Figure 11 The process illustrated in the diagram is represented by the calculation w. Δ The difference in TBCC codewords. Here, note the difference with... Figure 10 In comparison, CRC masking is unnecessary because it disappears after applying the difference between the two codewords. Δ This can be considered as an additional scrambling mask applied to the codewords in the second TTI relative to the codewords in the first TTI. Therefore, in order to use the two received codewords for joint decoding, the receiver can use w Δ The second received codeword is descrambled and then soft-combined with the first codeword. Note that this technique can be extended to use more than two TTIs for joint decoding, at the cost of increased soft buffer requirements.

[0165] For MIB-NB, the six frame counter bits (s6, s7, s8, s9, h0, h1) have 64 combinations, but only produce six distinct x values. Δ Vectors and therefore six different w Δ Vectors. This is illustrated in Table 5. In Table 5, we highlight the first new x in blue. Δ Vectors appear. As you can see, many frame counter values ​​share the same x. Δ vector.

[0166] Six different w ΔThe vector requires that the codewords received within two TTIs be combined in six different ways. Therefore, when combining across two TTIs, the decoder memory is increased from 150 soft bits to 900 soft bits. However, the decoder complexity is the same as a regular TBCC decoder, manifested in the number of grid states remaining at 64, with each state having two outgoing branches and two incoming branches. The only twist is that the branch metric computation requires an appropriate selection of versions of the combined received codewords. However, for a given state, the process of determining which version of the combined received codewords to use is deterministic and does not involve additional assumptions.

[0167] Table 5 In frame timer value and x Δ The relationship between them. Although there are 64 possible frame counter values, only 6 are possible x. Δ vector Opinion 3: By utilizing the linear code properties of CRC and TBCC, joint decoding across multiple NPBCH TTIs can be achieved by simply applying an appropriate descrambling mask to the bit soft value before combining TBCC codewords across multiple TTIs.

[0168] Using a more robust NPBCH receiver is the most attractive solution because it does not require additional signaling and therefore does not incur any additional signaling overhead.

[0169] 4. The new mechanism allows skipping MIB-NB and SIB1-NB readings. Since MIBs and SIs rarely change (except for SIB14-NB and SIB16), one way to allow UEs to skip re-obtaining MIB-NBs and SIs that will remain unchanged is to have the eNB indicate the validity interval or expiration time of the MIB-NB and SI information. In the following discussion, we will assume that changes to the AB flag, SIB14-NB, SIB16, SFN, and H-SFN are not used to determine the MI / SI validity interval or expiration time. With such an indication, if the UE wakes up within the validity interval of a version of the MI / SI it previously obtained, it does not need to obtain the same information again. In such cases, the UE only needs to obtain the AB flag, SFN, and H-SFN. To support this approach, two issues need to be addressed: 1) How does the network signal the MI / SI validity interval or expiration time? and 2) How does the UE obtain the AB flag, SFN, and H-SFN without obtaining the complete MIB-NB and SIB1-NB? 4.1 Signal notification MI / SI validity interval or expiration time There are many methods that can be used to signal the validity interval or expiration time of MI / SI. Here are a few possible solutions.

[0170] 4.1.1 The new system information type can be defined to indicate the validity interval or expiration time of the MI / SI. One possible format is to use GPS time or Coordinated Universal Time (UTC). The UE can obtain GPS and UTC time from SIB16 to establish its real-time clock. The new SIB-X can then be used to indicate the GPS or UTC time at which the current MI / SI will expire. The format of SIB-X can be similar to the UTC format used in SIB-16. However, the time resolution in SIB16 is 10ms. For SIB-X, a coarser time resolution can be used to reduce the number of bits required to represent UTC time. One possibility is to quantize UTC time with a resolution equivalent to one or more SFN cycles. Also, the UTC time information in SIB16 includes year and month information. For SIB-X, including year and month information may not be required.

[0171] 4.1.2 The UE can be notified of SIB-X updates via an SI update notification. Such update notifications may be SIB-X specific.

[0172] Proposal 2: Consider eNB signaling notification of MI / SI validity intervals or expiration times. MI / SI validity intervals or expiration times are not affected by changes to the AB flag, SFN, and H-SFN. The exact signaling method is FFS.

[0173] 4.2 The UE obtains the AB mark, SFN, and H-SFN. System acquisition time reduction requires allowing certain configurations to support use cases that require long battery life (e.g., 10-15 years) and a 10ms delay for exception reporting [4]. However, the solution need not meet use cases that transmit data at a lower frequency than, for example, once every three days. For use cases with very infrequent data transmission, a 15-year battery life can already be achieved without further system acquisition time reduction. Considering an oscillator accuracy of 20ppm, the UE clock can be shut down for approximately ±5120ms over 3 days. Therefore, if the UE returns to the network after 3 days, it needs to resolve this time ambiguity. This uncertainty window matches the duration of an SFN cycle, and therefore it uses a 10-bit SFN representation to resolve the time ambiguity. The UE will perform NPSS and NSSS synchronization steps, and after these two steps, it achieves 80-ms framing synchronization in the system frame structure, i.e., it obtains 3 SFNs of the SFN. Therefore, if the UE skips reading the MIB-NB, it needs to obtain 7 MSB bits of the SFN to resolve the time ambiguity. Including the AB flag, a total of 8 bits of information need to be provided to the UE.

[0174] There are two alternatives for how the UE obtains this information, which are described below.

[0175] 4.2.1 Using NPBCH The SFN and AB flags are provided in the NPBCH. The UE can treat all other information elements as known and focus only on decoding the SFN and AB flags. Known information bits can be used to trim the grid, and performance is expected to be significantly improved through grid trimming. In fact, the UE can also check the SI value tag if the MI / SI validity interval or expiration time information, as discussed in Section 4.1, is not provided. By utilizing a more sophisticated NPBCH decoder with known MIB-NB bits, the UE can decode the information elements it needs (e.g., the SFN and AB flags) with less repetition. This helps reduce system acquisition time.

[0176] 4.2.2 Use wake-up or sleep-entry signals Wake-up or sleep-entry signals are discussed as a potential solution for reducing power consumption. The required timing information and AB flag can be bundled with the wake-up or sleep-entry signal. If MI / SI validity interval or expiration time information, as discussed in Section 4.1, is provided, the SI value tag can also be bundled. However, this approach only works for UEs monitoring wake-up or sleep-entry signals.

[0177] 5. Conclusion In this document, we discuss potential solutions that can reduce system acquisition time. Based on the discussion presented in this document, the following comments and suggestions are made.

[0178] Recommendation 1: Improvements to reduce system acquisition time should primarily target in-band modes. Solutions that reduce system acquisition time for in-band modes can be directly applied to guard bands and stand-alone modes.

[0179] Proposal 1: Rel-15 should first focus on improving NPBCH performance.

[0180] Opinion 2: On the Rel-13 NB-IoT anchor carrier, excluding those resource elements carrying SIB1-NB, the percentage of resource elements available for NPDCCH / NPDSCH symbols is only 42% in the worst case (in-band, 3 OFDM symbols and 4 CRS ports for LTE PDCCH). Using more NPBCH repetitions will further reduce the percentage of resource elements available for NPDCCH / NPDSCH.

[0181] Opinion 3: By utilizing the linear code properties of CRC and TBCC, joint decoding across multiple NPBCH TTIs can be achieved by simply applying an appropriate descrambling mask to the bit soft value before combining TBCC codewords across multiple TTIs.

[0182] Proposal 2: Consider eNB signaling notification of MI / SI validity intervals or expiration times. MI / SI validity intervals or expiration times are not affected by changes to the AB flag, SFN, and H-SFN. The exact signaling method is FFS.

[0183] 6. References [1]RP-170852, “Further NB-IoT enhancements”, RAN#75, source Huawei, HiSilicon, Neul, 6–9 March, 2017. [2]R1-1705188, "On system acquisition time reduction", RAN1#88b, sourceEricsson, 3–7April, 2017. [3]R1-152190,PBCH repetition for MTC,Ericsson,RAN1#80bis. [4]3GPP TR45.820 Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT)

Claims

1. A method for reducing the time to obtain system information (SI), the method being performed by a network node and comprising: The user equipment (UE) is notified of the validity interval, which may be 3 hours or 24 hours. Generate a Master Information Block (MIB) which includes a one-bit flag that provides an indication that the systemInfoValueTag has not been changed during the validity interval. as well as The MIB is transmitted to the UE, wherein the validity interval indicates to the UE whether the information contained in the MIB is valid.

2. The method of claim 1, further comprising determining, before generating the MIB, that the systemInfoValueTag has been changed within the past 24 hours.

3. The method of claim 1, further comprising: Update the systemInfoValueTag; Set the SI change flag to a first value to indicate that the systemInfoValueTag has been changed; Activate a timer that will expire after a period of time equal to 24 hours since the timer was activated. If the systemInfoValueTag is further updated while the timer is still running, the timer is reset so that the timer expires after the specified amount of time since the timer was reset. If the timer expires, the SI change flag is set to a second value to indicate that the systemInfoValueTag has not changed within the specified time, wherein The one-bit flag contained in the MIB is set to be equal to the value of the SI change flag.

4. A method for reducing system information (SI) acquisition time, the method being performed by a user equipment (UE) and comprising: Receive validity intervals from network nodes, the validity intervals including 3 hours or 24 hours; Receive a Master Information Block (MIB) from the network node, which includes a one-bit flag; as well as Based on the value of the one-bit flag, determine whether the systemInfoValueTag included in SIB1-BR has not been changed within the validity interval.

5. The method of claim 4, further comprising: After receiving the MIB, a System Information Block (SIB) including the systemInfoValueTag is obtained, wherein the UE obtains the SIB regardless of the value set by the flag.

6. The method of claim 5, further comprising: After obtaining the SIB, a subsequent MIB is received, including a one-bit flag set to a specific value indicating that the systemInfoValueTag has not been changed since a specific point in the past. Determine whether the acquisition of a subsequent SIB can be skipped, wherein the determination includes determining that the flag contained in the subsequent MIB is set to a specific value indicating that the systemInfoValueTag has not been changed; as well as After determining that the acquisition of the subsequent SIB can be skipped, the acquisition of the subsequent SIB, including the systemInfoValueTag, is skipped.

7. The method of claim 6, wherein, Determining whether the subsequent acquisition of the SIB can be skipped further includes the UE determining whether it currently has the latest SIB.

8. A network node for reducing the time required to obtain system information (SI), the network node comprising: processor; A memory having instructions stored thereon, which, when executed by the processor, cause the processor to: The user equipment (UE) is notified of the validity interval, which may be 3 hours or 24 hours. Determine whether the systemInfoValueTag included in SIB1-BR has changed within the validity interval; Generate a Master Information Block (MIB) which includes a one-bit flag that provides an indication of whether the systemInfoValueTag has been changed, and The MIB is transmitted to the UE, wherein the validity interval indicates to the UE whether the information contained in the MIB is valid.

9. The network node of claim 8, wherein the instructions further cause the processor to: Update the systemInfoValueTag; Set the SI change flag to a first value to indicate that the systemInfoValueTag has been changed; Activate the timer, which will expire 24 hours after it was activated; If the timer expires, the SI change flag is set to a second value to indicate that the systemInfoValueTag has not been changed in the past 24 hours; Set the one-bit flag contained in the MIB to be equal to the value of the SI change flag.

10. A user equipment (UE) for reducing the time required to obtain system information (SI), the UE comprising: processor; A memory having instructions stored thereon, which, when executed by the processor, cause the processor to: Receive validity intervals from network nodes, the validity intervals including 3 hours or 24 hours; Receive the Master Information Block (MIB) from the network node, which includes a one-bit flag; and Based on the value of the one-bit flag, determine whether the systemInfoValueTag included in SIB1-BR has not been changed within the validity interval.

11. The UE of claim 10, wherein the instructions further cause the processor to: Upon receiving the MIB, a System Information Block (SIB) including the systemInfoValueTag is obtained, wherein the instructions further cause the processor to obtain the SIB regardless of the value to which the flag is set.

12. The UE of claim 11, wherein the instructions further cause the processor to: After obtaining the SIB, a subsequent MIB is received, including a one-bit flag set to a specific value indicating that the systemInfoValueTag has not been changed since a specific point in the past. Determine whether the acquisition of a subsequent SIB can be skipped, wherein the determination includes determining that the flag contained in the subsequent MIB is set to a specific value indicating that the systemInfoValueTag has not been changed; as well as After determining that the acquisition of the subsequent SIB can be skipped, the acquisition of the subsequent SIB, including the systemInfoValueTag, is skipped.

13. The UE as claimed in claim 12, wherein, Determining whether the subsequent acquisition of the SIB can be skipped further includes the UE determining whether it currently has the latest SIB.

14. A non-transitory computer-readable storage medium having instructions stored thereon, which, when executed on at least one processor, cause the at least one processor to perform the method as described in any one of claims 1-7.

Images