Patent Description:
In the current state of development for LTE, anyone deploying a base station (eNodeB), whether a network operator, neutral host, etc., makes that eNodeB available to the greater mobile network, including all information related to the capabilities of the eNodeB. In many cases, the entity may deploy a plurality of eNodeBs as a local network. This is typically done in a large venue, such as a stadium, airport, university campus, etc. In this case, the capabilities of each deployed eNodeB are known to the greater mobile network.

A disadvantage of the current state is that there is currently no way for anyone deploying a network of eNodeBs to reconfigure or redesign the network without it impacting the entire network. There is currently no way for someone to deploy an LTE subnetwork in such a way that the inner workings of the subnetwork are hidden from the greater network.

A further disadvantage of the current state is as follows. A given eNodeB is identified by a 20bit identifier (eNB ID). Each eNodeB can support up to <NUM> cells, each of which is identified by a global cell identifier (E-CGI) that appends the 20bit eNB ID with a unique 8bit pattern. Although each eNodeB may, in theory, support <NUM> cells, this is basically impossible due to computing constraints. In practice, each eNodeB typically supports a maximum of approximately twelve cells. This not only limits the potential usefulness of a given eNodeB, but it also leads to inefficient use of E-CGI address space.

Accordingly, there is a need for a method for creating and maintaining an LTE private subnetwork whereby the subnetwork is seen by the greater network as a single eNodeB, in which the complexities of the subnetwork are hidden from the greater network, and in which the subnetwork may be redesigned, and/or dynamically reconfigured as needed, in a way that is transparent to the greater network, and in which the eNodeB may make full use of the capability of servicing as many as <NUM> cells.

<CIT> discloses a network selection device that may determine that a communication between a user device and a first network device should be transferred from the first network device to a second network device that is in an idle state; output an instruction to cause the second network device to exit the idle state and communicate with the user device; determine that the second network device is unused or underutilized; and output, based on determining that the second network device is unused or underutilized, an instruction to cause the second network device to reenter the idle state.

<CIT> discloses two methods of managing the operation mode of a first base station and a second base station. One method uses an operation mode controller that sends respective resource usage status requests to the first and second base stations and receives respective resource usage information reports from the base stations. If the UE resource usage information associated with the first base station and the second base station satisfies a predefined condition, the operation mode controller sends a sleep/wakeup command to the first base station, the sleep command including instructions for the first base station to hand over its UE to the second base station. Next, the operation mode controller notifies the second base station that the first base station is going to enter a predefined sleep or wakeup mode, the wakeup notification including instructions for the second base station to hand over its UE to the first base station. In the other method, a sleep mode request and a corresponding sleep mode response are exchanged directly between a first base station and a second base station. The first base station enters a predefined sleep mode if the second base station responds to the sleep mode request from the first base station.

<CIT> discloses a virtual cell being connectable to a base station of a mobile telecommunications system, the base station being configured to communicate with at least one user equipment and at least one virtual cell, the virtual cell comprising circuitry being configured to communicate with at least one user equipment and the base station. A virtual cell can be turned off, e.g. since there is no traffic demand in its area. But the base station (e.g. eNodeB) could broadcast virtual cell related system information instead, potentially with a longer period. If then a UE receives such system information and decides to access to the virtual cell, the UE functioning as a slave base station and establishing the virtual cell will indicate to the base station the demand to access this certain virtual cell.

<FIG> illustrates an exemplary private subnetwork of LTE base stations (hereinafter subnetwork <NUM>) according to the disclosure. Subnetwork <NUM> comprises a connection aggregator (hereinafter S <NUM>-Conn <NUM>); an operation and maintenance module <NUM>; a plurality of internal baseband processors, i.e. internal eNodeBs <NUM>, each of which has a corresponding supervisor module <NUM>, and each of which has one or more corresponding cells <NUM>. Each internal eNodeB <NUM> is coupled to the S1-Conn <NUM> by a respective internal S1 connection <NUM>, which is a standard S1 connection as would be implemented between a conventional eNodeB and a conventional MME (Mobility Management Entity) as defined in the LTE specification. Each supervisor module <NUM> may be coupled to the operation and maintenance module <NUM> by a conventional IP connection <NUM>.

S1-Conn <NUM> may be coupled to one or more MMEs <NUM> via a corresponding external S1 connection <NUM>. Each external S1 connection <NUM> may be identical to each internal S1 connection <NUM> in that they each are standard S1 connections as defined in the LTE specification.

Also illustrated in <FIG> is an external eNodeB <NUM> having at least one corresponding cell <NUM>. External eNodeB <NUM> may be coupled to one or more of the illustrated MMEs <NUM> via an S1 connection <NUM>. Further illustrated is a UE <NUM>, which may be in communication with one or more cells <NUM>/<NUM>.

