CN105376802B - Inter-Frequency and Inter-Technical Neighbor Planning on Ad Hoc Networks - Google Patents

Abstract

The present disclosure relates to inter-frequency and inter-technology neighbor planning on ad hoc networks. In an example, a self-organizing network (SON) provides automated inter-frequency load balancing for base stations, such as node bs. The node B may provide multiple carriers (e.g., in multiple UARFCN frequencies), and the SON may provide configuration commands to improve efficiency. For example, when one carrier becomes overloaded, the SON may update neighbor associations to utilize a relatively empty frequency carrier. A plurality of scenarios S may be provided, and a policy P may be defined for each scenario. When the node B encounters scenario S, the SON may send a configuration command implementing policy P. Similar concepts and strategies may be applied in connection with inter-technology neighbor definitions between LTE and UMTS, and between UMTS and GSM. For example if GSM frequency neighbors need to be replaced by neighbors of a different frequency from UMTS depending on load or RF conditions.

Description

Inter-Frequency and Inter-Technical Neighbor Planning on Ad Hoc Networks

Related applications

This application is US Application Serial No. 14/333,261, filed July 16, 2014, entitled "Interfrequency and Inter-TechnologyNeighbor Planning on a Self-Organizing Network" (Inventor Ashish Bansal) and claiming priority to that application under 35 USC §120. The disclosure of the earlier application is considered to be part of the disclosure of the present application and is incorporated by reference into the disclosure of the present application.

technical field

The present application relates to the field of telecommunications, and more particularly to policy automation in telecommunications networks related to Neighbor Definitions.

Background technique

The 3rd Generation Partnership Project (3GPP) is an organization that disseminates wireless telecommunications standards and facilitates their adoption. 3GPP has provided useful standards such as Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), Code Division Multiple Access (CDMA), Universal Mobile Telecommunications System (UMTS), and Long Term Evolution (LTE).

Some of these standards provide base stations such as Node Bs, Evolved Node Bs (eNodeBs) that operate on one or more carriers on the UMTS Terrestrial Radio Access (UTRA) Absolute Radio Frequency Number (UARFCN) defined, Femtocell, Home eNodeB (HeNB), or similar device. In the 3GPP-based UMTS specification example, UARFCN frequency carriers can have up to two interfrequency "SIB11 neighbor relationships". These neighbor relationships can provide, for example, overflow of traffic on overloaded carriers to neighbors.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, there is provided a network device comprising: an interface for coupling with a telecommunications engine operable to provide wireless uplink and downlink communication services in a plurality of frequency carriers, the plurality of frequency carriers are configured in a baseline configuration P0 with baseline neighbor associations; an interface for coupling with an ad hoc network controller; and a policy engine operable to: identify a network conditional scenario S1; locate a policy P1 related to said scenario S1; and provide a configuration command to the telecommunications engine based on said policy P1, wherein the neighbor association between the first frequency carrier and the second frequency carrier is updated to the Neighbor association between a frequency carrier and a third frequency carrier.

According to another aspect of the present invention, there is provided one or more computer-readable media having executable instructions stored thereon, the executable instructions operable to instruct a processor to perform the following operations: identify a network condition scenario S1; Locate a policy P1 related to the scenario S1; provide a configuration command to the telecommunications engine based on the policy P1, wherein the neighbor association between the first frequency carrier and the second frequency carrier is updated to the first frequency carrier and the third frequency neighbor association between carriers; and provides operational support system services or radio access network management services.

According to yet another aspect of the present invention, there is provided a method comprising: coupling with a telecommunications engine operable to provide wireless uplink and downlink communication services in a plurality of frequency carriers, the plurality of frequency carriers are configured in a baseline configuration P0 with baseline neighbor associations; identify a network condition scenario S1; locate a policy P1 associated with the scenario S1; provide configuration commands to the telecommunications engine based on the policy P1, wherein the first frequency carrier The neighbor association with the second frequency carrier is updated to the neighbor association between the first frequency carrier and the third frequency carrier; and an operation support system service or a radio access network management service is provided.

Description of drawings

The present disclosure is best understood from the following detailed description when read in conjunction with the accompanying drawings. It is emphasized that, in accordance with standard practice in the industry, the various features are not drawn to scale and are for illustrative purposes only. In fact, the dimensions of the various features may be arbitrarily expanded or reduced for clarity of discussion.

1 is a network diagram of a telecommunications network in accordance with one or more examples of the present specification.

2 is a block diagram of a base station in accordance with one or more examples of the present specification.

3 is a block diagram of a base station in accordance with one or more examples of the present specification.

4 is a block diagram of a base station in accordance with one or more examples of the present specification.

5 is a block diagram of a base station in accordance with one or more examples of the present specification.

6 is a block diagram of a base station in accordance with one or more examples of the present specification.

7 is a block diagram of a base station in accordance with one or more examples of the present specification.

8 is a block diagram of a base station in accordance with one or more examples of the present specification.

9 is a block diagram of a base station in accordance with one or more examples of the present specification.

10 is a block diagram of a base station in accordance with one or more examples of the present specification.

11 is a block diagram of a base station in accordance with one or more examples of the present specification.

12 is a block diagram of a base station in accordance with one or more examples of the present specification.

13 is a block diagram of a base station in accordance with one or more examples of the present specification.

14 is a flowchart of a method according to one or more examples of the present specification.

15 is a block diagram of a base station in accordance with one or more examples of the present specification.

16 is a block diagram of a SON controller according to one or more examples of the present specification.

17 is a block diagram of a telecommunications network in accordance with one or more examples of the present specification.

18 is a block diagram of a base station in accordance with one or more examples of the present specification.

19 is a block diagram of a telecommunications network in accordance with one or more examples of the present specification.

Detailed ways

Overview

In one example, a self-organizing network (SON) provides automated inter-frequency load balancing for base stations such as Node Bs. The Node B may provide multiple carriers (eg, in multiple UARFCN frequencies), and the SON may provide configuration directives to improve efficiency. For example, when a carrier becomes loaded, the SON may update neighbor associations to utilize relatively unloaded frequency carriers. Multiple scenarios S can be provided, and a policy P can be defined for each scenario. When Node B encounters Scenario S, the SON can send a configuration command implementing Policy P. Similar concepts and strategies can be applied in conjunction with LTE and UMTS, and inter-technology neighbor definitions between UMTS and GSM. For example if a GSM frequency neighbor needs to be replaced by a different frequency neighbor from UMTS depending on load or RF conditions.

A network device is disclosed in a first example embodiment, the network device comprising: an interface for coupling with a telecommunications engine operable to provide wireless uplink and downlink communication services in a plurality of frequency carriers , the plurality of frequency carriers are configured with a baseline configuration P0 with baseline neighbor associations; and a policy engine operable to: identify a network condition scenario S1; locate a policy P1 associated with the scenario S1; The engine provides a configuration command in which the neighbor association between the first frequency carrier and the second frequency carrier is updated to the neighbor association between the first frequency carrier and the third frequency carrier.

