System and method for creating and managing a private sub-network of LTE base stations

Abstract

A system and method for creating and maintaining a virtual subnetwork of telecommunication base stations within a larger telecommunication network is disclosed. In an LTE-based example, the subnetwork includes a connection aggregator coupled between multiple eNodeBs inside the subnetwork and one or more MMEs in an external network. The connection aggregator intercepts all control plane messages between the MME and the internal eNodeBs, remaps the eNodeB identifiers, and sends the rewrapped messages so that the external network sees the entire subnetwork as a single "giant" eNodeB. The disclosed system and method enables operators of the virtual subnetwork to add and shut down eNodeBs as connectivity demands fluctuate, and to do so so that all changes are invisible to the external network.

Description

Technical Field

[0001] The present invention relates to wireless communication base stations, and more particularly, to a system and method for creating a private sub-network of LTE base stations for use in large venues and urban scenarios. Background Art

[0002] In the current state of development regarding LTE, any party that deploys a base station (eNodeB) - whether a network operator, a neutral host, etc. - makes that eNodeB available to the larger mobile network, which includes all information about the capabilities of that eNodeB. In many cases, an entity may deploy multiple eNodeBs as a local network. This is often done in large venues (e.g., stadiums, airports, university campuses, etc.). In this case, the capabilities of each deployed eNodeB are known to the larger mobile network.

[0003] The disadvantage of the current state is that currently, any party deploying an eNodeB network cannot reconfigure or redesign the eNodeB network without affecting the entire network. Currently, a party cannot deploy an LTE subnetwork in such a way that the inner workings of the LTE subnetwork are hidden from the larger network.

[0004] Another disadvantage of the current state of affairs is as follows. A given eNodeB is identified by a 20-bit identifier (eNB ID). Each eNodeB is capable of supporting up to 256 cells, each of which is identified by a global cell identifier (E-CGI) appended in a unique 8-bit pattern after the 20-bit eNB ID. Although each eNodeB could theoretically support 256 cells, this is essentially impossible due to computational constraints. In practice, each eNodeB typically supports a maximum of approximately twelve cells. This not only limits the potential availability of a given eNodeB, but also results in inefficient use of the E-CGI address space.

[0005] Therefore, a need exists for systems and methods for creating and maintaining an LTE private subnetwork, whereby the subnetwork is viewed by the larger network as a single eNodeB, wherein the complexity of the subnetwork is hidden from the larger network, and wherein the subnetwork can be redesigned and / or dynamically reconfigured as needed in a manner that is transparent to the larger network, and wherein the eNodeB can take full advantage of the ability to serve up to 256 cells. Summary of the invention

[0006] One aspect of the present invention relates to a telecommunications system, comprising: a plurality of internal baseband processors; and a connection aggregator coupled to the plurality of internal baseband processors, wherein the connection aggregator maintains a plurality of internal identifiers each corresponding to one of the plurality of internal baseband processors. The connection aggregator is configured to: intercept an outgoing message from an internal baseband processor, replace the internal identifier of the internal baseband processor within the outgoing message with a virtual sub-network baseband processor identifier, and send the modified outgoing message. The connection aggregator is also configured to: intercept an incoming message destined for a destination internal baseband processor, replace the virtual sub-network baseband processor identifier within the incoming message with the destination internal identifier to create a modified incoming message, and send the modified incoming message to the destination internal baseband processor.

[0007] Another aspect of the present invention relates to a method for configuring a telecommunications subnetwork. The method includes: intercepting a plurality of PWS restart indication messages, each of the plurality of PWS restart indication messages is from an internal eNodeB; extracting an internal eNodeB identifier and one or more cell IDs from each intercepted PWS restart indication message; allocating each internal eNodeB identifier and corresponding one or more cell IDs to a memory; and sending a subnetwork PWS restart indication message. The subnetwork PWS restart indication message includes a virtual subnetwork baseband processor identifier and one or more cell IDs from the plurality of PWS restart indication messages.

[0008] Another aspect of the present invention relates to a method for configuring a telecommunications subnetwork. The method comprises: intercepting a plurality of initiation messages from corresponding multiple internal baseband processors, wherein each initiation message comprises an internal identifier and at least one cell ID for each cell corresponding to the internal baseband processor; extracting the internal identifier and the at least one cell ID from each initiation message; storing each internal identifier and each at least one cell ID in a memory; generating a virtual subnetwork baseband processor identifier; and sending a subnetwork initiation message, wherein the subnetwork initiation message comprises the virtual subnetwork baseband processor identifier and each one or more cell IDs.

[0009] Another aspect of the present invention relates to a method for establishing a connection between a source internal baseband processor and a target internal baseband processor within a telecommunications subnetwork. The method comprises: generating a source internal baseband processor identifier; generating a target internal baseband processor identifier; generating a source configuration transfer message, the source configuration transfer message including the source internal baseband processor identifier and the target internal baseband processor identifier; sending the source configuration transfer message to a mobility management entity; intercepting the source configuration transfer message to the mobility management entity; extracting the source internal baseband processor identifier and the target internal baseband identifier from the source configuration transfer message; generating a target configuration transfer message, the target configuration transfer message including the source internal baseband processor identifier and the target internal baseband processor identifier; and sending the target configuration transfer message to the target internal baseband processor.

[0010] Another aspect of the present invention relates to a method for handing over a call of a UE from an internal eNodeB within a telecommunications subnet to an external eNodeB. The method comprises: sending a handover requirement message, the handover requirement message comprising an internal eNodeB identifier and a target eNodeB identifier; intercepting the handover requirement message; replacing the internal eNodeB identifier with a virtual subnet eNodeB identifier to generate a subnet handover requirement message; sending the subnet handover requirement message to an MME; receiving a handover command from the MME; replacing the virtual subnet eNodeB identifier with the internal eNodeB identifier to generate a subnet handover command message; and sending the subnet handover command message to the internal eNodeB for transmission to the UE.