Subnetwork <NUM> may be deployed or integrated in, for example, a dense urban environment or a large venue, such as a stadium, airport, shopping center, university campus, etc. Each internal eNodeB <NUM> may correspond to macro cell, a small cell, femto cell, or a Distributed Antenna System (DAS). Each internal eNodeB <NUM> may have any number of cells <NUM>.

Each individual internal eNodeB <NUM> may be individually implemented as a pure software-based virtual baseband processor that may be instantiated and de-instantiated as needed, or each may be individually implemented as a hardware-based baseband processor that is deployed in dedicated hardware in close proximity to its corresponding RF and antenna components, or any combination of the above. Although an LTE-specific term is used to refer to a given eNodeB <NUM>, it may actually be implemented according to a different or legacy RAT technology, as long as it communicates with S <NUM>-Conn <NUM> via an S1 interface. As used herein, the terms baseband processor and eNodeB may be interchangeable.

S <NUM>-Conn <NUM> and operation and maintenance module <NUM> (and potentially one or more of the internal eNodeBs <NUM>) are implemented in software that runs in a conventional server hardware that may be located in a single location (e.g., one or more racks) within or near the venue where subnetwork <NUM> is deployed, or otherwise distributed. There may be an advantage to having the internal eNodeBs <NUM> pure software-based virtual baseband processors in that they can make the best advantage of the ability of the subnetwork <NUM> to dynamically instantiate and de-instantiate internal eNodeBs <NUM> as traffic demand within the venue fluctuates. Further, having each internal eNodeB <NUM> implemented purely in software enables each internal eNodeB <NUM> to be instrumented with code to enable interaction with its corresponding supervisor module <NUM> and easier configuration and maintenance from operation and maintenance module <NUM>. However, it will be understood that hardware-based internal eNodeBs <NUM> may be activated/de-activated in place of instantiation/de-instantiation of a virtual internal eNodeB <NUM>.

<FIG> illustrates an exemplary process for configuring a subnetwork <NUM> according to the disclosure.

In step <NUM>, S1-Conn <NUM> establishes an S1 interface with each of the MMEs <NUM>. In doing so, S1-Conn <NUM> issues an S1 SETUP REQUEST message to each of the MMEs <NUM>, which includes its own 20bit eNB ID (the virtual subnetwork baseband processor identifier) and all of the E-CGIs corresponding to each of the constituent cells of all of the internal eNodeBs <NUM>. In response, each MME <NUM> may send a subsequent S1 SETUP RESPONSE message to S1-Conn <NUM>, thereby establishing an external S1 Connection <NUM> between the S1-Conn <NUM> and each MME <NUM>.

In step <NUM>, each internal eNodeB <NUM> starts up according to its nominal function. Each internal eNodeB <NUM> has the same 20bit identifier, and a number of allocated 8bit subidentifiers for each possible cell <NUM> that might correspond to that particular internal eNodeB <NUM>. This information may be stored in a configuration file within each internal eNodeB <NUM> and may be supplied by its corresponding supervisor module <NUM>. Alternatively, configuration information for each internal eNodeB <NUM> may be stored in a distributed data source. Examples of such distributed data sources may include systems like consul and etcd. Given that all of the internal eNodeBs <NUM> have the same 20bit identifier, in order to uniquely identify each internal eNodeB <NUM>, each one may select a 8bit cell identifier of one of its cells <NUM> (for example, its first cell <NUM>) and append it to its own 20bit identifier, making it a 28bit eNodeB identifier. The internal identifier may be the same as that used conventionally with Home eNodeBs (HeNB). This internal 28bit eNodeB identifier may be referred to herein as an "internal identifier".

Once it has started up, in step <NUM>, each internal eNodeB <NUM> sets up an S1 connection with S1-Conn <NUM>, using its individual internal 28bit eNodeB identifier. An example of how the internal eNodeB <NUM> may establish an S1 connection with an MME <NUM> is described in 3GPP TS <NUM>. In doing so, the given internal eNodeB <NUM> functions as if it is establishing an S1 connection with each MME <NUM>. However, S1-Conn <NUM> intercepts each S1 SETUP REQUEST from each internal eNodeB. S1-Conn <NUM> uses this information to establish an S1 interface with each internal eNodeB <NUM> and subsequently generates and issues an S1 SETUP RESPONSE message to each of the internal eNodeBs <NUM>. In doing so, each of the internal eNodeBs <NUM> "thinks" that it has established an S1 interface with a single MME that has a lot of capabilities (actually the collective capabilities of the MMEs <NUM>), but what it has actually done is establish an internal S1 connection <NUM> with the S1-Conn <NUM>.