A computer readable medium having stored thereon instructions operable to instruct a processor to couple with a telecommunications engine operable to provide a wireless uplink in a plurality of frequency carriers is disclosed in a second example embodiment and downlink communication services, the plurality of frequency carriers are configured in a baseline configuration P0 with baseline neighbor associations; and provide a policy engine operable to: identify network condition scenarios S1; locate scenarios associated with scenario S1 and provide a configuration command to the telecommunications engine based on P1, wherein the neighbor association between the first frequency carrier and the second frequency carrier is updated to the neighbor association between the first frequency carrier and the third frequency carrier.

A method is disclosed in a third example embodiment, the method comprising: coupling with a telecommunications engine operable to provide wireless uplink and downlink communication services in a plurality of frequency carriers, the plurality of frequencies The carriers are configured in a baseline configuration P0 with baseline neighbor associations; identify a network condition scenario S1; locate a policy P1 associated with the scenario S1; and provide configuration commands to the telecommunications engine based on The neighbor association of is updated to the neighbor association between the first frequency carrier and the third frequency carrier.

Specific Embodiments of the Disclosure

The following disclosure provides many different embodiments, or examples, for implementing different features of the present disclosure. Specific examples of components and arrangements are described below to simplify the present disclosure. These are of course only examples and are not intended to be limiting. Furthermore, the present disclosure may repeat reference numerals and/or letters in various instances. This repetition is for the purpose of simplicity and clarity, and does not in itself indicate a relationship between the various embodiments and/or configurations discussed.

Different embodiments may have different advantages, but no embodiment necessarily requires a specific advantage.

1 is a block diagram of a mobile network 100 in accordance with one or more examples of the present specification. The mobile network 100 includes user equipment 120 that is communicatively coupled to a radio access network (RAN) 110 , eg, via a wireless antenna 116 . RAN 110 is communicatively coupled to core network 130, eg, via Voice over Internet Protocol (VOIP). The core network 130 may in turn be connected to different networks, such as the Public Switched Telephone Network (PSTN) 172, or the Internet 170, which provides access to one or more services. In one example, the mobile network 100 provides voice call services over the PSTN 172 when the UE 120 is participating in a phone call. In another example, the UE 120 connects to the Internet 170 via the mobile network 100 when the UE 120 is performing a data operation (eg, web application, web surfing, email, or other network operation). It should be noted, however, that PSTN 172 and Internet 170 are provided only as examples of their respective classes of service, and other classes of services may also be provided. Accordingly, these examples are not intended to limit mobile network 100 to the specific examples disclosed in this application.

In this example, two classes of signals are communicated in the mobile network 100: voice, data, and call signals (referred to herein as "user plane" signals), and control signals (referred to herein as the "control plane" Signal).

In one example scenario, user plane signals originating from UE 120 are delivered to RAN 110 . In RAN 110, user plane signals are first received by Node B 112 (or other similar base station), which passes the "call" to Radio Network Controller (RNC) 114. The RNC 114 converts the call to a VOIP data stream and provides it to the core network 130 .

Core network 130 may be, for example, a General Packet Radio Service (GPRS) 2G, 3G, 3G+, or other network. In the specification, a Long Term Evolution (LTE) network (generally considered a 3G+ or 4th generation network) is used as an example. It should be noted, however, that this is not intended to be limiting and any suitable network may be substituted.

In this example, the core network 130 includes a Serving GPRS Support Node (SGSN) 140 and a Gateway GPRS Support Node (GGSN) 142 .

SGSN 140 may be configured to receive data packets from and deliver data packets to mobile base stations (eg, Node Bs 112) within a geographic service area. SGSN 140 may provide packet routing and delivery, mobility management (attach/detach and location management), logical link management, and authentication and charging functions. Common SGSN functions include, by way of non-limiting example, detunneling GTP packets from GGSN 142 (downlink) and tunneling IP packets towards GGSN 142 (uplink) for mobility Manage and bill for user data. In a GSM/EDGE configuration, the SGSN 140 may provide additional functionality including, by way of non-limiting example: providing a maximum data rate between 60kBd and 150kBd per subscriber; connecting to a packet control unit; accepting uplink data to form IP packets; encrypt downlink data; decrypt uplink data; and perform mobility management.

The GGSN 142 is responsible for networking between the GPRS network and external networks (eg, the Internet 170). The GGSN 142 is thus an outward-facing node from all perspectives of the Internet 170, and the subnet behind the GGSN 142. Thus, the GGSN 142 hides from the Internet 170 any GPRS infrastructure found within the mobile network 100. In an example method, the GGSN 142 receives data addressed to a particular UE 120 and then verifies that the requested UE 120 is active on the mobile network 100 . If the UE 120 is active, the GGSN 142 forwards the data to the SGSN 140, which provides the data to the UE 120. On the other hand, if the UE 120 is inactive, the data is discarded.

Instead, packets originating from UE 120 arrive at GGSN 142, and GGSN 142 directs the traffic to the correct node on Internet 170 (eg, the correct IP address). GGSN 142 may also be operable to convert incoming GPRS packets from SGSN 140 to Packet Data Protocol (PDP) format and send them out to Internet 170 . In the reverse direction, the PDP address of the incoming data packet is translated to the GSM address of the UE 120 .

While GGSN 142 provides data traffic directly to Internet 170, voice traffic first passes through media gateway (MGW) 138 before proceeding to PSTN 172. In an example, the MGW 138 translates digital media streams between different telecommunications networks (eg, PSTN, and next-generation networks such as 2G, 2.5G, 3G, 3G+, LTE, etc.). This enables multimedia communication across next-generation networks via multiple transport protocols such as Asynchronous Transfer Mode (ATM) and IP.

MGW 138 may be controlled by a separate Media Gateway Controller Function (MGCF) 136, which provides call control and signaling functions.

On the control plane, Node B 112 and RNC 114 may be served by a centralized ad hoc network device (C-SON) 180 and an operations support system (OSS) 160 . One or more distributed SON (dSON) devices may also be provided, eg, attached to one or more Node Bs 112 .

A Media Gateway Controller Function (MGCF) 136 is an endpoint device for converting call protocols (eg, between Session Initiation Protocol (SIP) and ISDN User Part (ISUP) protocols). MGCF 136 may control MGW 138 resources.

A Call Session Control Function (CSCF) 134 performs some of the roles of a SIP server or proxy, which is a CSCF service and can be used in SIP signaling.

Home Subscriber Server (HSS) 132 provides both Home Location Register (HLR) and Authentication Center (AuC) functions.

SON provides automated techniques designed to make the planning, configuration, management, optimization and recovery of mobile radio access networks simpler and faster than manual configuration schemes. SON functions and behaviors have been defined and specified in recommendations produced by organizations such as 3GPP and others.

SON may be provided in a number of different ways, including centralized SON (C-SON), distributed SON (dSON), and hybrid SON (hSON).

The dSON functionality is distributed among multiple network elements (including one or more Node Bs 112) at the edge of the network. This provides localized functionality.

C-SON functions are typically concentrated closer to higher order network nodes (eg, OSS 160) to allow a broader overview of more edge elements, and coordination of functions such as load across large geographic areas.

H-SON is a hybrid of centralized and distributed SON, combining elements of each in a hybrid scheme.

Advantageously, SON provides useful functions such as:

