Patent Description:
As the number of applications and services for digital data continues to explode, the demands and challenges placed on network resources and operators will continue to increase. Being able to deliver a wide variety of network performance characteristics that future services will demand is one of the primary technical challenges faced by service providers today.

For the narrowband internet of things (NB-IoT), a SystemInformationBlockType1 (SIB1) (e.g., SIB1 message) may be transmitted in subframe <NUM> (e.g., a fifth subframe in time within a frame, with the first subframe in time within a frame noted as subframe <NUM>) and may be repeated up to <NUM> times within a transmission period (e.g., within a <NUM> millisecond transmission period). Certain base stations (BSes) may also repeat the same SIB1 of subframe <NUM> in subframe <NUM> (e.g., a fourth subframe in time within the frame). This SIB1 within subframe <NUM> may be referred to as an additional SIB1 in subframe <NUM>, to contrast with the SIB1 in subframe <NUM>.

Within the NB-IoT system, a BS may indicate whether the BS transmits an additional SIB1 in subframe <NUM> through in an additionalTransmissionSIB1 field of a master information block (MIB). As noted above, the SIB1 in both subframes <NUM> and <NUM> may be the same. Also, subframes <NUM> and <NUM> may be within a same frame (e.g., radio frame).

Also, a BS may transmit a bitmap that indicates whether subframe <NUM> containing the additional SIB1 is invalid (e.g., reserved for specific messages and not available for dynamic data allocation, such as dynamic data allocation with the additional SIB1). Stated another way, the BS may transmit the bitmap (e.g., a DL-Bitmap-NB) in the MIB to indicate which subframes are valid or invalid.

Certain user equipment (UE) may not support the receipt of the additional SIB1 in subframe <NUM>. For example, such UEs may only support the receipt of the SIB1 in subframe <NUM> and not subframe <NUM>. Reference to supporting receipt of a signal may refer to a UE being capable of, or configured to, properly process the received signal.

In contrast, a UE that supports receipt of the additional SIB1 in subframe <NUM> may also support subframe <NUM> as a valid subframe. For example, a bitmap may be transmitted from a BS for over <NUM> milliseconds to indicate that subframe <NUM> is an invalid subframe. However, the BS may also transmit subframe <NUM> with the additional SIB1 dynamically allocated to subframe <NUM>. In such a situation, a UE that supports receipt or processing of the additional SIB1 in subframe <NUM> may also support having the subframe <NUM>, when not containing the additional SIB1 , as a valid subframe for the UE. By being a valid subframe for the UE, the UE may receive and process dynamically modulated data in subframe <NUM> in a UE-specific search space. Accordingly, there is a need to harmonize understanding between a BS and a UE of whether subframe <NUM> is a valid subframe for receipt of the additional SIB1.

<NPL> specifies narrowband physical downlink shared channel related procedures, among other topics. 3GPP <NPL>" specifies the feature of Additional SIB1-NB transmission as not being indicated to the RAN network as a UE radio access capability parameter, among other topics. <NPL>" specifies the procedure for transmission of additional SIB1, among other topics.

Preferred embodiments are recited in the dependent claims.

The exemplary embodiments disclosed herein are directed to solving the issues relating to one or more of the problems presented in the prior art, as well as providing additional features that will become readily apparent by reference to the following detailed description when taken in conjunction with the accompany drawings. In accordance with various embodiments, exemplary systems, methods, devices and computer program products are disclosed herein. It is understood, however, that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art who read the present disclosure that various modifications to the disclosed embodiments can be made while remaining within the scope of the invention as defined by the independent claims.

Various exemplary embodiments of the invention are described below with reference to the accompanying figures to enable a person of ordinary skill in the art to make and use the invention. As would be apparent to those of ordinary skill in the art, after reading the present disclosure, various changes or modifications to the examples described herein can be made without departing from the scope of the invention which is solely defined by the appended claims. Thus, the present invention is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order or hierarchy of steps in the methods disclosed herein are merely exemplary approaches. Based upon design preferences, the specific order or hierarchy of steps of the disclosed methods or processes can be re-arranged while remaining within the scope of the present invention. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in a sample order, and the invention is not limited to the specific order or hierarchy presented unless expressly stated otherwise.

