Patent Description:
Generally, in order for a UE to be able to communicate with a network the UE must obtain some system information (SI). Typically, a base station periodically broadcasts a Master Information Block (MIB) that contains SI that is needed by a UE. The base station also transmits different System Information Blocks (SIBs) that may also contain further SI that is needed by the UE. For example, an LTE-M1 base station transmits, for example, a particular SIB that is referred to as "SIB1-BR.

There has been a lot of work in 3GPP lately on specifying technologies to cover Machine-to-Machine (M2M) and/or Internet of Things (IoT) related use cases. Most recent work for 3GPP Release <NUM> includes enhancements to support Machine-Type Communications (MTC) with a new UE category M1 (Cat-M1), supporting reduced maximum bandwidth of up to <NUM> physical resource blocks (PRBs), and Narrowband IoT (NB-IoT) work item specifying a new radio interface (and UE category NB1, Cat-NB1).

We will refer to the LTE enhancements introduced in 3GPP Release <NUM> for MTC as "eMTC", and the further enhancements introduced in 3GPP Release <NUM> as "FeMTC" including (not limiting) support for bandwidth limited UEs, Cat-M1, Cat-M2, and support for coverage enhancements. This is to separate discussion from NB-IoT, although the supported features are similar on a general level.

There are multiple differences between "legacy" LTE and the procedures and channels defined for eMTC or FeMTC work (likewise for NB-IoT). Some important differences include new physical channels, such as the physical downlink control channels (PDCCH), called MPDCCH in eMTC and NPDCCH in NB-IoT, and a new physical random access channel, NPRACH, for NB-IoT.

For system information (SI) (both eMTC and NB-IoT) there is no dynamic scheduling of either SIB1-BR/SIB1-NB (scheduling information included in MIB/MIB-NB), or system information messages (fixed scheduling inside system information window provided in SIB1-BR/SIB1-NB). Both eMTC and NB-IoT support coverage enhancements, and the UE may have to accumulate several repetitions of system information broadcast in order to be able to successfully decode it. This means that system information acquisition time will in practice be longer the worse coverage the UE is in. In order to combat this, more dense repetitions for some physical channels and system information was introduced in eMTC and NB-IoT Release <NUM>. The drawback of this is an increase in system overhead (i.e., more radio resources are consumed by continuous ("always-on") control signaling broadcast). The system acquisition procedure is in general the same for eMTC and NB-IoT as for LTE: the UE first achieves downlink synchronization by reading PSS/SSS, then the UE reads the MIB, then SIB1 (e.g., SB1-BR), and finally the SI-messages are acquired (each possibly containing multiple SIBs).

At the 3GPP RAN#<NUM> meeting, a new Release <NUM> work item named Narrowband IoT (NB-IoT) was approved. The objective is to specify a radio access for cellular internet of things (IoT) that addresses improved indoor coverage, support for massive number of low throughput devices, not sensitive to delay, ultra-low device cost, low device power consumption and (optimized) network architecture.

For NB-IoT, three different operation modes are defined, i.e., stand-alone, guard-band, and in-band. In stand-alone mode, the NB-IoT system is operated in dedicated frequency bands. For in-band operation, the NB-IoT system can be placed inside the frequency bands used by the current LTE system, while in the guard-band mode, the NB-IoT system can be operated in the guard band used by the current (legacy) LTE system. NB-IoT can operate with a system bandwidth of <NUM>. When multiple carriers are configured, several <NUM> carriers can be used, e.g., for increasing the system capacity, inter-cell interference coordination, load balancing, etc..

In order to adapt to certain use cases that requires more capacity than usual, e.g., software or firmware upgrade, multi-carrier operations are used. The NB-IoT device listens to the system information on the anchor carrier, but when there is data, the communication can be moved to a secondary carrier.

Some background information can be found in <NPL>, and "<NPL>.

During Release <NUM>, some potential problems related to long system information acquisition time were identified by RAN4. Reducing the system acquisition time is also one of the agreed work item objectives for Release <NUM> for eMTC. More specifically, RAN1 generally outlines some areas in which RAN2 could provide improvements (on top of the considered RAN1 improvements). In principle, this is just raising the question to RAN2 whether some SI broadcast messages could be skipped by the UE in some situations, and the case of most interest here is skipping SIB1-BR reading). For reference, the content of the LTE-M MIB is shown below in Table <NUM>:
<IMG>.

The most noticeable difference to NB-IoT is that, in NB-IoT, the valueTag is not present in MIB but is instead located in SIB1-BR.

There currently exist certain challenge(s). The SIB1-BR contains the following: i) access information, ii) system information valueTag, iii) hyper system frame number (H-SFN), iv) a bitmap indicating the valid subframes, v) the starting OFDM symbol for MPDCCH and PDSCH (essentially replacing PCFICH), and vi) scheduling information of other SI messages.

