Patent Description:
This section is intended to provide a background or context to the invention disclosed below. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived, implemented or described. Therefore, unless otherwise explicitly indicated herein, what is described in this section is not prior art to the description in this application and is not admitted to be prior art by inclusion in this section. Abbreviations that may be used in the specification and/or drawings are defined below.

Idle-mode load balancing is an active LTE Rel. <NUM> topic, with a lot of interest from various major operators. The massive growth in data services and devices to support them also demand growth in an operator's network. The number of online gaming applications, real time applications, and the like is growing by the day. That means more and more LTE sites are installed to support the high demand for data. Heterogeneous networks (HetNets) where underlay small cells cover hot spots under overlaid macro cells are becoming very common in urban areas. With such growth also come challenges. For instance, maintaining a well-balanced load among different cells is critical for operators to run their networks smoothly.

Some techniques already exist to tackle idle mode load balancing in previous LTE releases (LTE Rel. <NUM> and before). However, these techniques are not robust. For example, one such existing technique is redirection of a UE to a different cell at call setup if the cell on which the UE that attempted the call setup is either congested or not optimal for the service the UE is requesting. If the UE has more up to date information, the UE can be camped on a cell that can provide the best service when the UE becomes active. By doing this, there will be less chance of the UE being re-directed to a different cell during call setup. Also, re-directing a UE to a different cell increases signaling during call setup and add delays to the overall call setup procedure.

United States patent application number <CIT> relates to directing traffic between cells of different sizes. One embodiment of the method includes determining, at a mobile unit, whether to hand off from a source cell to a target cell based on information indicating sizes of coverage areas of the source cell and the target cell.

All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention.

The exemplary embodiments herein describe techniques for network congestion control via paging procedures. Additional description of these techniques is presented after a system is described into which some exemplary embodiments may be used.

Turning to <FIG>, this figure shows a block diagram of an exemplary system in which exemplary embodiments may be practiced. In <FIG>, M UEs <NUM>-<NUM> through <NUM>-M are in wireless communication with a wireless network <NUM> and specifically with N eNBs <NUM>-<NUM> through <NUM>-N. Each of the UEs is assumed to be similar, so possible internal configuration of one UE will be described. A user equipment <NUM> (e.g., <NUM>-<NUM>) includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> includes a Network Congestion Control (NCC) module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The NCC module <NUM> may be implemented in hardware as NCC module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The NCC module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the NCC module <NUM> may be implemented as NCC module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the user equipment <NUM> to perform one or more of the operations as described herein.

Each UE <NUM> communicates with one or more eNBs <NUM>-<NUM> through <NUM>-N via a corresponding wireless link <NUM>-<NUM> through <NUM>-N. For instance, UE <NUM>-<NUM> communicates with eNBs <NUM>-<NUM> through <NUM>-N via a corresponding wireless link <NUM>-<NUM> through <NUM>-1N, while UE <NUM>-M communicates with one or more eNBs <NUM>-<NUM> through <NUM>-N via a corresponding wireless link <NUM>-M1 through <NUM>-MN. Note that each UE <NUM> may not actually communicate with each eNB <NUM>.

The eNBs <NUM>-<NUM> through <NUM>-N are expected to be similar. Therefore, only one possible implementation of an eNB will be described in reference to <FIG>. An eNB <NUM> (e.g., eNB <NUM>-<NUM>) is a base station that provides access by wireless devices such as the UEs <NUM> to the wireless network <NUM>. The eNB <NUM> includes one or more processors <NUM>, one or more memories <NUM>, one or more network interfaces (N/W I/F(s)) <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. The eNB <NUM> includes a Network Congestion Control (NCC) NCC module <NUM>, comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The NCC module <NUM> may be implemented in hardware as NCC module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The NCC module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the NCC module <NUM> may be implemented as NCC module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. For instance, the one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the eNB <NUM> to perform one or more of the operations as described herein. Two or more eNBs <NUM> communicate using, e.g., link <NUM>. The link <NUM> may be wired or wireless or both and may implement, e.g., an X2 interface.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM>, with the other elements of the eNB <NUM> being physically in a different location from the RRH, and the one or more buses <NUM> could be implemented in part as fiber optic cable to connect the other elements of the eNB <NUM> to the RRH <NUM>.