a. Self-configuration. Self-configuration strives to achieve a "plug-and-play" model whereby new base stations are automatically configured and integrated into the network, and new functions on the base station (including bringing new carrier frequencies on-line) are seamlessly integrated. Self-configuration may be provided to each radio cell by the equipment vendor as part of the software delivery. When a new base station is introduced into the network and turned on, it is immediately recognized and registered by the network. Neighbor base stations then automatically adjust to provide the desired coverage and capacity, as well as to provide interference avoidance.

b. Self-optimization. A base station may contain a number of configuration parameters that control its operation. Each of these parameters can be adjusted to change network behavior based on both observations of the base station itself, as well as measurements at the mobile station or handheld device. One of the first SON features establishes Automatic Neighbor Relations (ANR), while the other features optimize random access parameters, or flow robustness, in a way of switching oscillations. A very illustrative use case is automatically shutting down a certain percentage of base stations during the night. Neighboring base stations will then reconfigure their parameters to keep the entire area covered by the signal. In case of a sudden increase in connection demand for any reason, the "sleeping" base station is "awakened" almost instantaneously. This mechanism provides significant energy savings for the operator.

c. Self-healing. When certain nodes in the network become inoperable, the self-healing mechanism is intended to reduce the effects of failure, eg by adjusting cell parameters and algorithms in neighbors (so that other nodes can support users that were once supported by the failed node). Impact. In traditional networks, a failed base station is sometimes difficult to identify and requires a very large amount of time and resources to repair it. This functionality of the SON allows such a faulty base station to be detected immediately, so that further measures can be taken and the user is assured that there is no significant degradation of service.

2 is a block diagram of a frequency carrier 230 in Node B 112 in accordance with one or more examples of the present specification. In this example, Node B 112 is communicatively coupled to femtocell 210, which may be any suitable small base station, such as an LTE Home eNodeB (HeNB) or similar base station. It should also be noted that certain elements and network equipment such as gateways, mobility management entities (MMEs) and other network equipment that may also be present have been omitted from FIG. 2 and other figures for the sake of brevity of discussion.

In the example of FIG. 2, carrier F1 230-1 is assigned to the frequency carrier denoted by 1087. Carrier F2 230-2 is assigned 412 frequency carriers. Carrier F3 230-3 is assigned 437 frequency carrier. Carrier F4 230-4 is assigned to 1062 frequency carriers. Carrier F5 230-5 is assigned 612 frequency carriers.

These frequency carrier designations are provided by way of example only, and it should be noted that any suitable combination of carriers may be used. In this example, the frequency carrier designation is the UMTS Terrestrial Radio Access (UTRA) Absolute Radio Frequency Number (UARFCN) designation.

UMTS frequency carrier The radio frequencies used by the Universal Mobile Telecommunications System (UMTS) network. The frequency carriers are assigned by the governing body, each marked with a nominal frequency for the uplink and downlink, and may include designated uses.

At the date of writing this specification, UARFCN is available on the Internet, for example at http://niviuk.free.fr/umts_band.php . Exemplary frequency carriers are as follows:

Table 1 - Carrier Frequency

These exemplary carriers are used throughout this specification by way of example only to illustrate an example of intra-carrier load balancing. It should be appreciated, however, that the choice of these carriers is not limited and any suitable carrier arrangement may be used.

In some embodiments (eg, according to the UMTS 3rd Generation Partnership Project (3GPP) specification), each carrier 230 may have no more than two inter-frequency "neighbor" relationships, in this example, femto Cell 210 and the next deployed UMTS carrier. In some known embodiments, these neighbor relationships may be statically defined through an engineering process. Among other functions, neighbor relationships allow traffic to be "overflowed" to neighbor carriers when the carrier to which the traffic is directed cannot handle the traffic. Furthermore, in some embodiments of LTE, each carrier 230 must have a unique UARFCN in communication with the femtocell 210 .

Thus in the example of Figure 2, carrier F1 230-1 has an inter-frequency neighbor relationship with femtocell 210, and with carrier F2 230-2. Carrier F2 230-2 has a neighbor relationship with femtocell 210, and with carrier F3 230-3. Carrier F3 230-3 has neighbor relationships with femtocell 210 and with carrier F4 230-4. Carrier F4 230-4 has neighbor relationships with femtocell 210, and with carrier F5 230-5. Carrier F5 230-5 has a neighbor relationship with femtocell 210, and loops back to carrier F1 230-1, forming a closed loop neighbor relationship system. Femtocell 210 operates on the 9938 carrier.

As can be seen in FIG. 2, this static arrangement can lead to a situation where the carrier 230 is not optimally organized. For example, carriers F1 230-1 and F5 230-5 may be designated as "loaded carriers" in this example. This means that the two carriers are overloaded. Carrier F2 230-2 may be designated in this example as a "relatively less-loaded carrier." This means that carrier F2 230-2 is handling some traffic, but it is not handling traffic that carrier F1 230- 1 and F5 230-5 so much. So while carrier F2 230-2 is loaded, it may have substantially more bandwidth available than carriers F1 230-1 and F5 230-5. Finally, carriers F3 230-3 and F4 230-4 may be designated as "free carriers". This means that there is basically no traffic on the two carriers.

Obviously, this arrangement may lead to certain difficulties. For example, the neighbor relationship between carrier F5 230-5 and carrier F1 230-1 may present difficulties. Because carrier F1 230-1 is overloaded, carrier F1 230-1 may not have available bandwidth to handle traffic when carrier F5 230-5 attempts to provide traffic switching. This can lead to dropped calls or dropped packets. At the same time, carriers F3 230-3 and F4 230-4 remain completely unloaded, while carrier F2 230-2 remains partially unloaded. This may result in sub-optimal operating conditions for Node B 112, which may result in unacceptable network performance.

Dropped calls, packet loss, or other sub-optimal network operations (eg, UE 120 being unable to connect to the network) may adversely affect the network's key performance indicators (KPIs), which can affect the network's effectiveness and its commercial viability. Thus in some embodiments it is beneficial to improve KPIs by increasing network efficiency.

In some embodiments, C-SON 180 (used alone, or in combination with dSON 182 and OSS 160) may be provided with a policy engine 1624 (FIG. 16) that is provided with multiple rules. In one example, multiple scenarios S0...Sn are provided, each scenario S may be defined by some cross-section of network conditions. Some policies are also defined by P0...PK. Policies can be defined to respond to network condition scenarios.

The C-SON 180 or similar network device may include a communication interface for coupling with the Node B 112, which itself includes a telecommunications engine 1526 (FIG. 15). Telecommunications engine 1526 is operable to provide wireless uplink and downlink communication services on multiple frequency carriers configured in a baseline configuration P0 with baseline neighbor associations.

Policy engine 1624 of C-SON 180 is operable to identify network condition scenario S1; locate policy P1 associated with scenario S1; and provide configuration commands to telecom engine 1526 based on P1, wherein the first frequency carrier and the second frequency carrier are The inter-neighbor association may be updated to a neighbor association between the first frequency carrier and the third frequency carrier. Such a configuration is provided by way of example to illustrate an embodiment in which the SON function resides external to the Node B 112 . However, it is also possible to provide embodiments where the SON functionality is internal to the Node B 112. In this case, the procedure described above may be the same, except that the communication interface may be internal to Node B 112, rather than an interface to an external network.