Due to the access-related info, valid subframe indication, etc. it is very difficult or even impossible for UEs to skip reading SIB1-BR for initial acquisition. However, for re-acquisition of SI it could be a viable option, e.g. for UEs waking up from eDRX or PSM. In most cases, SI has not changed in the cell, but the UE must still ensure this is the case by reading the system information valueTag. One approach would therefore be to put the valueTag directly in MIB. However, this is problematic for several reasons. First, the valueTag is <NUM> bits, but there are only <NUM> spare bits left in MIB. It is highly unlikely that eMTC is allowed by 3GPP to use up all the remaining spare bits intended for any future use for LTE in general. Moreover, some of the MIB spare bits will likely be used for other purposes, still related to `reduced system acquisition time' e.g. to have the access barring enabled flag (ab-Enabled) in MIB as for NB-IoT. Another problem with including the valueTag in the MIB is that this will result in broadcasting redundant information, in worst case <NUM> bits, increasing the system overhead. Another approach is to use fewer bit for the valueTag (e.g., <NUM> bits instead of <NUM>). With <NUM> bits the network can update the system information up to <NUM> times during the SI validity time of <NUM> or <NUM> (this is up to the configuration). If a valueTag of fewer than <NUM> bits is used instead, this means that the network will be restricted to change SI fewer than <NUM> times (e.g., <NUM> or <NUM> times) during the SI validity time. This is a quite intrusive change to legacy operation, e.g. a <NUM> bit valueTag would mean that the network can only update the SI <NUM> times during this period.

Certain aspects of the present disclosure and their embodiments provide solutions to these or other challenges. For example, certain embodiments presented herein make use of an indication (a one bit flag) in the MIB that is set to a particular value if the UE needs to read certain SI (e.g. SIB1-BR), otherwise the MIB indication is set to a different value. This MIB indication is unlike a valueTag in the sense that upon any change of the certain SI (e.g. SIB1-BR) and the systemInfoValueTag therein, in the simplest case the flag is changed from '<NUM>' to '<NUM>', indicating that UEs can no longer omit reading the certain SI (e.g. SIB1-BR), but at a subsequent change of certain SI (e.g. SIB1-BR) the flag is still set to '<NUM>' for the remainder of a certain time period. Only using <NUM> bit out of the MIB spare bits provides a clear advantage to all UEs when SIB1-BR/systemInfoValueTag is not updated, which is most often the case. If the SI has been updated, UEs will simply follow Release <NUM> procedures. The above described solution, which reduces the need for UEs to acquire SIB1-BR (to check system valueTag, etc.) greatly improves system access time and UE battery life.

There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. Certain embodiments may provide one or more of the following technical advantage(s). UEs can skip reading SIB1-BR for SI re-acquisition, thereby improve UE system acquisition/access time and extend UE battery life; and the solution uses only <NUM> of the MIB spare bits, thereby efficiently using scarce resources.

The problems described herein are overcome by the invention defined in the appended claims.

These and other embodiments are further described herein. The parts of the description which do not relate to the use of a MIB indication as depicted by <FIG> are provided for information purposes only and do not describe the claimed invention.

Cat-M1, Cat-M2, Cat-N1 and Cat-N2 UEs in poor coverage may experience long system acquisition time. It is identified in [<NUM>] [<NUM>] that in some cases for both NB-IoT and LTE-M (eMTC), it may take long time to acquire the system information. Therefore, one objective for both LTE-M and NB-IoT further enhancements in Rel-<NUM> is to reduce system acquisition time.

In this disclosure, we propose methods and systems that enable a NB-IoT UE to skip acquisition of certain master information (MI) in the master information block (MIB) and/or certain system information (SI) in some system information blocks (SIBs). The proposed methods include the embodiments as follows.

(<NUM>) Signal the MIB/SIB validity interval or expiration time in a new system information block (SIB). We will refer to this new SIB as SIB-X, to be differentiated those system information blocks that are already defined for NB-IoT.

(<NUM>) Mechanism for allowing a UE skipping MI/SI acquisition to acquire one or more of Access Barring flag, System Information Number, and Hyper System Information number.

A UE can skip reading the master information block (MIB) (or parts thereof) carried in Narrowband Physical Broadcast Channel (NPBCH) or certain System Information Blocks (SIBs) (or parts thereof) carried in Narrowband Physical Downlink Shared Channels (PDSCH), when the essential master information or system information has not been changed since the last time the UE acquires them. Not having to re-acquire up-to-date MI/SI, the UE reduces energy consumption and therefore enjoys longer battery lifetime. Furthermore, the latency of UE establishing access to the network when it has data to send is reduced.

The NB-IoT system information is outlined below:.

NB-IoT master information block (MIB-NB) consists of the following information:.

NB-IoT further define the following system information types:.

The LTE-M system information is outlined below:.

The LTE-M master information block (MIB-NB) consists of the following information:.

LTE-M further define the following system information types:.

Among these different types of master and system information, only SFN, H-SFN, ACB (LTE-M) and AB flag (NB-IoT), SIB14(-NB) and SIB16 are typically changing more dynamically. The other information is rarely changed. SIB <NUM> is not needed when the UE access the network. SIB14(-NB) is not needed if the AB flag is not set for NB-IoT, or if SIB14 is not scheduled in SIB1-BR for LTE-M. Thus, in most occasions, only SFN, H-SFN, and AB flag (or ACB plus SIB-<NUM> scheduling for LTE-M) need to be acquired.

Since most of MIB and SI rarely changes, one way to allow the UE to skip reacquiring MIB(-NB) and SI that will remain unchanged is to have eNB indicate the validity interval or the expiration time of MIB(-NB) and SI information beforehand. (In the below description, we will assume that changes of 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 indication, if the UE wakes up within the MI/SI validity interval of the version that it has acquired previously, there is no need to reacquire the same information. In such scenarios, the UE only needs to acquire only AB flag, SFN and H-SFN (or ACB plus SIB <NUM> scheduling in SIB <NUM>-BR for LTE-M), and not necessarily all other information elements contained in MIB-NB and SIB1-NB. To support this method, there are two issues that need to be addressed.

How does the network signal the MI/SI validity interval or expiration time?.

How does the UE acquire AB flag (or ACB plus SIB14 scheduling in SIB1-BR for LTE-M), SFN and H-SFN if it knows that all the other MI/SI information stays the same?.

Methods for addressing these issues are described below.

A new system information type can be defined to indicate MI/SI validity interval or expiration time. One possible format is to use GPS time or Coordinated Universal Time (UTC). A UE can acquire GPS and UTC time from SIB16 to establish its real-time clock. A new SIB-X can then be used to indicate the GPS or UTC time that the current MI/SI will expire. The format of SIB-X can be similar to the UTC format used in SIB16. However, in SIB16 the time resolution is <NUM>. For SIB-X, much coarse time resolution can be used to reduce the number of bits needed to represent the UTC time. One possibility is to quantize the UTC time with a resolution equivalent to one or multiple SFN cycles. Also, the UTC time information in SIB16 includes year and month information. For SIB-X, it may not be necessary to include year and month information.

A UE can be notified of an update of SIB-X via SI update notification. Such an update notification may be specific to SIB-X.

System acquisition time reduction needs to allow certain configurations to support use cases that requires long battery lifetime (e.g. <NUM>-<NUM> years) and <NUM> latency for sending exception report such as alarm signal. However, it is not necessary for a solution to cater for use cases that only transmit data less frequently than once every three days as we believe for such use cases, <NUM> years battery lifetime can already be achieved without further system acquisition time reduction. Consider <NUM> ppm oscillator accuracy, the UE clock may be off by approximately ±<NUM> in <NUM> days. Thus, if the UE comes back to the network after <NUM> days, it needs to resolve this time ambiguity. This uncertainly window matches the duration of one SFN cycle, and thus it takes <NUM> bits SFN representation to resolve the time ambiguity. The UE will go through the steps of NPSS and NSSS synchronization, and after these two steps it achieves synchronization to <NUM>-ms framing in the system frame structure, i.e. it acquires the <NUM> LSBs of SFN. Thus, if the UE skips reading MIB-NB, it needs to get the <NUM> MSBs bits of SFN to resolve the time ambiguity. Adding the AB flag, overall an <NUM>-bit information needs to be provided to the UE.

There are two alternatives of how a UE can acquire such information. We proposed two alternatives below.

The SFN and AB flag are provided in MIB carried in NPBCH. The UE can treat all the other information elements as known and only focus on decoding SFN and AB flag. The known information bits can be used to prune the trellis used in the Viterbi decoder and it is expected that the performance can be significantly improved with trellis pruning. In fact, the UE may also check the SI value tag if the MI/SI validity interval or expiration time information as discussed in Section <NUM> is not provided.

A "go-to-sleep" signal is used to indicate that there will not be any down-link control information (DCI) sent during the NPDCCH/MPDCCH search space that follows. Upon receiving such a signal, the UE goes back to the sleep mode. However, if the go-to-sleep" signal is not detected, the UE has to stay up to attempt to decode the DCI carried in NPDCCH/MPDCCH.

On the other hand, "wake-up" signal is used to indicate that there will be one or more DCIs during sent in the coming NPDCCH/MPDCCH search space. Upon receiving such a signal, the UE needs to stay up to attempt to decode the DCI carried in NPDCCH/MPDCCH. However, if the "wake-up" signal is not present, the UE can go back to sleep. The "wake-up" signal can be sent in subframe(s) before the starting of NPDCCH/MPDCCH search space or at the beginning of the NPDCCH/MPDCCH search space. Also, the "wake-up" signal does not necessary to occupied one or several entire subframe (s). The signal can use partial of the subframes, either in time or frequency domain, e.g., first several symbols in a slot, or a combination of time or frequency domain.

At the time of this writing there is no decision in 3GPP whether the "go-to-sleep" signal and/or the "wake-up" signal approaches will be adopted. However, the approach described here applies notwithstanding whether one or both of these signal approaches are adopted.

One use case of "go-to-sleep" signal and/or the "wake-up" signal is to provide indication to a UE whether this is a paging DCI coming in the next paging occasion that a UE needs to monitor. Therefore, it is expected the "go-to-sleep" signal and/or the "wake-up" signal should be periodic. In addition to indicating whether there is a paging DCI coming in the next paging occasion that a UE needs to monitor, we can take advantage of the periodicity of the "go-to-sleep" signal and/or the "wake-up" to include either partly of the <NUM>-bits or all the <NUM>-bits can be provided in the "go-to-sleep" signal and/or the "wake-up" signal.

All the <NUM>-bit information are provided to all the UEs together with the indication of whether this is a paging DCI coming in the next paging occasion that a group UE needs to monitor. All the UEs can listen to this periodic "go-to-sleep" signal and/or the "wake-up" signal for the information that they are interested, i.e., the <NUM>-bit information provided above. For the UEs that are not being paged in the nearest paging occasion, it can simply ignore the indication of the paging related information.

Part of the <NUM>-bit information are provided to the UE together with the indication of whether this is a paging DCI coming in the next paging occasion that a UE needs to monitor. This can be the AB flag, or the timing information.

In addition to the timing and AB flag information, the SI value tag which is used to indicate whether SIBs are changed can also be included in the "go-to-sleep" signal and/or the "wake-up" signal. Notice that it is also possible to only include the SI value tag in the "go-to-sleep" signal and/or the "wake-up" signal.

In the "go-to-sleep" signal and/or the "wake-up" signal we can further include indications to the UE whether it can skip some of the SIBs and/or the MIB reading when being paged.

In the "go-to-sleep" signal and/or the "wake-up" signal we can further include indications to the UE when was the previous time the MIB has changed, e.g., using a time stamp or a version number of other mechanisms. If the UE has the latest version of the MIB, it can skip read the MIB.

Notice that some of the above mentioned alternatives may be combined together to reduce the system acquisition time also.

In NB-IoT, MasterInformationBlock-NB (MIB-NB) scheduling is fixed with a periodicity of <NUM> and with L1 repetitions in between, i.e. in every sub-frame <NUM>. MIB-NB is sent on NPBCH. The MIB-NB contains:.

Due to the <NUM> MSB bits of the SFN in MIB-NB, the MIB-NB content is changed every <NUM>. Besides the SFN the modification period equals <NUM> sec.

SIB1-NB scheduling is fixed with a periodicity of <NUM> sec. SIB1-NB is broadcasted in every second sub-frame <NUM>. SIB1-NB is sent on DL SCH. The number of NPDSCH repetitions are indicated in MIB-NB (schedulingInfoSIBl). SIB1-NB has a modification period of <NUM> sec, i.e. only after <NUM>,<NUM> sec the SIB1-NB content may change.

SIBs other than SIB1-NB are sent in SI-messages, which are sent on DL SCH. An SI message may contain one or more SIBs, as indicated in the scheduling info in SIB1-NB.

The content of these other SIBs may change after the BCCH modification period. The BCCH modification period is larger or equal to <NUM> and indicated in SIB2-NB (modificationPeriodCoeff * defaultPagingCycle). SIB change (content and/or scheduling) is indicated by systemInfoValueTag in MasterInformationBlock-NB or systemInfoValueTagSI in SystemInformationBlockType1-NB.

The Access Barring parameters in SIB14-NB can change at any point in time (section <NUM>. <NUM> in TS <NUM> [<NUM>]), and such change does not impact systemInfoValueTag in MasterInformationBlock-NB or systemInfoValueTagSI in SystemInformationBlockType1-NB.

The content in the other SIBs is not expected to change frequently, except for SIB14-NB during congestion periods.

As the problem identified in [<NUM>] is that for some cases it may take longer than <NUM> sec to acquire some of the SIBs, the UE may have difficulties to perform combining efficiently across the modification period boundary.

Therefore, the network would then base on the needs to provide a longer modification period than <NUM> sec a UE can assume when decoding MIB-NB, SIB1-NB and SIB2-NB. Recall that BCCH modification period is indicated in SIB2-NB. Certainly, new values can be defined and signal to the UE. Considering the backward compatible issue, the network can configure the new values in a multiple of <NUM> sec. This would not have impact on legacy NB-IoT UEs, which would still assume a modification period of <NUM> sec for MIB-NB and SIB <NUM>-NB.

Since there are several spare bits in the MIB-NB, we can use some of the spare bits to indicate whether the modification period of <NUM> sec is extended, e.g., in a multiple of the <NUM> sec or other values that the network prefers.

We can use one of the SIBs to indicate whether the modification period of <NUM> sec is extended is extended, e.g., in a multiple of the <NUM> sec or other values that the network prefers.

We can use one of the dedicated signaling to a specific group of UEs to indicate whether the modification period of <NUM> sec is extended, e.g., in a multiple of the <NUM> sec or other values that the network prefers.

Other methods to indicate whether the modification period <NUM> sec is extended, e.g., in a multiple of the <NUM> see or other values that the network prefers.

In addition to the alternative listed above, in order to provide flexibility at the network, the network would also inform the UEs if the extended modification period is active or not.

Notice that the approach listed above is discussed in the context of NB-IoT, but can also be applied to LTE-M, which has a different modification period.

As shown in <FIG>, a UE <NUM> may be in communication with a network node <NUM> (e.g., a base station, such as, for example, an LTE base station ("eNB") or <NUM> base station ("gNB")). For example, UE <NUM> may communicate with network node <NUM> using M2M, MTC, or IoT type communication patterns. UE <NUM> may transition to sleep mode in which it does not actively communicate with network node <NUM> and may, when prompted by network node <NUM> or on its own initiative, wake up from its sleep mode and begin communication with network node <NUM> once more.

<FIG> illustrates a method <NUM>, which may be implemented on UE <NUM>. UE <NUM> receives a master information block (MIB) and/or a system information block (SIB) (step202). UE <NUM> receives an indication of validity of at least a portion of the received MIB and/or SIB (step <NUM>). The MIB is carried in a Narrowband Physical Broadcast Channel (NPBCH), the SIB is carried in a Narrowband Physical Downlink Shared Channel (PDSCH), and the indication indicates a validity interval or expiration time.

According to some embodiments, the indication is in GPS or UTC time format, and/or the indication is quantized with a resolution equivalent to a multiple of System Frame Number (SFN) cycles. In some embodiments, the method further includes receiving an update notification. In some embodiments, receiving the indication comprising receiving a system information block (SIB) comprising the indication.

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

In some embodiments, the method further includes, as a result of determining that the stored 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. In some embodiments, the second MIB comprises encoded operating mode information indicating an operation mode and encoded access barring (AB) flag, the UE decodes the encoded AB flag, and the UE skips the decoding of the operating mode information.

<FIG> illustrates a method <NUM>, which may be implemented on UE <NUM>. UE <NUM> wakes up from a sleep state (step <NUM>). UE <NUM> determines if a portion of a master information block (MIB) and/or system information block (SIB) needs to be reacquired (step <NUM>). UE <NUM>, in response to determining that a portion of MIB and/or SIB information does not need to be reacquired, acquires only the remaining portion of MIB and/or SIB information (step <NUM>).

In some embodiments, the remaining portion includes System Frame Number (SFN) and Access Barring (AB) flag information. In some embodiments, acquiring only the remaining portion of MI and/or SI information includes decoding a Master Information Block (MIB) carried on the Narrowband Physical Broadcast Channel (NPBCH), and mayt further include using the portion of MI and/or SI that does not need to be reacquired to prune the trellis used in the Viterbi decoder.

In some embodiments, a "wake-up" signal and/or a "go-to-sleep" signal is used to indicate whether Downlink Control Information (DCI) will be sent.

<FIG> illustrates a method <NUM>, which may be implemented on network node <NUM>. Network node <NUM> transmits a MIB on the NPBCH (step <NUM>). Network node <NUM> transmits a SIB on the PDSCH (step <NUM>). Network node <NUM> transmits an indication of 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 is in GPS or UTC time format. In some embodiments, the validity indication is quantized with a resolution equivalent to a multiple of System Frame Number (SFN) cycles.

For LTE-M the system value tag is, unlike for NB-IoT, located in SIB1-BR. A UE waking up from eDRX or PSM would therefore have to read SIB1-BR in order to find out whether SI has been updated and if it must reacquire the SI (either full information or the SIBs as indicated by the SI-message specific valueTags in systemInfoValueTagList). Further the UE may have to check whether it is subject to access barring or not. In LTE-M, UEs must not be barred according to both the ACB information in SIB2 and the enhanced access class barring (EAB) information in SIB14 in order to access. Typically SIB14 is only scheduled and broadcast when EAB is enabled so if it is not according to scheduling info in SIB <NUM>-BR the UE can interpret this as access is allowed according to EAB. In most cases, SI has not been updated and the UE is not barred, however the UE must still check to ensure this is the case. In Release <NUM> operation, this means that the UE has to read SIB1-BR and SIB2. Spare bits in the MIB could be used, however, to signal to the UE that the UE may skip acquiring SIB1-BR.

As described above, it is highly unlikely that 3GPP will agree to use all the <NUM> MIB spare bits for all future of LTE for the systemInfoValueTag, which is already present in SIB1-BR. A solution for eMTC to skip reading SIB1-BR is therefore to have a short indication in the MIB (e.g., a one bit flag). This short indication in the MIB is referred to herein as "the MIB indication. " Generally, a UE should only skip reading SIB1-BR during re-acquisition of SI since SIB1-BR is, in many cases, essential for access and hence required for initial access.

Because SIB1-BR (and the systemInfoValueTag therein) is rarely updated, it is advantageous to have a MIB indication (e.g., flag) that is set to <NUM> to indicate that SIB1-BR/systemInfoValueTag has been updated at some point during a certain period of time (e.g., during a current period of time or the period of time immediately preceding the current period), and set the MIB indication to <NUM> to indicate otherwise (i.e., UE may skip reading SIB1-BR when the MIB indication is set to <NUM>, otherwise UE should not skip reading SIB1-BR). That is, if SIB1-BR has not been updated during the certain time period, which is most often the case, the MIB indication is set to '<NUM>' and the UE can skip reading the SIB1-BR and the systemInfoValueTag. If there is a subsequent SIB1-BR change during the time period the MIB indication remains set to '<NUM>' and is not toggled back to '<NUM>' (i.e. unlike a valueTag). The MIB indication may be reset to '<NUM>' at the time period boundaries (e.g., if there has been no change to the SIB1-BR within the last X units of time (i.e., the certain time period)). Note that since the system valueTag and the scheduling information of the SI-messages are located in SIB1-BR, SIB1-BR will be updated if any of the SI messages are updated.

In some embodiments, using the MIB indication, the UE is required to check the MIB indication once per the MIB indication time period (e.g., in the last BCCH modification period of the time period). That is, if the UE skips a time period, the SIB <NUM>-BR might have been updated during that period and this will then not be discovered by the UE. The MIB indication time period could be:.

<NUM>) The system information validity period or <NUM> or <NUM>. Since the UE is required to check the MIB once per predefined time period (e.g., at least once every <NUM> or <NUM> hours), if a <NUM> bit indication is used, this has the advantage that it is considerably longer than the BCCH modification period and hence the UE is required to do so much more infrequently.

<NUM>) A HSFN period. The time period is based on system frame number (SFN) and/or hyper system frame number (HSFN). The latter is more probable since a longer timer period is more effective. <NUM> bits is used for SFN, giving a SFN wrap-around after <NUM> seconds. <NUM> bits is used for HSFN giving <NUM> SFN periods which equals ~<NUM> hours. A likely embodiment is to use <NUM>" SFN periods as the time period, where n is the HSFN. This time reference would be common to all UEs.

A UE in DRX or eDRX that is in coverage would rely on being notified in paging whenever there is an update of SI, i.e. by checking systemInfoModification or, if the eDRX cycle is longer than the BCCH modification period, the systemInfoModification-eDRX in the paging message. With solutions described herein, the UE could potentially instead check the MIB indication once per time period (since SIB1-BR contains the system valueTag, this is potentially less energy-consuming than attempting to find the systemInfoModification indication at least modificationPeriodCoeff times during the modification period (refer to section <NUM>. <NUM> in 3GPP TS <NUM> v <NUM>. Further, as explained in 3GPP TS <NUM>, for UEs with eDRX longer than the BCCH modification period, UEs are required to read SIB1-BR before access: "When the RRC IDLE UE is configured with a DRX cycle that is longer than the modification period, and at least one modification period boundary has passed since the UE last verified validity of stored system information, the UE verifies that stored system information remains valid by checking the systemInfoValueTag before establishing or resuming an RRC connection.

In case there has been no SI update, the UE applying the solutions described herein advantageously only needs to acquire MIB and check the MIB indication and skip acquisition of SIB1-BR.

For a UE in power-saving mode (PSM), the UE will reside in a power-saving state (sub-state to RRC_IDLE) and before "keep-alive" signaling/checking for downlink data through the periodic Tracking Area Update (TAU) or before uplink data transmission, the UE must ensure it has up-to-date SI. In Release <NUM> and <NUM> operation, the UE would check that it has already acquired the up-to-date SI by checking the valueTag (i.e. systemInfoValueTag) in SIB1-BR. With the solutions described herein, the UE could acquire only MIB to check the MIB indication and skip reading SIB1-BR if and only if the time since the last uplink data transmission or periodic-TAU does not surpass the MIB indication time period (e.g., <NUM> or <NUM>) and the MIB indication is set to a particular value, which could be <NUM> or <NUM>. For example, if the time period chosen for the described solutions is the HSFN wrap-around of <NUM>, the UE would not have to read SIB1-BR (assuming its content has not been updated of course) if it is configured with a periodic-TAU that is shorter than <NUM>. Again, in the rare case that SI has been updated, then the UE will just continue to read SIB1-BR as in Release <NUM> operation.

An example of the functionality of the MIB indication is given in <FIG>. In this case, the time period is based on HSFN using <NUM> HSFN bits, which makes it <NUM> radio frames long. The BCCH modification period is here <NUM> radio frames. As in Release <NUM> operation, the UEs are notified in paging when SI is to be updated, and the new SI will start to be broadcast in the subsequent BCCH modification period.

In general, the MIB indication would be set to a first particular value (e.g., <NUM>) whenever UEs are required to read SIB1-BR, and set to a second particular value (e.g. <NUM>) otherwise. There are alternative embodiments on how this could be done. In the embodiment shown in <FIG>, the indication is set to <NUM> when the valueTag (i.e. systemInfoValueTag) is changed and remains set to <NUM> during the time periods after which SIB1-BR and SI has been updated. Alternatively, the MIB indication can be set to <NUM> even before the SI is updated, e.g. already in the preceding BCCH modification period in which UEs are notified in paging about the upcoming SI update (not shown in <FIG>). In the above embodiment in which the MIB indication is set to <NUM> during the entire subsequent time period, it is sufficient that the UE checks the MIB indication once per time period and can do so at any time (i.e., if the SI is updated at the end of the time period after the UE has checked it still not go unnoticed since the UE will notice this the subsequent time period).

In one alternative embodiment, UEs could be required to check the MIB indication during the last BCCH modification period (and before access as always of course) in which case the MIB indication could always be reset to '<NUM>' at the time period boundaries. Thus, ensuring that the UE will still be notified about the SIB1-BR update if it is updated at the end of the time period. However, since SI is updated rarely, the benefit of this embodiment is likely negligible to the previous one and in general it may be better to have the MIB indication set to '<NUM>' for longer to avoid error cases (since setting it to '<NUM>' means that UEs will fall back to Release <NUM> operation). Therefore, in yet another embodiment the MIB indication could be set to '<NUM>' more extensively in time before and after a SI and SIB1-BR update. For example, the MIB indication could be set to '<NUM>' during the entire time period preceding the SI update, and/or set to '<NUM>' during the entire time period during the SI update, and/or set to '<NUM>' during the entire time period after the SI update.

The above embodiments use a <NUM> bit MIB indication, but additional embodiments using more bits is possible. For example, <NUM> bits could be used to indicate the following:.

In one embodiment, the time period is the HSFN period. Further Ni could be linear, e.g. N<NUM>=<NUM>, N<NUM>=<NUM> and N<NUM>=<NUM>. In an alternative embodiment, Ni could be non-linear, e.g. logarithmic such that Ni=<NUM>, N<NUM>=<NUM> and N<NUM>=<NUM>, or Ni=<NUM>, N<NUM>=<NUM> and N<NUM>=<NUM>. This would provide finer granularity of the information communicated to the UE (the UE would compare to when it last acquired SI) and it can be used to achieve gains beyond the HSFN period of <NUM>. That is, if it is agreed to base the time period on SFN, UE would have to check the indication in MIB at least once every <NUM>, but using multiple indication bits as above this could be extended such that UEs using PSM with very long periodic TAU (can be configured to be almost <NUM> days) could benefit from the solutions described herein, and would only need to acquire MIB at wake-up if there has been no SI update.

In some further embodiments, the time period itself associated with the <NUM> bit indication can be set/modified in a system information message. Similarly, the value of at least one of N<NUM>, N<NUM> and N<NUM> in the example <NUM>-bit indication embodiment above may be modified. Default values may be given by the standard, and these values will be used if a corresponding modified value is not provided as a part of the broadcasted system information. This increases the flexibility in the network to adapt to different deployment scenarios, configurations of eDRX and PSM, etc..

Note that the MIB indication is a systemInfoValueTag-indication in the sense that if any of the content of SIB1-BR is changed systemInfoValueTag is updated. However, in yet another embodiment the UE could still skip acquiring SIB1-BR although systemInfoValueTag has been updated. That is, a first bit is, as above, used to specify if the UE needs to acquire SIB1-BR or can skip it, whereas the additional bits specify what has changed in SIB1-BR.

The additional bits could for example indicate: (<NUM>) whether the update is related to other SI than SI required for monitoring paging (UEs in eDRX waking up to check paging could then still skip SIB1-BR acquisition); (<NUM>) whether the update is related to other SI than SI required for access (UEs attempting random access and RRC Connection Setup etc. could then still skip SIB1-BR acquisition); (<NUM>) any specified (group of) SIBs. And if the UE does not require any of that it can still omit reading SIB1-BR.

An example process <NUM> for UE operation is shown in <FIG>. The process <NUM> begins when the UE determines whether the MIB indication is set to a particular value (e.g. <NUM> or <NUM>) (step s602). This MIB indication may be a <NUM> bit MIB indication, but may also include additional bits, as described in more detail above. If the UE determines that the MIB indication is set to the particular value (e.g., <NUM>), the UE can skip acquiring the SIB1-BR (step s604). However, if the UE determines that the MIB indication is not set to the particular value (e.g., is set to <NUM>), then the UE will acquire the SIB1-BR (step s606).

An example process <NUM> for network node (e.g., eNB) operation is shown in <FIG>. The example process <NUM> begins when the network node determines whether a SIB1-BR update occurred during the previous or current time period (step s702). If no, no MIB indication is set (step s704). If yes, the network node sets a MIB indication (step s706). In the case of a <NUM> bit MIB indication "set MIB indication" would correspond to e.g. setting it to value ` <NUM>' and that it is not set would correspond to value '<NUM>'. Note also that the logic of when it should be set to ` <NUM>' by the eNB will depend on the embodiments as discussed above. After these steps, the network node determines whether a MIB indication time period has ended (step s708). If no, the network node repeats the previous steps, determining whether a SIB1-BR update has occurred. If the MIB indication time period has ended, the MIB indication may be reset by the network node (step s710). According to certain embodiments, this resetting may depend on other factors, including past and/or upcoming SIB1-BR updates.