The wireless network <NUM> may include a network control element (NCE) <NUM> that may include MME/SGW functionality, and which provides connectivity with a further network, such as a telephone network and/or a data communications network (e.g., the Internet). The eNB <NUM> is coupled via a link <NUM> to the NCE <NUM>. The link <NUM> may be implemented as, e.g., an S1 interface. The NCE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the NCE <NUM> to perform one or more operations.

Note that not all (or even no) eNBs <NUM> need to implement virtualization and thus RRHs <NUM> might not be used by one or more of the eNBs <NUM>.

The UEs <NUM> may be formed into one or more groups <NUM>. For ease of reference, only one group <NUM> is illustrated in <FIG>, and this group <NUM> contains UEs <NUM>-<NUM> through <NUM>-M. However, the UEs <NUM>-<NUM> through <NUM>-M may be formed into multiple groups <NUM>.

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples.

In general, the various embodiments of the user equipment <NUM> can include, but are not limited to, cellular telephones such as smart phones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, tablets with wireless communication capabilities, as well as portable units or terminals that incorporate combinations of such functions.

Turning to <FIG>, this figure is an example of a HetNet scenario. A HetNet scenario is one scenario where the techniques herein may be applied. In this example, there are two macro cells <NUM>-<NUM> and <NUM>-<NUM> (formed by eNBs <NUM>-<NUM> and <NUM>-<NUM>, respectively), which overlie a number of underlying cells <NUM>-<NUM>, -<NUM>, -<NUM>, -<NUM>, -<NUM>, and -<NUM> (formed by eNBs <NUM>-<NUM>, -<NUM>, -<NUM>, -<NUM>, -<NUM>, and -<NUM>, respectively). It is noted that the overlying and underlying cells may also be referred to using other terminology. For instance, overlying cells <NUM>-<NUM> and <NUM>-<NUM> may also be referred to as coverage or candidate cells, while the underlying cells <NUM>-<NUM>, -<NUM>, - <NUM>, -<NUM>, -<NUM>, and -<NUM> may also be called capacity booster or original cells. It is furthered noted that description herein indicates that "cells" perform functions, but it should be clear that the eNB that forms the cell will perform the functions. The cell makes up part of an eNB. That is, there can be multiple cells per eNB. For instance, there could be three cells for a single eNB carrier frequency and associated bandwidth, each cell covering one-third of a <NUM> degree area so that the single eNB's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and an eNB may use multiple carriers. So if there are three <NUM> degree cells per carrier and two carriers, then the eNB has a total of <NUM> cells.

Now that an exemplary system has been described, additional description of problems with conventional load balancing is presented. Currently, idle mode load balancing is performed via cell reselection priorities. There are currently two ways of providing cell reselection priorities to the UEs: Either by broadcast of Absolute Priorities (AP) in System Information, or giving the dedicated priorities (DP) in the RRC message RRCConnectionRelease.

With APs, the UE <NUM> is instructed in SIB signaling as to which cells to prioritize for reselection in idle mode. This method is applicable to LTE Rel. <NUM> UEs and beyond. With Dedicated Priorities (DPs), which are provided to a UE during RRC Connection Release (as is known, this is a message sent from the eNB to the UE when UE is supposed to switch from an RRC_CONNECTED state to an RRC_IDLE state) and applied by the UE during idle mode cell selection, the UE applies the priorities for a set amount of time or until the UE moves to the RRC_CONNECTED state again. However, for DP, no mechanism exists which would allow reaching a subset of UEs that are already in idle mode (thus - not reachable via call release in the case of DPs). As a result, the only possibility is to send APs which would be globally acquired by the entire UE population.

A second problem with the dedicated priorities in the existing procedure is that these priorities may be outdated. This means the network (e.g., or one of its carriers) that was congested at the time of UE release may not be congested when the UE attempts to set up a new call some time later (or vice versa). As the network has no control over the time the UE stays idle, there is a good chance that the dedicated priorities sent to the UE as part of call release may be outdated. In such situations, applying dedicated priorities could negatively impact the network operation.