The discussion below may refer to functional entities or processes which are similar to those mentioned above with respect to conventional communication systems. As would be understood by persons of ordinary skill in the art, however, such conventional functional entities or processes do not perform the functions described below, and therefore, would need to be modified or specifically configured to perform one or more of the operations described below. Additionally, persons of skill in the art would be enabled to configure functional entities to perform the operations described herein after reading the present disclosure.

<FIG> illustrates an exemplary wireless communication network <NUM> in which techniques disclosed herein may be implemented, in accordance with an embodiment of the present disclosure. Such an exemplary network <NUM> includes a base station <NUM> (hereinafter "BS <NUM>") and a user equipment device <NUM> (hereinafter "UE <NUM>") that can communicate with each other via a communication link <NUM> (e.g., a wireless communication channel), and a cluster of notional cells <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> overlaying a geographical area <NUM>. A UE <NUM> may undergo a random access procedure to join the network <NUM>. Accordingly, reference to a cell may be a short hand reference to a BS with an associated coverage region or area. In certain embodiments, a cell may be interchangeably referred to as a BS.

For example, the BS <NUM> may operate at an allocated channel transmission bandwidth (e.g., spectrum) to provide adequate coverage to the UE <NUM>. The spectrum may be regulated to define a licensed range and/or an unlicensed range. The radio frames may also be referred to more simply as a frame. Each frame <NUM>/<NUM> may be further divided into sub-frames <NUM>/<NUM> which may include data symbols <NUM>/<NUM>. Such communication nodes may be capable of wireless and/or wired communications, in accordance with various embodiments of the invention. In certain embodiments, a communication device may refer more specifically to a UE and a communication node may refer more specifically to a BS in relation to the UE.

<FIG> illustrates a block diagram of an exemplary wireless communication system <NUM> for transmitting and receiving wireless communication signals (e.g., OFDM/OFDMA signals) in accordance with some embodiments of the invention. The system <NUM> may include components and elements configured to support known or conventional operating features that need not be described in detail herein. In one exemplary embodiment, system <NUM> can be used to transmit and receive data symbols in a wireless communication environment such as the wireless communication environment <NUM> of <FIG>, as described above.

The BS <NUM> communicates with the UE <NUM> via a communication channel <NUM>, which can be any wireless channel or other medium known in the art suitable for transmission of data as described herein.

In accordance with some embodiments, the UE transceiver module <NUM> may be referred to herein as an "uplink" transceiver module <NUM> that includes a RF transmitter and receiver circuitry that are each coupled to the antenna <NUM>. Similarly, in accordance with some embodiments, the BS transceiver module <NUM> may be referred to herein as a "downlink" transceiver module <NUM> that includes RF transmitter and receiver circuity that are each coupled to the antenna <NUM>. The operations of the two transceiver modules <NUM> and <NUM> are coordinated in time such that the uplink receiver is coupled to the uplink antenna <NUM> for reception of transmissions over the wireless transmission link <NUM> at the same time that the downlink transmitter is coupled to the downlink antenna <NUM>. Preferably there is close time synchronization with only a minimal guard time between changes in duplex direction.

The UE transceiver module <NUM> and the BS transceiver module <NUM> are configured to communicate via the wireless data communication link <NUM>, and cooperate with a suitably configured RF antenna arrangement <NUM>/<NUM> that can support a particular wireless communication protocol and modulation scheme. In some exemplary embodiments, the UE transceiver module <NUM> and the BS transceiver module <NUM> are configured to support industry standards such as the Long Term Evolution (LTE) and emerging <NUM> standards, and the like. It is understood, however, that the invention is not necessarily limited in application to a particular standard and associated protocols. Rather, the UE transceiver module <NUM> and the BS transceiver module <NUM> may be configured to support alternate, or additional, wireless data communication protocols, including future standards or variations thereof.