In step <NUM>, each internal eNodeB <NUM> sends an initiation message that would otherwise indicate to one or more MMEs <NUM> that it is functioning. This initiation message would include its own identity and the cell identities of its corresponding cells <NUM>. In an exemplary embodiment of process <NUM>, each internal eNodeB <NUM> sends a PWSRestartIndication message, which is intercepted by S1-Conn <NUM>. The PWSRestartIndication message, an example of which is described in 3GPP TS <NUM>, includes the following information: the E-CGI (Enhanced Cell Global ID) of each cell corresponding to the sending internal eNodeB <NUM>, the Global eNB ID for the sending internal eNodeB <NUM> (which is its aforementioned internal 28bit eNodeB identifier), the TAI (Tracking Area Identifier) list for the internal eNodeB's <NUM> corresponding cells, and the Emergency Area ID list for the internal eNodeB's <NUM> corresponding cells.

It will be understood that the described functions performed by each internal eNodeB <NUM> may correspond to a sequence of computer instructions stored on a machine readable memory allocated to or associated with each corresponding internal eNodeB <NUM>, and executed either by a dedicated processor embedded within corresponding eNodeB <NUM> or by a server processor or virtual machine spawned in a cloud computing environment running on server hardware located within the venue of subnetwork <NUM> or elsewhere. The same is true for the S1-Conn <NUM> and the operation and maintenance module <NUM>. These components may comprise computer instructions that may be stored in non-volatile memory and executed on server compute hardware that may be located in, near, or distributed around the venue corresponding to subnetwork <NUM>. Each of these components may be implemented in C, C++, Java, one or more scripting languages, or any combination thereof, depending on the given subcomponent within each of these components.

In step <NUM>, S1-Conn <NUM> intercepts each PWSRestartIndication message from each internal eNodeB <NUM>, and in step <NUM>, creates a mapping of the following for each internal eNodeB <NUM>: its internal 28bit eNodeB identifier, its constituent cell IDs (E-CGIs), and the rest of the information provided in its corresponding PWSRestartIndication message. Further to step <NUM>, S1-Conn <NUM> assigns itself the 20bit eNodeB ID common to all of the internal eNodeBs <NUM>, extracts the constituent cells IDs (E-CGIs) and further information gathered from each corresponding PWSRestartIndication message and populates this information in a new "repackaged" PWSRestartIndication Message. The 20bit eNodeB ID assigned to the S1-Conn <NUM> may be referred to as a virtual subnetwork baseband processor identifier.

In step <NUM>, S1-Conn <NUM> sends its own PWSRestartIndication message assembled in step <NUM> to each corresponding MME <NUM> via its respective external S1 connection <NUM>.

Accordingly, each MME <NUM> will behave as though it is interacting with a single "giant" eNodeB with a potentially large number of aggregated cells <NUM> (potentially as many as <NUM> cells), even though each MME <NUM> is interacting exclusively with S1-Conn <NUM>. Further, each internal eNodeB <NUM> will behave as though it is interacting with any of MMEs <NUM>, even though it is interacting exclusively with S1-Conn <NUM>. In order to accomplish this, S1-Conn <NUM> intercepts each subsequent message, bidirectionally, between a given MME <NUM> and an internal eNodeB <NUM>, and also between the MME <NUM> a given UE <NUM>. S1-Conn <NUM> remaps the cell IDs and other required information using - for example - look up tables stored in memory allocated to S1-Conn <NUM>, repackages the given message with the re-mapped information, and sends the repackaged message to its destination. For the purposes herein, the internal eNodeB <NUM> that is the destination of the incoming message from a given MME <NUM> may be referred to as a message destination baseband processor.

Advantages of this include the following. First, any given (non-Home) eNodeB has a 20bit identifier and may have allocated to it as many as <NUM> cells, given that the cell ID for each eNodeB is an 8bit identifier. However, given the practical limitations in computational power, any given eNodeB typically has no more than a dozen cells. The disclosed subnetwork <NUM> enables a given eNodeB (in this case, the S-Conn <NUM> acting like a "giant" eNodeB) to make use of all 8bits of cell IDs. This is because each internal eNodeB <NUM> has allocated to it (either in dedicated hardware or provisioned cloud computing resources) sufficient memory and computational resources to handle a typical number of cells commonly used.

Second, given that the external network (e.g., from the MMEs <NUM> outward) is only aware of a single "giant" eNodeB encompassed by the functions of S1-Conn <NUM>, the number of internal eNodeBs <NUM> (and subsequent number of cells <NUM>) may be dynamically adjusted according to traffic demand. This may be extremely useful for venues, such as stadiums, that may be filled to capacity one day a week and quiet the rest of the time. In this case, internal eNodeBs <NUM>, each with a plurality of corresponding cells <NUM>, may be created and allocated to handle changes in traffic demand, such that all of these changes are hidden to the outer network.

It will be understood that the described functions performed by the S-Conn <NUM> is further describing a sequence of computer instructions stored on a machine readable memory allocated to or associated with the S1-Conn <NUM>, and executed either by a dedicated processor or by a server processor or virtual machine spawned in a cloud computing environment running on server hardware located within the venue of subnetwork <NUM> or elsewhere.