As stated above, the topic of idle load mode balancing has been under discussions in the prior LTE releases. Conventional solutions include cell specific absolute priorities, randomization (nicely summarized in, e.g., <NPL>), and use of paging for one-off rebalancing (<NPL>).

A cell de-prioritization mechanism was defined in Rel-<NUM> , where a UE can be informed via an RRCConnectionReject message that the current frequency or RAT is being deprioritized. This was intended for, e.g., CSFB cases.

Cell-specific priorities can be used to differentiate the priorities between cells operating on the same carrier frequency. It can be of use especially in heterogeneous deployments, but potentially also in situations with unbalanced load between cells operating on the same frequency. However, this solution is not suitable for solving the issue of closely located idle-mode UEs (e.g., almost) simultaneously entering the coverage area of a cell with high priority.

Techniques based on the so-called randomization of frequency and/or cell specific priorities try to solve this problem by associating to a specific cell and/or frequency priority a probability, which an idle-mode UE should take into account. However, solutions based on randomization at the UE present the challenge that an update of the frequency and/or cell specific priority will need to be applied only once by a UE. So some other mechanism to prevent UEs from continuously reapplying the redistribution function with no control from the network side is needed.

Therefore a method based on one-off re-distribution of a fraction of users in a cell using paging mechanism is proposed in R2-<NUM>. The proposed technique there is to provide the one-off prioritization information in the paging message itself. The main limitation of this proposed technique is that indicating which UEs should apply the redistribution can consume a lot of resources from the network, as the amount of data to perform the indicating could be large.

In this disclosure, we propose further enhancements to the conventional techniques, based on a different type of paging mechanism. Specifically, exemplary embodiments herein are aimed at providing additional load balancing capabilities to the network/eNB by utilizing the existing paging procedure. Briefly, the following implementations are possible (and others are described below):.

In more detail, one idea is to use the existing paging message with additional Information Elements (lEs) to instruct an idle-mode UE <NUM> or a group <NUM> of idle-mode UEs <NUM> on the set of reselection priorities to apply during cell selection. This can be achieved either via a dedicated paging message (i.e., paging a single UE) or a group paging message (i.e. paging a group <NUM> of UEs).

When the network <NUM> crosses a congestion threshold, the network can decide to start paging UEs <NUM> or a group <NUM> of UEs <NUM> for the purpose of load balancing. Since the UEs <NUM> are expected to wake up during their paging interval, a UE <NUM> shall be able to decode the page, obtain the DP load balancing triggers, and apply the triggers during cell selection. This can especially be beneficial if the UE is being paged (e.g., a mobile terminated call setup) along with congestion control DP triggers during network congestion. Also, using paging to trigger reselection of DPs while the network is congested is more practical as compared to sending DP in an RRC call release procedure, since the network <NUM> has no control over UE <NUM> as to when the UE goes from the idle mode to the active mode. By adopting this enhanced paging method, we are eliminating the use of stale DPs for cases when UE stays in idle mode for a much longer time.

Also, not only the activation, but the de-activation of these DP triggers can be controlled via a paging method. As the network load keeps changing with time (e.g., busy hours versus non-busy hours) the need for DPs trigger also keeps changing. This enhanced paging method for congestion control is well adopted with ongoing changes in network load, which prior to these techniques was not possible with the RRC call release procedure. As a matter of fact, applying outdated DPs via RRC call release procedure could negatively impact the network performance.

The following is a list of possibilities on how to notify a UE, or how to activate or de-activate DPs during congestion or if the network is coming out of a congested state. The priorities described below for paging may be considered to be DPs.

Turning now to <FIG>, this figure is a logic flow diagram performed by a base station for network congestion control via paging procedures. This figure also illustrates the operation of an exemplary method, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiment. The blocks in <FIG> are assumed to be performed by eNB <NUM>, e.g., under control in part by the Network Congestion Control (NCC) module <NUM>.