The memory modules <NUM> and <NUM> may be realized as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage and/or computer-readable medium known in the art. In this regard, memory modules <NUM> and <NUM> may be coupled to the transceiver modules <NUM> and <NUM>, respectively, such that the transceiver modules <NUM> and <NUM> can read information from, and write information to, memory modules <NUM> and <NUM>, respectively. The memory modules <NUM> and <NUM> may also be integrated into their respective transceiver modules <NUM> and <NUM>. In some embodiments, the memory modules <NUM> and <NUM> may each include a cache memory for storing temporary variables or other intermediate information during execution of instructions to be executed by transceiver modules <NUM> and <NUM>, respectively. Memory modules <NUM> and <NUM> may also each include non-volatile memory for storing instructions to be executed by the transceiver modules <NUM> and <NUM>, respectively.

The network communication module <NUM> generally represents the hardware, software, firmware, processing logic, and/or other components of the base station <NUM> that enable bi-directional communication between the BS transceiver module <NUM> and other network components and communication nodes configured to communication with the base station <NUM>. In a typical deployment, without limitation, network communication module <NUM> provides an <NUM> Ethernet interface such that the BS transceiver module <NUM> can communicate with a conventional Ethernet based computer network. The terms "configured for," "configured to" and conjugations thereof, as used herein with respect to a specified operation or function, refer to a device, component, circuit, structure, machine, signal, etc., that is physically or virtually constructed, programmed, formatted and/or arranged to perform the specified operation or function.

As noted above, a system information block type <NUM>, or SystemInformationBlockType1 (SIB1) message may be transmitted on a subframe <NUM> and is transmitted on a subframe <NUM> within a frame. Reference to subframe <NUM> may refer to a fourth subframe in time within a frame of contiguous subframes (e.g., a subframe that follows subframe <NUM>, subframe <NUM>, and subframe <NUM>). Similarly, reference to subframe <NUM> may refer to a fifth subframe in time within a frame of contiguous subframes (e.g., the subframe that follows subframe <NUM>, subframe <NUM>, subframe <NUM>, and subframe <NUM>).

However, certain user equipment (UE) may not support the receipt of the additional SIB1 in subframe <NUM>. For example, such UEs may only support the receipt of the SIB1 in subframe <NUM> and not subframe <NUM>. For compatibility, a BS may transmit a bitmap that indicates whether the subframe <NUM> containing the additional SIB1 is invalid. However, despite the indication in the bitmap, a UE that supports receiving and processing the additional SIB1 in subframe <NUM> can also support having the subframe <NUM> in another frame, such as a future frame (e.g., when not containing the additional SIB1) as a valid subframe when the UE receives data in a UE-specific search space, thus increasing data throughput.

Accordingly, systems and methods in accordance with various embodiments harmonize an understanding of valid and/or invalid subframes between a BS and a UE. This understanding may be based on the BS coming to an understanding of whether a certain subframe (e.g., subframe <NUM>) is a valid subframe for dynamic data allocation (e.g., the allocation of NPDCCH in a UE-specific search space, and NPDSCH scheduled by the NPDCCH in a UE-specific search space). This understanding may be facilitated by either the BS receiving capability information indicating that the UE supports receiving the additional SIB1 from the UE or from a core network. To be clear, the capability information may refer to information characterizing or indicating whether the UE supports certain subframe(s) (e.g., subframe <NUM>), when not containing the additional SIB1, as a valid subframe or an invalid subframe. This capability information may be sent in a capability message.