<FIG> illustrates an exemplary process <NUM> by which a UE <NUM> establishes connection with an internal eNodeB <NUM>.

In step <NUM>, the UE <NUM> and the given internal eNodeB <NUM> exchange appropriate conventional signals to establish a connection. For example, UE <NUM> may transmit an RRC Connection Request to the internal eNodeB <NUM>, which may in turn respond with an RRC Connection Setup message, etc. The result is that UE <NUM> is connected to internal eNodeB <NUM> and that internal eNodeB <NUM> has established an internal identifier corresponding to that UE.

In subprocess <NUM>, internal eNodeB <NUM> establishes a default bearer with an MME <NUM> via S1-Conn <NUM>. As illustrated in <FIG>, subprocess <NUM> comprises several steps that are added to the default bearer establishment procedures specified in 3GPP TS <NUM>, for example. steps <NUM>, <NUM>, and <NUM> describe modifications/enhancements to the conventional procedures described in the 3GPP technical specifications.

In step <NUM>, S1-Conn <NUM> intercepts the default bearer establishment messages sent by internal eNodeB <NUM>, which includes a UE ID generated by the internal eNodeB <NUM>.

In step <NUM>, the S1-Conn replaces the UE ID (generated by the internal eNodeB <NUM>) and replaces it with a unique UE ID generated by the S1-Conn <NUM>. This is necessary because each of the internal eNodeBs <NUM> generate UE IDs without any awareness of the UE IDs generated by any of the other internal eNodeBs <NUM>. There is a significant chance of two eNodeBs <NUM> generating duplicate UE IDs. Given this possibility, S1-Conn replaces the UE ID generated by the internal eNodeB <NUM> with a unique value, repackages the message, and transmits the message to the appropriate MME <NUM>.

In step <NUM>, S1-Conn <NUM> intercepts default bearer establishment messages from the MME <NUM> to the internal eNodeB <NUM>, remaps the UE ID, and transmits the repackaged message to the internal eNodeB <NUM>.

The objective is that the given internal eNodeB <NUM> is not aware that it is not interacting directly with MME <NUM>, and that the MME <NUM> is not aware that it is not interacting directly with internal eNodeB <NUM>. In the former case, S1-Conn <NUM> is acting as the MME <NUM> for the internal eNodeB <NUM>, and in the latter case, S1-Conn <NUM> is acting as the eNodeB that interacts with the MME <NUM> (and the UE <NUM>).

In subprocess <NUM>, internal eNodeB <NUM> establishes a dedicated bearer with an MME <NUM> via S1-Conn <NUM>. As illustrated in <FIG>, subprocess <NUM> comprises several steps that are added to the default bearer establishment procedures specified in 3GPP TS <NUM>. The steps required for establishing a dedicated bearer may be substantially identical to steps <NUM> and <NUM> described above. The result is that there is at least one dedicated bearer established between UE <NUM> and MME <NUM>, whereby S1-Conn <NUM> is serving as an unseen intermediary between internal eNodeB <NUM> and MME <NUM>.

<FIG> illustrates an exemplary process <NUM> for establishing an X2 connection between two internal eNodeBs <NUM>.

In step <NUM>, UE <NUM> communicates with its currently connected source internal eNodeB <NUM> that it has a strong signal from another internal eNodeB <NUM>. UE <NUM> does so by transmitting a measurement report to the source internal eNodeB <NUM>, which identifies neighboring internal eNodeBs <NUM> and cell <NUM> from which UE <NUM> is receiving a strong signal. Step <NUM> may be a conventional process, an example of which is described in 3GPP TS <NUM>. From this information UE <NUM> identifies and recommends a target internal eNodeB <NUM> for handover.

In step <NUM>, the source internal eNodeB <NUM> retrieves its own internal 28bit identifier from internal memory. Recalling from step <NUM>, each internal eNodeB has as a default the same 20bit eNodeB identifier. In order to prevent collisions within subnetwork <NUM>, each internal eNodeB's supervisor module <NUM> instructs its respective internal eNodeB <NUM> to select the 8bit identifier of one of its cells (e.g., the first cell) and append its own 20bit identifier with the 8bit identifier of its cell, creating a false Home eNodeB (HeNB) internal identifier for itself, referred to herein as an internal eNodeB identifier. Further to step <NUM>, the source internal eNodeB <NUM> retrieves the E-CGI for the target cell identified by the UE (via the measurement report) and uses that 28bit cell identifier corresponding to the target eNodeB.

In step <NUM>, the source internal eNodeB <NUM> sends an eNBConfigurationTransfer command, which is conventionally sent to one of the MMEs <NUM>. In the eNBConfigurationTransfer command, the source internal eNodeB <NUM> is identifying itself with its internal eNodeB identifier and the internal eNodeB identifier for the target internal eNodeB identifier.

