Patent Description:
With the increase in different types of devices communicating with various network devices, usage of 3GPP LTE systems has increased. The penetration of mobile devices (user equipment or UEs) in modern society has continued to drive demand for a wide variety of networked devices in a number of disparate environments. The use of networked UEs using 3GPP LTE systems has increased in all areas of home and work life. Fifth generation (<NUM>) wireless systems are forthcoming, and are expected to enable even greater speed, connectivity, and usability.

One concern with UEs is handling of unattended (or background) traffic. More specifically, when an Evolved Node-B (eNB) has allowed communication of background traffic after background traffic has been previously disallowed, all UEs in the eNB cell may initiate (or resume) communication of their background traffic at the same (or similar) time instant, which can result in cell traffic overload and reduction of data rates. <NPL>, provides some field studies on unattended/background data traffic. Based on the analysis of field results and existing mechanisms, the document proposes a possible enhancement to ensure the fulfilment of the requirement. <NPL>, discloses various proposals for controlling of unattended traffic. <CIT> discusses how the access of a UE configured for and activated to implement extended access barring, EAB, or included in a group of UEs addressed via group paging to a wireless communication network is controlled. First, an access delay for the UE is determined. Second, a timing of an attempt by the UE to access a cell in the wireless communication network is controlled based on the determined access delay. Preferred embodiments of the invention are stipulated in the dependent claims.

In the figures, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Some embodiments are illustrated by way of example, and not limitation, in the following figures of the accompanying drawings.

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. A number of examples are described in the context of 3GPP communication systems and components thereof. It will be understood that principles of the embodiments are applicable in other types of communication systems, such as Wi-Fi or Wi-Max networks, Bluetooth or other personal-area networks, Zigbee or other home-area networks, wireless mesh networks, and the like, without limitation, unless expressly limited by a corresponding claim. Given the benefit of the present disclosure, persons skilled in the relevant technologies will be able to engineer suitable variations to implement principles of the embodiments in other types of communication systems. Various diverse embodiments may incorporate structural, logical, electrical, process, and other differences. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments.

<FIG> shows an example of a portion of an end-to-end network architecture of a Long Term Evolution (LTE) network with various components of the network in accordance with some embodiments. As used herein, LTE and LTE-A networks and devices are referred to merely as LTE networks and devices. The network <NUM> may comprise a radio access network (RAN) (e.g., as depicted, the E-UTRAN or evolved universal terrestrial radio access network) <NUM> and the core network <NUM> (e.g., shown as an evolved packet core (EPC)) coupled together through an S1 interface <NUM>. For convenience and brevity, only a portion of the core network <NUM>, as well as the RAN <NUM>, is shown in the example.

The core network <NUM> includes a mobility management entity (MME) <NUM>, a serving gateway (serving GW) <NUM>, and packet data network gateway (PDN GW) <NUM>. The RAN <NUM> includes Evolved Node-B's (eNB) <NUM> (which may operate as base stations) for communicating with User Equipment (UE) <NUM>. The eNBs <NUM> may include macro eNBs and low power (LP) eNBs, such as micro, pico or femto eNBs. In accordance with some embodiments, the eNB <NUM> may transmit a downlink control message to the UE <NUM> to indicate an allocation of physical uplink control channel (PUCCH) channel resources. The UE <NUM> may receive the downlink control message from the eNB <NUM>, and may transmit an uplink control message to the eNB <NUM> in at least a portion of the PUCCH channel resources.

The MME <NUM> is similar in function to the control plane of legacy Serving GPRS Support Nodes (SGSN). The MME <NUM> manages mobility aspects in access such as gateway selection and tracking area list management. The serving GW <NUM> terminates the interface toward the RAN <NUM>, and routes data packets between the RAN <NUM> and the core network <NUM>. In addition, it may be a local mobility anchor point for inter-eNB handovers and also may provide an anchor for inter-3GPP mobility. The serving GW <NUM> and the MME <NUM> may be implemented in one physical node or separate physical nodes. The PDN GW <NUM> terminates a SGi interface toward the packet data network (PDN). The PDN GW <NUM> routes data packets between the EPC <NUM> and the external PDN, and may be a key node for policy enforcement and charging data collection. It may also provide an anchor point for mobility with non-LTE accesses. The external PDN can be any kind of IP network, as well as an IP Multimedia Subsystem (IMS) domain. The PDN GW <NUM> and the serving GW <NUM> may be implemented in one physical node or separated physical nodes.