[0011] Another aspect of the present invention relates to a method for reconfiguring a telecommunications subnetwork. The method comprises: evaluating a need for connectivity within the telecommunications subnetwork; identifying a low-activity internal baseband processor; switching one or more UE connections from the low-activity internal baseband processor to one or more neighboring internal baseband processors; shutting down the low-activity internal baseband processor; and removing an internal eNodeB identifier and at least one cell ID corresponding to the low-activity internal baseband processor from a memory corresponding to an active internal baseband processor.

[0012] Another aspect of the present invention relates to a method for reconfiguring a telecommunications subnetwork. The method includes: evaluating demand for connectivity within the telecommunications subnetwork; identifying one or more high-demand internal baseband processors; instantiating a virtual internal baseband processor; allocating one or more cells to the virtual internal baseband processor; switching a UE connection from the one or more high-demand baseband processors to the virtual baseband processor; sending an initiation message, the initiation message including an internal identifier corresponding to the virtual baseband processor and one or more cell IDs; intercepting the initiation message; and retrieving and storing the internal identifier and the one or more cell IDs from the initiation message.

[0013] Another aspect of the present invention relates to a method for determining the location of an event within a venue. The method includes: intercepting a first plurality of call setup messages, each call setup message from one of a plurality of UEs; determining whether each call setup message within the first plurality of call setup messages corresponds to a voice call; determining a second plurality of call setup messages, wherein each of the second plurality of call setup messages corresponds to a voice call; retrieving a call setup message time corresponding to each of the second plurality of call setup messages; retrieving an internal baseband processor identifier from each of the second plurality of call setup messages; and identifying a cluster of call setup messages within the second plurality of call setup messages, wherein the cluster of call setup messages corresponds to a single eNodeB, and wherein the call setup time corresponding to each of the cluster of call setup messages occurs within a narrow time window. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 An exemplary private sub-network of an LTE base station according to the present disclosure is shown.

[0015] Figure 2 An exemplary process for configuring a private sub-network of an LTE base station according to the present disclosure is shown.

[0016] Figure 3 An exemplary process for a UE to establish a connection with an eNodeB inside a private sub-network is shown.

[0017] Figure 4 An exemplary process for establishing an X2 connection between two eNodeBs within a private sub-network according to the present disclosure is shown.

[0018] Figure 5 An exemplary process for performing an X2 handover between two eNodeBs within a private subnetwork is shown.

[0019] Figure 6An exemplary process for performing an S1 handover between an eNodeB inside a private sub-network to an eNodeB outside the private sub-network is shown.

[0020] Figure 7 An exemplary process for reconfiguring a private sub-network based on an increase or decrease in traffic demand is shown.

[0021] Figure 8 An exemplary process for a private subnetwork to interact with a positioning system implemented, for example, according to the LTE Positioning Protocol Annex (LPPa) is shown.

[0022] Fig. 9 An exemplary process is shown by which a private sub-network can identify patterns in call setup messages to identify a possible emergency and notify venue security personnel. DETAILED DESCRIPTION

[0023] Figure 1 An exemplary private sub-network (hereinafter referred to as sub-network 100) of an LTE base station according to the present disclosure is shown. Sub-network 100 includes: a connection aggregator (hereinafter referred to as S1-Conn 110); an operation and maintenance module 120; and a plurality of internal baseband processors (or internal eNodeBs 125), each of which has a corresponding supervision module 130, and each of which has one or more corresponding cells 135. Each internal eNodeB 125 is coupled to S1-Conn 110 via a corresponding internal S1 connection 140, which is a standard S1 connection defined in the LTE specification that is implemented between a conventional eNodeB and a conventional MME (Mobility Management Entity). Each supervision module 130 can be coupled to the operation and maintenance module 120 via a conventional IP connection 145.

[0024] S1-Conn 110 may be coupled to one or more MMEs 150 via corresponding external S1 connections 155. Each external S1 connection 155 may be identical to each internal S1 connection 140 in that they are both standard S1 connections defined in the LTE specifications.

[0025] Figure 1 Also shown is an external eNodeB 160 having at least one corresponding cell 165. The external eNodeB 160 may be coupled to one or more of the illustrated MMEs 150 via an S1 connection 170. Further shown is a UE 170, which may communicate with one or more of the cells 135 / 165.

[0026] The subnetwork 100 may be deployed or integrated, for example, in a dense urban environment or a large venue (e.g., a stadium, an airport, a shopping mall, a university campus, etc.). Each internal eNodeB 125 may correspond to a macro cell, a small cell, a femto cell, or a distributed antenna system (DAS). Each internal eNodeB 125 may have any number of cells 135.

[0027] Each individual internal eNodeB 125 may be individually implemented as a pure software-based virtual baseband processor that can be instantiated and de-instantiated as needed, or each may be individually implemented as a hardware-based baseband processor deployed in dedicated hardware adjacent to its corresponding RF and antenna components, or any combination of the above. Although LTE-specific terminology is used to refer to a given eNodeB 125, it may actually be implemented according to a different or legacy RAT technology as long as it communicates with the S1-Conn 110 via the S1 interface. As used herein, the terms "baseband processor" and "eNodeB" may be interchangeable.