In step <NUM>, S1-Conn <NUM> intercepts the eNBConfigurationTransfer transmitted in step <NUM>. In step <NUM>, S1-Conn <NUM> extracts the internal eNodeB identifier of the source internal eNodeB <NUM> and the internal eNodeB identifier of the target internal eNodeB <NUM> (as well as other information in the eNBConfigurationTransfer command) and constructs an MMEConfigurationTransfer command with this information. And in step <NUM>, S1-Conn sends the MMEConfigurationTransfer command to the target internal eNodeB <NUM>.

With the configuration transfer complete, source internal eNodeB <NUM> and target eNodeB <NUM> may establish an X2 connection between them. In performing the steps of process <NUM>, S1-Conn <NUM> is acting as the MME <NUM> such that neither source internal eNodeB <NUM> nor target eNodeB <NUM> is aware that they were not communicating directly with MME <NUM>. Further, MME <NUM> was not at any point involved in the process. This is because MME <NUM> sees the S1-Conn <NUM> as a "giant" eNodeB and thus there would be no X2 connection, given only one eNodeB.

<FIG> illustrates an exemplary process <NUM> for executing an X2 handover between two internal eNodeBs <NUM>.

In step <NUM>, the UE <NUM> identifies a target cell <NUM> and target internal eNodeB <NUM> and notifies the source internal eNodeB <NUM>, to which the UE <NUM> is currently connected. This process may be substantially similar to step <NUM> of process <NUM>.

In step <NUM>, the source internal eNodeB <NUM> forwards any data packets (downlink and potentially uplink) corresponding to UE <NUM> to target internal eNodeB <NUM> over the X2 connection that was established in process <NUM>.

In step <NUM>, the target internal eNodeB <NUM> sends a Path Switch Request message to the relevant MME <NUM>. The Path Switch Request includes the TAI (Tracking Area Identity) of the target cell <NUM> of the target internal eNodeB <NUM> as well as the target cell's E-CGI. S1-Conn <NUM> relays this message to the relevant MME <NUM>.

In step <NUM>, target internal eNodeB <NUM> sends a Release Resource message to the source internal eNodeB <NUM> over their mutual X2 connection, thus completing the handover process of a UE <NUM> between two internal eNodeBs <NUM> within subnetwork <NUM> in a way that is hidden from the outer network.

<FIG> illustrates an exemplary process <NUM> for executing an S1 handover between an internal eNodeB <NUM> to an external eNodeB <NUM>. This is for the situation in which UE <NUM> is moving out of range of the internal eNodeBs <NUM> of subnetwork <NUM>. The steps of process <NUM> may be incorporated into the S1-based handover process.

In step <NUM>, the UE <NUM> identifies a target cell <NUM> and target external eNodeB <NUM> and notifies the source internal eNodeB <NUM>, to which the UE <NUM> is currently connected. This process may be substantially similar to step <NUM> of process <NUM> and step <NUM> of process <NUM>.

In step <NUM>, the source internal eNodeB <NUM> sends a Handover Required message to the relevant MME <NUM>. In doing so, source internal eNodeB <NUM> uses its internal eNodeB identifier in the message.

In step <NUM>, S1-Conn <NUM> intercepts the Handover Required message and repackages the message with its own 20bit virtual subnetwork baseband processor identifier and the E-CGI of the cell currently connecting UE <NUM> with source internal eNodeB <NUM>, and sends the message to the relevant MME <NUM>.

In step <NUM>, MME <NUM> sends a Handover Command to S1-Conn <NUM>. It will be understood that MME <NUM> behaves as though it were interacting with a conventional eNodeB.

In step <NUM>, S1-Conn <NUM> receives the Handover Command from MME <NUM> and remaps the eNB ID to the internal eNodeB identifier of the source internal eNodeB <NUM>, and sends the repackaged Handover Command to the source internal eNodeB <NUM>. Subsequently, in step <NUM>, source internal eNodeB <NUM> sends the Handover Command to UE <NUM>.

If any of the E-RABs (Evolved Radio Access Bearers) corresponding to UE <NUM> are configured for PDCP (Packet Data Convergence Protocol) preservation, the source internal eNodeB <NUM> may send an eNB Status Transfer message to the relevant MME <NUM>. S1-Conn <NUM> may intercept this message, remap the information in the message to specify the virtual subnetwork baseband processor identifier, repackage the message, and transmit it to the relevant MME <NUM> (the source MME).

In step <NUM>, the source MME <NUM> sends a UE Context Release Command to the S1-Conn <NUM>. In step <NUM>, the S1-Conn <NUM> in turn remaps the eNB ID to the internal eNodeB identifier of the source internal eNodeB <NUM> and transmits the message to the source internal eNodeB <NUM>.

In step <NUM>, the source internal eNodeB <NUM> sends a UE Context Release Complete message to the source MME <NUM>.