A UE informs a base station directly as to whether the UE supports the ability to receive an additional SIB1 (e.g., an SIB1 in subframe <NUM>) in radio resource control (RRC) messaging, or, in an embodiment not comprised within the scope of the claims, via a medium access control element (MAC CE). If the UE supports the ability to receive an additional SIB1, then the BS sends a confirmation message to confirm that the BS has now determined that the subframe <NUM>, when not containing the additional SIB1, is considered as (e.g., designated as) a valid subframe to the UE via RRC messaging and/or via a MAC CE. After receiving the confirmation message, the UE may begin to utilize the subframe <NUM>, when not containing the additional SIB1, also as a valid subframe for dynamic data allocations in future communications. In certain embodiments, this confirmation message may override a previous understanding of whether subframe <NUM> (or any other specific subframe) is a valid or invalid subframe by the bitmap in the MIB. For example, if a previously received bitmap indicated that subframe <NUM> is an invalid subframe, a subsequently received confirmation message that indicates that the subframe <NUM>, when not containing the additional SIB1, is a valid subframe may override an effect of any notation that subframe <NUM> is an invalid subframe from the previously received bitmap.

However, if the UE does not support the ability to receive an additional SIB1, then such a confirmation message will not be sent from the BS to the UE. Stated another way, the receipt of the confirmation message is optional. Accordingly, the UE will not utilize subframe <NUM> as a valid subframe for dynamic data allocations in future communications. Rather, the UE will reserve subframe <NUM> as an invalid subframe that cannot be utilized for dynamic data allocation in future communications but is reserved for specific predetermined information in future communications.

In certain embodiments, the BS may not necessarily send the confirmation message even though the BS has come to an understanding that the UE supports the ability to receive an additional SIB1 (e.g., an SIB1 in subframe <NUM>). In such embodiments, the BS and UE may operate with the implied understanding (e.g., without use of a confirmation message) that the BS understands and is operating based on the UE supporting the ability to receive the additional SIB1. This implied understanding may be based on the BS receiving the capability information indicating that the UE supports the ability to receive the additional SIB1.

In various embodiments, these future communications may include communications in the context of a narrowband physical downlink control channel (NPDCCH) in UE-specific search space. These future communications may also include communications in the context of a narrowband physical downlink shared channel (NPDSCH) transmission scheduled by the NPDCCH in a UE-specific search space after, optionally, receiving the confirmation message.

<FIG> is a flow chart of a process <NUM> of communicating and confirming a UE <NUM> capability to receive SIB1 in a subframe <NUM> from a BS <NUM>, in accordance with some embodiments of the present disclosure. The UE <NUM> and the BS <NUM> may be the same type of UE and/or BS as those illustrated above in <FIG> and <FIG>, but are remunerated in <FIG> onward for ease of explanation.

Returning to <FIG>, at operation <NUM>, the UE may communicate a capability message which includes capability information that indicates whether the UE <NUM> supports receiving the additional SIB1. At operation <NUM>, the BS <NUM> may determine whether the UE can consider the subframe <NUM>, when not containing the additional SIB1, as a valid subframe for reception of dynamic data allocation based on the capability information.

At operation <NUM>, the BS <NUM> may, optionally, send a confirmation message to confirm that the BS <NUM> has now determined that the UE <NUM> supports subframe <NUM>, when not containing the additional SIB1, as a valid subframe to the UE <NUM>. This operation may be performed if the capability information indicates that the UE <NUM> supports receiving the additional SIB1. As will be illustrated below, this may be sent via RRC messaging and/or via a MAC CE. After receiving the confirmation message, the UE <NUM> may begin to utilize subframe <NUM>, when not containing the additional SIB1, also as a valid subframe for dynamic data allocations in future communications.

However, if the UE <NUM> does not support the ability to receive an additional SIB1, then operation <NUM> may not be performed. If operation <NUM> is not performed, such a confirmation message will not be sent from the BS <NUM> to the UE <NUM>. Accordingly, the UE <NUM> will not utilize subframe <NUM>, when not containing the additional SIB1, as a valid subframe for dynamic data allocations in future communications. Rather, the UE <NUM> will reserve subframe <NUM> as an invalid subframe that cannot be utilized for dynamic data allocation in future communications but is reserved for specific predetermined information in future communications.

