阅读说明：本技术 用于创建并管理lte基站的私有子网络的系统和方法 (System and method for creating and managing private sub-networks of LTE base stations ) 是由 杰弗里·迈克尔·库林顿 维沙尔·阿格拉沃尔 萨斯·埃斯瓦尔卡瓦 马西莫·诺塔尔贾科莫 斯蒂芬 于 2019-08-22 设计创作，主要内容包括：公开一种用于在更大电信网络内创建并维护电信基站的虚拟子网络的系统和方法。在基于LTE的示例中,所述子网络包括连接聚合器,其耦合在所述子网络内部的多个eNodeB与外部网络中的一个或多个MME之间。所述连接聚合器拦截MME与内部eNodeB之间的所有控制平面消息,重新映射eNodeB标识符,并发送重新包封的消息,以使得外部网络将整个子网络视为单个“巨型”eNodeB。所公开的系统和方法使得虚拟子网络的运营商能够随着连接性需求的波动而添加和关闭eNodeB,并且能够这样做以使得所有改变不为外部网络所见。(A system and method for creating and maintaining a virtual sub-network of telecommunications base stations within a larger telecommunications network is disclosed. In an LTE-based example, the sub-network includes a connection aggregator coupled between a plurality of enodebs internal to the sub-network and one or more MMEs in external networks. The connection aggregator intercepts all control plane messages between the MME and the internal enodebs, remaps the eNodeB identifiers, and sends the re-encapsulated messages so that the external network sees the entire subnetwork as a single "giant" eNodeB. The disclosed systems and methods enable operators of virtual sub-networks to add and shut down enodebs as connectivity requirements fluctuate, and to do so that all changes are not seen by external networks.)

1. A telecommunications system, comprising:

a plurality of internal baseband processors; and

a connection aggregator operably 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,

and wherein the connection aggregator is configured to: intercepting an outgoing message from an internal baseband processor that is one of the plurality of internal baseband processors, replacing an internal identifier of the internal baseband processor within the outgoing message with a virtual sub-network baseband processor identifier, and transmitting a modified outgoing message,

and wherein the connection aggregator is configured to: intercepting an incoming message destined for a destination internal baseband processor that is one of the plurality of internal baseband processors, replacing the virtual sub-network baseband processor identifier within the incoming message with an internal identifier of the destination internal baseband processor to create a modified incoming message, and sending the modified incoming message to the destination internal baseband processor.

2. The telecommunications system of claim 1, wherein the connection aggregator is further configured to:

intercepting an outgoing message from a second internal baseband processor that is one of the plurality of internal baseband processors, replacing an internal identifier of the second internal baseband processor within the outgoing message with the virtual sub-network baseband processor identifier, and transmitting a modified outgoing message, an

Intercepting an incoming message destined for a second destination internal baseband processor that is one of the plurality of internal baseband processors, replacing the virtual sub-network baseband processor identifier within the incoming message with an internal identifier of the second destination internal baseband processor to create a modified incoming message, and sending the modified incoming message to the second destination internal baseband processor.

3. The telecommunications system as set forth in claim 2,

wherein the connection aggregator is further configured to: sending the modified outgoing message from the internal baseband processor and the modified outgoing message from the second internal baseband processor, both including the virtual sub-network baseband processor identifier, to a Mobility Management Entity (MME), and

wherein the connection aggregator is further configured to: receiving, from an MME, the incoming message for the destination internal baseband processor and an incoming message for the second destination internal baseband processor, both including the virtual sub-network baseband processor identifier.

4. The telecommunications system of claim 1, wherein each of the plurality of internal baseband processors includes an internal eNodeB.

5. The telecommunications system of claim 4, in which the internal eNodeBs comprise virtual eNodeBs.

6. The telecommunications system of claim 5, wherein the virtual eNodeB includes a supervisor module.

7. The telecommunications system of claim 6, further comprising an operation maintenance module coupled to each of the supervisor modules.

8. The telecommunications system of claim 4, wherein each internal identifier comprises a 28-bit internal eNodeB identifier.

9. The telecommunications system of claim 8, wherein the 28-bit internal eNodeB identifier corresponds to a 28-bit cell identity of a cell of the internal eNodeB.

10. The telecommunications system of claim 8, wherein the virtual sub-network baseband processor identifier includes 20 bits, wherein the 20 bits are the same as the first 20 bits of the 28-bit internal eNodeB identifier.

11. A method for configuring a telecommunications subnetwork, comprising:

intercepting a plurality of messages, each of the plurality of messages from a corresponding one of a plurality of internal baseband processors in the subnet;

extracting an internal baseband processor identifier and one or more cell IDs from each intercepted message;

assigning each internal baseband processor identifier and corresponding one or more cell IDs to a memory; and