[0028] S1-Conn 110 and operation and maintenance module 120 (and potentially, one or more of the internal eNodeBs 125) may be implemented in software that may be run in conventional server hardware located in a single location (e.g., one or more racks) within or near the site where subnetwork 100 is deployed or distributed in other ways. Purely software-based virtual baseband processors with internal eNodeBs 125 may have the following advantages: they are able to fully utilize the capabilities of subnetwork 100 to dynamically instantiate and de-instantiate internal eNodeBs 125 as business demand within the site fluctuates. In addition, having each internal eNodeB 125 implemented purely in software enables each internal eNodeB 125 to be manipulated in code to achieve interaction with its corresponding supervisory module 130 and easier configuration and maintenance from the operation and maintenance module 120. However, it should be understood that hardware-based internal eNodeBs 125 may be activated / deactivated to replace the instantiation / de-instantiation of virtual internal eNodeBs 125.

[0029] Figure 2 An exemplary process for configuring sub-network 100 according to the present disclosure is shown.

[0030] In step 205, S1-Conn 110 establishes an S1 interface with each of the MMEs 150. In doing so, S1-Conn 110 issues an S1 SETUP REQUEST message to each of the MMEs 150, each MME including its own 20-bit eNB ID (virtual subnetwork baseband processor identifier) ​​and all E-CGIs corresponding to each of the constituent cells of all internal eNodeBs 125. In response, each MME 150 may send a subsequent S1 SETUPRESPONSE message to S1-Conn 110, thereby establishing an external S1 connection 155 between S1-Conn 110 and each MME 150.

[0031] In step 210, each internal eNodeB 125 is started according to its nominal functionality. Each internal eNodeB 125 has the same 20-bit identifier and a plurality of assigned 8-bit sub-identifiers for each possible cell 135 that may correspond to that particular internal eNodeB 125. This information may be stored in a configuration file within each internal eNodeB 125 and may be provided by its corresponding supervisory module 130. Alternatively, configuration information about each internal eNodeB 125 may be stored in a distributed data source. Examples of these distributed data sources may include systems such as consul and etcd. Provided that all internal eNodeBs 125 have the same 20-bit identifier to uniquely identify each internal eNodeB 125, each may select an 8-bit cell identifier for its cell 135 (e.g., its first cell 135) and append it to its own 20-bit identifier, making it a 28-bit eNodeB identifier. The internal identifier may be the same as the identifier conventionally used for a home eNodeB (HeNB). This internal 28-bit eNodeB identifier may be referred to herein as the "internal identifier."

[0032] Once it has started, in step 215, each internal eNodeB 125 sets up an S1 connection with the S1-Conn 110 using its individual internal 28-bit eNodeB identifier. An example of how an internal eNodeB 125 can establish an S1 connection with an MME 150 is described in 3GPP TS 36.413. By doing so, a given internal eNodeB 125 behaves as if it is establishing an S1 connection with each MME 150. However, the S1-Conn 110 intercepts each S1 SETUP REQUEST from each internal eNodeB. The S1-Conn 110 uses this information to establish an S1 interface with each internal eNodeB 125, and then generates and issues an S1 SETUP RESPONSE message to each of the internal eNodeBs 125. By doing so, each of the internal eNodeBs 125 “thinks” that it has established an S1 interface with a single MME having many capabilities (in fact, the collective capabilities of the various MMEs 150 ), but what it has actually done is establish an internal S1 connection 140 with S1-Conn 110 .

[0033] In step 220, each internal eNodeB 125 sends an initiation message that will otherwise indicate to one or more MMEs 150 that it is operating. The initiation message will include its own identity and the cell identity of its corresponding cell 135. In an exemplary embodiment of process 200, each internal eNodeB 125 sends a PWSRestartIndication message, which is intercepted by S1-Conn 110. The PWSRestartIndication message (an example of which is described in 3GPP TS 36.413) includes the following information: an E-CGI (Enhanced Cell Global ID) corresponding to each cell of the sending internal eNodeB 125, a global eNB ID for the sending internal eNodeB 125 (which is its aforementioned internal 28-bit eNodeB identifier), a list of TAIs (Tracking Area Identifiers) for the corresponding cells of the internal eNodeB 125, and a list of Emergency Area IDs for the corresponding cells of the internal eNodeB 125.

[0034] It will be understood that the described functions performed by each internal eNodeB 125 may correspond to a sequence of computer instructions stored on a machine-readable memory assigned to or associated with each corresponding internal eNodeB 125 and executed by either a dedicated processor embedded in the corresponding eNodeB 125 or by a server processor or virtual machine generated in a cloud computing environment running on server hardware located in a premises of the sub-network 100 or elsewhere. The same is true for S1-Conn 110 and the operation and maintenance module 120. These components may include computer instructions that may be stored in non-volatile memory and executed on server computing hardware that may be located in, near, or distributed around the premises corresponding to the sub-network 100. Depending on the given subcomponents within each of these components, each of these components may be implemented by C, C++, Java, one or more scripting languages, or any combination thereof.

[0035] In step 225, S1-Conn 110 intercepts each PWSRestartIndication message from each internal eNodeB 125, and in step 230, creates a mapping of the following items for each internal eNodeB 125: its internal 28-bit eNodeB identifier, its constituent cell ID (E-CGI), and the rest of the information provided in its corresponding PWSRestartIndication message. Referring again to step 230, S1-Conn 110 assigns itself a 20-bit eNodeB ID common to all internal eNodeBs 125, extracts the constituent cell ID (E-CGI) and other information collected from each corresponding PWSRestartIndication message, and fills this information in a new "re-wrapped" PWSRestartIndication message. The 20-bit eNodeB ID assigned to S1-Conn 110 may be referred to as a virtual subnetwork baseband processor identifier.

[0036] In step 235 , the S1-Conn 110 sends its own PWSRestartIndication message assembled in step 225 to each corresponding MME 150 via its respective external S1 connection 155 .