The standard impact of the proposed solutions would be procedure text for the UE and updated MIB content, for which an example is shown below (changes in bold font):
<IMG>.

The solutions proposed herein are described for eMTC but would be generally applicable also to other systems such as LTE or NR (but not needed for NB-IoT since there the system valueTag is located directly in MIB-NB).

In another embodiment, the MIB one bit flag could be used with the following meaning:.

Bit set to `<NUM>'=SI has not been updated since the last BCCH modification period boundary and access barring (ACB or EAB) is currently not enabled in the cell.

Bit set to ` <NUM>'=SI has been updated since the last BCCH modification period boundary or access barring (ACB or EAB) is currently enabled in the cell.

Note that this is not a valueTag and if the SI changes a second time to bit is not toggled back to value '<NUM>'. In an alternative embodiment the time period for the SI update is different from the BCCH modification period, e.g. multiple BCCH modification periods, the SIB1-BR modification period, or the SI validity time of <NUM>/<NUM>.

In alternative embodiments multiple bits could be used to indicate more options, e.g. according to the following:.

Alternatively, either SI update or Access Barring could be omitted, or they could be indicated by separate bits.

Alternatively, this indication could be added to the Wake-up and go-to-sleep signal as described above.

According to the above, in one aspect there is provided a method, performed by a network node (e.g., network node <NUM>), for reducing SI acquisition time. In one embodiment, the method includes the following steps: (<NUM>) generating a MIB comprising a one bit flag for indicating whether or not certain SI (e.g., value Tag) has changed since a particular time in the past (e.g., <NUM> hours ago, <NUM> hours ago, etc.) and (<NUM>) transmitting the MIB. In some embodiments, the particular time in the past is based on the current time and a MIB indication time period (e.g., <NUM> or <NUM> hours). In some embodiments, the particular time in the past is the current time minus the MIB indication time period. In other embodiments, the particular time in the past is a certain absolute time period boundary.