The eNBs <NUM> (macro, micro, pico or femto) may terminate the air interface protocol and may be the first point of contact for a UE <NUM>. At least some of the eNBs <NUM> may be in a cell <NUM>, in which the eNBs <NUM> of the cell <NUM> may be controlled by the same processor or set of processors. In some embodiments, an eNB <NUM> may be in a single cell <NUM>, while in other embodiments the eNB <NUM> may be a member of multiple cells <NUM>. In some embodiments, an eNB <NUM> may fulfill various logical functions for the RAN <NUM> including but not limited to RNC (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In accordance with embodiments, UEs <NUM> may be configured to communicate Orthogonal frequency-division multiplexing (OFDM) communication signals with an eNB <NUM> over a multicarrier communication channel in accordance with an OFDMA communication technique. The OFDM signals may comprise a plurality of orthogonal subcarriers. Each of the eNBs <NUM> may be able to transmit a reconfiguration message to each UE <NUM> that is connected to that eNB <NUM>. The reconfiguration message may contain reconfiguration information including one or more parameters that indicate specifics about reconfiguration of the UE <NUM> upon a mobility scenario (e.g., handover) to reduce the latency involved in the handover. The parameters may include physical layer and layer <NUM> reconfiguration indicators, and a security key update indicator. The parameters may be used to instruct the UE <NUM> to avoid or skip one or more of the processes indicated to decrease messaging between the UE <NUM> and the network. The network may be able to automatically route packet data between the UE <NUM> and the new eNB <NUM> and may be able to provide the desired information between the eNBs <NUM> involved in the mobility. The application, however, is not limited to this, however, and additional embodiments are described in more detail below.

In an example, the UE operating system may designate certain data traffic as background (or unattended) data traffic. As used herein, the terms "background traffic" and "unattended traffic" are interchangeable and refer to one or more types of data traffic that are, e.g., associated with a UE in a background mode and/or the data packets have low QoS requirements, and/or the data packet has small packet size with long packet inter-arrival time.

In an example, the eNB <NUM> may implement a barring mechanism for unattended data traffic. For example, the eNB can introduce a restricting bit <NUM> within a system information block (SIB) <NUM> to inform the UE that the unattended traffic is barred. In this regard the restricting bit can be used as an unattended traffic barring indication, which can be communicated to one or more UEs in the eNB cell (i.e., the bit is common for all UEs in the cell). When the eNB removes the restricting bit (e.g., changes status of bit from TRUE to FALSE), then the UEs within the cell can again send unattended traffic.

In an example, the eNB <NUM> may be configured to determine based on amount of radio resource control (RRC) configuration messaging received at the eNB, to bar unattended data traffic from the UE. The eNB <NUM> may update a System Information Block (SIB) information element (IE) to include a restricting bit, the restricting bit indicating that the unattended data traffic is barred. The eNB <NUM> may encode the SIB IE for transmission to the UE during a modification period. The eNB may encode the SIB IE for multiple transmissions to the UE during the modification period. The eNB <NUM> may determine (e.g., based on an algorithm at the eNB) to stop barring the unattended data traffic from the UE, and update the restricting bit in the SIB IE to indicate that the unattended data traffic is no longer barred. Other considerations that may be used by the eNB <NUM> in determining to stop barring may include a number of resource blocks that are used (or free) over a period of time, the amount of buffered data, and so forth.

<FIG> illustrates transmission of system information in subsequent modification periods. Referring to <FIG>, there are illustrated two modification periods <NUM> and <NUM>. Change of system information may occur during the subsequent modification periods. For example, system information (e.g., <NUM>) can be transmitted a number of times during the modification period <NUM>, as defined by its scheduling. In some instances, system information block (SIB) can be transmitted only once (and in other instances more than once) during the modification period. When system information (e.g., <NUM>) changes, the network transmits the updated system information (e.g., <NUM>) during the subsequent modification period (e.g., <NUM>).

In an example, the SIB changes can be read by the UEs <NUM> periodically during a modification period time interval (e.g., <NUM>), and can act on it at the modification period boundary (e.g., <NUM>, <NUM>). In this regard, all UEs <NUM> within the eNB cell can read and act on the SIB indication at the same instant in time. Consequently, when the restricting bit is removed, the UEs that have accumulated background data while it was barred, may try to access the cell network at the same time instant (e.g., immediately after the barring is removed), which can cause surge in traffic. LTE Access class barring allows barring of fractional number of users. This fraction can be changed by the network over time and can be used to avoid the issue discussed here. For example, during alleviation of barring, network can gradually reduce the fraction of users that is barred, thereby avoiding the surge that can happen when the barring is suddenly removed. However, for barring background traffic, only a single barring bit is used and the barring of a fraction of traffic or users is not possible.

In another example, the eNB can temporarily restrict (or bar) all data traffic immediately after removal of the restricting bit. For example, after background traffic has been restricted (restricting bit has been set), background traffic can be allowed by removing/clearing the restricting bit. After the restricting bit has been cleared (and background traffic is allowed), a random timer may be initiated for a random duration. After the random timer has expired, background traffic communication may resume. This solution, however, may result in barring of normal traffic during the transition period.

Another solution to address potential data traffic surge after removal of a restricting bit is to have UEs <NUM> act on the removal of barring bit immediately after reading the bit rather than at the SIB change boundary (i.e., at the boundary of the modification period). Since different UEs are likely to read the bit at different times, this will result in a natural distribution of released unattended data traffic from the UEs. However, checking for a removal of a restricting bit in each received SIB may be power-intense as the SIB can be received multiple times within a modification period.

In an example, after the UE <NUM> receives a SIB <NUM>, the UE <NUM> can detect a change in the restricting bit status (e.g., removal of the restriction of unattended traffic indicated by change of the bit status from TRUE to FALSE). After the UE detects a change in the restricting bit <NUM> status from barring/restricting unattended data traffic (i.e., TRUE status/state) to non-restricting of unattended data traffic (i.e., FALSE status/state), the UE <NUM> can use a random timer after the SIB modification period boundary, and continues to restrict unattended data traffic until the timer expires. Unattended data traffic can be resumed after expiration of the timer. In another example, the UE may read the SIB at another time instance and not at a modification period boundary (for example when the UE comes back from out of coverage). In this instance, the timer may be applied when the SIB is read (not necessarily at the modification period boundary).

In another example, the UE can start a random timer when there is background data to send and the restricting bit is set (i.e., TRUE status/state). If the restricting bit <NUM> was already cleared in the previous modification period (e.g., the bit is not set at the modification period boundary just prior to the timer expiry), then the UE <NUM> is allowed to access the cell with unattended data traffic when the timer expires. Other examples of handling unattended data traffic are disclosed herein below.

In an example, the SIB <NUM> may also include a timer base value <NUM>. The timer base value <NUM> can be used by the UE <NUM> as a base value in configuring the duration of the random timer.

The S1 interface <NUM> is the interface that separates the RAN <NUM> and the EPC <NUM>. It is split into two parts: the S1-U, which carries traffic data between the eNB <NUM> and the serving GW <NUM>, and the S1-MME, which is a signaling interface between the eNB <NUM> and the MME <NUM>. The X2 interface is the interface between eNB <NUM>. The X2 interface comprises two parts, the X2-C and X2-U. The X2-C is the control plane interface between the eNB <NUM>, while the X2-U is the user plane interface between the eNB <NUM>.

With cellular networks, Low Power (LP) cells are typically used to extend coverage to indoor areas where outdoor signals do not reach well, or to add network capacity in areas with very dense phone usage, such as train stations. As used herein, the term low power (LP) eNB refers to any suitable relatively low power eNB for implementing a narrower cell (narrower than a macro cell) such as a femtocell, a picocell, or a micro cell. Femtocell eNBs are typically provided by a mobile network operator to its residential or enterprise customers. A femtocell is typically the size of a residential gateway or smaller and generally connects to the user's broadband line. Once plugged in, the femtocell connects to the mobile operator's mobile network and provides extra coverage in a range of typically <NUM> to <NUM> meters for residential femtocells. Thus, a LP eNB might be a femtocell eNB since it is coupled through the PDN GW <NUM>. Similarly, a picocell is a wireless communication system typically covering a small area, such as in-building (offices, shopping malls, train stations, etc.), or more recently in-aircraft. A picocell eNB can generally connect through the X2 link to another eNB such as a macro eNB through its base station controller (BSC) functionality. Thus, LP eNB may be implemented with a picocell eNB since it is coupled to a macro eNB via an X2 interface. Picocell eNBs or other LP eNBs may incorporate some or all functionality of a macro eNB. In some cases, this may be referred to as an access point base station or enterprise femtocell.

Communication over an LTE network may be split up into <NUM> frames, each of which contains ten <NUM> subframes. Each subframe, in turn, may contain two slots of <NUM>. Each slot may contain <NUM>-<NUM> symbols, depending on the system used. A resource block (RB) (also called physical resource block (PRB)) may be the smallest unit of resources that can be allocated to a UE. A resource block may be <NUM> wide in frequency and <NUM> slot long in time. In frequency, resource blocks may be either <NUM> x <NUM> subcarriers or <NUM> x <NUM> subcarriers wide. For most channels and signals, <NUM> subcarriers may be used per resource block. In Frequency Division Duplexed (FDD) mode, both the uplink and downlink frames may be <NUM> and may be frequency (full-duplex) or time (half-duplex) separated. In Time Division Duplexed (TDD), the uplink and downlink subframes may be transmitted on the same frequency and may be multiplexed in the time domain. A downlink resource grid may be used for downlink transmissions from an eNB to a UE. The grid may be a time-frequency grid, which is the physical resource in the downlink in each slot. Each column and each row of the resource grid may correspond to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain may correspond to one slot. The smallest time-frequency unit in a resource grid may be denoted as a resource element. Each resource grid may comprise a number of the above resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block may comprise <NUM> (subcarriers) *<NUM> (symbols) =<NUM> resource elements.

In some embodiments, a downlink resource grid may be used for downlink transmissions from an eNB <NUM> to a UE <NUM>, while uplink transmission from the UE <NUM> to the eNB <NUM> may utilize similar techniques. The grid may be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Each column and each row of the resource grid correspond to one OFDM symbol and one OFDM subcarrier, respectively. The smallest time-frequency unit in a resource grid is denoted as a resource element (RE). Each resource grid comprises a number of resource blocks (RBs), which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements in the frequency domain and may represent the smallest quanta of resources that currently can be allocated. Two example physical downlink channels are the physical downlink shared channel and the physical down link control channel.

There may be several different physical downlink channels that are conveyed using such resource blocks. Two of these physical downlink channels may be the physical down link control channel (PDCCH) and the physical downlink shared channel (PDSCH). Each subframe may be partitioned into the PDCCH and the PDSCH.

The physical downlink shared channel (PDSCH) carries user data and higher-layer signaling to a UE <NUM> (<FIG>). The physical downlink control channel (PDCCH) carries information about the transport format and resource allocations related to the PDSCH channel, among other things. It also informs the UE <NUM> about the transport format, resource allocation, and hybrid automatic repeat request (HARQ) information related to the uplink shared channel. Typically, downlink scheduling (e.g., assigning control and shared channel resource blocks to UE <NUM> within a cell) may be performed at the eNB <NUM> based on channel quality information fed back from the UE <NUM> to the eNB <NUM>, and then the downlink resource assignment information may be sent to the UE <NUM> on the control channel (PDCCH) used for (assigned to) the UE <NUM>.

The PDCCH uses CCEs (control channel elements) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols are first organized into quadruplets, which are then permuted using a sub-block inter-leaver for rate matching. Each PDCCH is transmitted using one or more of these control channel elements (CCEs), where each CCE corresponds to nine sets of four physical resource elements known as resource element groups (REGs). Four QPSK symbols are mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of downlink control information (DCI) and the channel condition. There may be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=<NUM>, <NUM>, <NUM>, or <NUM>).