[0037] Accordingly, even though each MME 150 is interacting exclusively with S1-Conn 110, each MME 150 will behave as if it is interacting with a single "giant" eNodeB with a potentially large number of aggregated cells 135 (potentially, as many as 256 cells). Furthermore, even though each internal eNodeB 125 is interacting exclusively with S1-Conn 110, it will behave as if it is interacting with any one of the MMEs 150. To accomplish this, S1-Conn 110 intercepts each subsequent message bidirectionally between a given MME 150 and the internal eNodeB 125, and also between the MME 150 and a given UE 170. S1-Conn 110 remaps the cell ID and other required information using, for example, a lookup table stored in a memory assigned to S1-Conn 110, re-wrappes the given message with the remapped information, and sends the re-wrapped message to its destination. For purposes herein, an internal eNodeB 125 that is the destination for an incoming message from a given MME 150 may be referred to as a message destination baseband processor.

[0038] The advantages of this operation include the following. First, any given (non-home) eNodeB has a 20-bit identifier, and provided that the cell ID for each eNodeB is an 8-bit identifier, up to 256 cells may have been assigned to it. However, in view of practical limitations in computing power, any given eNodeB typically has no more than twelve cells. The disclosed subnetwork 100 enables a given eNodeB (in this case, an S-Conn 110 that acts like a "giant" eNodeB) to use all 8 bits of the cell ID. This is because each internal eNodeB 125 has been assigned enough memory and computing resources (either in dedicated hardware or in the provided cloud computing resources) to handle the typical number of cells used.

[0039] Second, if the external network (e.g., from the MME 150 outward) is only aware of a single "giant" eNodeB covered by the functionality of S1-Conn 110, the number of internal eNodeBs 125 (and the subsequent number of cells 135) can be dynamically adjusted according to business needs. This may be extremely useful for venues (e.g., stadiums) that may be packed to capacity one day a week and quiet the rest of the time. In this case, internal eNodeBs 125 each with multiple corresponding cells 135 can be created and dispatched to handle changes in business needs so that all these changes are hidden from the external network.

[0040] It will be understood that the described functions performed by S1-Conn 110 further describe sequences of computer instructions stored on a machine-readable memory assigned to or associated with S1-Conn 110 and executed either by a dedicated processor or by a server processor or virtual machine generated in a cloud computing environment running on server hardware located within a premises in subnet 100 or elsewhere.

[0041] Figure 3 An exemplary process 300 for a UE 170 to establish a connection with an internal eNodeB 125 is shown.

[0042] In step 305, the UE 170 and the given internal eNodeB 125 exchange appropriate conventional signals to establish a connection. For example, the UE 170 may send an RRC Connection Request to the internal eNodeB 125, which may in turn respond with an RRC Connection Setup message, etc. As a result, the UE 170 is connected to the internal eNodeB 125, and the internal eNodeB 125 has established an internal identifier corresponding to the UE.

[0043] In sub-process 310, the internal eNodeB 125 establishes a default bearer with the MME 150 via S1-Conn 110. Figure 3 As shown, sub-process 310 includes several steps added to the default bearer establishment process specified in 3GPP TS 24.301, for example, steps 315, 320 and 325 describe modifications / enhancements to the conventional process described in the 3GPP technical specifications.

[0044] In step 315 , S1-Conn 110 intercepts a default bearer establishment message sent by internal eNodeB 125 , which includes a UE ID generated by internal eNodeB 125 .

[0045] In step 320, S1-Conn replaces the UE ID (generated by the internal eNodeB 125) and replaces it with a unique UE ID generated by S1-Conn 110. This is necessary because each of the internal eNodeBs 125 generates a UE ID without knowing the UE ID generated by any other internal eNodeB 125. There is a significant chance that two eNodeBs 125 generate a duplicate UE ID. Due to this possibility, S1-Conn replaces the UE ID generated by the internal eNodeB 125 with a unique value, re-encapsulates the message, and sends the message to the appropriate MME 150.

[0046] In step 325 , S1-Conn 110 intercepts the default bearer setup message from MME 150 to internal eNodeB 125 , remaps the UE ID, and sends the re-wrapped message to internal eNodeB 125 .

[0047] The intent is that a given internal eNodeB 125 is unaware that it is not interacting directly with the MME 150, and the MME 150 is unaware that it is not interacting directly with the internal eNodeB 125. In the former case, the S1-Conn 110 acts as the MME 150 for the internal eNodeB 125, while in the latter case, the S1-Conn 110 acts as the eNodeB interacting with the MME 150 (and the UE 170).

[0048] In sub-process 330, internal eNodeB 125 establishes a dedicated bearer with MME 150 via S1-Conn 110. Figure 3 As shown, sub-process 330 includes several steps added to the default bearer establishment process specified in 3GPP TS24.301. The steps required to establish a dedicated bearer can be substantially the same as steps 320 and 325 described above. As a result, there is at least one dedicated bearer established between UE 170 and MME 150, whereby S1-Conn 110 is acting as an invisible intermediary between internal eNodeB 120 and MME 150.

[0049] Figure 4 An exemplary process 400 for establishing an X2 connection between two internal eNodeBs 125 is shown.

[0050] In step 405, the UE 170 communicates with the source internal eNodeB 125 to which it is currently connected so that it has a strong signal from another internal eNodeB 125. The UE 170 does this by sending a measurement report to the source internal eNodeB 125, which identifies the neighboring internal eNodeBs 125 and cells 135 that the UE 170 is receiving strong signals from. Step 405 may be a conventional process, an example of which is described in 3GPP TS 36.300. Based on this information, the UE 170 identifies and recommends a target internal eNodeB 125 for handover.