transmitting a subnet message, wherein the subnet message corresponds to a plurality of intercepted messages, and wherein the subnet message comprises a virtual subnet baseband processor identifier and the one or more cell IDs from the plurality of intercepted messages.

12. The method of claim 11, wherein each of the plurality of messages is a Public Warning System (PWS) restart indication message.

13. The method of claim 11, wherein each of the plurality of messages is an origination message.

14. The method of claim 11, further comprising:

generating the virtual sub-network baseband processor identifier included in the sub-network message.

15. A method for establishing a connection between a source internal baseband processor and a target internal baseband processor within a telecommunications subnetwork, comprising:

generating a source internal baseband processor identifier;

generating a target internal baseband processor identifier;

generating a source configuration transfer message comprising 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 destined for 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 comprising 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.

16. The method of claim 15, wherein the source configuration transfer message comprises an eNB configuration transfer message.

17. The method of claim 15, wherein the target configuration transfer message comprises a MIME configuration transfer message.

18. The method of claim 15, wherein the generating a source internal baseband processor identifier comprises: generating a 28-bit internal identifier, wherein the 28-bit internal identifier comprises a 20-bit eNodeB identifier and an 8-bit identifier corresponding to a cell of the source internal baseband processor.

19. The method of claim 15, wherein the generating a target internal baseband processor identifier comprises: a 28-bit cell identifier is retrieved from the measurement report.

20. A method for handing over a call of a UE from an internal eNodeB to an external eNodeB within a telecommunications subnetwork, comprising:

sending a handover required message, the handover required message comprising an internal eNodeB identifier and a target eNodeB identifier;

intercepting the switching requirement message;

replacing the internal eNodeB identifier with a virtual sub-network eNodeB identifier to generate a sub-network handover required message;

sending the sub-network switching requirement message to MME;

receiving a handover command from the MIME;

replacing the virtual sub-network eNodeB identifier with the internal eNodeB identifier to generate a sub-network handover command message; and

sending the sub-network handover command message to the internal eNodeB for transmission to the UE.

21. The method of claim 20, further comprising:

receiving a UE context release command message from the MME;

replacing the virtual sub-network eNodeB identifier with the internal eNodeB identifier to generate a sub-network UE context release command message; and

sending the sub-network UE context release order message to the internal eNodeB.

22. A method for reconfiguring a telecommunications subnetwork, comprising:

assessing a need for connectivity within the telecommunications sub-network;

identifying a low activity internal baseband processor based on the evaluation of connectivity requirements within the telecommunications subnetwork;

switching one or more UE connections from the low activity internal baseband processor to one or more neighboring internal baseband processors;

turning off 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.

23. The method of claim 22, wherein evaluating the need for connectivity within the telecommunications subnetwork comprises:

the demand for the internal baseband processor is compared to a preconfigured threshold that reflects a low activity condition.

24. The method of claim 23, wherein the threshold reflecting a low activity condition is based on a percentage of maximum capacity.

25. A method for reconfiguring a telecommunications subnetwork, comprising:

assessing a need for connectivity within the telecommunications sub-network;

identifying one or more high demand internal baseband processors based on the evaluation of demand for connectivity within the telecommunications subnetwork;

instantiating 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 baseband processor;

transmitting an 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.

26. The method of claim 25, wherein evaluating the need for connectivity within the telecommunications subnetwork comprises:

the demand for the internal baseband processor is compared to a preconfigured threshold that reflects a high demand condition.

27. The method of claim 26, wherein the threshold reflecting a high demand condition is based on a percentage of maximum capacity.

Technical Field

The present invention relates to wireless communication base stations, and more particularly, to a system and method for creating private subnetworks for LTE base stations in large scale venue and urban scenarios.

Prior Art

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

The disadvantages of the current state are: currently, there is no way for any party deploying an eNodeB network to reconfigure or redesign the eNodeB network without it affecting the entire network. Currently, a party cannot deploy an LTE sub-network in such a way that the internal workings of the LTE sub-network are hidden from the larger network.

Another disadvantage of the current state is as follows. A given eNodeB is identified by a 20-bit identifier (eNB ID). Each eNodeB can support up to 256 cells, where each cell is identified by a global cell identifier (E-CGI) attached in a unique 8-bit pattern after a 20-bit eNB ID. While each eNodeB can 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 leads to inefficient use of the E-CGI address space.

Accordingly, there is a need for a system and method for creating and maintaining an LTE private sub-network whereby the sub-network is treated by a larger network as a single eNodeB, wherein the complexity of the sub-network is hidden from the larger network, and wherein the sub-network can be redesigned and/or dynamically reconfigured as needed in a manner transparent to the larger network, and wherein the eNodeB can leverage the capability to serve up to 256 cells.

Background