As used herein, the term circuitry may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), or memory (shared, dedicated, or group) that executes one or more software or firmware programs, a combinational logic circuit, or other suitable hardware components that provide the described functionality. Embodiments described herein may be implemented into a system using any suitably configured hardware or software.

<FIG> is a functional diagram of a User Equipment (UE) in accordance with some embodiments. The UE <NUM> may be suitable for use as a UE <NUM> as depicted in <FIG>. In some embodiments, the UE <NUM> may include application circuitry <NUM>, baseband circuitry <NUM>, Radio Frequency (RF) circuitry <NUM>, front-end module (FEM) circuitry <NUM>, and multiple antennas 210A-210D, coupled together at least as shown. In some embodiments, other circuitry or arrangements may include one or more elements or components of the application circuitry <NUM>, the baseband circuitry <NUM>, the RF circuitry <NUM> or the FEM circuitry <NUM>, and may also include other elements or components in some cases. As an example, "processing circuitry" may include one or more elements or components, some or all of which may be included in the application circuitry <NUM> or the baseband circuitry <NUM>. As another example, "transceiver circuitry" may include one or more elements or components, some or all of which may be included in the RF circuitry <NUM> or the FEM circuitry <NUM>. These examples are not limiting, however, as the processing circuitry or the transceiver circuitry may also include other elements or components in some cases.