[0051] In step 410, the source internal eNodeB 125 retrieves its own internal 28-bit identifier from internal memory. Recalling from step 210, each internal eNodeB has the same 20-bit eNodeB identifier by default. To prevent collisions within the subnetwork 100, the supervisory module 120 of each internal eNodeB instructs its corresponding internal eNodeB 125 to select an 8-bit identifier for one of its cells (e.g., the first cell) and append its own 20-bit identifier to the 8-bit identifier of its cell, creating a mis-homed eNodeB (HeNB) internal identifier for itself, referred to herein as the internal eNodeB identifier. Referring again to step 410, the source internal eNodeB 125 retrieves the E-CGI for the target cell identified by the UE (via the measurement report) and uses the 28-bit cell identifier corresponding to the target eNodeB.

[0052] In step 415, the source internal eNodeB 125 sends an eNBConfigurationTransfer command, which is conventionally sent to one of the MMEs 150. In the eNBConfigurationTransfer command, the source internal eNodeB 125 is identifying itself by its internal eNodeB identifier and the internal eNodeB identifier for the target internal eNodeB identifier.

[0053] In step 420, S1-Conn 110 intercepts the eNBConfigurationTransfer sent in step 415. In step 425, S1-Conn 110 extracts the internal eNodeB identifier of the source internal eNodeB 125 and the internal eNodeB identifier of the target internal eNodeB 125 (as well as other information in the eNBConfigurationTransfer command), and constructs an MMEConfigurationTransfer command through this information. And in step 430, S1-Conn sends the MMEConfigurationTransfer command to the target internal eNodeB 125.

[0054] With the configuration transfer complete, the source internal eNodeB 125 and the target eNodeB 125 can establish an X2 connection between them. In performing the steps of process 400, S1-Conn 110 is acting as an MME 150, so that neither the source internal eNodeB 125 nor the target eNodeB 125 is aware that they are not communicating directly with the MME 150. In addition, the MME 150 is not at any point involved in the process. This is because the MME 150 sees the S1-Conn 110 as a "giant" eNodeB, and therefore given only one eNodeB, there will be no X2 connection.

[0055] Figure 5 An exemplary process 500 for performing an X2 handover between two internal eNodeBs 125 is shown.

[0056] In step 505, UE 170 identifies target cell 135 and target internal eNodeB 125, and is informed of the source internal eNodeB 125 to which UE 170 is currently connected. This process may be substantially similar to step 405 of process 400.

[0057] In step 510 , the source internal eNodeB 125 forwards any data packets (downlink, and potentially uplink) corresponding to the UE 170 to the target internal eNodeB 125 over the X2 connection established in process 400 .

[0058] In step 515, the target internal eNodeB 125 sends a path switch request message to the relevant MME 150. The path switch request includes the TAI (Tracking Area Identity) of the target cell 135 of the target internal eNodeB 125 and the E-CGI of the target cell. S1-Conn 110 relays the message to the relevant MME 150.

[0059] In step 520, the target internal eNodeB 125 sends a release resources message to the source internal eNodeB 125 through their mutual X2 connection, thus completing the handover process of the UE 170 between the two internal eNodeBs 125 within the subnetwork 100 in a manner hidden from the external network.

[0060] Figure 6 An exemplary process 600 is shown for performing an S1 handover between an internal eNodeB 125 to an external eNodeB 160. This is for a scenario where a UE 170 is moving out of range of an internal eNodeB 125 of a sub-network 100. The steps of process 600 may be incorporated into an S1 based handover procedure.

[0061] In step 605, UE 170 identifies target cell 165 and target external eNodeB 160, and informs the source internal eNodeB 125 to which UE 170 is currently connected. This process may be substantially similar to step 405 of process 400 and step 505 of process 500.

[0062] In step 610, the source internal eNodeB 125 sends a Handover Required message to the relevant MME 150. In doing so, the source internal eNodeB 125 uses its internal eNodeB identifier in the message.

[0063] In step 615 , S1-Conn 110 intercepts the Handover Required message and re-encapsulates the message with its own 20-bit virtual sub-network baseband processor identifier and the E-CGI of the cell currently connecting UE 170 with the source internal eNodeB 125 , and sends the message to the relevant MME 150 .

[0064] In step 620, the MME 150 sends a handover command to the S1-Conn 110. It will be appreciated that the MME 150 behaves as if it is interacting with a regular eNodeB.

[0065] In step 625, S1-Conn 110 receives the handover command from MME 150 and remaps the eNB ID to the internal eNodeB identifier of source internal eNodeB 125, and sends the re-wrapped handover command to source internal eNodeB 125. Subsequently, in step 630, source internal eNodeB 125 sends the handover command to UE 170.

[0066] If any E-RAB (Evolved Radio Access Bearer) corresponding to UE 170 is configured for PDCP (Packet Data Convergence Protocol) reservation, the source internal eNodeB 125 may send an eNB state transfer message to the relevant MME 150. 110 may intercept the message, remap the information in the message to specify the virtual sub-network baseband processor identifier, re-encapsulate the message, and send it to the relevant MME 150 (source MME).

[0067] In step 635, the source MME 150 sends a UE context release command to the S1-Conn 110. In step 640, the S1-Conn 110 in turn remaps the eNB ID to the internal eNodeB identifier of the source internal eNodeB 125 and sends a message to the source internal eNodeB 125.

[0068] In step 645 , the source internal eNodeB 125 sends a UE context release complete message to the source MME 150 .

[0069] In step 650 , S1-Conn 110 intercepts the UE context release complete message, remaps the message to reflect the virtual sub-network baseband processor identifier, re-encapsulates the message, and sends it to the source MME 150 .