3 is a block diagram of a modified Node B 112 in accordance with one or more examples of this specification. In this example, Node B 112 is communicatively coupled to femtocell 210 as in the example of FIG. 2 . In the example of FIG. 3 , the carriers 230 each have, by way of example, the same loads as those disclosed in connection with FIG. 2 . Specifically, carriers F1 230-1 and F5 230-5 are overloaded. The carrier F2 230-2 is relatively lightly loaded. Carriers F3 203-3 and 203-4 F4 are empty. In this example, however, C-SON 180 has provided Node B 112 with a configuration command for reassigning the neighbor relationship of carrier 230.

Specifically, carrier F1 230-1 now has a relationship with carrier F3 230-3 instead of a neighbor relationship with carrier F2 230-2. This allows overflow traffic from the heavy carrier F1 230-1 to flow to the empty carrier F3 203-3. Similarly, carrier F5 230-5 loops back to carrier F4 230-4 instead of back to carrier F1 230-1. Again, this allows traffic to flow to relatively lightly loaded carriers.

In some embodiments, a scenario that requires reconfiguration to optimally allocate multiple carriers of neighbor relations may be designated as S, with a scenario designation such as S1. There may be a policy associated with scenario S1, such as policy P1. In some embodiments, C-SON 180 may identify scenario S1 in advance. Therefore, when the C-SON 180 determines that the scenario S1 has been encountered, the C-SON 180 already has a clear strategy P1 for handling the scenario S1. Specifically, policy P1 requires neighbor relations to be updated so that a heavily loaded carrier is associated with a relatively lightly loaded carrier. Ideally, a heavily loaded carrier is associated with an empty carrier, and a relatively lightly loaded carrier is also associated with an empty carrier.

It will be appreciated, however, that this may direct a significant amount of traffic to an idle carrier (eg, idle carrier F3 230-3). So over time, it may be necessary to evaluate the effectiveness of the strategy in this particular instance. If it is found that carrier F3230-3 has become an overloaded carrier, then the neighbor relationship may need to be reconfigured to better utilize the available carriers. Also in some embodiments, C-SON 180 may be configured to instruct Node B 112 to return its baseline configuration policy PO associated with context SO. This ensures that Node B 112 does not stay in an abnormal configuration for an extended period of time. If any changes are found to degrade network conditions, the changes can be reverted.

4 is a block diagram of Node B 112 in accordance with one or more examples of this specification. In this example, a scenario S is presented where significant inter-frequency interference may occur, where the two frequency carriers have significantly separated values. For example, carriers F1 230-1 and F5 230-5 have strong received signal strength indicators (RSSIs) and are significantly separated on their frequency carriers. They are therefore designated as "high interference" carriers. However carriers F2 230-2, F3 230-3 and F4 230-4 have very close frequency carriers and are therefore more likely to have clean inner carrier lines. These carriers are designated as relatively "clean" carriers. A strategy P is therefore defined to group clean carriers together and to avoid high interfering carriers.

In this example, carriers F1 230-1, F2 230-2, F3 230-3, and F4 230-4 are linearly arranged in the policy P0 of FIG. 1 . In Figure 3, however, carrier F4 is not linked down to carrier F5 230-5, and carrier F5 230-5 does not feed loopback to carrier F1 230-1, which may be candidates for interference. And F5 230-5 has a neighbor relationship with carrier F4 230-4. Carrier F4 230-4 feeds the loop back to carrier F2 230-2, creating a closed loop arrangement of clean carriers. This arrangement helps eliminate interference as traffic will be allowed to flow into a clean block of carriers and will not cascade out.

5 is a block diagram of Node B 112 in accordance with one or more examples of this specification. The example of FIG. 5 provides a strategy P and a scenario S in which power saving is considered. For example, it may not be necessary to provide five carriers 230 during certain times of the day (eg, between midnight and 6 am). Therefore, it may be beneficial to turn off one or more carriers. In this case, policy P calls for shutting down carriers F4 230-4 and F5 230-5 to save power. This makes three carriers F1 230-1, F2 230-2 and F3 230-3 available to serve the femtocell 210. In this case, carriers F1 230-1, F2 230-2, and F3 230-3 are arranged in a linear closed-loop fashion, thereby providing closed-loop functionality. This will ensure that traffic flows neither to carrier F4 230-4 nor carrier F5 230-5.

6 and 7 provide block diagrams of Node B 112, where microcells 610-1 and 610-2 are also communicatively coupled to Node B 112 and femtocell 210. Microcell 610 may be an intermediate level base station, larger than femtocell 210 and smaller than Node B 112 . Micro cells can be provided, for example, to cover limited areas such as shopping malls, office buildings, hotels, or high-density commercial areas. In this case, microcell 610-1 operates on the 1087 frequency carrier, just like carrier F1 230-1. Microcell 610-2 operates on 412 frequency carrier, just like carrier F2 230-2. Therefore, the connection between microcell 610-1 and carrier 230-1 is considered an intrafrequency connection, while any connection between microcell 610-1 and any carrier other than carrier F1 230-1 is considered an intrafrequency connection considered as an inter-frequency connection. Similarly, a connection between microcell 610-2 and carrier F2 230-2 is considered an intra-frequency connection, while a connection between microcell 610-2 and any carrier other than carrier F2 230-2 is considered an intra-frequency connection inter-frequency connection.

This scenario S introduces additional complexity. It can be seen in Figure 6 that the intra-frequency connections 620 and 624 are bidirectional connections. This is because the carrier's F1 230-1 does not need to "use up" a complete one of the two inter-frequency neighbor associations to which it is allocated to associate with the microcell 610-1. Accordingly, carrier F1 230-1 may form neighbor associations with microcell 610-1, microcell 610-2, femtocell 210, and carrier F2 230-2. This causes a large amount of load to be applied to the carrier F1230-1. In contrast, inter-frequency connections 622 and 626 are unidirectional connections.

To alleviate this overload, the feedback loop from the overloaded carrier F5 230-5 to 230-1F1 has been removed in FIG. 7 . This may prevent overloaded carrier F5 230-5 from continuing to direct additional traffic to overloaded carrier F1 230-1.

8 and 9 are block diagrams of Node B 112 in accordance with one or more examples of this specification. In the example of Figure 8, a single microcell 810 is provided. In this case, microcell 810 operates on the same frequency carrier (ie, 9938) as femtocell 210. Therefore, all connections to carrier 230 are intra-frequency connections.

10 and 11 are block diagrams of Node Bs 112 in accordance with one or more examples of this specification. In this example, carriers F1 230-1, F2 230-2, and F5 230-5 provide respective carrier frequencies in frequency band 1900. Carriers F3 230-3 and F4 230-4 provide respective frequencies in frequency band 850. These frequency bands are managed and specified due to their respective UARFCNs.

In this example, carriers F1 230-1 and F5 230-5 are heavy duty carriers. Carrier F2 230-2 is a relatively lightly loaded carrier. Carriers F3 230-3 and 230-4 F4 are empty carriers. In this case, all carrier loading occurs in band 1900 and no carrier loading occurs in band 850. Therefore, it may not be useful to allow traffic to cascade from carrier F5 230-5 to carrier F1 230-1. Since this still keeps frequency band 1900 too crowded, the neighbor relationship between carriers F1 230-1 and F2 230-2 is also less useful. This loading of frequency bands can result in a loss of KPIs.