The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the system to perform one or more of the functionalities described herein.

The baseband circuitry <NUM> may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry <NUM> and to generate baseband signals for a transmit signal path of the RF circuitry <NUM>. Baseband processing circuity <NUM> may interface with the application circuitry <NUM> for generation and processing of the baseband signals and for controlling operations of the RF circuitry <NUM>. For example, in some embodiments, the baseband circuitry <NUM> may include a second generation (<NUM>) baseband processor 204a, third generation (<NUM>) baseband processor 204b, fourth generation (<NUM>) baseband processor 204c, or other baseband processor(s) 204d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (<NUM>), <NUM>, etc.). The baseband circuitry <NUM> (e.g., one or more of baseband processors 204a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry <NUM>. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry <NUM> may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry <NUM> may include Low Density Parity Check (LDPC) encoder/decoder functionality, optionally along-side other techniques such as, for example, block codes, convolutional codes, turbo codes, or the like, which may be used to support legacy protocols. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry <NUM> may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY) 205a, media access control (MAC) 205b, radio link control (RLC) 205c, packet data convergence protocol (PDCP) 205d, and/or radio resource control (RRC) 205e elements. Additionally, the UE <NUM> may further include network attached storage 205f.

A central processing unit (CPU) 204e of the baseband circuitry <NUM> may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 204f. The audio DSP(s) 204f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry <NUM> and the application circuitry <NUM> may be implemented together such as, for example, on a system on chip (SOC).