[0070] It will be appreciated that, as described in 3GPP TS 23.401, there are many steps of a conventional process for S1-based handover that occur, for example, between steps 615 and 620 and between steps 620 and 635. These steps occur in the external network (e.g., between the MME 150, S-GW and P-GW (not shown) and the external eNodeB 160). It should be appreciated that these external steps are known and fully described in the referenced 3GPP documents.

[0071] Accordingly, for external networks, the S1-based handover disclosed in process 600 involves a handover between a "giant" eNodeB represented by S1-Conn 110 and an external eNodeB 160. The internal workings of subnetwork 100 are hidden from external networks.

[0072] Figure 7 An exemplary process 700 is shown for reconfiguring subnetwork 100 based on an increase or decrease in traffic demand. This enables subnetwork 100 to expand and contract based on demand while hiding the changes to the subnetwork from the external network.

[0073] In step 705, the operation and maintenance module 120 can be combined with S1-Conn 110 to evaluate current business usage and demand. This may involve: analyzing historical usage data and extrapolating near-future demand. For example, if the subnetwork 100 is deployed in a stadium, the operation and maintenance module 120 may have stored a schedule of upcoming events in an accessible memory so that it can predict periods of high and low demand. For deployments in dense urban scenarios, for example, the operation and maintenance module 120 may have accumulated historical data on demand based on time of day, day of the week, holidays, and days with special events. In view of this, the operation and maintenance module 120 may be able to perform appropriate analysis to estimate current and near-future demand, and take action accordingly to provide cloud-based computing power for the virtual internal eNodeB 125, or power on / off the hardware-based internal eNodeB 125.

[0074] Additionally, the virtual eNodeB 125 may employ a 3GPP-specified mechanism regarding evaluating (i.e., determining) demand, including: setting a configurable threshold, and comparing the actual demand with the threshold. The eNodeB 125 may then send the result of the comparison to the operation and maintenance module 120. The operation and maintenance module 120 may then further determine whether the demand has fallen below a low threshold (e.g., 5% of the configured maximum capacity) or whether the demand has gone above a high threshold (e.g., 95% of the configured maximum capacity). Alternatively, if either threshold has been exceeded, each of the eNodeBs may make the above-mentioned further determinations and send an alarm signal, etc. to the operation and maintenance module 120. The mechanism may use a standard PM-Stat file (performance measurement) generated every 15 minutes and sent to the core network via a northbound interface (not shown) also specified by 3GPP. It will be understood that these variations are possible and within the scope of the present disclosure.

[0075] Depending on the results of the evaluation performed in step 705, process 700 may also take no action ( Figure 7 ); it may adopt sub-process path 701, wherein the operation and maintenance module 120 may increase the capacity of the sub-network 100 by adding one or more internal eNodeBs 125; or it may adopt sub-process path 702, wherein the operation and maintenance module 120 may reduce the capacity by removing one or more internal eNodeBs 125.

[0076] With respect to sub-process path 701, if in the evaluation in step 705, the operation and maintenance module 120 determines that additional capacity is needed, the operation and maintenance module 120 may proceed to step 710 and execute instructions to identify where one or more additional internal eNodeBs 125 are needed within the sub-network 100. For example, this may include: determining the location of the internal eNodeBs 125 with the greatest demand; and determining the availability of nearby remote radio units and antenna hardware.

[0077] In step 715, the operation and maintenance module 120 executes instructions to start one or more new internal eNodeBs 125. By doing so, the operation and maintenance module 120 can execute instructions to cause the local server hardware to instantiate one or more software-based virtual baseband processors and / or power up one or more dormant hardware-based base stations.

[0078] In step 720, the operation and maintenance module 120 may issue an instruction to the S1-Conn 110 to instruct the currently operating high-demand internal eNodeB 125 to switch the UE connection to the recently introduced new internal eNodeB 125. This operation may be done alternatively, whereby the operation and maintenance module 120 may issue an instruction to the appropriate supervisory module 130 via the IP connection 145 to cause the corresponding internal eNodeB 125 to perform the UE connection switch.

[0079] In the case where a new eNodeB 125 is up and running, it is necessary to update the identifier mapping information within S1-Conn 110. Accordingly, in step 725, the newly online internal eNodeBs 125 may each issue a PWSRestartIndication message (or similar initiation message) indicating their internal eNodeB identifier and constituent cell IDs.

[0080] In step 730, S1-Conn 110 intercepts one or more PWSRestartIndication messages, one each from each newly online internal eNodeB 125, extracts the internal eNodeB identifier and corresponding cell ID, and adds this information to the pre-existing mapping that S1-Conn 110 stored in its memory.

[0081] In step 735, S1-Conn may issue its own PWSRestartIndication to one or more MMEs 150, similar to step 235 in process 200. In this case, the external network is unaware of the addition of the new internal eNodeB 125. Instead, it is only aware of a single "giant" eNodeB with one or more additional cells.

[0082] With respect to sub-process path 702, if in the evaluation in step 705, the operations and maintenance module 120 determines that the sub-network 100 has excess capacity, the operations and maintenance module 120 may proceed to step 750 and execute instructions to identify locations within the sub-network 100 where one or more additional internal eNodeBs 125 are to be shut down. This may include determining locations of internal eNodeBs 125 that have insufficient demand and internal identifiers of neighboring eNodeBs 125 that may be available for handover.

[0083] In step 755, the operation and maintenance module 120 may execute instructions to instruct the internal eNodeB 125 designated to be shut down to switch the UE connection to another neighboring eNodeB that can serve these UEs 170. As in step 720, this operation may be performed in one or more ways: the operation and maintenance module 120 issues an instruction to the S1-Conn 110 to indicate the switch, or the operation and maintenance module 120 issues an instruction to the relevant supervision module 130 to implement the switch. It will be understood that these variations are possible and within the scope of the present disclosure.