Disclosure of Invention

One aspect of the 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: intercepting an outgoing message from an internal baseband processor, replacing an internal identifier of the internal baseband processor within the outgoing message with a virtual sub-network baseband processor identifier, and sending a modified outgoing message. The connection aggregator is further configured to: intercepting an incoming message destined for a destination internal baseband processor, replacing the virtual sub-network baseband processor identifier within the incoming message with a destination internal identifier to create a modified incoming message, and sending the modified incoming message to the destination internal baseband processor.

Another aspect of the invention relates to a method for configuring a telecommunications sub-network. The method comprises the following steps: intercepting a plurality of PWS restart indication messages, each of the plurality of PWS restart messages being from an internal eNodeB; extracting an internal eNodeB identifier and one or more cell IDs from each intercepted PWS restart indication message; assigning each internal eNodeB identifier and corresponding one or more cell IDs to a memory; and sending a sub-network PWS restart indication message. The sub-network PWS restart indication message includes a virtual sub-network baseband processor identifier and one or more cell IDs from the plurality of PWS restart indication messages.

Another aspect of the invention relates to a method for configuring a telecommunications sub-network. The method comprises the following steps: intercepting a plurality of initiation messages from a corresponding plurality of 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 origination message; storing each internal identifier and each at least one cell ID in a memory; generating a virtual sub-network baseband processor identifier; and transmitting a subnet initiation message, wherein the subnet initiation message includes the virtual subnet baseband processor identifier and each one or more cell IDs.

Another aspect of the 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 the following steps: generating a source internal baseband processor identifier; generating a target internal baseband processor identifier; generating a source configuration transfer message comprising 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 destined for 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 comprising 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.

Another aspect of the invention relates to a method for handing over a call of a UE from an internal eNodeB within a telecommunications sub-network to an external eNodeB. The method comprises the following steps: sending a handover required message, the handover required message comprising an internal eNodeB identifier and a target eNodeB identifier; intercepting the switching requirement message; replacing the internal eNodeB identifier with a virtual sub-network eNodeB identifier to generate a sub-network handover required message; sending the sub-network switching requirement message to MME; receiving a handover command from the MME; replacing the virtual sub-network eNodeB identifier with the internal eNodeB identifier to generate a sub-network handover command message; and sending the sub-network handover command message to the internal eNodeB for transmission to the UE.

Another aspect of the invention relates to a method for reconfiguring a telecommunications sub-network. The method comprises the following steps: assessing a need for connectivity within the telecommunications sub-network; 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; turning off the low activity internal baseband processor; and removing the internal eNodeB identifier and at least one cell ID corresponding to the low activity internal baseband processor from the memory corresponding to the active internal baseband processor.

Another aspect of the invention relates to a method for reconfiguring a telecommunications sub-network. The method comprises the following steps: assessing a need for connectivity within the telecommunications sub-network; identifying one or more high demand internal baseband processors; instantiating 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 baseband processor; transmitting an 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.

Another aspect of the invention relates to a method for determining a location of an event within a venue. The method comprises the following steps: 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.

Drawings

Fig. 1 shows an exemplary private sub-network of an LTE base station according to the present disclosure.

Fig. 2 illustrates an example process for configuring a private sub-network of an LTE base station according to this disclosure.

Fig. 3 shows an exemplary procedure for a UE to establish a connection with an eNodeB inside a private sub-network.

Fig. 4 illustrates an exemplary process for establishing an X2 connection between two enodebs within a private sub-network in accordance with the present disclosure.

Fig. 5 shows an exemplary procedure for performing an X2 handover between two enodebs that are inside a private sub-network.

Fig. 6 shows an exemplary procedure for performing an S1 handover between an eNodeB inside a private sub-network to an eNodeB outside the private sub-network.

Fig. 7 illustrates an exemplary process for reconfiguring a private sub-network based on an increase or decrease in traffic demand.

Fig. 8 illustrates an exemplary procedure for a private sub-network to interact with a positioning system, e.g., implemented according to LTE positioning protocol annex (LPPa).

Figure 9 illustrates an exemplary process by which a private sub-network may identify a pattern of call setup messages to identify a possible emergency and notify venue safety personnel.

Detailed Description

Fig. 1 shows an exemplary private sub-network (hereinafter sub-network 100) of an LTE base station according to the present disclosure. The sub-network 100 comprises: connecting aggregators (hereinafter referred to as S1-Conn 110); a maintenance module 120; a plurality of internal baseband processors (or internal enodebs 125), each of which has a corresponding supervisory module 130, and each of which has one or more corresponding cells 135. Each internal eNodeB125 is coupled to the S1-Conn110 by a respective internal S1 connection 140, which internal S1 connection 140 is a standard S1 connection defined in the LTE specifications that would be implemented between a conventional eNodeB and a conventional MME (mobility management entity). Each supervisor module 130 may be coupled to the operation and maintenance module 120 by a conventional IP connection 145.