In step <NUM>, the S1-Conn <NUM> intercepts the UE Context Release Complete message, remaps the information to reflect the virtual subnetwork baseband processor identifier, repackages the message, and transmits it to the source MME <NUM>.

It will be understood that there are many steps to the conventional process of an S1-based handover, as described in 3GPP TS <NUM>, that occur (for example) between steps <NUM> and <NUM>, and between steps <NUM> and <NUM>. These steps occur in the outer network (e.g., between MMEs <NUM>, S-GW and P-GW (not shown) and external eNodeB <NUM>. It is understood that these external steps are known and fully described in the referenced 3GPP documentation.

Accordingly, to the outer network, the S1-based handoff disclosed in process <NUM> involves a handoff between the "giant" eNodeB represented by S1-Conn <NUM> and external eNodeB <NUM>. The inner workings of subnetwork <NUM> are hidden from the outer network.

<FIG> illustrates an exemplary process <NUM> for reconfiguring subnetwork <NUM> based on an increase or decrease in traffic demand. This enables the subnetwork <NUM> to expand and contract based on demand while hiding the changes to the subnetwork from the outer network.

In step <NUM>, the operation and maintenance module <NUM> may, in conjunction with the S1-Conn <NUM>, make an assessment of current traffic usage and demand. This may involve analyzing historical usage data as well as extrapolating near future demand. For example, if subnetwork <NUM> is deployed in a stadium, operation and maintenance module <NUM> may have stored in accessible memory a calendar of upcoming events so that it can anticipate periods of high and low demands. For deployments such as in a dense urban setting, operation and maintenance module <NUM> may have accumulated historical data on demand based on time of day, day of week, holidays, and days with special events. Given this, operation and maintenance module <NUM> is able to perform appropriate analytics to estimate current and near future demand, and take action accordingly to provide for the provisioning of cloud-based computing capacity for virtual internal eNodeBs <NUM>, or to power up/down hardware-based internal eNodeBs <NUM>.

Additionally, the virtual eNodeBs <NUM> may employ 3GPP-specified mechanisms for assessing (i.e., determining) demand, including setting a configurable threshold(s), and comparing actual demand to said threshold(s). The eNodeBs <NUM> can then send the results of the comparisions to the operation and maintenance module <NUM>. The operation and maintanenace module <NUM> can then further determine whether demand has dropped below a low threshold (e.g., <NUM>% of configured maximum capacity) or whether demand has gone above a high threshold (e.g., <NUM>% of configured maximum capacity). Alteratively, each of the eNodeBs can make the above described further determinations and send an alarm signal, or the like, to the operation and maintenance module <NUM> if either of the thresholds has been exceeded. This mechanism may use the standard PM-Stat files (Performance Measurement) that are generated every <NUM> minutes and transmitted to the core network via a northbound interface (not shown) that is also specified by 3GPP. It will be understood that such variations are possible and within the scope of the disclosure.

Depending on the result of the assessing done in step <NUM>, process <NUM> may either take no action (not shown in <FIG>); it may take subprocess path <NUM>, in which operation and maintenance module <NUM> may increase the capacity of subnetwork <NUM> by adding one or more internal eNodeBs <NUM>; or it may take subprocess path <NUM>, in which operation and maintenance module <NUM> may reduce capacity by removing one or more internal eNodeBs <NUM>.

Regarding subpath <NUM>, if in the assessing in step <NUM> the operation and maintenance module <NUM> determines that additional capacity is required, operation and maintenance module <NUM> may proceed to step <NUM> and execute instructions to identify where within subnetwork <NUM> one or more additional internal eNodeBs <NUM> are needed. This includes determining the location of the internal eNodeBs <NUM> with the greatest demand and determining the availability of remote radio unit and antenna hardware in the vicinity, for example.

In step <NUM>, operation and maintenance module <NUM> executes instructions to bring up one or more new internal eNodeBs <NUM>. In doing so, operation and maintenance module <NUM> may execute instructions to have local server hardware instantiate one or more software-based virtual baseband processors, and/or to power up one or more dormant hardware-based base stations.

In step <NUM>, operation and maintenance module <NUM> issues instructions to S1-Conn <NUM> to command the currently-running high-demand internal eNodeBs <NUM> to handoff UE connections to the recently-introduced new internal eNodeBs <NUM>. This may be alternatively done whereby the operation and maintenance module <NUM> may issue instructions to the appropriate supervisor modules <NUM>, via IP connection <NUM>, to have the corresponding internal eNodeBs <NUM> execute UE connection handoffs.

With the new eNodeBs <NUM> up and running, it is necessary to update the identifier mapping information within S1-Conn <NUM>. Accordingly, in step <NUM>, the newly online internal eNodeBs <NUM> may each issue a PWSRestartIndication message (or similar initiation message), indicating its internal eNodeB identifier and constituent cell IDs.

In step <NUM>, S1-Conn <NUM> intercepts the one or more PWSRestartIndication messages, one from each newly online internal eNodeB <NUM>, extracts the internal eNodeB identifier and corresponding cell IDs, and adds this information to the pre-existing mapping that S1-Conn <NUM> stores in its memory.

In step <NUM>, S1-Conn may issue its own PWSRestartIndication to one or more MMEs <NUM>, similarly to step <NUM> in process <NUM>. In this case, the outer network is not aware of the addition of new internal eNodeBs <NUM>. Instead, it is only aware of a single "giant" eNodeB that has one or more additional cells.

Regarding subpath <NUM>, if in the assessing in step <NUM> the operation and maintenance module <NUM> determined that subnetwork <NUM> has excess capacity, operation and maintenance module <NUM> proceeds to step <NUM> and executes instructions to identify where within subnetwork <NUM> one or more additional internal eNodeBs <NUM> are to be shut down. This may include determining the location of the internal eNodeBs <NUM> with insufficient demand and the internal identifiers of neighboring eNodeBs <NUM> that might be available for handoff.

In step <NUM>, operation and maintenance module <NUM> executes instructions to command the internal eNodeBs <NUM> designated for shutdown to handoff UE connections to neighboring eNodeBs that are otherwise capable of servicing these UEs <NUM>. As with step <NUM>, this may happen one or more ways: whereby operation and maintenance module <NUM> issues instructions to S1-Conn <NUM> to command the handoffs, or operation and maintenance module <NUM> issues instructions to the relevant supervisor modules <NUM> to implement the handoffs. It will be understood that such variations are possible and within the scope of the disclosure.

In step <NUM>, operation and maintenance module <NUM> shuts down the internal eNodeBs <NUM> designated in step <NUM>. In the case of software-based virtual internal eNodeBs <NUM>, this may involve terminating the corresponding virtual machine running on the subnetwork's server hardware. Alternatively (or additionally) this may involve powering down appropriate hardware-based base stations. Operation and maintenance module <NUM> may do this by issuing commands to the relevant supervisor modules <NUM>.

In step <NUM>, S1-Conn <NUM> executes instructions to remove the terminated internal eNodeB identifiers and corresponding cell IDs from its memory. Subprocess <NUM> then proceeds to step <NUM>. In step <NUM>, S1-Conn <NUM> issues a new PWSRestartIndication with the revised list of Cell IDs (minus the Cell IDs corresponding to the terminated internal eNodeBs <NUM>).

The ability of the S1-Conn <NUM> to intercept, re-map information within, repackage, and transmit messages between the internal eNodeBs <NUM> and the MMEs <NUM> enables other capabilities. For example, S1-Conn <NUM> may identify patterns in messages from the internal eNodeBs and derive position information from one or more of the UEs <NUM> connected to them.

<FIG> illustrates two exemplary processe <NUM> by which S1-Conn <NUM> handles position-related information in accordance with the LTE Positioning Protocol Annex (LPPa) between an E-SMLC (Evolved Serving Mobile Location Center) <NUM> and an internal eNodeB <NUM> and a UE <NUM>, respectively. The E-SMLC <NUM> may be coupled to subnetwork <NUM> via one of the MMEs <NUM>. The connection between MME <NUM> and E-SMLC <NUM> may be over an SLs interface, as specified in 3GPP TS <NUM>. Details regarding LPPa may be found in 3GPP TS <NUM>.

Through process <NUM>, the E-SMLC <NUM> interacts with eNodeB in accordance with LPPa procedures, with the exception of the intervention of the S1-Conn <NUM>, which as described above, makes the E-SMLC function as though it is interacting with a single "giant" eNodeB that is actually the S1-Conn <NUM> acting as a proxy for the internal eNodeBs <NUM> within subnetwork <NUM>.

In step <NUM>, E-SMLC <NUM> issues a request/command to the eNodeB emulated by S1-Conn <NUM>. In this case, the E-SMLC <NUM> is not aware of the internal eNodeBs <NUM> of subnetwork <NUM>, and only interacts with the S1-Conn <NUM>. The request/command may include, for example, E-CID (Enhanced Cell ID) MEASUREMENT INITIATION REQUEST, E-CID MEASUREMENT TERMINATION COMMAND, OTDOA (Observed Time Difference of Arrival) INFORMATION REQUEST, etc. Note that in these interactions, S1-Conn <NUM> will report a predetermined location that may or may not be the actual location of the instantiation of S1-Conn <NUM>. For example, if subnetwork <NUM> is deployed in a venue such as a stadium or an airport, the position reported by S1-Conn <NUM> may be the location of the venue's security office, or its main entrance, etc. Alternatively, S1-Conn <NUM> may return a list of locations, one for each cell <NUM> within subnetwork <NUM>.

In step <NUM>, S1-Conn <NUM> receives and processes the request/command, and in step <NUM>, the S1-Conn <NUM> packages a response and transmits it to the E-SMLC <NUM>.

<FIG> illustrates an exemplary process <NUM> by which S <NUM>-Conn <NUM> may selectively intercept requests from multiple UEs <NUM> connecting to one or more eNodeBs <NUM> of subnetwork <NUM> and take actions to intervene and notify relevant people/entities related to the venue of anomalous behavior among connected or connecting UEs <NUM>.

In step <NUM>, a plurality of UEs <NUM> issue messages to initiate a call, either by VoIP or CS fallback to a <NUM>/<NUM> cell (not shown). These calls may be initiated via one internal eNodeB <NUM>, or two or more neighboring internal eNodeBs <NUM>.

In step <NUM>, S1-Conn <NUM> intercepts the call initiation messages. In the case of VoIP, the S1-Conn <NUM> retrieves the QCI (QoS Class Identifier) from each message. If the QCI is equal to <NUM>, the bearer to be established is identified as corresponding to a voice call. Alternatively, if the QCI is equal to <NUM>, then the message corresponds to IMS (IP Multimedia Subsystem) signaling used to establish and release a VoIP connection. As with any message, S1-Conn <NUM> remaps the eNodeB cell ID with its virtual subnetwork baseband processor identifier, repackages the message, and transmits it to the intended MME <NUM>. With each recognized VoIP call initiation, S1-Conn <NUM> may execute instructions to log relevant information corresponding to the call initiation (e.g., UE identifier, internal eNodeB identifier, 28bit cell identifier (ECGI), S-TMSI (SAE-Temporary Mobile Subscriber Identity), time of receipt of message, etc.).

In step <NUM>, S1-Conn <NUM> stores information related to call establishment events in step <NUM>. Further to step <NUM>, S1-Conn <NUM> may execute instructions to identify patterns, including history of call patterns, as a function of time. If, in the course of executing these instructions, S1-Conn <NUM> might identify an anomaly in call establishment, such as a sudden surge in call establishment messages from UEs <NUM> connected to a given internal cell <NUM>, or multiple adjacent cells <NUM> of a single eNodeB <NUM>, or an isolated instance of numerous UEs <NUM> within a single cell <NUM> simultaneously initiating calls. As used herein, simultaneously may imply events within a single narrow time window, such as within <NUM> second, <NUM> seconds, etc., at the location(s) corresponding to the antenna(s) of relevant cell(s) <NUM>. In this case, S1-Conn <NUM> may store a plurality of identifiers, each corresponding to a UE <NUM> identified within the cluster.

In step <NUM>, the S1-Conn <NUM> may command the relevant internal eNodeBs <NUM> to provide the most recent Timing Advance values corresponding to each UE identified in step <NUM>. Subsequently, in step <NUM>, the relevant internal eNodeBs <NUM> may provide the requested Timing Advance information corresponding to each UE <NUM> identified in step <NUM>.

In step <NUM>, once the S1-Conn <NUM> has received these values, it may execute instructions to determine if the Timing Advance values are sufficiently clustered to indicate whether the call establishment procedures executed by the relevant UEs may be in response to an event in their common location. It will be understood that, in doing so, S1-Conn <NUM> may execute instructions corresponding to one or more known clustering algorithms. If the clustering calculated in step <NUM> indicates a possible event, S1-Conn <NUM> may transmit instructions to neighboring internal eNodeBs <NUM> to determine Timing Advance values for each of the relevant UEs <NUM> and provide them to the S1-Conn <NUM>. S1-Conn <NUM> may then determine the position of the cluster of UEs <NUM> based on triangulation.

Claim 1:
A method of reconfiguring a telecommunication subnetwork, the telecommunication subnetwork comprising eNodeBs, referred to as internal eNodeBs, an operation and maintenance module (<NUM>), and a connection aggregator (<NUM>) coupling each of the internal eNodeBs to one or more Mobility Management Entities, the method comprising:
assessing (<NUM>) by said operation and maintenance module (<NUM>) in conjunction with said connection aggregator (<NUM>) demand for connectivity within the telecommunication subnetwork;
identifying (<NUM>) by said operation and maintenance module (<NUM>) a low-activity internal eNodeB based on a result of assessing demand for connectivity within the telecommunication subnetwork;
commanding by said operation and maintenance module (<NUM>) the handing off (<NUM>) a UE connection associated with each of one or more UEs from the low-activity internal eNodeB to a neighboring internal eNodeB;
shutting down (<NUM>) by said operation and maintenance module (<NUM>) the low-activity internal eNodeB; and
instructing by said operation and maintenance module (<NUM>) said connection aggregator (<NUM>) to remove (<NUM>) an eNodeB identifier and at least one cell ID corresponding to the low-activity internal eNodeB from a memory corresponding to active internal eNodeBs;
wherein assessing demand for connectivity within the telecommunication subnetwork comprises comparing demand for connectivity with an internal eNodeB to a threshold value that reflects a low-activity condition.