[0084] In step 760, the operation and maintenance module 120 may shut down the internal eNodeB 125 specified in step 750. In the case of a software-based virtual internal eNodeB 125, this may involve terminating the corresponding virtual machine running on the server hardware of the sub-network. Alternatively (or additionally), this may involve powering off the appropriate hardware-based base station. The operation and maintenance module 120 may do this by issuing a command to the relevant supervisory module 130.

[0085] In step 765, S1-Conn 110 executes instructions to remove the terminated internal eNodeB identifier and corresponding cell ID from its memory. Sub-process path 702 then proceeds to step 735. In step 735, S1-Conn 110 issues a new PWSRestartIndication with a revised list of cell IDs (minus the cell ID corresponding to the terminated internal eNodeB 125).

[0086] The ability of S1-Conn 110 to intercept messages, remap information within the messages, repackage the messages, and send messages between the internal eNodeBs 125 and the MME 150 enables other capabilities. For example, S1-Conn 110 can identify patterns in messages from the internal eNodeBs and derive location information from one or more of the UEs 170 connected to them.

[0087] Figure 8 Two exemplary processes 800 are shown by which S1-Conn 110 processes location-related information according to the LTE Positioning Protocol Annex (LPPa) between an E-SMLC (Evolved Serving Mobile Location Center) 801 and an internal eNodeB 125 and a UE 170, respectively. The E-SMLC 801 may be coupled to the subnetwork 100 via one of the MMEs 150. The connection between the MME 150 and the E-SMLC 801 may be through the SL interface, as specified in 3GPP TS 23.271. Details on LPPa may be found in 3GPP TS 36.455.

[0088] Through process 800, the E-SMLC 801 interacts with the eNodeBs according to the LPPa process, but except for the intervention of S1-Conn 110, it causes the E-SMLC to operate as if it were interacting with a single "giant" eNodeB of S1-Conn 110 that actually acts as a proxy for the internal eNodeBs 125 within the subnetwork 100 as described above.

[0089] In step 805, the E-SMLC 801 issues a request / command to the eNodeB simulated by the S1-Conn 110. In this case, the E-SMLC 801 is not aware of the internal eNodeB 125 of the sub-network 100 and only interacts with the S1-Conn 110. The request / command may include, for example, an E-CID (Enhanced Cell ID) MEASUREMENT INITIATION REQUEST, an E-CID MEASUREMENT TERMINATION COMMAND, an OTDOA (Observed Time Difference of Arrival) INFORMATION REQUEST, etc. Note that in these interactions, the S1-Conn 110 will report a predetermined location, which may or may not be the actual location of the S1-Conn 110 instantiation. For example, if the sub-network 100 is deployed in a venue such as a stadium or an airport, the location reported by the S1-Conn 110 may be the location of the security room or its main entrance of the venue, etc. Alternatively, S1-Conn 110 may return a list of locations, one for each cell 135 within the subnetwork 100.

[0090] In step 810 , S1-Conn 110 receives and processes the request / command, and in step 820 , S1-Conn 110 encapsulates a response and sends it to E-SMLC 801 .

[0091] Fig. 9 An exemplary process 900 is shown by which S1-Conn 110 can selectively intercept requests from multiple UEs 170 connected to one or more eNodeBs 125 of a subnetwork 100 and take action to intervene and notify relevant persons / entities related to the location of abnormal behavior between connected or connecting UEs 170.

[0092] In step 905, multiple UEs 170 initiate calls via VoIP or CS fallback to a 3G / 2G cell (not shown). These calls may be initiated via one internal eNodeB 125 or two or more adjacent internal eNodeBs 125.

[0093] In step 910, S1-Conn 110 intercepts the call initiation message. In the case of VoIP, S1-Conn 110 retrieves the QCI (QoS Class Identifier) ​​from each message. If the QCI is equal to 1, the bearer to be established is identified as corresponding to a voice call. Alternatively, if the QCI is equal to 5, the message corresponds to IMS (IP Multimedia Subsystem) signaling used to establish and release VoIP connections. Like any message, S1-Conn 110 remaps the eNodeB cell ID with its virtual subnet baseband processor identifier, re-encapsulates the message, and sends it to the intended MME 150. With each identified VoIP call initiation, S1-Conn 110 can execute instructions to log relevant information corresponding to the call initiation (e.g., UE identifier, internal eNodeB identifier, 28-bit cell identifier (ECGI), S-TMSI (SAE Temporary Mobile Subscriber Identity), message reception time, etc.).

[0094] In step 915, S1-Conn 110 stores the information related to the call setup event in step 910. Further to step 915, S1-Conn 110 may execute instructions to identify a pattern including a call pattern history as a function of time. If in the process of executing these instructions, S1-Conn 110 may identify anomalies in call setup (e.g., a sudden surge in call setup messages from UEs 170 connected to multiple neighboring cells 135 of a given internal cell 135 or a single eNodeB 125, or isolated instances of a large number of UEs 170 initiating calls simultaneously within a single cell 135). As used herein, "simultaneously" may imply an event within a single narrow time window (e.g., 1 second, 5 seconds, etc.) at a location corresponding to the antenna of the relevant cell 135. In this case, S1-Conn 110 may store multiple identifiers that each correspond to the UEs 170 identified within the cluster.

[0095] In step 920, S1-Conn 110 may instruct the relevant internal eNodeB 125 to provide the most recent timing advance value corresponding to each UE identified in step 915. Subsequently, in step 925, the relevant internal eNodeB 125 may provide the requested timing advance information corresponding to each UE 170 identified in step 915.