In some embodiments, the method also includes the network node performing the following steps: updating the 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 indication time period (e.g., <NUM> 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 within the MIB indication time period (e.g., within the past <NUM> hours); and if the certain SI is further updated while the timer is still running, resetting the timer so that timer will expire when the MIB indication time period has elapsed since the timer was reset. In this embodiment, the one bit flag included in the MIB is set equal to the value of the SI change flag.

In another aspect there is provided a method, performed by UE <NUM>, for reducing SI acquisition time. In one embodiment, the method includes the UE receiving a MIB comprising a one bit flag for indicating whether or not certain SI has been changed since a particular time in the past. The method may further include the UE, after receiving the MIB, acquiring a SIB that comprises the certain SI (e.g., acquire SIB1-BR), wherein the UE acquires the SIB regardless of the value to which the flag is set. For instance, the UE may acquire the SIB regardless of the setting of the flag after the UE wakes from a sleep and the last time the UE has acquired the particular SIB was more than X hours ago (e.g., X=<NUM> or <NUM>).

The method may further include the UE, after acquiring the SIB, receiving a subsequent MIB comprising the MIB indication that is set to a value that indicates that the certain SI has not been changed since a particular point in time in the past (e.g., indicating that the SI has not changed in the last X hrs); the UE determining whether acquisition of a subsequent SIB may be skipped, wherein the determining comprises the UE determining that the flag is set to the particular value; and after determining that acquisition of the subsequent SIB may be skipped, the UE skipping the acquisition of a subsequent SIB that comprises the certain SI. In some embodiments, the particular time in the past is based on a current time and a MIB indication time period. In some embodiments, the step of determining whether acquisition of the subsequent SIB may be skipped further includes the UE determining whether it currently has up-to-date SI. In some embodiments, the UE determines that it has up-to-date SI by determining that it last acquired the SI within the MIB indication time period.

<FIG> is a block diagram of UE <NUM> according to some embodiments. As shown in <FIG>, UE <NUM> may comprise: a data processing apparatus (DPA) <NUM>, which may include one or more processors (P) <NUM> (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a transmitter <NUM> and a receiver <NUM> coupled to an antenna <NUM> for enabling UE <NUM> to transmit data to and receive data from an AN node (e.g., base station); and local storage unit (a. , "data storage system") <NUM>, 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 <NUM> includes a general purpose microprocessor, a computer program product (CPP) <NUM> may be provided. CPP <NUM> includes a computer readable medium (CRM) <NUM> storing a computer program (CP) <NUM> comprising computer readable instructions (CRI) <NUM>. CRM <NUM> 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 <NUM> of computer program <NUM> is configured such that when executed by data processing apparatus <NUM>, the CRI causes UE <NUM> to perform steps described above (e.g., steps described above with reference to the flow charts). In other embodiments, UE <NUM> may be configured to perform steps described herein without the need for code. That is, for example, data processing apparatus <NUM> may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

<FIG> is a block diagram of a network node <NUM> according to some embodiments. As shown in <FIG>, node <NUM> may comprise: a data processing apparatus (DPA) <NUM>, which may include one or more processors (P) <NUM> (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a network interface <NUM> comprising a transmitter (Tx) <NUM> and a receiver (Rx) <NUM> for enabling node <NUM> to transmit data to and receive data from other nodes connected to a network <NUM> (e.g., an Internet Protocol (IP) network) to which network interface <NUM> is connected; circuitry <NUM> (e.g., radio transceiver circuitry) coupled to an antenna system <NUM> for wireless communication with UEs); and local storage unit (a. , "data storage system") <NUM>, 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 <NUM> includes a general purpose microprocessor, a computer program product (CPP) <NUM> may be provided. CPP <NUM> includes a computer readable medium (CRM) <NUM> storing a computer program (CP) <NUM> comprising computer readable instructions (CRI) <NUM>. CRM <NUM> 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 <NUM> of computer program <NUM> is configured such that when executed by data processing apparatus <NUM>, the CRI causes node <NUM> to perform steps described above (e.g., steps described above with reference to the flow charts). In other embodiments, node <NUM> may be configured to perform steps described herein without the need for code. That is, for example, data processing apparatus <NUM> may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

Claim 1:
A method for reducing system information, SI, acquisition time, the method being performed by a network node (<NUM>) and comprising:
when certain SI is changed in a BCCH modification period in a master information block, MIB, indication time period, setting a one bit flag to a first value for the rest of the current MIB indication time period and the immediately following MIB indication time period, and otherwise setting the flag to a second value;
generating a MIB comprising the value for the one bit flag; and
transmitting the MIB;
wherein the MIB indication time period is a time period in which the UE is required to check the MIB at least once.