The S1-Conn110 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, as they are standard S1 connections defined in the LTE specifications.

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

The sub-network 100 may be deployed or integrated, for example, in a dense urban environment or in a large venue (e.g., a stadium, airport, shopping mall, college campus, etc.). Each internal eNodeB125 may correspond to a macrocell, a small cell, a femtocell, or a Distributed Antenna System (DAS). Each interior eNodeB125 may have any number of cells 135.

Each individual internal eNodeB125 may be implemented individually as a pure software-based virtual baseband processor that may be instantiated and de-instantiated as needed, or may each be implemented individually as a hardware-based baseband processor deployed in dedicated hardware proximate to its corresponding RF and antenna components, or any combination thereof. Although LTE-specific terminology is used to refer to a given eNodeB125, it may in fact be implemented according to a different or legacy RAT technology as long as it communicates with the S1-Conn110 via an S1 interface. As used herein, the terms "baseband processor" and "eNodeB" may be interchangeable.

S1-Conn110 and the operation and maintenance module 120 (and potentially one or more of the internal enodebs 125) may be implemented in software that may run in conventional server hardware located in a single location (e.g., one or more racks) or otherwise distributed within or near the site where the subnetwork 100 is deployed. A pure software based virtual baseband processor with an internal eNodeB125 may have the following advantages: they can leverage the capabilities of the sub-network 100 to dynamically instantiate and de-instantiate the internal enodebs 125 as traffic demand within the site fluctuates. Furthermore, having each internal eNodeB125 implemented purely in software enables each internal eNodeB125 to manipulate in code to enable interaction with its corresponding supervisor module 130 and easier configuration and maintenance from the operation and maintenance module 120. However, it should be understood that the hardware-based internal enodebs 125 may be activated/deactivated instead of the instantiation/de-instantiation of the virtual internal enodebs 125.

Fig. 2 illustrates an exemplary process for configuring a sub-network 100 according to the present disclosure.

In step 205, S1-Conn110 establishes an S1 interface with each of the MMEs 150. By doing so, the S1-Conn110 issues an S1 SETUP REQUEST message to each of the MMEs 150, each MME including its own 20-bit eNB ID (virtual sub-network 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 SETUP RESPONSE message to the S1-Conn110, thereby establishing an external S1 connection 155 between the S1-Conn110 and each MME 150.

In step 210, each internal eNodeB125 starts according to its nominal function. Each internal eNodeB125 has the same 20-bit identifier and multiple 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 eNodeB125 and may be provided by its corresponding supervisor module 130. Alternatively, the configuration information for each internal eNodeB125 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 eNodeB125, each can select the 8-bit cell identifier of its cell 135 (e.g., its first cell 135) and attach it to its own 20-bit identifier, making it a 28-bit eNodeB identifier. The internal identifier may be the same as that conventionally used for home enodebs (henbs). This inner 28-bit eNodeB identifier may be referred to herein as an "inner identifier".

Once it has started, in step 215 each internal eNodeB125 uses its individual internal 28-bit eNodeB identifier setting to connect with S1 of S1-Conn 110. An example of how an internal eNodeB125 may establish an S1 connection with an MME 150 is described in 3GPP TS 36.413. By doing so, a given internal eNodeB125 acts as if it is establishing an S1 connection with each MME 150. However, the S1-Conn110 intercepts each S1 SETUP REQUEST from each internal eNodeB. The S1-Conn110 uses this information to establish an S1 interface with each internal eNodeB125, 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 that has many capabilities (in effect, the collective capabilities of the MMEs 150), but what it has actually done is to establish an internal S1 connection 140 with the S1-Conn 110.

In step 220, each internal eNodeB125 sends an initiation message that would otherwise indicate to one or more MMEs 150 that it is functioning. The initiation message will include its own identity and the cell identity of its corresponding cell 135. In the exemplary embodiment of process 200, each internal eNodeB125 sends a PWSRestartIndication message, which is intercepted by S1-Conn 110. The pwsrestindication message (an example of which is described in 3gpp ts 36.413) includes the following information: E-CGI (enhanced cell global ID) corresponding to each cell transmitting the internal eNodeB125, global eNB ID for transmitting the internal eNodeB125, which is its aforementioned internal 28-bit eNodeB identifier, TAI (tracking area identifier) list of corresponding cells for the internal eNodeB125, and emergency area ID list of corresponding cells for the internal eNodeB 125.

It will be understood that the described functions performed by each internal eNodeB125 may correspond to a sequence of computer instructions stored on a machine-readable memory assigned to or associated with each corresponding internal eNodeB125 and executed either by a dedicated processor embedded within the corresponding eNodeB125 or by a server processor or virtual machine generated in a cloud computing environment running on server hardware located within the premises of the sub-network 100 or elsewhere. The same is true for S1-Conn110 and operation 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 site corresponding to sub-network 100. Each of these components may be implemented by C, C + +, Java, one or more scripting languages, or any combination thereof, depending on the given sub-components within each of these components.

In step 225, S1-Conn110 intercepts each PWSRestartIndication message from each internal eNodeB125, and in step 230, creates a mapping for each internal eNodeB125 of: its internal 28-bit eNodeB identifier, its constituent cell ID (E-CGI), and the rest of the information provided in its corresponding pwsrestindication message. And step 230, S1-Conn110 assigns itself a 20-bit eNodeB ID common to all internal enodebs 125, extracts the constituent cell IDs (E-CGIs) and other information gathered from each corresponding pwsrestindication message, and populates this information in a new "re-wrapped" pwsrestindication message. The 20-bit eNodeB ID assigned to S1-Conn110 may be referred to as a virtual sub-network baseband processor identifier.

In step 235, the S1-Conn110 sends its own pwsrestindication message assembled in step 225 to each corresponding MME 150 via its respective external S1 connection 155.

Accordingly, even though each MME 150 is exclusively interacting with S1-Conn110, 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 if each internal eNodeB125 is interacting exclusively with S1-Conn110, it will behave as if it is interacting with any of MMEs 150. To achieve this operation, S1-Conn110 bi-directionally intercepts each subsequent message between a given MME 150 and an internal eNodeB125, and also between MME 150 and a given UE 170. The S1-Conn110 remaps the cell IDs and other required information using, for example, a look-up table stored in memory assigned to the S1-Conn110, to repackage a given message with the remapped information, and to send the repackaged message to its destination. For purposes herein, the internal eNodeB125 that is the destination of incoming messages from a given MME 150 may be referred to as a message destination baseband processor.

Advantages of this operation include the following. First, any given (non-home) eNodeB has a 20-bit identifier, and provided the cell ID for each eNodeB is an 8-bit identifier, it may have been assigned up to as many as 256 cells. However, in view of practical limitations in terms of computational 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 acting like a "giant" eNodeB) to use all 8 bits of the cell ID. This is because each internal eNodeB125 has allocated it (either in dedicated hardware or in the provided cloud computing resources) enough memory and computing resources to handle a typical number of used cells.