[0096] In step 930, once S1-Conn 110 has received these values, it may execute instructions to determine whether the timing advance values ​​are sufficiently clustered to indicate whether the call setup procedures performed by the related UEs can respond to an event at their common location. It will be appreciated that by doing so, S1-Conn 110 may execute instructions corresponding to one or more known clustering algorithms. If the clustering calculated in step 920 indicates a possible event, S1-Conn 110 may send instructions to the neighboring internal eNodeBs 125 to determine the timing advance values ​​for each of the related UEs 170 and provide them to S1-Conn 110. S1-Conn 110 may then determine the location of the cluster of UEs 170 based on triangulation.

[0097] In step 935, if S1-Conn 110 identifies a cluster of timing advance values ​​for the associated UE 170 (regardless of whether it executes instructions to determine the cluster location via triangulation), S1-Conn 110 may execute instructions to send a message to a predetermined entity within the premises of subnetwork 100. Examples of predetermined entities may include customer offices (e.g., security offices).

Claims

1. A method for reconfiguring a telecommunications subnetwork, comprising: assessing demand for connectivity within the telecommunications subnetwork; identifying low activity internal baseband processors based on the evaluation of connectivity requirements within the telecommunications subnetwork; Connecting to one or more UEs connected to the low-activity internal baseband processor, and receiving identification information of one or more adjacent internal baseband processors; switching a UE connected to one or more UEs from the low activity internal baseband processor to one or more of the neighboring internal baseband processors based on the received information; shutting down the low activity internal baseband processor; as well as removing, from a memory corresponding to an active internal baseband processor, an internal eNodeB identifier and at least one cell ID corresponding to the low-activity internal baseband processor; Wherein, evaluating the demand for connectivity within the telecommunications subnetwork includes: The connection demand for the internal baseband processor is compared to a preconfigured threshold reflecting a low activity condition.

2. The method of claim 1, wherein: The threshold reflecting a low activity condition is based on a percentage of maximum capacity.

3. The method according to claim 1 or 2, wherein: The threshold reflecting a low activity condition is configurable.

4. The method of claim 1, wherein: Comparing the connection demand of the internal baseband processor to a threshold reflecting the low activity condition includes comparing an actual connection demand of the internal baseband processor to the threshold reflecting the low activity condition.

5. The method of claim 1, wherein: Further comprising: sending an alarm signal based on identifying a low activity internal baseband processor.

6. A system comprising use of the method according to any one of claims 1 to 5.

7. A method for reconfiguring a telecommunications subnetwork, comprising: assessing demand for connectivity within the telecommunications subnetwork; identifying one or more high demand internal baseband processors based on the evaluation of demand for connectivity within the telecommunications subnetwork; Instantiate a virtual internal baseband processor; assigning one or more cells to the virtual internal baseband processor; switching a UE connection from the one or more high demand baseband processors to the virtual internal baseband processor; sending an initiation message, the initiation message including an internal identifier corresponding to the virtual internal baseband processor and one or more cell IDs; intercepting the initiation message; as well as retrieving and storing the internal identifier and the one or more cell IDs from the initiation message; Wherein, evaluating the demand for connectivity within the telecommunications subnetwork includes: The connection demand on the internal baseband processor is compared to a preconfigured threshold reflecting a high demand condition.

8. The method of claim 7, wherein: The threshold reflecting a high demand condition is based on a percentage of maximum capacity.

9. The method according to claim 7 or 8, wherein: The threshold reflecting high demand conditions is configurable.

10. The method of claim 7, wherein: Comparing the connection demand of the internal baseband processor to a threshold reflecting a high demand condition includes comparing an actual connection demand of the internal baseband processor to the threshold reflecting a high demand condition.

11. The method of claim 7, wherein: Further comprising: sending an alarm signal based on identifying high activity internal baseband processor.

12. The method of claim 7, further comprising: Identify where within the sub-network a virtual internal baseband processor is required.

13. The method of claim 12, wherein identifying a location within a sub-network where a virtual internal baseband processor is needed comprises: determining a location of the one or more high demand internal baseband processors; Determine the availability of attached remote radio units and antenna hardware.

14. A system comprising use of the method according to any one of claims 7 to 13.

15. A method for reconfiguring a telecommunications subnetwork, comprising: assessing demand for connectivity within the telecommunications subnetwork; identifying a high demand internal baseband processor based on the evaluation of demand for connectivity within the telecommunications subnetwork; Instantiate a virtual internal baseband processor; assigning a cell to the virtual internal baseband processor; Switching the UE connection from the high demand baseband processor to the virtual internal baseband processor; sending an initiation message, the initiation message including an internal identifier corresponding to the virtual internal baseband processor and a cell ID; Wherein, evaluating the demand for connectivity within the telecommunications subnetwork includes: The connection demand on the internal baseband processor is compared to a preconfigured threshold reflecting a high demand condition.

16. The method of claim 15, wherein: The threshold reflecting high demand conditions is configurable.

17. The method according to any one of claims 15 or 16, wherein: Comparing the connection demand of the internal baseband processor to a threshold reflecting a high demand condition includes comparing an actual connection demand of the internal baseband processor to the threshold reflecting a high demand condition.

18. The method of claim 15, wherein: Further comprising: sending an alarm signal based on identifying high activity internal baseband processor.

19. The method of claim 15, further comprising: Identify where within the sub-network a virtual internal baseband processor is required.

20. The method of claim 19, identifying where a virtual internal baseband processor is needed within a sub-network comprises: Identify the location of one or more high-demand internal processors; Determine the availability of attached remote radio units and antenna hardware.

21. A system comprising use of the method according to any one of claims 15-20.

Images