In certain embodiments, the confirmation message (e.g., operation <NUM>) may override previous understandings of whether subframe <NUM> is a valid or invalid subframe. For example, the confirmation message may indicate that subframe <NUM>, when not containing the additional SIB1, is a valid subframe, overriding a previous understanding that subframe <NUM> is an invalid subframe as indicated in a bitmap sent in a master information block (MIB).

<FIG> is a flow chart of a process <NUM> of transferring system information from the BS <NUM> to the UE <NUM>, in accordance with some embodiments of the present disclosure. At operation <NUM>, the BS <NUM> may transmit the MIB to a UE. The MIB may include information that characterizes subsequent transmissions, such as the timing and/or characterization of subsequent transmissions.

As an example of arbitrary values that characterize subsequent transmissions, the BS may set a field of the MIB (e.g., additionalTransmissionSIB1) to True, the physical cell identifier (PCID) to <NUM> (e.g., PCID=<NUM>), and the number of repetitions of the SIB1 to <NUM>. In certain embodiments, a specific subframe for transmission of an SIB1 may be set by the BS in accordance with the following formula: <MAT> where SFNi is a system frame number and i is an arbitrary value indicating the number of SIB1 subframe(s) within a SIB1 frame (e.g., <NUM> SIB1 subframes). For example, an MIB may indicate that subframe <NUM> is to transmit an additional SIB1 in addition to subframe <NUM> transmitting the SIB1. Also, a BS may broadcast a <NUM> millisecond downlink subframe bitmap of valid or invalid subframes, which may indicate whether subframe <NUM> is invalid. For example, the bitmap may be included in the subframePattern field of the MIB or the DL-Bitmap field of the MIB. Also, for example, a bitmap value of <NUM> may indicate that subframe <NUM> of each radio frame is an invalid subframe (e.g., as the fourth subframe in a radio frame in time).

At operation <NUM>, the BS <NUM> may also transmit the SIB1 to the UE <NUM> after transmitting the MIB. At operation <NUM>, further transmissions of other system information (e.g., SystemInformation) from the BS <NUM> to the UE <NUM> may follow after transmission of the SIB1. Process <NUM> may be referred to as precursor operations in the following figures.

<FIG> is a flow chart of a process <NUM> of communicating and confirming UE capability to receive SIB1 in subframe <NUM> directly between a UE <NUM> and a BS <NUM> in radio resource control (RRC) messaging, in accordance with some embodiments of the present disclosure. Process <NUM> may occur after process <NUM> of <FIG>, discussed further above. Also, for simplicity of explanation, RRC messaging may be considered part of a set of five messages, as will be discussed further below. The set of five messages may be part of a random access procedure.

At operation <NUM>, a first message (MSG1) of the set of five messages may be part of an NB-IoT physical random access channel (NPRACH) sent from the UE <NUM> to the BS <NUM>.

At operation <NUM>, a second message (MSG2) of the set of five messages may be a random access response (RAR) sent from the BS <NUM> to the UE <NUM>.

At operation <NUM>, the third message (MSG3) may be a RRC request message sent from the UE to the BS. At operation <NUM>, the UE may include capability information that indicates whether the UE supports (e.g., is has the UE capability for) receiving the additional SIB1. Stated another way, the MSG3 RRC request message may be a capability message that includes capability information.

At operation <NUM>, the BS <NUM> may determine whether the UE supports subframe <NUM>, when not containing the additional SIB1, as a valid subframe for reception of dynamically allocated data or an invalid subframe for reception of dynamic data based on the RRC request message.

At operation <NUM>, as a fourth message (MSG4) of the set of five messages, the BS <NUM> may send a RRC response message that includes a confirmation message if the capability information indicates that the UE <NUM> supports subframe <NUM>, when not containing the additional SIB1, as a valid subframe for reception of dynamically allocated data. This confirmation message, as part of the RRC response message, may confirm that the BS <NUM> has now determined that the BS <NUM> supports considering subframe <NUM>, when not containing the additional SIB1, as a valid subframe for the UE <NUM>.