In Figure 11, the load on frequency band 1900 is lightened. In this case, a strategy P is provided to feed carrier F5 230-5 back to carrier F3 230-3. This allows network traffic to more efficiently "break out" of the band 1900 and cascade into the available bandwidth on the 850 band.

12 and 13 are block diagrams of Node Bs 112 disclosing dynamic integration of new frequency carriers, according to one or more examples of the present specification. In this example, carriers F1 230-1, F2 230-2, F3 230-3, and F4 230-4 have been integrated into Node B 112 and arranged according to a linear feedback configuration policy P0. Carrier F5 230-5 is added to Node B 112. Once the Node B 112 reports the existence of the new carrier F5 230-5 to the C-SON 180, the C-SON 180 provides configuration instructions to integrate the carrier F5 230-5 into the Node B 112. In this case, C-SON 180 may define a new baseline policy P0 that includes carrier F5 230-5 in its linear feedback configuration.

14 is a flowchart of a method 1400 for providing automatic inter-frequency load balancing in accordance with one or more examples of the present specification.

At block 1410, the C-SON 180 predefines certain scenarios and builds a policy P associated with each scenario. These can be designated as scenarios S0...Sn, and policies P0...Pk. Each context S may have rules for identifying that context, and each policy P may have additional rules for implementing the policy P. In one example, the following policies are defined:

At block 1420, C-SON 180 sends a configuration command to Node B 112 for policy P0. The configuration commands are adapted to provide Node B 112 with the necessary information and instructions to implement policy P0 on Node B 112 . It should be noted that in this context, implementing policy P0 does not necessarily imply a direct literal translation of policy P0 to Node B 112 . While literal translation of policy P0 may occur in some cases, in other cases Node B 112 receives configuration commands and translates the configuration commands into Node B 112 within a configuration engine such as configuration engine 1524 (FIG. 15). The native executable instructions or available instructions are also possible.

At block 1430, the C-SON 180 determines whether a new context Sn has been detected. If no new context Sn is detected, then at block 1420, the C-SON 180 instructs the Node B 112 to continue maintaining the baseline policy P0. At block 1440, if the context has changed, the C-SON 180 identifies the context Sn and applies the associated policy Pk. It should be noted that the mapping between scenarios Sn and policies Pk need not be a one-to-one mapping. For example, multiple scenarios can all map to the same policy. In other examples, multiple policies may map to the same context, and additional logic may be provided to select among policies. Therefore, the specification of scenarios Sn and policies Pk is expressly intended to include cases where there is an indirect and literal one-to-one mapping between policies and scenarios.

At block 1450, SON 180 may measure one or more KPIs to determine whether network conditions have improved after implementing policy Pk. This may include, for example, measuring the signal strength of connections, checking load balancing among carriers 230, checking for dropped calls and packet loss, and checking for users unable to connect to the network. It should be noted, however, that many other feedback mechanisms are possible and are intended to be included within this specification. Thus, block 1450 represents a feedback operation in which SON 180 determines whether the change in policy has produced a positive effect, a negative effect, or a neutral effect.

If the situation does not improve, control may return to block 1420, where the baseline policy P0 may be restored. In other cases, control may return to block 1440 so that SON 180 may determine whether there is another scenario S that is more consistent with the current network conditions. In this case, the identification of the correct scenarios and strategies can be an iterative process. One or more strategies can be applied one or more times, and the effect of each application can be measured to determine whether it has actually had a positive effect.

At block 1460, timeout measures are provided. If a timeout occurs, control returns to block 1420, and policy P0 may resume. This prevents Node B 112 from getting stuck in a suboptimal policy, with no way out. The use of this timeout also prevents the C-SON 180 from becoming more and more "lazy". In other words, the C-SON 180 must constantly re-evaluate the current strategy to determine if there is a strategy that is more suitable for the current situation under operating conditions.

At block 1490, the method is complete.

15 is a block diagram of a base station 112 in accordance with one or more examples of the present specification.

Base station 112 includes a processor 1510 coupled to memory 1520 on which executable instructions for providing an operating system 1522 are stored, a configuration engine 1524, and a telecommunications engine 1526. Other components of base station 112 include storage device 1550 , wireless network interface 1562 , and auxiliary interface 1540 .

In one example, the processor 1510 may be communicatively coupled to the memory 1520 via a memory bus 1570-3, which may be, for example, a direct memory access (DMA) bus. Processor 1510 may be communicatively coupled to other devices via system bus 1570-1. As used throughout this specification, a "bus" includes any wired or wireless interconnection, network, connection, bundle operable to carry data, signals, or energy between components of a computing device, or between computing devices , single bus, multi-bus, crossbar network, single-level network, multi-level network or other conductive medium. It should be noted that these use cases are disclosed by way of non-limiting example only, and that some embodiments may omit one or more of the aforementioned buses, while other embodiments may use additional or different buses.

In various embodiments, a "processor" may include any combination of hardware, software, or firmware that provides programmable logic, including, by way of non-limiting example, microprocessors, digital signal processors, field programmable gate arrays, Programmable logic array, application specific integrated circuit, or virtual machine processor.

Processor 1510 may be connected to DMA-configured memory 1520 through DMA bus 1570-3. To simplify the present disclosure, memory 1520 is disclosed as a single logical block, but in a physical embodiment may comprise one or more blocks of any one or more suitable volatile or non-volatile memory technologies, including, for example, DDR RAM, SRAM, DRAM, buffer memory, L1 or L2 memory, on-chip memory, registers, flash memory, ROM, optical media, virtual memory areas, magnetic or tape memory, or similar storage devices. In some embodiments, memory 1520 may include relatively low-latency volatile main memory, while storage device 1550 may include relatively high-latency non-volatile memory. However, memory 1520 and storage 1550 need not be physically separate devices, and in some examples may merely represent a logical separation of functions. It should also be noted that although DMA is disclosed by way of non-limiting example, DMA is not the only protocol consistent with this specification, and other memory architectures may be used.

Storage device 1550 may be any kind of storage 1520, or may be a separate device such as a hard drive, solid state drive, external storage, redundant array of independent disks (RAID), network attached storage, optical storage, tape drives, backup systems , cloud storage, or any combination of the foregoing. Storage 1550 may be (or may include therein) data or one or more databases stored in other configurations, and may include stored operating software (eg, operating system and copy of operating system 1522, and configuration engine 1524 and telecommunications a copy of the software portion of the engine 1526). Many other configurations are possible and are intended to be covered by the broad scope of this specification.

Backhaul interface 1560 may be provided as a network interface for communicatively coupling base station 112 to a wired or wireless backhaul network (eg, an X2 network). As used throughout this specification, a "network" may include any communication platform operable to exchange data or information between or within computing devices, including, by way of non-limiting example, ad-hoc local networks, Internet infrastructure where computing devices provide electronic interaction capabilities, Plain Old Telephone System (POTS) (where computing devices may be used to perform transactions in which they may be assisted by human operation, or where they may manually enter data into a telephone or other suitable electronic equipment), any Packet Data Network (PDN), or any Local Area Network (LAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), Wireless Local Area Network ( WLAN), virtual private network (VPN), intranet, or any other suitable structure or system that facilitates communication in a network or telephony environment.