Second, the number of internal enodebs 125 (and subsequent number of cells 135) may be dynamically adjusted according to traffic needs, provided that the external network (e.g., outward from MME 150) is only aware of the single "jumbo" eNodeB encompassed by the functionality of S1-Conn 110. This may be extremely useful for locations (e.g., gyms) that may be crowded with volumes for one day per week, with the rest of the time being quiet. In this case, internal enodebs 125, each having multiple corresponding cells 135, may be created and assigned to handle changes in traffic demand so that all these changes are hidden from the external network.

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

Fig. 3 shows an exemplary procedure 300 for a UE 170 to establish a connection with an internal eNodeB 125.

In step 305, the UE 170 and a given internal eNodeB125 exchange appropriate conventional signals to establish a connection. For example, the UE 170 may send an RRC connection request to the internal eNodeB125, and the internal eNodeB125 may in turn respond with an RRC connection setup message or the like. As a result, the UE 170 connects to the internal eNodeB125, and the internal eNodeB125 has established an internal identifier corresponding to the UE.

In subprocess 310, internal eNodeB125 establishes a default bearer with MME 150 via S1-Conn 110. As shown in fig. 3, the sub-process 310 includes several steps added to the default bearer establishment procedure specified in 3GPP TS 24.301, e.g., steps 315, 320 and 325 describe modifications/enhancements to conventional procedures described in the 3GPP technical specification.

In step 315, S1-Conn110 intercepts a default bearer setup message sent by the internal eNodeB125, including the UE ID generated by the internal eNodeB 125.

In step 320, S1-Conn replaces the UE ID (generated by the internal eNodeB 125) and replaces it with the 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. The chance of two enodebs 125 generating duplicate UE IDs is significant. Due to this possibility, S1-Conn replaces the UE ID generated by the internal eNodeB125 with a unique value, re-encapsulates the message, and sends the message to the appropriate MME 150.

In step 325, S1-Conn110 intercepts the default bearer setup message from MME 150 to internal eNodeB125, remaps the UE ID, and sends the re-encapsulated message to internal eNodeB 125.

The goal is that a given internal eNodeB125 is not aware that it is not interacting directly with MME 150, and MME 150 is not aware that it is not interacting directly with internal eNodeB 125. In the former case, the S1-Conn110 acts as the MME 150 for the internal eNodeBs 125, while in the latter case, the S1-Conn110 acts as the eNodeB that interacts with the MME 150 (and the UE 170).