In certain embodiments, after receiving the confirmation message in operation <NUM>, the UE <NUM> may begin to utilize subframe <NUM>, when not containing the additional SIB1, as a valid subframe for dynamic data allocations in future communications. Also, the BS may utilize subframe <NUM>, when not containing the additional SIB1, as a valid subframe for dynamic data allocations in future communications, thereby increasing data throughput. For example, the BS may dynamically allocate data in subframe <NUM>, as a valid subframe, in a narrowband Physical Downlink Shared Channel (NPDSCH) and/or a narrowband Physical Downlink Control Channel (NPDCCH). Stated another way, the narrowband Physical Downlink Shared Channel (NPDSCH) and/or a narrowband Physical Downlink Control Channel (NPDCCH) may be received in a UE specific search space with a subframe <NUM> utilized as a valid subframe.

In various embodiments, the RRC response message of operation <NUM> may not include the confirmation message. The lack of this confirmation message, as part of the RRC response message, may confirm that the BS <NUM> has not determined that the BS <NUM> supports receiving an additional SIB1 in subframe <NUM> to the UE <NUM>. Accordingly, the UE <NUM> and the BS <NUM> will not utilize subframe <NUM> as a valid subframe for dynamic data allocations in future communications. Rather, the UE <NUM> and the BS <NUM> will reserve subframe <NUM> as an invalid subframe that cannot be utilized for dynamic data allocation in future communications but is reserved for specific predetermined information in future communications. As noted above, these future communications may include communications in the context of a narrowband physical downlink control channel (NPDCCH) UE specific search space, and/or communications in the context of a narrowband physical downlink shared channel (NPDSCH) transmission scheduled by the NPDCCH in a UE specific search space.

<FIG> is a flow chart of a process <NUM> of communicating and confirming UE capability to receive SIB1 in a subframe <NUM> via a core network, in accordance with some embodiments of the present disclosure. Operation <NUM> and operation <NUM> are already discussed above in connection with process <NUM> in <FIG> and will not be repeated here for brevity.

Returning to <FIG>, at operation <NUM>, the third message (MSG3) may be a RRC request message sent from the UE to the BS. At operation <NUM>, unlike operation <NUM> of <FIG>, the UE may not include capability information that indicates whether the UE supports receiving SIB1 in subframe <NUM>. Stated another way, the MSG3 RRC request message may not be a capability message that includes capability information.

At operation <NUM>, the BS <NUM> may send a retrieve UE information message to a core network <NUM>. More specifically, the BS <NUM> may send the retrieve UE information message to a mobility management entity (MME) of the core network. The retrieve UE information message may request the core network <NUM> to communicate capability information that indicates whether the UE <NUM> supports receiving SIB1 in subframe <NUM>.

At operation <NUM>, the core network <NUM> may transmit a UE information transfer message that includes capability information characterizing whether the UE <NUM> supports receiving SIB1 in subframe <NUM>. The capability information within the UE information transfer message may be stored at the core network <NUM>, such as at the MME of the core network <NUM>.

At operation <NUM>, the BS <NUM> may determine whether the UE supports having subframe <NUM>, when not containing the additional SIB1, as a valid subframe for reception of dynamically allocated data based on the capability information received in operation <NUM>.

At operation <NUM>, as a fourth message (MSG4) of the set of five messages, the BS <NUM> may send a RRC response message that includes a confirmation message if the capability information indicates that the UE <NUM> supports receiving SIB1 in subframe <NUM>. This confirmation message, as part of the RRC response message, may confirm that the BS <NUM> has now determined that the BS <NUM> supports subframe <NUM>, when not containing the additional SIB1, as a valid subframe for reception of dynamically allocated data for the UE <NUM>.