In some embodiments, the RF circuitry <NUM> may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry <NUM> may include mixer circuitry 206a, amplifier circuitry 206b and filter circuitry 206c. The transmit signal path of the RF circuitry <NUM> may include filter circuitry 206c and mixer circuitry 206a. RF circuitry <NUM> may also include synthesizer circuitry 206d for synthesizing a frequency for use by the mixer circuitry 206a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 206a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry <NUM> based on the synthesized frequency provided by synthesizer circuitry 206d. The amplifier circuitry 206b may be configured to amplify the down-converted signals and the filter circuitry 206c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry <NUM> for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 206a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect. In some embodiments, the mixer circuitry 206a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 206d to generate RF output signals for the FEM circuitry <NUM>. The baseband signals may be provided by the baseband circuitry <NUM> and may be filtered by filter circuitry 206c. The filter circuitry 206c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion or upconversion respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a may be arranged for direct downconversion or direct upconversion, respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the synthesizer circuitry 206d may be a fractional-N synthesizer or a fractional N/N+<NUM> synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 206d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider. The synthesizer circuitry 206d may be configured to synthesize an output frequency for use by the mixer circuitry 206a of the RF circuitry <NUM> based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 206d may be a fractional N/N+<NUM> synthesizer.

Synthesizer circuitry 206d of the RF circuitry <NUM> may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+<NUM> (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 206d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry <NUM> may include an IQ/polar converter.

FEM circuitry <NUM> may include a receive signal path, which may include circuitry configured to operate on RF signals received from one or more of the antennas 210A-D, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry <NUM> for further processing. FEM circuitry <NUM> may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry <NUM> for transmission by one or more of the one or more antennas 210A-D.

In some embodiments, the UE <NUM> may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface.

<FIG> is a functional diagram of an Evolved Node-B (eNB) in accordance with some embodiments. It should be noted that in some embodiments, the eNB <NUM> may be a stationary non-mobile device. The eNB <NUM> may be suitable for use as an eNB <NUM> as depicted in <FIG>. The components of eNB <NUM> may be included in a single device or a plurality of devices. The eNB <NUM> may include physical layer (PHY) circuitry <NUM> and a transceiver <NUM>, one or both of which may enable transmission and reception of signals to and from the UE <NUM>, other eNBs, other UEs or other devices using one or more antennas 301A-B. As an example, the physical layer circuitry <NUM> may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals. For example, physical layer circuitry <NUM> may include LDPC encoder/decoder functionality, optionally along-side other techniques such as, for example, block codes, convolutional codes, turbo codes, or the like, which may be used to support legacy protocols. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. As another example, the transceiver <NUM> may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range. Accordingly, the physical layer circuitry <NUM> and the transceiver <NUM> may be separate components or may be part of a combined component. In addition, some of the described functionality related to transmission and reception of signals may be performed by a combination that may include one, any or all of the physical layer circuitry <NUM>, the transceiver <NUM>, and other components or layers. The eNB <NUM> may also include medium access control layer (MAC) circuitry <NUM> for controlling access to the wireless medium. The eNB <NUM> may also include processing circuitry <NUM> and memory <NUM> arranged to perform the operations described herein. The eNB <NUM> may also include one or more interfaces <NUM>, which may enable communication with other components, including other eNB <NUM> (<FIG>), components in the EPC <NUM> (<FIG>) or other network components. In addition, the interfaces <NUM> may enable communication with other components that may not be shown in <FIG>, including components external to the network. The interfaces <NUM> may be wired or wireless or a combination thereof.

In an example, the eNB <NUM> may further include radio link control (RLC) 311a, packet data convergence protocol (PDCP) 311b, and/or radio resource control (RRC) 311c elements.

The antennas 210A-D (in the UE) and 301A-B (in the eNB) may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some multiple-input multiple-output (MIMO) embodiments, the antennas 210A-D, 301A-B may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.

In some embodiments, the UE <NUM> or the eNB <NUM> may be a mobile device and may be a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a wearable device such as a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive or transmit information wirelessly. In some embodiments, the UE <NUM> or eNB <NUM> may be configured to operate in accordance with 3GPP standards (e.g., <NUM>, <NUM>, <NUM> or another standard), although the scope of the embodiments is not limited in this respect. Mobile devices or other devices in some embodiments may be configured to operate according to other protocols or standards, including IEEE <NUM> or other IEEE standards. In some embodiments, the UE <NUM>, eNB <NUM> or other device may include one or more of a keyboard, a display, a non-volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other mobile device elements. The display may be an LCD screen including a touch screen.

Although the UE <NUM> and the eNB <NUM> are each illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements.

Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media. Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device.

It should be noted that in some embodiments, an apparatus used by the UE <NUM> or eNB <NUM> may include various components of the UE <NUM> or the eNB <NUM> as shown in <FIG> and <FIG>. Accordingly, techniques and operations described herein that refer to the UE <NUM> (or <NUM>) may be applicable to an apparatus for a UE. In addition, techniques and operations described herein that refer to the eNB <NUM> (or <NUM>) may be applicable to an apparatus for an eNB.

<FIG> illustrates reception of a system information block (SIB) during a modification period, in accordance with some embodiments. Additional modification period structure is illustrated in reference to <FIG> and corresponding description herein above. Referring to <FIG>, there is illustrated a modification period <NUM>, during which the eNB <NUM> can transmit system information to the UE <NUM>. In an example, the system information can include a system information block (SIB) <NUM>. The SIB <NUM> can include cell access related information, information for cell selection, scheduling information, radio resource configuration information, as well as other system information. In an example, the SIB <NUM> can be a System Information Block - Type <NUM>, which can include radio resource configuration information that is common for all UEs <NUM> within the cell of the eNB <NUM>.

In an example, the SIB <NUM> can include a restricting bit, such as the restricting bit <NUM> in SIB <NUM>. Additionally, the SIB <NUM> can be broadcast by the eNB <NUM> (and received by the UE <NUM>) a number of times within the modification period <NUM>. For example, and as seen in <FIG>, the SIB <NUM> is transmitted three times during the modification period <NUM>, at times t1, t2, and t3.

The modification period can have a beginning time A <NUM> and an end time (or boundary) B <NUM>. During the modification period, the SIB <NUM> can be the same or some portions of the SIB <NUM> can be modified between the multiple transmissions within the period <NUM>. For example, the status of the restricting bit <NUM> can stay the same (e.g., TRUE or FALSE) throughout the period <NUM>, or it may change. The UE <NUM> can receive the multiple transmissions of the SIB <NUM>, and can act on the restricting bit <NUM> at the expiration of the modification period (e.g., at the boundary <NUM>).

<FIG> illustrate example System_Information_Block_Type2 signaling, in accordance with some embodiments. Referring to <FIG>, there is illustrated a System Information Block - Type <NUM> (SIB-<NUM>) information element <NUM>. The SIB-<NUM> can include a restricting bit <NUM> and a timer base value <NUM>. The restricting bit <NUM> may be similar to the restricting bit <NUM>, and the timer base value <NUM> can be similar to the timer base value <NUM>.

In an example, the restricting bit <NUM> can be an unattended data traffic (udt) restricting bit, which is designated as udt-Restricting in <FIG>. A restricting bit value of TRUE indicates to the UE to restrict unattended data traffic. For example, the UE can indicate to a higher layer (e.g., operating system layer or an application layer) to restrict the unattended data traffic. should indicate to the higher layers to restrict unattended data traffic.

In an example, the timer base value <NUM> can be an unattended data traffic (udt) RestrictingTime value, as illustrated in <FIG>. If present and when the udt-Restricting changes from TRUE to FALSE, the UE can run a random timer for a period equal to, e.g., (rand * udt-RestrictingTime) seconds, where rand can be a random number drawn that is uniformly distributed in the range <NUM> ≤ rand < <NUM>. In instances when udt-Restricting bit <NUM> changes to TRUE, the random timer can stop (or expire). Upon timer expiry, the UE may indicates to the higher layers that the restriction on unattended data traffic is alleviated.

Even though <FIG> illustrates the SIB-<NUM> information element as using designations of udt-Restricting and udt-RestrictingTime for the restricting bit and the timer base value, the disclosure is not limited in this regard and other designations may be used as well. For example, in other instances udt-Barring and udt-BarringTime may be used instead. As used herein, the terms "restricting" and "barring" are used interchangeably.

<FIG> are flow diagrams illustrating example functionalities for solutions for staggering unattended data traffic after barring, in accordance with some embodiments. Referring to <FIG> and <FIG>, at <NUM>, the UE <NUM> can communicate any kind of data traffic to the eNB <NUM> as access to the eNB is not barred. As the UE <NUM> receives SIBs (e.g., <NUM>) during a modification period (e.g., <NUM>), the UE <NUM> can monitor status of the restricting bit <NUM>. The UE <NUM> may process the SIB at the modification period boundary, and detect the status of the restricting bit at that time. If the restricting bit is not set, then communication of unattended data traffic to the eNB may continue. If the restricting bit <NUM> is set (i.e., it has a value of TRUE indicating unattended data traffic is to be restricted), then at <NUM>, the UE <NUM> restricts communication of unattended data traffic. Such restriction may take place at the end of the modification period (e.g., boundary <NUM>). At <NUM>, it may be determined (e.g., after the UE receives a new SIB and reads it at the modification period boundary) whether the restricting bit <NUM> has been cleared (e.g., the status has changed from TRUE to FALSE, or from restricting to non-restricting). If the bit has not cleared, then processing resumes at <NUM>, when unattended data traffic is still barred. If the bit has cleared, then processing resumes at <NUM>.

At <NUM>, the UE <NUM> can start a random timer when it is detected that the restricting bit status has changed to non-restricting. By default, the UE <NUM> reads the SIB <NUM> at the modification period boundary and, therefore, the barring removal is identified by the UE at the modification period boundary. The UE <NUM> may then access the eNB cell with unattended data traffic (and/or any other type of data traffic) when the timer expires. The timer value (e.g., the timer duration) may be randomly chosen and may be based on the timer base value <NUM> that is broadcast with the SIB <NUM>. Since different UEs may select different random values, each UE may be allowed to access the cell at different times, thereby distributing the load to the eNB and reducing the potential for data overload.

In an example, the timer base value of the random timer may be provided in the SIB, as illustrated in <FIG>. In another example, the timer base value may be specified in a wireless standard (i.e., be pre-determined and known to all UEs) rather than being broadcast by the eNB. In yet another example, the timer base value may be determined by the UE. In yet another example, the timer base value (or the random timer altogether) may be handled or provided by the higher layers, such as, operating system layer, application, connection manager, and so forth.

Alternatively, the barring timer may be set differently in instances when there is certain granularity within the background applications or categorizations of data traffic within the UE. For example, instead of treating all background traffic the same, certain classification may be implemented which may allow for setting of different barring rules. For example, different restricting bits can be defined and used within the SIB, where each restricting bit can be associated with a different type of unattended data traffic. Example types of background/unattended data traffic may include higher priority traffic (e.g., synchronization of news, work/personal email or shared notes) and lower priority traffic (e.g., synchronization of social media/network applications, discussion forums, or maps).

At <NUM>, it may be determined whether the random timer has expired. If the random timer has expired, processing may resume at <NUM>, when it may be determined again whether the restricting bit is set.

Referring to <FIG> and <FIG>, the example method illustrated may start at <NUM>, when it may be determined that the UE <NUM> has unattended data traffic to send. At <NUM>, it may be determined whether a barring (random) timer is already running. If no timer is running, at <NUM>, it may be determined whether the barring/restricting bit <NUM> is set (i.e., unattended traffic is being barred/restricted). If the bit is set, then at <NUM>, a random timer may be started, and if it is not set, then unattended data may be communicated at <NUM>. If the random timer has started at <NUM> (or if the timer is already running), then processing may continue at <NUM>. At <NUM>, it may be determined whether the timer has expired. If it has expired, then processing may continue at <NUM>, when it may be determined whether the restricting of unattended data traffic has been removed at a previous modification period boundary. If restricting has not been removed, then processing may continue at <NUM>. If the restricting has been removed (i.e., the restricting bit is set to FALSE), then processing may continue at <NUM> when unattended data may be sent out to the eNB.

Referring to <FIG> and <FIG>, the example method <NUM> may start at <NUM>, when a System Information Block (SIB) information element (IE) is decoded to determine status of a restricting bit in the SIB IE. For example, the UE <NUM> may decode the SIB <NUM> to determine status of the restricting bit <NUM>. The SIB IE <NUM> may be received during a modification period (e.g., <NUM>). The SIB IE <NUM> may be received a number of times within the modification period <NUM> (e.g., as illustrated in <FIG>). In some examples, the SIB may be transmitted (and received during a single modification period) only once, and in other examples it may be transmitted (and received) more than once in a single modification period. At <NUM>, a change in the restricting bit status may be detected from barring of unattended data traffic to non-barring of the unattended data traffic. For example, the UE <NUM> may initially detect that the restricting bit <NUM> is set and unattended data traffic is restricted/barred. During a subsequent modification period, however, the UE may detect that the restricting bit status has changed from barring (e.g., TRUE value for the bit) to non-barring (e.g., FALSE value for the bit). At <NUM>, a timer may be initiated for a time interval with a random duration. For example, the UE <NUM> may initiate a random timer using, e.g., the timer base value <NUM> received from the eNB. AT <NUM>, upon expiration of the time interval, communication of the unattended data traffic may be resumed with the eNB. As illustrated in <FIG>, the restricting bit may be an unattended data traffic (udt) Restricting bit, and the timer base value may be a udt-RestrictingTime value.

Referring to <FIG> and <FIG>, the example method <NUM> may start at <NUM>, when a System Information Block (SIB) information element (IE) may be decoded to determine status of a restricting bit in the SIB IE. For example, the UE <NUM> may receive data from the eNB (e.g., a SIB <NUM>), and the SIB <NUM> may be decoded to determine status of the restricting bit <NUM>. The SIB IE <NUM> may be received during a modification period (e.g., <NUM>). The SIB IE <NUM> may be received a number of times within the modification period <NUM> (e.g., as illustrated in <FIG>). AT <NUM>, a first timer with a random duration may be initiated, upon detecting availability of unattended data for communication to the eNB and the restricting bit status indicates barring of unattended data traffic. For example, the UE <NUM> may detect that there is unattended data traffic for communication to the eNB <NUM>. At a modification period boundary (e.g., at <NUM>), the UE may further determine that the restricting bit <NUM> status indicates restricting of unattended data traffic. The UE may then initiate a timer with a random duration. At <NUM>, upon expiration of the first timer, communication of the unattended data traffic to the eNB may be initiated, when the restricting bit status indicates non-barring of the unattended data traffic. In this regard, after expiration of the timer, the UE <NUM> may verify (e.g., at modification period boundary <NUM>) that the restricting bit <NUM> status has changed to non-barring before proceeding with communication of the unattended data traffic to the eNB <NUM>.

<FIG> illustrates a block diagram of a communication device such as an eNB or a UE, in accordance with some embodiments. In alternative embodiments, the communication device <NUM> may operate as a standalone device or may be connected (e.g., networked) to other communication devices. In a networked deployment, the communication device <NUM> may operate in the capacity of a server communication device, a client communication device, or both in server-client network environments. In an example, the communication device <NUM> may act as a peer communication device in peer-to-peer (P2P) (or other distributed) network environment. The communication device <NUM> may be a UE, eNB, PC, a tablet PC, a STB, a PDA, a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by that communication device. Further, while only a single communication device is illustrated, the term "communication device" shall also be taken to include any collection of communication devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.

In an example, the software may reside on a communication device readable medium.

Communication device (e.g., UE) <NUM> may include a hardware processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory <NUM> and a static memory <NUM>, some or all of which may communicate with each other via an interlink (e.g., bus) <NUM>. The communication device <NUM> may further include a display unit <NUM>, an alphanumeric input device <NUM> (e.g., a keyboard), and a user interface (UI) navigation device <NUM> (e.g., a mouse). The communication device <NUM> may additionally include a storage device (e.g., drive unit) <NUM>, a signal generation device <NUM> (e.g., a speaker), a network interface device <NUM>, and one or more sensors <NUM>, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The communication device <NUM> may include an output controller <NUM>, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The storage device <NUM> may include a communication device readable medium <NUM> on which is stored one or more sets of data structures or instructions <NUM> (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM>, within static memory <NUM>, or within the hardware processor <NUM> during execution thereof by the communication device <NUM>. In an example, one or any combination of the hardware processor <NUM>, the main memory <NUM>, the static memory <NUM>, or the storage device <NUM> may constitute communication device readable media.

While the communication device readable medium <NUM> is illustrated as a single medium, the term "communication device readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions <NUM>.

The term "communication device readable medium" may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device <NUM> and that cause the communication device <NUM> to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting communication device readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of communication device readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, communication device readable media may include non-transitory communication device readable media. In some examples, communication device readable media may include communication device readable media that is not a transitory propagating signal.

The instructions <NUM> may further be transmitted or received over a communications network <NUM> using a transmission medium via the network interface device <NUM> utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) <NUM> family of standards known as Wi-Fi®, IEEE <NUM> family of standards known as WiMax®), IEEE <NUM>. <NUM> family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device <NUM> may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network <NUM>. In an example, the network interface device <NUM> may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) techniques. In some examples, the network interface device <NUM> may wirelessly communicate using Multiple User MIMO techniques. The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the communication device <NUM>, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

