Patent Application
20190141561
The present invention relates generally to the field of wireless mesh networks. More specifically, the present invention is related to a self-backhauling mesh/relay system and a method that is specifically designed for 5G, 4G and 3G technologies to perform an instantly reconfigurable network topology, load balancing and resource partitioning across a mesh network.
Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common knowledge in the field.
In remote locations, where well-planned wireless infrastructure is not yet deployed, or when the base stations are moving as in military or public safety applications, bringing the cellular data communications service for everyday use or under emergency conditions using a fixed wire-line core network infrastructure is impossible. In such areas where a facilities infrastructure is not available, it is much easier to use wireless mesh networks wherein base stations are directly interconnected with wireless/air interfaces to relay data traffic in a hop-by-hop fashion. There are many alternative air interface technologies to use in wireless mesh networks. Orthogonal Frequency-Division Multiple Access (OFDMA) is one of the most popular air interface technology for Wireless Mesh Networks because of its advantages in high data transmission rate, mitigation in frequency selectivity in multi-path environments, robustness against frequency selective fading, and ability to provide frequency diversity in multi-user environments.
In order to meet the public safety, military and rural community communications requirements, mesh networks must satisfy the following requirements: (1) establishing uninterrupted and reliable device-to-device and device-to-infrastructure communications aligned with 3G/4G/LTE standards; and (2) developing prioritization mechanisms in data delivery.
The key invention of this patent application is to create a new control messaging sequence between adjacent mesh nodes to instantly change the network connectivity/topology and doing so, to redistribute the traffic load among mesh nodes to meet the aforementioned requirements. Broadcasting the topology and routing information amongst mesh nodes, as opposed to relaying them to a centralized system for routing and topology determination achieves this.
Embodiments of the present invention are an improvement over prior art systems and methods.
The present invention provides a method and a special mesh node design for wireless communications that combine on a single air interface across a pair of mesh nodes both data transmission and the control messaging exchange to make packet data routing in a wireless mesh network with many such pairwise interconnected mesh nodes more dynamic and efficient. Using (1) a simple over the air connection (called backhaul) created via a regular user equipment (called backhaul UE) in a mesh node that attaches to the base station component of an adjacent mesh node, (2) a mesh application, according to an aspect of this invention, implemented in each mesh node as an additional software component (1) for storing (a) the list of UEs (including backhaul UEs) to reject or accept, said list being reconfigurable, and (b) the adjacency information of all mesh nodes, and (3) a sharing mechanism of the aforementioned information with the adjacent mesh nodes on a control channel on the backhaul connection, attaining a periodic or event driven information broadcast across all the network, and (4) a method for determining overall routing of data packets across the mesh network, and dynamically altering and optimizing radio resource utilization by handing over UEs between mesh nodes. Exchange of control messages according to an aspect of this invention between mesh nodes and the mesh application provides the advantage to coordinate topology modification and routing between neighboring mesh nodes.
In one embodiment, the present invention provides a method as implemented in a mesh network, the mesh network comprising at least a first mesh node and a remote second mesh node, the first mesh node comprising a first base station, a first backhaul user equipment (UE), and a first integrated computer implementing a first core network and running a first mesh application, the first mesh node directly attached to at least a first radio access user terminal, the second mesh node comprising a second base station, a second backhaul user equipment (UE), and a second integrated computer implementing a second core network and running a second mesh application, the second mesh node directly attached to at least a second radio access user terminal, the first mesh node interconnected with the second mesh node via the first backhaul UE communicating with the second base station over an air interface to provide the backhauling or hopping of data traffic, the method as implemented in the first mesh node comprising: establishing a control connection towards the second mesh application of the second mesh node via the first backhaul UE's communicating with the second base station of the second mesh node, the control connection exchanging control messages; and establishing a data connection towards the second mesh application of the second mesh node to exchange data packets between the first radio access user terminal attached to the first mesh node and the second radio access user terminal attached to the second mesh node.
In another embodiment, the present invention provides a topology alteration method as implemented in a mesh network, the mesh network comprising at least a first mesh node, a remote second mesh node, and a remote third mesh node, the first mesh node comprising a first base station, a first backhaul user equipment (UE), and a first integrated computer implementing a first core network and running a first mesh application, the first mesh node directly attached to at least a first radio access user terminal, the second mesh node comprising a second base station, a second backhaul user equipment (UE), and a second integrated computer implementing a second core network and running a second mesh application, the second mesh node directly attached to at least a second radio access user terminal, the third mesh node comprising a third base station, a third backhaul user equipment (UE), and a third integrated computer implementing a third core network and running a third mesh application, the third mesh node directly attached to at least a third radio access user terminal, the first mesh node interconnected with the second mesh node via the first backhaul UE communicating with the second base station over a first air interface to provide the backhauling or hopping of data traffic, and the second mesh node interconnected with the third mesh node via the second backhaul UE communicating with the third base station over a second air interface to provide the backhauling or hopping of data traffic, the method comprising: each mesh application at a corresponding mesh node storing a User Equipment (UE) reject list containing a listing of those UE whose connection attempt to that corresponding mesh node will be rejected with an associated reject reason, the UE reject list containing at least the identifier of the corresponding mesh node's backhaul UE, so that when the corresponding mesh node's backhaul terminal tries to attach to its local base station, the connection is rejected by the local base station to force corresponding mesh node's backhaul user terminal to attach to a remote mesh node's base station; the first mesh application sending a topology directive message to the second mesh application to request the rejection of a connection request of the first backhaul UE to the second mesh application, the second mesh application adding the first backhaul UE's identifier to its UE reject list and rejecting the first backhaul UE's attachment to the second base station; and the first backhaul UE being disconnected from both the first and second base stations attempting to attach the third base station, connecting and therefore altering the topology of connectivity between the three mesh nodes.
In yet another embodiment, the present invention provides a mesh network comprising: a first mesh node comprising a first base station, a first backhaul user equipment UE), and a first integrated computer implementing a first core network and running a first mesh application, the first mesh node directly attached to at least a first radio access user terminal, a second mesh node comprising a second base station, a second backhaul user equipment (UE), and a second integrated computer implementing a second core network and running a second mesh application, the second mesh node directly attached to at least a second radio access user terminal, the first mesh node interconnected with the second mesh node via the first backhaul UE communicating with the second base station over an air interface to provide the backhauling or hopping of data traffic, the first mesh node establishes a control connection towards the second mesh application of the second mesh node via the first backhaul UE's communicating with the second base station of the second mesh node, the control connection exchanging control messages; and establishes a data connection towards the second mesh application of the second mesh node to exchange data packets between the first radio access user terminal attached to the first mesh node and the second radio access user terminal attached to the second mesh node.
In another embodiment, the present invention provides a mesh network allowing topology alteration comprising: a first mesh node comprising a first base station, a first backhaul user equipment (UE), and a first integrated computer implementing a first core network and running a first mesh application, the first mesh node directly attached to at least a first radio access user terminal, a second mesh node comprising a second base station, a second backhaul user equipment (UE), and a second integrated computer implementing a second core network and running a second mesh application, the second mesh node directly attached to at least a second radio access user terminal, a third mesh node comprising a third base station, a third backhaul user equipment (UE), and a third integrated computer implementing a third core network and running a third mesh application, the third mesh node directly attached to at least a third radio access user terminal, the first mesh node interconnected with the second mesh node via the first backhaul UE communicating with the second base station over a first air interface to provide the backhauling or hopping of data traffic, and the second mesh node interconnected with the third mesh node via the second backhaul UE communicating with the third base station over a second air interface to provide the backhauling or hopping of data traffic, wherein: each mesh application at a corresponding mesh node storing a User Equipment (UE) reject list containing a listing of those UE whose connection attempt to that corresponding mesh node will be rejected with an associated reject reason, the UE reject list containing at least the identifier of the corresponding mesh node's backhaul so that when the corresponding mesh node's backhaul terminal tries to attach to its local base station, the connection is rejected by the local base station to force corresponding mesh node's backhaul user terminal to attach to a remote mesh node's base station; the first mesh application sending a topology directive message to the second mesh application to request the rejection of a connection request of the first backhaul UE to the second mesh application, the second mesh application adding the first backhaul UE's identifier to its UE reject list and rejecting the first backhaul UE's attachment to the second base station; and the first backhaul UE being disconnected from the second base stations attempting to attach the third base station, connecting to the third base station and therefore altering the topology of connectivity between the three mesh nodes.
The present disclosure, in accordance with one or more various examples, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict examples of the disclosure. These drawings are provided to facilitate the reader's understanding of the disclosure and should not be considered limiting of the breadth, scope, or applicability of the disclosure. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale.
While this invention is illustrated and described in a preferred embodiment, the invention may be produced in many different configurations. There is depicted in the drawings, and will herein be described in detail, a preferred embodiment of the invention, with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and the associated functional specifications for its construction and is not intended to limit the invention to the embodiment illustrated. Those skilled in the art will envision many other possible variations within the scope of the present invention.
Note that in this description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the invention. Further, separate references to “one embodiment” in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated and except as will be readily apparent to those of ordinary skill in the art. Thus, the present invention can include any variety of combinations and/or integrations of the embodiments described herein.
Cellular communication technologies usually require a high amount of infrastructure behind the base stations for routing and forwarding of data packets to their destinations. In a traditional cellular deployment, as illustrated in
According to one embodiment of the invention, an apparatus for wireless communication is provided which should allow hopping of packets from one mesh node to another without using any wire-line backhaul infrastructure. An exemplary arrangement of the building blocks of an embodiment of the invention is shown in
Between the base station, 204, and core network, 205, the S1-AP interface, 213, includes the control channel, and the S1-U interface, 214, includes the IP tunneled data communication. Both of these interfaces are well defined in LTE standards documents, and may be replaced with other standard interfaces defined for UMTS or 5G.
According to one embodiment of this invention, Mesh App, 202, has three different control interfaces for: (1) management of the core network, 210, (2) management of the base station, 212, and (3) management of the backhaul modems, 208. Mesh App, 202, also has two types of data forwarding interfaces; (1) towards the backhaul modems, 209, to forward data packets to other mesh nodes by tunneling, and (2) towards the core network, 211, to forward data packets to other mesh nodes by tunneling or to UEs directly attached to that mesh node without tunneling.
Backhaul UE/modem 201 is a general purpose UMTS (3G), LTE (4G), or 5G modem which is connected with a physical USB connection to the mesh node. There may be several backhaul modems per mesh node. However, each backhaul modem 201 can only be connected to one remote mesh node's base station at a time. The functionality of the control interface, 208, of a backhaul modem is fairly limited using off the shelf modems. Two commonly available examples of the control interface are AT and QMI, neither of which provide the needed functionality for cell id or TAC/LAC specific cell selection, the importance of which will be described later. These control interfaces provide received signal power and signal to noise ratio (SINR) of the connected base station and an attribute to reset the backhaul modem.
Core Network 205 has a user interface for instantaneous notifications of UE attach, detach, handover, or cell reselection occurrences. It also provides an interface for configurable ‘UE reject list’ where each entry contains the International Mobile Subscriber Identity (IMSI) of a UE and reject cause for ‘attach reject’ and ‘tracking area update (TAU) reject’ messages. When a UE in that reject list of Core Network 205, and it tries to attach Base Station 204, the connection gets rejected. Core network 205 also provides a Command Line Interface (CLI) for manual network initiated detach operations for a specific IMSI.
Base Station 204 can be a gNode-B for a 5G, an eNode-B for an LTE (4G), or a Node-B for a UMTS (3G) based network. Base station 204 provides a management interface, 212, to trigger handover for any technology. For UMTS (3G), the base station may also provide a configurable Access Point Name Control List (ACL), where each entry contains IMSI of the UE that can connect to the base station. ACL support provides access and topology control option with the base station control interface, 212, in UMTS (3G).
When a radio access the UE is connected to a base station of a Mesh Node, it is registered in its Core Network. Namely, the UE acquires its IP address from that Core Network. Note that a backhaul UE A 201 registers with the Core Network 205b, the Core Network of the adjacent Mesh Node, 206b, whereas radio access UE 105 registers with Core Network 205a, the Core Network of the Mesh Node it directly attaches to. UE 105 obtains its IP address from Core Network 205a, while UE 106 and backhaul UE 201 obtain their IP addresses from Core Network 205b.
A Core Network obtains information about all UEs (both radio access of backhaul) from a Home Location Registrar (HLR) database within itself. This database in each Core Network contains the IMSI of each UE along with the corresponding static and uniquely assigned IP address, which has to be preconfigured by the operator at the beginning of operation. Therefore, a Core Network knows all IP addresses used by radio access UEs attached to it. Note that for the packets of UEs to remain as unique within the Mesh Node, the Core Network has to disable Network Address Translation (NAT), so that the source and destination IP addresses remain as the original addresses and could be routable using the IP header of those data packets.
Two simple topologies of the same mesh network with four mesh nodes are illustrated in
Base station in each mesh node must be configured with a different cell id and Tracking Area Code (TAC) in LTE [or a different Location Area Code (LAC) in GSM/3G] to distinguish them, but with the same Public Land Mobile Network (PLMN) ID to group them as part of the same mesh network. Different TAC [or LAC] is required to prepare the ‘UE Reject List’ according to TAC/LAC rejected.
It is pertinent to this patent application to understand the LTE UE's cell selection procedure because this process is leveraged to achieve instant mesh network topology changes by (1) changing the selection of a connection between a backhaul UE and its adjacent base stations in other mesh nodes; and (2) changing the selection of connections of UEs (i.e., which UE connects to which mesh node). Similar cell selection procedures of UMTS (3G) and 5G, are applicable for the same purposes. The UE (backhaul or radio access) measures the signals from every supported frequency band and compares them with a threshold for detection of the nearby cells. The UE then decodes Master Information Block (MIB) and System Information Blocks (SIBS) coming from the candidate cells and obtains identifiers such as Public Land Mobile Network (PLMN) id, Physical Cell ID (PCI), Tracking Area Code (TAC) of each cell/base station. The selection of the base station to attach to depends on the UE's pre-defined PLMN priorities and forbidden TAC lists, or signal strength. A ‘forbidden list’ is updated depending on the last errorless service taken or previously received rejections.
The rejection of a UE's attachment to a base station is leveraged for the change of connectivity topology method of this patent application. In LTE, a base station can reject the connection request of a UE. The rejection and its cause can be sent by the base station to UE in following exemplary messages;
All these messages are well defined by the LTE standards. The Mobility Management Entity (MME) subcomponent of a Core Network has a configurable ‘Rejection List’. If a UE's IP address is in this list, the Core Network will deny the connection. If a UE is in the rejection list of the MME, the MME responds to that UE's ATTACH REQUEST MESSAGE with an ATTACH REJECT MESSAGE and responds to UE Tracking Area Update (TAU) with and TAU REJECT MESSAGE. Both rejection messages include a ‘rejection cause’ section. Once the UE receives a rejection of connection, it enters into a different state and stores the TAC ID (TAI) of the rejecting node in its ‘forbidden Tracking Area list’. Some exemplary rejection causes and their consequent states (as defined in 3GPP TS 24.301) are as follows;
A block diagram of Mesh App, 202, of the mesh node, 206, is presented in
Topology decision logic, 403, has a direct connection for gathering information and directing the topology management of peripheral control connections. These connections are; (1) control interfaces of backhaul modems, 208, (2) control interface of core network software, 210, and (3) control interface of base station, 212. Moreover, topology management closure contains an inner UE reject database, 407, which maintains list of UE IMSIs, rejection causes, deciding mesh node identity, and validity time. When validity time for an entry time UE reject database times out, it is removed from the list. The inner UE reject database is the same list as that of the core network, except the rejection deciding mesh node identity. Note that sometimes a rejection of a backhaul UE is simply caused by a topology directive message received from an adjacent mesh node, with the goal of a directive of rejecting that UE's connection being to enable its connection to another mesh node. The main goal of the topology decision logic is to decide feasibility of every connected backhaul link or normal UE connection. Hence, it periodically evaluates the backhaul and normal UE links and discriminates or rejects infeasible links. A topology management action per this invention is triggered by the control interfaces of core network, 210, or base station, 212. Besides, backhaul modem control interface, 208, provides the received power information of active connection of each backhaul modem and provides the modem reset function. Backhaul modem reset function is triggered by topology decision logic, when the modem does not connect to any base station for a while, due to being rejected by all base stations, or when a long inner timer expires after an unsuccessful connection.
In the routing management procedure, control messaging function, 412, of
The purpose of the routing decision logic, 404, is to find the best routes for remote mesh nodes, UEs, and IP pools and storing the best routes in routing rules database, 415. Routing rules database, 415, includes entries for all known single IPs and IP pools, each of them is classified as local or remote with its remote tunnel direction. For every received packet, data packet router, 413, checks routing rules database, 415, and sends the packet to the stored next hop mesh node towards the destination. The routing decision logic, 404, updates routing rules database, 415, when a routing related control packet is received, a UE (or IP pool) attached or detached, or a neighbor mesh node is connected or disconnected with backhaul.
A block diagram that illustrates routing directions of data packet router, 413, is in
The Control Messaging function, 412, of Mesh App, 202, per this invention is responsible for providing the inter-Mesh App control connectivity for data routing and control messaging to inform and modify network topology. The Mesh App either runs on the same computer with the Core Network or can be on a separate computer attached with a local area network to the Core Network's computer. The backhaul UE can be a simple interface card (such as a SIM card) on the computer that runs Core Network or the Mesh App.
Once turned on, each Mesh App detects the backhaul UE in the same node and makes sure that the detected backhaul UE connects to a remote Mesh Base Station, and not to the local Mesh Node. This is achieved by keeping these backhaul UEs IMSIs in the ‘UE reject list’ of that mesh node. Once the Mesh App detects that a connection has been established from its local backhaul modem to an adjacent mesh node, it will form an IP tunnel 515 in the uplink direction and a control connection 513 towards the Mesh App of the adjacent node as illustrated in
The control information exchange between any pair of Mesh Apps along the control connection is formulated in three simple messages:
The Mesh App maintains two types of timers for the control information: (1) a connection timer for the control and data connections to test if a connection is still alive for every adjacent mesh node connection; (2) a mesh node timer for every known mesh node in the network to test if its routing information is fresh, meaning it is still valid. An exemplary simplified control connection setup procedure between a backhaul modem and a base station according to an aspect of this invention between two adjacent mesh nodes is performed as illustrated in
Mesh App should always configure the core network to reject its own backhaul modem connection attempts to avoid connecting to itself. Depending on all information obtained from other mesh nodes through the INFO messages and additional internal configuration information, a Mesh App can decide on rejecting the connection of certain backhaul modems of neighboring mesh nodes to steer the connectivity topology of the network. Note that the network connectivity/topology is governed by the backhaul modem-to-base station connections of adjacent nodes as illustrated in
An exemplary scenario of topology management is illustrated in
The Core Network knows the IP addresses of all UEs and Backhaul UEs attached to itself through the registry process, and thus it knows how to route data packets to destinations within the coverage of its collocated mesh base station. However, it can't route IP traffic destined to radio access UEs attached to different mesh nodes. The Core Network continuously notifies the Mesh App of the ‘Network Attach’, ‘Network Detach’, and ‘Handover’ events to keep an accurate registry of all locally supported IP end points. Doing so, the Mesh App obtains all local IP addresses from the attached Core Network. Meanwhile, it learns the remote IP addresses from the Mesh Apps in other mesh nodes to be able to route packets beyond the coverage of its own Mesh Node. The neighbor Mesh Apps, therefore, exchange periodic or event-based INFO messages on the control connection to obtain routing updates in the network. Besides periodic INFO message broadcasts, the INFO message is instantly generated in two events; (1) when a UE attaches as illustrated in
Each Mesh App is responsible for storing and updating of its routing table based on its own information of attachment/detachment/handover of local UEs and the received INFO message contents from neighbors. The Mesh App receives the packets by its virtual network interface, which is formed by data packet router, arriving from an attached radio access UE, and based on the destination IP address of the incoming packets, it will either send the packets directly to the Core Network for a local transmission or tunnel it to send to a remote Mesh App. When a UE attaches or detaches from the Core Network or if there is a handover, a notification message is sent from the Core Network to the local Mesh App so that the Mesh App updates its local routing table accordingly.
The Mesh App can't route packets directly to the destination of the IP packet when the destination address is not within the coverage of the Mesh Node of that Mesh App because, the destination IP address of the packet is not known within the Mesh Node and it would not be sufficient to simply bypass the radio access network and the air interface. Therefore, it has to be tunneled across the two mesh nodes, wherein the source and destination radio access UEs are within the coverage areas of these two Mesh Nodes.
Not all Mesh Nodes are created equal. One Mesh Node may need more resources than others and/or may require prioritization. For example, a sink node may require prioritization because it provides Internet connection and therefore most of the traffic gets concentrated around it. In other cases, number of radio access UEs connected to a specific Mesh Node would be much higher than others, or its coverage area would be large. In these cases, the topology management subcomponent of the Mesh App adjusts the number of UEs connected to a mesh node accordingly using TOPOLOGY DIRECTIVE messages.
A simple flowchart showing the control operations of the Mesh App is given in
Many of the above-described features and applications can be implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Embodiments within the scope of the present disclosure may also include tangible and/or non-transitory computer-readable storage media for carrying or having computer-executable instructions or data structures stored thereon. Such non-transitory computer-readable storage media can be any available media that can be accessed by a general purpose or special purpose computer, including the functional design of any special purpose processor. By way of example, and not limitation, such non-transitory computer-readable media can include flash memory, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions, data structures, or processor chip design. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, components, data structures, objects, and the functions inherent in the design of special-purpose processors, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing or executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device.
In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage or flash storage, for example, a solid-state drive, which can be read into memory for processing by a processor. Also, in some implementations, multiple software technologies can be implemented as sub-parts of a larger program while remaining distinct software technologies. In some implementations, multiple software technologies can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software technology described here is within the scope of the subject technology. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.
A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
These functions described above can be implemented in digital electronic circuitry, in computer software, firmware or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.
Some implementations include electronic components, for example microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media can store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, for example is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some implementations are performed by one or more integrated circuits, for example application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions that are stored on the circuit itself.
As used in this specification and any claims of this application, the terms “computer readable medium” and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.
A system and method is developed to dynamically change the topology of a mesh network connectivity comprised of many mesh nodes and route IP packets across the network in a wireless network, wherein an IP tunnel and a control connection are established between a pair of mesh nodes terminating on the system of invention, so called Mesh App. The Mesh App has several key functions such as collecting local wireless user equipment IP addresses from the local Core Network, and remote IP addresses and routing information from its neighbor Mesh Apps, enabling routing of data traffic hop by hop across the network. Furthermore, it changes the UEs in the ‘reject list’ forcing the disconnection of certain UEs and backhaul modems so as to altering the topology or the network, and distributing the topology change information to its neighbors.