In certain embodiments, after receiving the confirmation message in operation <NUM>, the UE <NUM> may begin to utilize subframe <NUM>, when not containing the additional SIB1, also as a valid subframe for dynamic data allocations in future communications. Also, the BS may utilize subframe <NUM>, when not containing the additional SIB1, as a valid subframe for dynamic data allocations in future communications, thereby increasing data throughput. For example, the BS may dynamically allocate data in subframe <NUM>, as a valid subframe, in a narrowband Physical downlink shared Channel (NPDSCH) and/or a narrowband Physical Downlink Control Channel (NPDCCH). Stated another way, the narrowband Physical Downlink Shared Channel (NPDSCH) and/or a narrowband Physical Downlink Control Channel (NPDCCH) may be received in a UE specific search space with a subframe <NUM> utilized as a valid subframe.

In various embodiments, the RRC response message of operation <NUM> may not include the confirmation message. The lack of this confirmation message, as part of the RRC response message, may confirm that the BS <NUM> has not determined that the BS <NUM> supports subframe <NUM>, when not containing the additional SIB1, as a valid subframe for the UE <NUM>. Accordingly, the UE <NUM> and the BS <NUM> will not utilize subframe <NUM> as a valid subframe for dynamic data allocations in future communications. Rather, the UE <NUM> and the BS <NUM> will reserve subframe <NUM> as an invalid subframe that cannot be utilized for dynamic data allocation in future communications but is reserved for specific predetermined information in future communications. As noted above, these future communications may include communications in the context of a NPDCCH UE specific search space, and/or communications in the context of a NPDSCH transmission scheduled by the NPDCCH in a UE specific search space.

<FIG> is a flow chart of a process <NUM> of communicating and confirming UE capability to receive SIB1 in subframe <NUM> when a core network does not include capability information, in accordance with some embodiments of the present disclosure. Operation <NUM> and operation <NUM> are already discussed above in connection with process <NUM> in <FIG> and will not be repeated here for brevity. Also, operation <NUM> and operation <NUM> are already discussed above in connection with process <NUM> in <FIG> and will not be repeated herein for brevity.

At operation <NUM>, the core network <NUM> may transmit a UE information transfer message to the BS <NUM>. However, unlike in operation <NUM> of <FIG>, the UE information transfer message of operation <NUM> may not include capability information characterizing whether the UE <NUM> supports receiving SIB1 in subframe <NUM>. This may be because the capability information may not be stored at the core network <NUM> (e.g., at the MME of the core network <NUM>).

At operation <NUM>, the BS <NUM> may attempt to determine whether the UE <NUM> supports receiving SIB1 in subframe <NUM> based on any capability information received in operation <NUM>. However, the BS <NUM> has not received any capability information in operation <NUM> (e.g., operation <NUM> did not indicate whether or not the UE supports receiving SIB1 in subframe <NUM> based on any capability information received in operation <NUM>). Therefore, the BS <NUM> is unable to, and has not determined whether or not the UE supports subframe <NUM>, when not containing the additonal SIB1, as a valid subframe for reception of dynamically allocated data.

At operation <NUM>, as a fourth message (MSG4) of the set of five messages, the BS <NUM> may send a RRC response message to the UE <NUM>. However, unlike operation <NUM> of <FIG>, at operation <NUM> the RRC response message may not include a confirmation message. This may be because the BS <NUM> has not received any capability information in operation <NUM>.

In certain embodiments, the RRC response message of operation <NUM> may specify that the BS has not received any capability information. In other embodiments, the RRC response message of operation <NUM> may simply not carry any information concerning the capability information (e.g., any information that indicates whether or not the UE supports subframe <NUM>, when not containing the additional SIB1, is a valid subframe for reception of dynamically allocated data).

At operation <NUM>, as a fifth message (MSG5) of the set of five messages, the UE <NUM> may send a RRC process completion message to the BS <NUM>. The RRC process completion message may indicate that the random access procedure is now complete or has been completed.

At operation <NUM>, the BS <NUM> may send a UE capability enquiry message to a UE <NUM>. The UE capability enquiry message may request or query the UE <NUM> to communicate capability information that indicates whether the UE <NUM> supports receiving SIB1 in subframe <NUM>.