A wireless network interface 1562 is also provided that communicatively couples the base station 112 to the wireless network, including interfaces to connect with the UE 120 and other wireless devices.

In one example, the configuration engine 1524 is a model or program that performs a method that includes receiving configuration commands from the SON, and translating the configuration commands into locally executable configuration instructions. In various embodiments, the configuration engine 1524 may be embodied in hardware, software, firmware, or some combination thereof. For example, in some cases, configuration engine 1524 may include an application specific integrated circuit designed to perform the method, and may also include software instructions operable to instruct a processor to perform the method. It should also be noted that the configuration engine 1524 is provided by way of non-limiting example only, and that other hardware and software (including interactive or user-mode software) may also be provided in conjunction with the configuration engine 1524, provided as the configuration engine 1524 In addition, or provided as an alternative to the configuration engine 1524, methods in accordance with the present specification are performed.

In one example, the configuration engine 1524 includes executable instructions stored on a non-transitory medium operable to perform all or part of one or more of the methods disclosed herein, or similar methods in accordance with this specification . At an appropriate moment (eg, upon starting the base station 112, or upon receiving a command from the operating system or the user), the processor 1510 may retrieve a copy of the configuration engine 1524 (or software portion thereof) from the storage device 1550 and copy the It is loaded into memory 1520. The processor 1510 may then iteratively execute the instructions of the configuration engine 1524.

An adjunct interface 1540 is provided to interface with adjuncts and peripherals, including any adjunct connected to the base station 112 but not necessarily part of the base station's 112 core architecture. Peripherals may be operable to provide extended functionality to base station 112 and may or may not be entirely dependent on base station 112 . In some cases, the peripheral device may be a stand-alone computing device. Peripherals may include input and output devices such as, by way of non-limiting example, test systems, display screens, terminals, printers, keyboards, mice, modems, network controllers, sensors, transducers, actuators, controllers, data acquisition bus, camera, microphone, speaker, or external storage device.

16 is a block diagram of a C-SON 180 in accordance with one or more examples of the present specification. It should be noted that the definitions and examples of FIG. 15 are equally applicable to reasonably corresponding devices and structures in FIG. 16 .

C-SON 180 includes processor 1610, policy engine 1624 coupled to memory 1620 on which executable instructions for providing operating system 1622 are stored. Other components of C-SON 180 include storage device 1650 , network interface 1660 , and auxiliary interface 1640 .

In an example, processor 1610 may be communicatively coupled to memory 1620 via memory bus 1670-3, which may be, for example, a direct memory access (DMA) bus. Processor 1610 may be communicatively coupled to other devices via system bus 1670-1.

Processor 1610 may be connected to DMA-configured memory 1620 through DMA bus 1670-3. To simplify the present disclosure, memory 1620 is disclosed as a single logical block, but in a physical embodiment may comprise one or more blocks of any one or more suitable volatile or non-volatile memory technologies. In some embodiments, memory 1620 may include relatively low-latency volatile main memory, while storage device 1650 may include relatively high-latency non-volatile memory. However, memory 1620 and storage 1650 need not be physically separate devices, and in some examples may merely represent a logical separation of functions. It should also be noted that although DMA is disclosed by way of non-limiting example, DMA is not the only protocol consistent with this specification, and other memory architectures may be used.

Storage device 1650 may be any kind of memory 1620, or may be a separate device. Storage device 1650 may be (or may include therein) data stored in other configurations or one or more databases, and may include stored operating software (eg, operating system and copy of operating system 1622, and policy engine 1624 software) part) copy. Many other configurations are possible and are intended to be covered by the broad scope of this specification.

Network interface 1660 may be provided as a network interface for communicatively coupling C-SON 180 to a wired or wireless network (eg, an X2 network).

In one example, the policy engine 1624 is a model or program that performs a method that includes receiving configuration commands from the SON, and translating the configuration commands into locally executable configuration instructions. In various embodiments, policy engine 1624 may be embodied in hardware, software, firmware, or some combination thereof. For example, in some cases, policy engine 1624 may include an application specific integrated circuit designed to perform the method, and may also include software instructions operable to instruct a processor to perform the method. It should also be noted that the policy engine 1624 is provided by way of non-limiting example only, and that other hardware and software (including interactive or user-mode software) may also be provided to integrate with the policy engine 1624 as a In addition, or provided as an alternative to the policy engine 1624, methods according to the present specification are performed.

In one example, the policy engine 1624 includes executable instructions stored on a non-transitory medium operable to perform all or part of one or more of the methods disclosed herein, or similar methods in accordance with this specification . At an appropriate moment (eg, upon startup of C-SON 180, or upon receipt of a command from the operating system or user), processor 1610 may retrieve a copy of policy engine 1624 (or a software portion thereof) from storage device 1650, and loaded into memory 1620. The processor 1610 may then iteratively execute the instructions of the policy engine 1624.

Auxiliary interface 1640 is provided to interface with auxiliary devices and peripheral devices, including any auxiliary device connected to C-SON 180 but not necessarily part of the core architecture of C-SON 180 . Peripherals may be operable to provide extended functionality to C-SON 180, and may or may not be fully dependent on C-SON 180.

17 is a block diagram of a telecommunications architecture in accordance with one or more examples of the present specification. In the example of Figure 17 it is a Heterogeneous Telecommunications Network (HETNET). In particular, C-SON 180 is communicatively coupled to a plurality of OSS systems 160, or other devices 1710 such as one or more RAN Management Systems (RMS). LTE OSS 160-1 provides LTE OSS services to one or more LTE eNodeBs 1722 (eg, eNodeB 1722-1 and eNodeB 1722-2). One or more LTE mobility management entities (MMEs) 1720 may also be provided for control plane management (eg, radio resource management, mobility management, encryption and decryption) functions.

The UMTS OSS 160-2 is communicatively coupled to one or more UMTS Node Bs 1732 (eg, Node B 1732-1 and Node B 1732-2). One or more Radio Network Controllers (RNCs) 1730 for control plane management (eg radio resource management, mobility management, encryption and decryption) functions may also be provided.

GSM OSS 160-3 is communicatively coupled to one or more base stations 1742 (eg, base station 1742-1 and base station 1742-2). One or more base station controllers (BSCs) 1740 may also be provided for control plane management (eg, radio resource management, mobility management, encryption and decryption) functions.

Finally, the RMS 1710 is communicatively coupled to one or more small cell base stations 1712 . Small cell base station 1712 may operate in any suitable technology, including any disclosed herein. Small cells 1712 may be configured to provide wireless network coverage to small areas such as hotels, office buildings, parks, or the like. In some embodiments, small cell 1710 is communicatively coupled to one or more base stations 1742 , Node Bs 1732 , or eNodeBs 1722 .

18 is a block diagram of an inter-technology neighbor relationship in accordance with one or more examples of this specification. In the example of Figure 18, three carrier devices, eg eNodeB 1722, Node B 1732, and Base Transceiver Station (BTS) 1742, are provided. In this example, eNodeB 1722 provides LTE network service, Node B 1732 provides UMTS network service, and BTS 1742 provides GSM network service.