In subprocess 330, internal eNodeB125 establishes a dedicated bearer with MME 150 via S1-Conn 110. As shown in fig. 3, the sub-process 330 includes several steps added to the default bearer establishment procedure specified in 3GPP TS 24.301. The steps required to establish the dedicated bearer may 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-Conn110 is acting as an invisible intermediary between internal eNodeB 120 and MME 150.

Fig. 4 shows an exemplary procedure 400 for establishing an X2 connection between two internal enodebs 125.

In step 405, the UE 170 communicates with the source internal eNodeB125 to which it is currently connected, so that it has a strong signal from another internal eNodeB 125. UE 170 does this by sending a measurement report to the source internal eNodeB125, thus identifying the neighboring internal eNodeB125 and cell 135 that UE 170 is receiving a strong signal. Step 405 may be a conventional procedure, an example of which is described in 3GPP TS 36.300. From this information, the UE 170 identifies and recommends the target internal eNodeB125 for handover.

In step 410, the source internal eNodeB125 retrieves its own internal 28-bit identifier from internal memory. Recall from step 210 that each internal eNodeB by default has the same 20-bit eNodeB identifier. To prevent collisions within the sub-network 100, the supervision module 120 of each internal eNodeB instructs its respective internal eNodeB125 to select an 8-bit identifier of one of its cells (e.g., the first cell) and attach its own 20-bit identifier with the 8-bit identifier of its cell, creating a wrong home eNodeB (henb) internal identifier for itself, referred to herein as the internal eNodeB identifier. And step 410, the source internal eNodeB125 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.

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

In step 420, the S1-Conn110 intercepts the eNBConfigurationTransfer sent in step 415. In step 425, the S1-Conn110 extracts the internal eNodeB identifier of the source internal eNodeB125 and the internal eNodeB identifier of the target internal eNodeB125 (and other information in the eNBConfigurationTransfer command), and constructs the mmeconfigrationtransfer command from this information. And in step 430, S1-Conn sends an MMEConfigurationTransfer command to the target internal eNodeB 125.

With the configuration transfer complete, the source internal eNodeB125 and the target eNodeB125 may establish an X2 connection between them. In performing the steps of process 400, S1-Conn110 is acting as MME 150, so that neither the source internal eNodeB125 nor the target eNodeB125 is aware that they are not communicating directly with MME 150. Furthermore, MME 150 is not at any point involved in the process. This is because MME 150 treats S1-Conn110 as a "giant" eNodeB, and thus given only one eNodeB, there will be no X2 connection.

Fig. 5 shows an exemplary procedure 500 for performing an X2 handover between two internal enodebs 125.

In step 505, UE 170 identifies target cell 135 and target internal eNodeB125 and informs the source internal eNodeB125 to which UE 170 is currently connected. The process may be substantially similar to step 405 of process 400.

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

In step 515, the target internal eNodeB125 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 eNodeB125 and the E-CGI of the target cell. S1-Conn110 relays the message to the relevant MME 150.

In step 520, the target internal eNodeB125 sends a release resource message to the source internal eNodeB125 over their mutual X2 connection, thus completing the handover procedure of the UE 170 between two internal enodebs 125 within the sub-network 100 in a manner hidden from the external network.

Fig. 6 shows an exemplary procedure 600 for performing an S1 handover between an internal eNodeB125 to an external eNodeB 160. This is for the case where the UE 170 is moving out of range of the internal eNodeB125 of the sub-network 100. The steps of process 600 may be incorporated into a handover process based on S1.

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

In step 610, the source internal eNodeB125 sends a handover required message to the relevant MME 150. By doing so, the source internal eNodeB125 uses its internal eNodeB identifier in the message.

In step 615, S1-Conn110 intercepts the handover required message and re-encapsulates it with its own 20-bit virtual sub-network baseband processor identifier and E-CGI of the cell currently connecting the UE 170 with the source internal eNodeB125 and sends the message to the relevant MME 150.

In step 620, MME 150 sends a handover command to S1-Conn 110. It will be understood that MME 150 behaves as if it is interacting with a conventional eNodeB.

In step 625, S1-Conn110 receives the handover command from MME 150 and remaps the eNB ID to the internal eNodeB identifier of the source internal eNodeB125, and sends the re-encapsulated handover command to the source internal eNodeB 125. Subsequently, in step 630, the source internal eNodeB125 sends a handover command to the UE 170.

Source internal eNodeB125 may send an eNB state transition message to the relevant MME 150 if any E-RAB (evolved radio access bearer) corresponding to UE 170 is configured for PDCP (packet data convergence protocol) reservation. 110 may intercept the message, remap information in the message to specify a virtual sub-network baseband processor identifier, re-encapsulate the message, and send it to the relevant MME 150 (source MME).