In block <NUM>, the eNB <NUM> starts a continuous idle-mode load balancing process. In block <NUM>, the eNB <NUM> configures UEs <NUM> with carriers to use for idle-mode camping on. Note that it is assumed that a single carrier is used per cell, and thus an eNB <NUM> that supports multiple carriers also supports multiple cells. In block <NUM>, the eNB <NUM> configures UEs <NUM> with load balancing information. Such information may include one or more of DPs and/or probabilities. Also, as noted above, there could be an indication (e.g., in RRC Connection Release for DPs or in SIB for APs) that this particular set of priorities should remain inactive until the paging trigger is received.

In block <NUM>, the eNB <NUM> determines load for a cell. The load corresponds to UEs that are in idle mode and camped on the cell. One possibility is for the load to correspond to the UEs which are in idle mode and camped on the cell, and the load can be used only in terms of the number of idle mode UEs. However, the assumption is that the network <NUM> performs load balancing and the network <NUM> can take into account more advanced factors (e.g., resource usage, interferences, etc.) for load determination. In block <NUM>, the eNB <NUM> determines whether a congestion threshold is reached. If the congestion threshold is not reached (block <NUM> = No), the flow continues to block <NUM>. Note that the flow may continue from block <NUM> (or block <NUM>), e.g., should the eNB <NUM> also determine to perform other configuration.

If the congestion threshold is reached (block <NUM> = Yes), the flow continues to block <NUM>. In block <NUM>, the eNB <NUM> determines (based on the load) if more than one UE should be offloaded from the current cell and, if so, assigns multiple UEs to a group <NUM>. One goal is to achieve a state "below the threshold" so in one example, if a threshold is <NUM> UEs (e.g., using a simple load based on number of UEs) and there are <NUM> UE, <NUM> UEs will be instructed to modify/apply their reselection priorities in order to mitigate the load situation.

In block <NUM>, the eNB <NUM> sends a paging message, configured with information, to the UE or the group of UEs. Examples of configured information in the paging messages are as follows. The paging message is configured to cause the one or more idle-mode UEs <NUM> to start a process to select a cell for camping on for idle mode. Note that since an idea is to reduce congestion, it is expected that the UEs will select a different cell (rather than the currently camped-on cell) to camp on for idle mode. However, individual UEs, e.g., using a randomization process, may select the currently camped-on cell instead of a different cell, depending on the techniques being used.

In block <NUM>, the configured information may include a trigger to activate previously acquired DPs. Refer also to paragraph a above.

In block <NUM>, the configured information may include a de-prioritization request, which instructs a UE or a group of UEs that a currently used carrier should be temporarily assigned the lowest priority. Refer also to paragraph b above.

In block <NUM>, the configured information may include a prioritization request, which causes the UE to temporarily assign a highest priority to a certain carrier. Refer also to paragraph c above, which further describes that the paging message may include an indication of frequency/carrier in an IE.

In block <NUM>, the configured information may include a probability. The probability could be used by the UE or group of UEs to trigger a randomization process. Refer also to paragraph d above.

In block <NUM>, the configured information may include an indication to trigger a randomization process based on one or more probabilities associated to one or more carriers that were previously acquired by the UEs. Refer also to paragraph e above.

Blocks <NUM>-<NUM> are expected to cause the UE(s) <NUM> receiving the paging message to consider starting a process to select a (e.g., different) cell on which the UE(s) will camp and potentially to cause the UE(s) <NUM> to select a different cell.

Referring to <FIG>, this figure is split into <FIG> and <FIG>, and contains a logic flow diagram that is shown that is performed by a user equipment for network congestion control via paging procedures. These figures further illustrate the operation of an exemplary method, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiment. The blocks in <FIG> are assumed to be performed by UE <NUM>, e.g., under control in part by the Network Congestion Control (NCC) module <NUM>.

In block <NUM>, the UE <NUM> receives configuration with carriers to use for idle-mode camping on. The UE <NUM>, in block <NUM>, receives configuration with load balancing information (e.g., DPs and/or probabilities). Also, as noted above, there could be an indication (e.g., in RRC Connection Release for DPs or in SIB for APs) that this particular set of priorities should remain inactive until the paging trigger is received. In block <NUM>, the UE <NUM> uses the configuration to select a cell to camp on, and in block <NUM>, the UE <NUM> camps on the selected cell.