As in the previous example, each carrier of Figure 18 is provided with multiple carrier frequencies. For example, eNodeB 1722 is provided with carriers Fl 1812, F2 1814, and F3 1816. The frequency bands of these carriers can be any suitable frequency band, as described above.

Similarly, Node B 1732 is provided with carriers F4 1822, F5 1824, F6 1826, and F7 1828.

Finally, the BTS 1742 is available with the F8 1832 and F9 1834.

In this example, each LTE carrier of eNodeB 1722 maintains an inter-technology neighbor relationship with each UMTS carrier of Node B 1732. Similarly, each UMTS carrier of Node B 1732 maintains an inter-technology neighbor relationship with each GSM carrier of BTS 1742.

In some embodiments, such a configuration (and the management functions provided by C-SON 180) may enable inter-technology load balancing (similar to intra-technology load balancing described in some of the preceding figures). In particular, C-SON 180 may perform methods such as method 1400 of FIG. 14 to provide inter-technology load balancing.

19 is a signal flow diagram of certain aspects of inter-technology load balancing in accordance with one or more examples of the present specification. For example only, an LTE eNodeB 1722 communicatively coupled to two UMTS Node Bs (ie, Node B 1732-1 and Node B 1732-2) is shown in this figure.

As can be seen from this example, some inter-technology load balancing operations may require additional signaling. For example, a handover from eNodeB 1722 to Node B 1732 may require a signal such as "IDLE RESELECTION" 1930, which is a System Information Block (SiB) Type 3 (SiB3) message. SiB3 includes, for example, parameters for cell site configuration and reselection. It may also be necessary to connect the circuit switched fallback (CSFB) signal 1932 (which is the SiB6 signal). The SiB6 includes, for example, parameters configured for normal and shared physical channels to be used in the connection mode between cell sites.

Signaling may also occur between intra-technology peers, eg, between UMTS Node B 1732-1 and UMT S Node B 1732-2. Specifically, it may be necessary to provide the "IFHO NEIGHBOR" signal (which is the SiB11 signal). The SiB 11 includes, for example, measurement control information to be used in the cell.

The UMTS Node B 1732 may also provide the GSM BTS 1742 with Inter-Radio Access Technology 1940 (IRAT) Neighbor ("IRAT Neighbor") signals (which are SiB11 signals).

Finally, the UMTS NodeB 1732 may "LTE RESELECTION" signal 1910 (which is a SiB19 signal) to the LTE eNodeB 1722. The SiB 19 signal includes, for example, the IRAT frequency and priority information to be used for the absolute RAT's priority cell reselection algorithm.

The foregoing has outlined features of some embodiments so that those skilled in the art may better understand various aspects of the present disclosure. Those skilled in the art should appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the embodiments described herein. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that they can make various changes, substitutions and alterations without departing from the spirit and scope of the present disclosure.

Certain embodiments of the present disclosure may readily include a system-on-chip (SOC) central processing unit (CPU) package. SOC stands for an integrated circuit (IC) that integrates components of a computer or other electronic system into a single chip. It can contain digital, analog, mixed-signal and RF functions: all these functions can be provided on a single chip substrate. Other embodiments may include a multi-chip module (MCM) having multiple chips within a single electronic package and configured to closely interact with each other through the electronic package. In various other embodiments, digital signal processing functions may be implemented in one or more silicon cores in Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and other semiconductor chips. Furthermore, in various embodiments, processors, memories, network cards, buses, storage devices, related peripherals, and other hardware elements described herein may be configured by software or firmware to emulate or virtualize the functionality of these hardware elements. processor, memory, and other related devices.

In example implementations, at least some portions of the processing activities outlined herein may also be implemented in software. In some embodiments, one or more of these features may be implemented in hardware provided external to the elements of the disclosed figures, or incorporated in any suitable manner to implement the intended functionality. The various components may include software (or reciprocating software) that can be coordinated to achieve operations as outlined herein. In further embodiments, these elements may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that aid in their operation.

Additionally, some components associated with the microprocessor may be removed, or otherwise incorporated. In general, the arrangements depicted in the figures may be more logical in their presentation, while the physical framework may include various permutations, combinations, and/or mixtures of these elements. It must be noted that countless possible design configurations can be used to achieve the operational goals outlined in this article. Thus, the associated infrastructure has countless alternative arrangements, design choices, equipment possibilities, hardware configurations, software implementations, equipment choices, and the like.

Any suitably configured processor component may execute any type of instructions associated with data that implement the operations detailed herein. Any of the processors disclosed herein can transform an element or item (eg, data) from one state or thing to another state or thing. In another example, some of the activities outlined herein may be implemented using fixed logic or programmable logic (eg, software/computer instructions executed by a processor), and the elements identified herein may be some type of programmable processor , programmable digital logic (eg, Field Programmable Gate Array (FPGA), Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM)), or including digital logic, software, Code, electronic instructions, and ASICs suitable for storing electronic instructions in flash memory, optical disks, CD-ROMs, DVD ROMs, magnetic or optical cards, other types of machine-readable media, or any suitable combination thereof. In operation, the processor may store information in any suitable type of non-transitory storage medium (eg, random access memory (RAM), read only memory (ROM), field programmable gate array (FPGA), erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable ROM (EEPROM), etc.), software, hardware, or any other suitable component, device, element or object as appropriate for the particular needs. Information that is tracked, sent, received, or stored in the processor may be provided in any database, register, table, buffer, queue, control list, or storage structure, in any suitable All this information is referenced at the time frame of . Any memory terms discussed herein should be understood to be included within the broad term "memory." Similarly, any potential processing elements, modules and machines described herein should be understood to be included within the broad terms "microprocessor" or "processor."

The computer program logic that implements all or part of the functions described herein is embodied in various forms including, but not limited to, source code form, computer executable form, and various intermediate forms (e.g., by an assembler, connector, connector, or locator generated form). In one example, the source code includes a series of computer program instructions implemented in various programming languages (eg, object code, assembly language, or, or a high-level language such as OpenCL, Fortran, C, C++, JAVA, or HTML), for use with various operating systems or operating environments. Source code can define and use various data structures and communication messages. The source code may be in a computer-executable form (eg, via an interpreter), or the source code may be converted (eg, via a translator, assembler, or compiler) into a computer-executable form.

Also in the discussion of the above embodiments, capacitors, buffers, graphics elements, interconnect boards, clocks, DDR, camera sensors, dividers, inductors, resistors, amplifiers, switches, digital cores, transistors and/or Other components can easily be replaced, substituted, or modified to suit specific circuit needs. Furthermore, it should be noted that the use of complementary electronics, hardware, non-transitory software, etc. provides equivalently viable options for implementing the teachings of the present disclosure.

In an example embodiment, any number of the circuits in the figures may be implemented on a circuit board of an associated electronic device. The board may be a common circuit board that can carry various components of the internal electronic system of the electronic device and further provide connectors to other peripheral devices. More specifically, the boards can provide electrical connections through which other components of the system can communicate electrically. Any suitable processors (including digital signal processors, microprocessors, supporting chipsets, etc.), memory elements, etc., may be appropriately coupled to the board based on particular configuration needs, processing requirements, computer design, etc. . Other components for audio/video display (eg external storage, additional sensors, controllers), and peripherals may be attached to the board as plug-in cards, attached to the board via cables, or integrated into the board itself. In another example embodiment, the electronic circuits in the figures may be implemented as separate modules (eg, devices having associated elements and circuits configured to perform a particular application or function), or as a component to an electronic device Plug-in modules for dedicated hardware.