In step 635, the source MME 150 sends a UE context release order to S1-Conn 110. In step 640, S1-Conn110 proceeds to remap the eNB ID to the internal eNodeB identifier of the source internal eNodeB125 and sends a message to the source internal eNodeB 125.

In step 645, the source internal eNodeB125 sends a UE context release complete message to the source MME 150.

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

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

Accordingly, for external networks, the S1 based handover disclosed in process 600 involves a handover between a "giant" eNodeB, represented by S1-Conn110, and the external eNodeB 160. The internal workings of the sub-network 100 are hidden from the external network.

Fig. 7 illustrates an exemplary process 700 for reconfiguring a sub-network 100 based on an increase or decrease in traffic demand. This enables the sub-network 100 to expand and contract based on demand while hiding changes to the sub-network from outside networks.

In step 705, the operation and maintenance module 120 may perform an evaluation of the current service usage and demand in combination with the S1-Conn 110. This may involve: analyzing historical usage data and extrapolating recent future demand. For example, if the sub-network 100 is deployed in a gym, the operation and maintenance module 120 may have stored in accessible memory a schedule of upcoming events so that it can anticipate periods of high and low demand. For deployments such as in dense urban scenarios, the operation and maintenance module 120 may have accumulated historical data on demand based on time of day, day of 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 future requirements in the near future and act accordingly to provide a supply of cloud-based computing capacity to the virtual internal eNodeB125 or to power up/down the hardware-based internal eNodeB 125.

Additionally, virtual eNodeB125 may employ 3GPP specified mechanisms with respect to evaluating (i.e., determining) demand, including: setting a configurable threshold, and comparing the actual demand to the threshold. eNodeB125 may then send the results of the comparison to operation maintenance module 120. The operation 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 further determinations as described above and send an alarm signal or the like to the operation and maintenance module 120. The mechanism may use a standard PM-Stat file (performance measure) generated every 15 minutes and sent to the core network via a northbound interface (not shown) also specified by 3 GPP. It will be understood that such variations are possible and within the scope of the present disclosure.

Depending on the results of the evaluation completed in step 705, process 700 may also take no action (not shown in FIG. 7); it may take a subprocess path 701, where the operation maintenance module 120 may increase the capacity of the sub-network 100 by adding one or more internal enodebs 125; or it may employ a subprocess path 702 in which the operation maintenance module 120 may reduce capacity by removing one or more internal enodebs 125.

With respect to sub-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. This may include, for example: determining the location of the interior eNodeB125 with the greatest demand; and determining availability of nearby remote radio units and antenna hardware.

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

In step 720, the operation and maintenance module 120 may issue an instruction to S1-Conn110 to instruct the currently operating high-demand internal eNodeB125 to handover the UE connection to the newly introduced new internal eNodeB 125. This may alternatively be done, whereby the operation and maintenance module 120 may issue instructions to the appropriate supervision module 130 via the IP connection 145 to cause the corresponding internal eNodeB125 to perform a UE connection handover.

In case a new eNodeB125 starts up and runs, 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 origination message) indicating its internal eNodeB identifier and constituting the cell ID.

In step 730, the S1-Conn110 intercepts one or more PWSRestartIndication messages, each from each newly online internal eNodeB125, extracts the internal eNodeB identifier and corresponding cell ID, and adds this information to the preexisting mapping stored in its memory by the S1-Conn 110.

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

With respect to sub-path 702, if in the evaluation in step 705, the operation maintenance module 120 determines that the sub-network 100 has additional capacity, the operation maintenance module 120 may proceed to step 750 and execute instructions to identify where one or more additional internal enodebs 125 are to be turned off within the sub-network 100. This may include: the location of the inner eNodeB125 with insufficient requirements and the inner identifier of the neighboring eNodeB125 that may be available for handover are determined.

In step 755, the operation maintenance module 120 may execute instructions to instruct the internal eNodeB125 designated to be shut down to handover the UE connection to neighboring enodebs that are otherwise capable of serving these UEs 170. As with step 720, this operation may proceed in one or more ways: whereby the operation and maintenance module 120 instructs S1-Conn110 to indicate the switch or the operation and maintenance module 120 instructs the relevant supervision module 130 to implement the switch. It will be understood that such variations are possible and within the scope of the present disclosure.

In step 760, the operation maintenance module 120 may shut down the internal eNodeB125 specified in step 750. In the case of a software-based virtual internal eNodeB125, this may involve: the corresponding virtual machine running on the server hardware of the sub-network is terminated. Alternatively (or additionally), this may involve: the appropriate hardware-based base station is powered down. The operation maintenance module 120 may do this by issuing a command to the associated supervisor module 130.