At operation <NUM>, the UE <NUM> may transmit an UE information transfer message that includes capability information characterizing whether the UE <NUM> supports receving SIB1 in subframe <NUM>. The UE information transfer message answers the UE capability enquiry message of operation <NUM>. The UE information transfer message may be sent by the UE <NUM> in response to receiving the UE capability enquiry message. The capability information within the UE information transfer message may be stored at the UE <NUM>.

At operation <NUM>, the BS <NUM> may determine whether the UE supports subframe <NUM> as a valid subframe for reception of SIB1 based on the capability information received in operation <NUM>.

At operation <NUM>, the BS <NUM> may send a MAC CE or RRC message that includes a confirmation message if the capability information indicates that the UE <NUM> supports subframe <NUM> as a valid subframe for reception of SIB1. This confirmation message may confirm to the UE <NUM> that the BS <NUM> has now determined that the UE <NUM> supports subframe <NUM>, when not containing the additional SIB1, as a valid subframe for reception of dynamically allocated data.

In certain embodiments, after receiving the confirmation message in operation <NUM>, the UE <NUM> may begin to utilize subframe <NUM>, when not containing the additional SIB1, also as a valid subframe for dynamic data allocations in future communications. Also, the BS may utilize subframe <NUM>, when not containing the additional SIB1, as a valid subframe for dynamic data allocations in future communications, thereby increasing data throughput. For example, the BS may dynamically allocate data in subframe <NUM>, as a valid subframe, in a narrowband Physical Downlink Shared Channel (NPDSCH) and/or a narrowband Physical Downlink Control Channel (NPDCCH). Stated another way, the narrowband Physical Downlink Shared Channel (NPDSCH) and/or a narrowband Physical Downlink Control Channel (NPDCCH) may be received in a UE specific search space with a subframe <NUM> utilized as a valid subframe.

In various embodiments, the MAC CE or RRC message of operation <NUM> may not include the confirmation message. The lack of this confirmation message, as part of the MAC CE or RRC message, may confirm that the BS <NUM> has not determined that the BS <NUM> supports subframe <NUM>, when not containing the additional SIB1, as a valid subframe for reception of dynamically allocated data to the UE <NUM>. Accordingly, the UE <NUM> and the BS <NUM> will not utilize subframe <NUM>, when not containing the additional SIB1, as a valid subframe for dynamic data allocations in future communications. Rather, the UE <NUM> and the BS <NUM> will reserve subframe <NUM>, when not containing the additional SIB1, as an invalid subframe that cannot be utilized for dynamic data allocation in future communications but is reserved for specific predetermined information in future communications. As noted above, these future communications may include communications in the context of a NPDCCH UE specific search space, and/or communications in the context of a NPDSCH transmission scheduled by the NPDCCH in a UE specific search space.

It is also understood that any reference to an element or embodiment herein using a designation such as "first," "second," and so forth does not generally limit the quantity or order of those elements.

Additionally, one or more of the functions described in this document may be performed by means of computer program code that is stored in a "computer program product", "computer-readable medium", and the like, which is used herein to generally refer to media such as, memory storage devices, or storage unit. These, and other forms of computer-readable media, may be involved in storing one or more instructions for use by processor to cause the processor to perform specified operations. Such instructions, generally referred to as "computer program code" (which may be grouped in the form of computer programs or other groupings), which when executed, enable the computing system to perform the desired operations.

Claim 1:
A method performed by a communication device, comprising:
receiving a SystemInformationBlockType1, SIB1, message in a fifth subframe of a frame from a communication node;
receiving an additional SIB1 message in a second particular subframe of the frame containing the additional SIB1 message from the communication node based on a communication device capability for processing the additional SIB1 message;
characterized by
sending a radio resource control signal to the communication node based on the communication device capability for processing the additional SIB1 message in the second particular subframe of the frame containing the additional SIB1 message, wherein the radio resource control signal comprises indication information for indicating whether the communication device supports processing the additional SIB1 message in the second particular subframe containing the additional SIB1 message; and
receiving a confirmation message from the communication node, the confirmation message confirming that the second particular subframe of another frame not containing the additional SIB1 is considered as a valid subframe.