The drawings show, by way of illustration, specific embodiments that may be practiced. " Such examples may include elements in addition to those shown or described. However, also contemplated are examples that include the elements shown or described. Moreover, also contemplated are examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein. " Also, in the following claims, the terms "including" and "comprising" are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to suggest a numerical order for their objects.

Claim 1:
A user equipment, UE (<NUM>, <NUM>), configured to communicate with an evolved node B, eNB, (<NUM>, <NUM>), the UE (<NUM>, <NUM>) comprising:
memory; and
processing circuitry coupled to the memory, the processing circuitry configured to:
decode (<NUM>) a System Information Block, SIB, information element, IE, to determine status of a restricting bit in the SIB IE as well as a timer base value in the SIB IE, the SIB IE received during a modification period from an evolved Node B, eNB, wherein the restricting bit is an unattended data traffic, udt, Restricting bit and the timer base value is a udt-RestrictingTime value determined by the eNB;
detect (<NUM>) a change in the restricting bit status from barring of unattended data traffic to non-barring of the unattended data traffic;
initiate (<NUM>), at a boundary time of the system information modification period, a timer for a time interval with a random duration, the random duration based on the udt-RestrictingTime value, in response to detecting said change from barring of unattended data traffic to non-barring of the unattended data traffic; and
upon expiration of the timer, resume (<NUM>) communication of the unattended data traffic with the eNB.