In step 765, S1-Conn110 executes instructions to remove the terminated internal eNodeB identifier and corresponding cell ID from its memory. The sub-process 702 then proceeds to step 735. In step 735, S1-Conn110 issues a new pwsrestindication with a revised list of cell IDs (minus the cell ID corresponding to the terminated internal eNodeB 125).

The ability of S1-Conn110 to intercept messages, remap information within messages, re-wrap messages, and send messages between internal enodebs 125 and MMEs 150 enables other capabilities. For example, S1-Conn110 may identify patterns in messages from internal enodebs and derive location information from one or more of the UEs 170 connected to them.

Fig. 8 illustrates two exemplary procedures 800 by which the S1-Conn110 processes location related information according to LTE positioning protocol annex (LPPa) between E-SMLC (evolved serving mobile location center) 801 and the internal eNodeB125 and UE 170, respectively. E-SMLC801 may be coupled to sub-network 100 via one of MMEs 150. The connection between MME 150 and E-SMLC801 may be over the SL interface, as specified in 3GPP TS 23.271. Details on LPPa can be found in 3GPP TS 36.455.

Through process 800, the E-SMLC801 interacts with enodebs according to LPPa procedures, but except for the intervention of the S1-Conn110, it makes the E-SMLC function as if it interacts with a single "jumbo" eNodeB of the S1-Conn110 that actually acts as a proxy for the internal enodebs 125 within the sub-network 100, as described above.

In step 805, E-SMLC801 issues a request/command to the eNodeB emulated by S1-Conn 110. In this case, E-SMLC801 does not know the internal enodebs 125 of sub-network 100 and only interacts with 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, and the like. Note that in these interactions, the S1-Conn110 will report a predetermined location, which may or may not be the actual location instantiated by the S1-Conn 110. For example, if the subnetwork 100 is deployed in a venue such as a gym or airport, the location reported by the S1-Conn 100 may be the location of the venue' S security room or its main entrance, etc. Alternatively, the Sl-Conn 110 may return a list of locations for each cell 135 within the subnet 100.

In step 810, the S1-Conn110 receives and processes the request/command, and in step 820, the S1-Conn110 encapsulates and sends a response to the E-SMLC 801.

Fig. 9 illustrates an exemplary process 900 by which S1-Conn110 may selectively intercept requests from multiple UEs 170 connected to one or more enodebs 125 of a sub network 100 and take action to intervene and notify related persons/entities regarding the location of anomalous behavior between connected or connecting UEs 170.

In step 905, the plurality of UEs 170 initiate a call by issuing a message through VoIP or CS fallback to a 3G/2G cell (not shown). These calls may originate via one internal eNodeB125 or two or more adjacent internal enodebs 125.

In step 910, S1-Conn110 intercepts the call initiation message. In case of VoIP, S1-Conn110 retrieves a 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 QCI is equal to 5, the message corresponds to IMS (IP multimedia subsystem) signaling to establish and release a VoIP connection. As with any message, S1-Conn110 remaps the eNodeB cell ID with its virtual sub-network baseband processor identifier, re-wraps the message, and sends it to the intended MME 150. With each identified VoIP call origination, the S1-Conn110 may execute instructions to log relevant information corresponding to the call origination (e.g., UE identifier, internal eNodeB identifier, 28-bit cell identifier (ECGI), S-TMSI (SAE temporary mobile subscriber identity), time of receipt of message, etc.).

In step 915, S1-Conn110 stores the information related to the call setup event in step 910. Further to step 915, S1-Conn110 may execute instructions to identify a pattern comprising a history of call patterns as a function of time. If in the course of executing these instructions, the S1-Conn110 may identify an anomaly in call setup (e.g., a sudden surge of call setup messages from UEs 170 connected with a given interior cell 135 or multiple neighboring cells 135 of a single eNodeB125, or isolated instances of a large number of UEs 170 within a single cell 135 initiating calls simultaneously). 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 an antenna of the relevant cell 135. In this case, S1-Conn110 may store a plurality of identifiers each corresponding to an identified UE 170 within the cluster.

In step 920, S1-Conn110 may instruct the relevant internal eNodeB125 to provide the most recent timing advance value corresponding to each UE identified in step 915. Subsequently, in step 925, the relevant internal eNodeB125 may provide the requested timing advance information corresponding to each UE 170 identified in step 915.

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

In step 935, if the S1-Conn110 identifies a cluster of timing advance values for the relevant UE 170 (whether or not it executes instructions to determine cluster location via triangulation), the S1-Conn110 may execute instructions to send a message to a predetermined entity within the premises of the sub-network 100. An example of a subscribing entity may include a customer office (e.g., a security office).