In block <NUM>, the UE <NUM> determines whether paging (e.g., a paging message) is received for load balancing. If no paging is received (block <NUM> = No), the flow proceeds to block <NUM> (although the flow may also proceed to block <NUM> or <NUM>, as described above in reference to <FIG>).

If paging is received (block <NUM> = Yes), the flow proceeds to block <NUM>, where the configured information in the paging message is processed. This configured information may include the information in blocks <NUM>-<NUM>, which have been previously described. The paging message is configured to indicate to the UE <NUM> that the UE <NUM> should perform a process to select a cell for camping on for idle mode.

In block <NUM>, the UE <NUM> performs actions to select another cell to camp on, in accordance with received paging message. Examples of actions that could be performed are as follows.

In block <NUM>, the UE <NUM>, responsive to the trigger in the configured information, starts appropriate timer(s) and applies the previously acquired DPs. The UE <NUM> will select a carrier based on the timer(s) and DPs. Refer also to block <NUM> of <FIG>. As is known, in current implementation there is a timer (denoted as "T320") which controls the validity of DPs. The UE <NUM> will apply DPs as long as the timer is not expired (the timer is started immediately when UE receives RRC Connection Release with DPs). Once the timer expires, the UE discards the DPs and follows broadcasted APs. In examples in the instant disclosure, the timer is started, provided that a paging trigger is received (so prior to that event, UE/group of UEs follow APs).

In block <NUM>, UE <NUM>, responsive to the de-prioritization request, temporarily deprioritizes a currently utilized carrier and therefore may select higher-priority carrier. Refer also to block <NUM> of <FIG>.

In block <NUM>, the UE <NUM>, responsive to the prioritization request, prioritizes a carrier (e.g., indicated in an IE), and selects a carrier based on the current priority. It is noted that de-prioritization does not necessarily imply that a new reselection target carrier will be chosen in a random way. A legacy cell reselection process may be applied (e.g., a carrier with the highest priority is selected). For block <NUM>, refer also to block <NUM> of <FIG>.

In block <NUM>, the UE <NUM>, responsive to the probability in the configured information, generates a random number and compares the generated number against the received value for probability and selects a carrier based thereon. In an example, the reception of a paging message with a probability should trigger such random number generation by the UE side and a succeeding comparison process to take a certain action or do nothing (depending on whether the outcome of comparison was 'true' or 'false') should follow. Refer also to block <NUM> of <FIG>.

In block <NUM>, the UE <NUM> responsive to the indication to trigger a randomization process, performs the triggered randomization process based on one or more probabilities associated to one or more carriers that were previously acquired by the UE. This could cause the UE to select another carrier. Additionally, refer to <FIG>, block <NUM>.

Note also that the indication in RRC Connection Release for dedicated priorities or in SIB for absolute priorities that this corresponding set of priorities should remain inactive until the paging message is received may be used, e.g., in blocks <NUM> and <NUM>, which could entail activating and using the corresponding set of priorities to select one of multiple cells for camping on for idle mode.

There are several advantages to this enhanced method of load balancing via paging over existing RRC call release procedures. The following is a non-limiting list of potential advantages and their corresponding technical effects:.

Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, the software (e.g., application logic, an instruction set) is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in <FIG>. A computer-readable medium may comprise a computer-readable storage medium (e.g., memories <NUM>, <NUM>, <NUM> or other device) that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. A computer-readable storage medium does not comprise propagating signals.

Claim 1:
A method for idle mode load balancing for a cell (<NUM>), comprising:
determining (<NUM>), by a base station, whether the cell (<NUM>) is congested for user equipment (<NUM>) camping on the cell (<NUM>) while the user equipment is in idle mode; and
in response to a determination the cell (<NUM>) is congested, sending (<NUM>), by the base station, a paging message to one or more idle mode user equipment (<NUM>) camped on the cell (<NUM>), wherein the paging message indicates that the user equipment (<NUM>) should modify cell selection priorities or carrier selection priorities and is configured to cause the one or more idle mode user equipment (<NUM>) to modify at least one of the cell selection priorities or carrier selection priorities to produce modified cell selection priorities or carrier selection priorities, and camp on a cell (<NUM>) according to the modified cell selection priorities or carrier selection priorities.