Note that with some of the examples provided above, interactions may be described with respect to two, three, four, or more electronic elements. However, this is only done for clarity and example purposes. It should be understood that the systems may be combined in any suitable manner. Following similar design alternatives, any of the components, modules and elements shown in the figures may be combined in various possible configurations, all of which are expressly within the scope of this description. In some cases, it may be easier to describe one or more of the functions of a given set of streams by only referencing a limited number of electronic elements. It should be appreciated that the circuits of the drawings and their teachings are susceptible to expansion and can accommodate a large number of components and more complex/precise arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of circuits potentially adaptable to numerous other architectures.

Numerous other changes, substitutions, changes, alterations, and modifications will be apparent to those skilled in the art, and it is intended that this disclosure include all such changes, substitutions, changes, alterations, and modifications that fall within the scope of the appended claims . To assist in the interpretation of the appended claims by the United States Patent and Trademark Office (USPTO) and any reader of any patents issued in this application in addition, Applicants wish to note that Applicants: (a) do not intend any of the appended claims The claim invokes paragraph six(6) of U.S.C. 35 Part 112 as of its filing date, unless the words "means for" or "step for" are specifically used in a particular claim; and (b) not It is intended that any statement in the specification limit the disclosure in any way not reflected in the appended claims.

Claims (20)

1. A network device, comprising: an interface for coupling with a telecommunications engine operable to provide wireless uplink and downlink communication services in a plurality of frequency carriers in a baseline configuration P0 with baseline neighbor associations configure; an interface for coupling with an ad hoc network controller; and A policy engine that is operable to do the following: identifying network condition scenario S1 including carrier load conditions; locate the policy P1 associated with the scenario S1; and A configuration command is provided to the telecommunications engine based on the policy P1, wherein when the third frequency carrier is relatively lighter than the second frequency carrier, the neighbor association between the first frequency carrier and the second frequency carrier is updated to the third frequency carrier Neighbor association between a frequency carrier and a third frequency carrier. 2. The network device of claim 1, wherein the policy engine is further operable to perform the following operations: evaluating network conditions after sending the configuration command; determining that the configuration commands based on the policy P1 have degraded network performance; and Send a configuration command to select a new policy Pn. 3. The network device of claim 1, wherein the policy engine is further operable to perform the following operations: evaluating network conditions after sending the configuration command; determining that the configuration command based on the policy P1 has degraded network performance; identify network condition scenario S2; and Send configuration commands based on baseline policy P2. 4. The network device of claim 1, wherein the policy engine is further operable to send a configuration command that restores the baseline configuration P0 after a period of time. 5. The network device of claim 1, wherein the policy engine further comprises a plurality of network condition contexts S, wherein at least some of the network condition contexts S have been associated with at least one policy P. 6. The network device of claim 5, wherein at least one of the network condition scenarios S is dynamically selected based on network requirements, and is selected from the group consisting of: carrier load, power Savings, interference, band loading, noise, key performance indicators, congestion, outages, resource-based, operator-defined conditions, network or carrier boundaries, new technologies, frequency cells turned on, and inter-technology load balancing. 7. The network device of claim 1, wherein the network condition scenario S includes automatic neighbor relationship management at different frequencies from a first technology to a second technology, or to the first technology, wherein the first technology The technology and the second technology are distinct and selected from the group consisting of: Global System for Mobile Communications, Enhanced Data Rates for GSM Evolution, Code Division Multiple Access, Universal System for Mobile Communications, and Long Term Evolution . 8. The network device of claim 1, wherein the network device is further configured to provide operations support system services. 9. The network device of claim 1, wherein the network device is further configured to provide radio access network management services. 10. One or more computer-readable media having stored thereon executable instructions operable to instruct a processor to: identifying network condition scenario S1 including carrier load conditions; Locate the policy P1 related to the scenario S1; A configuration command is provided to the telecommunications engine based on the policy P1, wherein the neighbor association between the first frequency carrier and the second frequency carrier is updated to the first frequency when the third frequency carrier is relatively lightly loaded than the second frequency carrier a neighbor association between the carrier and the third frequency carrier; and Provides operational support system services or radio access network management services. 11. The one or more computer-readable media of claim 10, wherein the instructions are further operable to instruct the processor to: evaluating network conditions after sending the configuration command; determining that the configuration commands based on the policy P1 have degraded network performance; and Send a configuration command to select a new policy Pn. 12. The one or more computer-readable media of claim 10, wherein the instructions are further operable to instruct the processor to: evaluating network conditions after sending the configuration command; determining that the configuration command based on the policy P1 has degraded network performance; identify network condition scenario S2; and Send configuration commands based on baseline policy P2. 13. The one or more computer-readable media of claim 10, wherein the instructions are further operable to instruct the processor to send a configuration command to restore a baseline configuration P0 after a period of time. 14. The one or more computer-readable media of claim 10, wherein the instructions are further operable to instruct the processor to perform the following operations: identify a plurality of network condition scenarios S, wherein the network condition At least some of the scenarios S have been associated with at least one policy P. 15. The one or more computer-readable media of claim 14, wherein at least one of the network condition scenarios S is selected from the group consisting of: carrier load, power saving, Interference, band loading, noise, key performance indicators, congestion, outages, resource-based, operator-defined conditions, network or carrier boundaries, new technologies, frequency cells turned on, and inter-technology load balancing. 16. The one or more computer-readable media of claim 10, wherein the network condition context S includes automatic neighbor relationship management from a first technology to a second technology, wherein the first technology and the The second technology is different and selected from the group consisting of: Global System for Mobile Communications, Enhanced Data Rates for GSM Evolution, Code Division Multiple Access, Universal System for Mobile Communications, and Long Term Evolution. 17. A method for communication comprising: coupled to a telecommunications engine operable to provide wireless uplink and downlink communication services in a plurality of frequency carriers configured in a baseline configuration P0 with baseline neighbor associations; identifying network condition scenario S1 including carrier load conditions; Locate the policy P1 related to the scenario S1; A configuration command is provided to the telecommunications engine based on the policy P1, wherein when the third frequency carrier is relatively lighter than the second frequency carrier, the neighbor association between the first frequency carrier and the second frequency carrier is updated to the third frequency carrier a neighbor association between a frequency carrier and a third frequency carrier; and Provides operational support system services or radio access network management services. 18. The method of claim 17, further comprising: evaluating network conditions after sending the configuration command; determining that the configuration commands based on the policy P1 have degraded network performance; and Send a configuration command to select a new policy Pn. 19. The method of claim 17, further comprising: evaluating network conditions after sending the configuration command; determining that the configuration command based on the policy P1 has degraded network performance; identify network condition scenario S2; and Send configuration commands based on baseline policy P2. 20. The method of claim 17, further comprising identifying a plurality of network condition scenarios S, wherein at least some of the network condition scenarios S have been associated with at least one policy P.