Optimized network node selection

A device receives Internet protocol (IP) addresses and metrics associated with network nodes of a network, and stores the IP addresses and the metrics in a route table. The device receives, from a user equipment, a request to connect to the network, and determines a particular network node, of the network nodes, to which to forward a communication session of the user equipment, based on the request and based on the metrics stored in the route table. The device forwards the communication session of the user equipment to the particular network node, and the particular network node enables the user equipment to connect to the network.

BACKGROUND

As wireless network data rates improve using third generation (3G), fourth generation (4G), and WiFi technologies, more and more bandwidth-intensive applications are being developed. A 4G wireless network is an all Internet protocol (IP) wireless network in which different advanced multimedia application services (e.g., voice over IP (VoIP) content, video content, etc.) are delivered over IP. 4G wireless networks include a radio access network (e.g., a long term evolution (LTE) network or an enhanced high rate packet data (eHRPD) network) and a wireless core network (e.g., referred to as an evolved packet core (EPC) network). The LTE network is often called an evolved universal terrestrial radio access network (E-UTRAN). The EPC network is an all-IP packet-switched core network that supports high-speed wireless and wireline broadband access technologies. An evolved packet system (EPS) is defined to include the LTE (or eHRPD) network and the EPC network.

A typical LTE network includes an eNodeB (eNB), a mobility management entity (MME), a serving gateway (SGW), and a packet data network (PDN) gateway (PGW). The current method for selecting a MME, SGW, and PGW for a particular eNB includes hard coding associations based on tracking area codes (TACs) assigned by wireless operators across all geographies and based on access point name (APN).

User equipment (UE) may connect to an appropriate eNB in a LTE network based on signal strength. The eNB forwards a request to the MME to select a SGW and a PGW, as well as a backup SGW and a backup PGW, based on querying a domain name system (DNS) that is manually configured with static mappings. The static mappings associate a TAC to the SGW and the MME, and associate an APN to the PGW. The MME obtains the TAC and the APN from a UE attach message, and uses this information to query the DNS. A minimum of two DNS queries must be performed. The first query obtains name authority pointer (NAPTR) records of correct SGWs, and the second query obtains the associated IP addresses of the SGWs. If any changes occur, these DNS entries must be manually configured and updated, which causes latency and load conditions on the DNS. The MME may select a SGW from a list of SGWs returned by the DNS queries.

Once the SGW is selected, the MME may perform DNS queries to obtain a list of PGWs from which to select based on the APN in the UE attach message. Once the MME selects one of the PGWs from the list, the MME may perform DNS queries to obtain an IP address of the selected PGW. Selection of the PGW causes latencies due to the multiple DNS messages and responses, and causes processing load on the MME and the DNS.

After the SGW and the PGW are selected, the SGW and the PGW may begin processing bearer data traffic. If the SGW or the PGW fails while processing bearer data traffic, the only way for the MME to obtain knowledge of the failure is via timeouts that may be thirty seconds or more. This outage time may not be acceptable in many wireless operator networks, such as LTE networks.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Systems and/or methods described herein may provide for optimized selection of network nodes, such as LTE network nodes (e.g., a MME, a SGW, a PGW, etc.), using an integrated control and data plane approach. The systems and/or methods may leverage features in routing protocols, such as the open shortest path first (OSPF) protocol, the intermediate system to intermediate system (IS-IS) protocol, and the enhanced interior gateway routing protocol (EIGRP), that perform longest prefix matching and metrics to select optimal routes. Furthermore, the systems and/or methods may eliminate long latencies in the event of network node failures, may eliminate unequal load on network nodes, and may eliminate complex mappings and manual configurations. The systems and/or methods may automatically load balance among a pool of network nodes by incorporating factors related to load in routing metrics.

In one example implementation, the systems and/or methods may receive a request to connect to a network from a UE, and may receive advertised IP addresses and metrics of network nodes. The systems and/or methods may store the advertised IP addresses and the metrics in a route table, and may determine a particular network node to which to forward a communication session of the UE based on the metrics provided in the route table. The systems and/or methods may route the communication session of the UE to the particular network node, and the particular network node may enable the UE to connect to the network.

The term “metric,” as used herein, is intended to be broadly construed to include a value that provides a network with an aggregated computed cost to reach a destination network node at a particular point in time. The computation of a metric may be configurable, and may be a measure of a load on the destination network node in terms of processor or memory load, congestion of a path to reach the destination network node, etc. At any point in time, network traffic may be forwarded to an optimal destination network node associated with a lowest metric value.

As used herein, the terms “subscriber” and/or “user” may be used interchangeably. Also, the terms “subscriber” and/or “user” are intended to be broadly interpreted to include a UE, or a user of a UE.

The term “component,” as used herein, is intended to be broadly construed to include hardware (e.g., a processor, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a chip, a memory device (e.g., a read only memory (ROM), a random access memory (RAM), etc.), etc.) or a combination of hardware and software (e.g., a processor, microprocessor, ASIC, etc. executing software contained in a memory device).

FIG. 1is a diagram of an example network100in which systems and/or methods described herein may be implemented. As illustrated, network100may include a UE110, an eNB120, and a network130that includes multiple network devices140-1through140-4(collectively referred to herein as “network devices140,” and, in some instances, singularly as “network device140”), a MME150, a PGW160, and a SGW170. Devices and/or networks of network100may interconnect via wired and/or wireless connections. For example, UE110may wirelessly interconnect with eNB120. One UE110, one eNB120, one network130, four network devices140, one MME150, one PGW160, and one SGW170have been illustrated inFIG. 1for simplicity. In practice, there may be more UEs110, eNBs120, networks130, network devices140, MMEs150, PGWs160, and/or SGWs170than depicted inFIG. 1.

UE110may include a radiotelephone; a personal communications system (PCS) terminal that may combine, for example, a cellular radiotelephone with data processing and data communications capabilities; a smart phone; a personal digital assistant (PDA) that can include a radiotelephone, a pager, Internet/intranet access, etc.; a laptop computer; a tablet computer; or other types of computation and/or communication devices. In one example, UE110may include a device that is capable of communicating with network130via eNB120.

eNB120may include one or more computation and/or communication devices that receive information (e.g., routing information, traffic, etc.) from network130and wirelessly transmit that information to UE110. eNB120may also include one or more devices that wirelessly receive information (e.g., connection requests, traffic, etc.) from UE110and transmit that information to network130and/or to other UEs110. eNB120may combine the functionalities of a base station and a radio network controller (RNC) in second generation (2G) or third generation (3G) radio access networks.

Network130may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network, such as the Public Switched Telephone Network (PSTN), an intranet, the Internet, an optical fiber (or fiber optic)-based network, or a combination of networks. In one example implementation, network130may include LTE network nodes, such as MME150, PGW160, SGW170, etc.

Network device140may include one or more traffic transfer devices, such as a gateway, a router, a switch, a firewall, a network interface card (NIC), a hub, a bridge, a proxy server, an optical add-drop multiplexer (OADM), or some other type of device that processes and/or transfers traffic. In one example implementation, network device140may provide for optimized selection of network nodes, such as MME150, PGW160, SGW170, etc., using an integrated control and data plane approach. Network device140may leverage features in routing protocols, such as the OSPF protocol, the IS-IS protocol, and the EIGRP, that perform longest prefix matching and metrics to select optimal routes. Network device140may eliminate long latencies in the event of network node failures, may eliminate unequal load on network nodes, and may eliminate complex mappings and manual configurations. Network device140may automatically load balance among a pool of network nodes by incorporating factors related to load in routing metrics.

MME150may include one or more computation and/or communication devices that may be responsible for idle mode tracking and paging procedures (e.g., including retransmissions) for UE110. MME150may be involved in a bearer activation/deactivation process (e.g., for UE110) and may choose a SGW for UE110at an initial attach and at a time of intra-network handover. MME150may authenticate UE110, and non-access stratum (NAS) signaling may terminate at MME150. MME150may generate and allocate temporary identities to UE110. MME150may check authorization of UE110to camp on a service provider's Public Land Mobile Network (PLMN) and may enforce roaming restrictions for UE110. MME150may be a termination point for ciphering/integrity protection for NAS signaling and may handle security key management. MME150may provide a control plane function for mobility between core and access networks.

PGW160may include one or more traffic transfer devices, such as a gateway, a router, a switch, a firewall, a NIC, a hub, a bridge, a proxy server, an OADM, or some other type of device that processes and/or transfers traffic. In one example implementation, PGW160may provide connectivity of UE110to external PDNs by being a traffic exit/entry point for UE110. UE110may simultaneously connect to more than one PGW160for accessing multiple PDNs. PGW160may perform policy enforcement, packet filtering for each user, charging support, lawful intercept, and packet screening.

SGW170may include one or more traffic transfer devices, such as a gateway, a router, a switch, a firewall, a NIC, a hub, a bridge, a proxy server, an OADM, or some other type of device that processes and/or transfers traffic. In one example implementation, SGW170may act as a mobility anchor for a user plane during inter-eNB handovers. For an idle state UE110, SGW170may terminate a downlink (DL) data path and may trigger paging when DL traffic arrives for UE110. SGW170may manage and store contexts associated with UE110(e.g., parameters of an IP bearer service, network internal routing information, etc.).

AlthoughFIG. 1shows example devices/networks of network100, in other implementations, network100may include fewer devices/networks, different devices/networks, differently arranged devices/networks, or additional devices/networks than depicted inFIG. 1. Alternatively, or additionally, one or more devices/networks of network100may perform one or more other tasks described as being performed by one or more other devices/networks of network100.

FIG. 2is a diagram of example components of a device200that may correspond to one or more devices (e.g., UE110, eNB120, MME150, PGW160, and/or SGW170) of network100(FIG. 1). In one example implementation, one or more of the devices of network100may include one or more devices200or one or more components of device200. As illustrated inFIG. 2, device200may include a bus210, a processing unit220, a memory230, an input device240, an output device250, and a communication interface260.

Bus210may permit communication among the components of device200. Processing unit220may include one or more processors or microprocessors that interpret and execute instructions. In other implementations, processing unit220may be implemented as or include one or more ASICs, FPGAs, or the like.

Memory230may include a RAM or another type of dynamic storage device that stores information and instructions for execution by processing unit220, a ROM or another type of static storage device that stores static information and instructions for the processing unit220, and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.

Input device240may include a device that permits an operator to input information to device200, such as a keyboard, a keypad, a mouse, a pen, a microphone, a touch screen display, one or more biometric mechanisms, and the like. Output device250may include a device that outputs information to the operator, such as a display, a speaker, etc.

Communication interface260may include any transceiver-like mechanism that enables device200to communicate with other devices and/or systems. For example, communication interface260may include mechanisms for communicating with other devices, such as other devices of network100.

AlthoughFIG. 2shows example components of device200, in other implementations, device200may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 2. Alternatively, or additionally, one or more components of device200may perform one or more other tasks described as being performed by one or more other components of device200.

FIG. 3is a diagram of example components of a device300that may correspond to network device140(FIG. 1). In one example implementation, network device140may include one or more devices300or one or more components of device300. As shown inFIG. 3, device300may include input components310, a switching/routing mechanism320, output components330, and a control unit340.

Input components310may be a point of attachment for physical links and may be a point of entry for incoming traffic, such as packets. Input components310may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In an example implementation, input components310may send and/or receive packets.

Switching/routing mechanism320may interconnect input components310with output components330. Switching/routing mechanism320may be implemented using many different techniques. For example, switching/routing mechanism320may be implemented via busses, via crossbars, and/or with shared memories. The shared memories may act as temporary buffers to store traffic from input components310before the traffic is eventually scheduled for delivery to output components330.

Output components330may store packets and may schedule packets for service on output physical links Output components330may include scheduling algorithms that support priorities and guarantees. Output components330may support data link layer encapsulation and decapsulation, and/or a variety of higher-level protocols. In an example implementation, output components330may send packets and/or receive packets.

Control unit340may use routing protocols and one or more forwarding tables for forwarding packets. Control unit340may connect with input components310, switching/routing mechanism320, and output components330. Control unit340may compute a forwarding table, implement routing protocols, and/or run software to configure and manage device300. Control unit340may determine routing for any packet whose destination address may not be found in the forwarding table.

In an example implementation, control unit340may include a bus350that may include a path that permits communication among a processor360, a memory370, and a communication interface380. Processor360may include one or more processors, microprocessors, ASICs, FPGAs, or other types of processing units that may interpret and execute instructions. Memory370may include a RAM, a ROM device, a magnetic and/or optical recording medium and its corresponding drive, and/or another type of static and/or dynamic storage device that may store information and instructions for execution by processor360. Memory370may also temporarily store incoming traffic (e.g., a header of a packet or an entire packet) from input components310, for processing by processor360, before a packet is directed back to switching/routing mechanism320, transported by switching/routing mechanism320, and eventually scheduled to be sent to output components330. Communication interface380may include any transceiver-like mechanism that enables control unit340to communicate with other devices and/or systems.

As described herein, device300may perform certain operations in response to processor360executing software instructions contained in a computer-readable medium, such as memory370. The software instructions may be read into memory370from another computer-readable medium, such as a data storage device, or from another device via communication interface380. The software instructions contained in memory370may cause processor360to perform processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 3shows example components of device300, in other implementations, device300may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 3. Alternatively, or additionally, one or more components of device300may perform one or more other tasks described as being performed by one or more other components of device300.

FIG. 4is a diagram of example MME selection operations capable of being performed by an example portion400of network100(FIG. 1). As shown, network portion400may include UE110, network devices140-1through140-4, a first MME150-1, a second MME150-2, a third MME150-3, PGW160, and SGW170. UE110, network devices140, MMEs150, PGW160, and SGW170may include the features described above in connection with, for example, one or more ofFIGS. 1-3.

As further shown inFIG. 4, first MME150-1may be provided in a first MME pool410-1of multiple MMEs, and may include a physical interface IP address420-1(e.g., address “192.168.1.0”) established with network device140-1. Second MME150-2may be provided in a second MME pool410-2of multiple MMEs, and may include a physical interface IP address420-2(e.g., address “172.1.1.0”) established with network device140-2. Third MME150-3may be provided in a third MME pool410-3of multiple MMEs, and may include a physical interface IP address420-3(e.g., address “168.0.0.1”) established with network device140-3. Physical interface IP addresses420-1,420-2, and420-3may be determined by the network architecture and assigned by a network administrator.

Network device140-4may connect with UE110, via eNB120(not shown), and may include a route table430. Route table430may include a network address field, a next hop field, and a metric field. The network address field may include entries for loopback IP addresses (e.g., IP addresses designated for routing information from an originating device back to a source device without intentional processing or modification) associated with MMEs150. The next hop field may include entries for physical interface IP addresses associated with MMEs150. The metric field may include entries for metrics assigned to MMEs150associated with the physical interface IP addresses identified in the next hop field. The metrics may be influenced by the loads placed on MMEs150, distances to MMEs150, costs of connecting to MMEs150, etc.

In one example implementation, first MME150-1, second MME150-2, and third MME150-3may be assigned a common loopback IP address (e.g., address “1.1.1.1/32”). As further shown inFIG. 4, first MME150-1may advertise, via network device140-1and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of first MME150-1, as indicated by reference number440-1. Second MME150-2may advertise, via network device140-2and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of second MME150-2, as indicated by reference number440-2. Third MME150-3may advertise, via network device140-3and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of third MME150-3, as indicated by reference number440-3. Network device140-4may receive advertisements440-1,440-2, and440-3, and may populate route table430with the information included in advertisements440-1,440-2, and440-3.

UE110may generate a connection request450to connect to network130(not shown), and may provide connection request450to network device140-4. Network device140-4may receive connection request450, and may determine an optimal MME150to which to route a communication session of UE110based on connection request450and based on the metrics provided in route table430. For example, assuming a lower metric value indicates a more optimal MME150, network device140-4may determine that MME150-1(e.g., associated with the next hop of “192.168.1.1”), which has a metric value of one (1), is the optimal MME150to which to route the communication session of UE110.

Based on the determination of the optimal MME150, network device140-4may route the communication session of UE110to MME150-1, as indicated by reference number460. UE110may connect to MME150-1, and MME150-1may enable UE110to connect to network130and receive services470from network130. In one example, MME150-1may serve as a routed device, rather than a host node, so that loopback may be achieved.

AlthoughFIG. 4shows example components of network portion400, in other implementations, network portion400may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 4. Additionally, or alternatively, one or more components of network portion400may perform one or more other tasks described as being performed by one or more other components of network portion400.

FIG. 5is a diagram of example SGW selection operations capable of being performed by another example portion500of network100(FIG. 1). As shown, network portion500may include UE110, network devices140-1through140-4, MME150, PGW160, a first SGW170-1, a second SGW170-2, and a third SGW170-3. UE110, network devices140, MME150, PGW160, and SGWs170may include the features described above in connection with, for example, one or more ofFIGS. 1-4.

As further shown inFIG. 5, first SGW170-1may be provided in a first SGW pool510-1of multiple SGWs, and may include a physical interface IP address520-1(e.g., address “192.168.1.0”) established with network device140-1. Second SGW170-2may be provided in a second SGW pool510-2of multiple SGWs, and may include a physical interface IP address520-2(e.g., address “172.1.1.0”) established with network device140-2. Third SGW170-3may be provided in a third SGW pool510-3of multiple SGWs, and may include a physical interface IP address520-3(e.g., address “168.0.0.1”) established with network device140-3. Physical interface IP addresses520-1,520-2, and520-3may be determined by the network architecture and assigned by a network administrator.

Network device140-4may connect with UE110, via eNB120(not shown), and may include a route table530. Route table530may include a network address field, a next hop field, and a metric field. The network address field may include entries for loopback IP addresses associated with SGWs170. The next hop field may include entries for physical interface IP addresses associated with SGWs170. The metric field may include entries for metrics assigned to SGWs170associated with the physical interface IP addresses identified in the next hop field. The metrics may be influenced by the loads placed on SGWs170, distances to SGWs170, costs of connecting to SGWs170, etc.

In one example implementation, first SGW170-1, second SGW170-2, and third SGW170-3may be assigned a common loopback IP address (e.g., address “1.1.1.1/32”). As further shown inFIG. 5, first SGW170-1may advertise, via network device140-1and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of first SGW170-1, as indicated by reference number540-1. Second SGW170-2may advertise, via network device140-2and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of second SGW170-2, as indicated by reference number540-2. Third SGW170-3may advertise, via network device140-3and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of third SGW170-3, as indicated by reference number540-3. Network device140-4may receive advertisements540-1,540-2, and540-3, and may populate route table530with the information included in advertisements540-1,540-2, and540-3.

UE110may generate a connection request550to connect to network130(not shown), and may provide connection request550to network device140-4. Network device140-4may receive connection request550, and may determine an optimal SGW170to which to route a communication session of UE110based on connection request550and based on the metrics provided in route table530. For example, assuming a lower metric value indicates a more optimal SGW170, network device140-4may determine that SGW170-1(e.g., associated with the next hop of “192.168.1.1”), which has a metric value of one (1), is the optimal SGW170to which to route the communication session of UE110.

Based on the determination of the optimal SGW170, network device140-4may route the communication session of UE110to SGW170-1, as indicated by reference number560. UE110may connect to SGW170-1, and SGW170-1may enable UE110to connect to network130and receive services570from network130. In one example, SGW170-1may serve as a routed device, rather than a host node, so that loopback may be achieved.

AlthoughFIG. 5shows example components of network portion500, in other implementations, network portion500may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 5. Additionally, or alternatively, one or more components of network portion500may perform one or more other tasks described as being performed by one or more other components of network portion500.

FIG. 6is a diagram of example PGW selection operations capable of being performed by still another example portion600of network100(FIG. 1). As shown, network portion600may include UE110, network devices140-1through140-4, MME150, a first PGW160-1, a second PGW160-2, a third PGW160-3, and SGW170. UE110, network devices140, MME150, PGWs160, and SGW170may include the features described above in connection with, for example, one or more ofFIGS. 1-5.

As further shown inFIG. 6, first PGW160-1may be provided in a first PGW pool610-1of multiple PGWs, and may include a physical interface IP address620-1(e.g., address “192.168.1.0”) established with network device140-1. Second PGW160-2may be provided in a second PGW pool610-2of multiple PGWs, and may include a physical interface IP address620-2(e.g., address “172.1.1.0”) established with network device140-2. Third PGW160-3may be provided in a third PGW pool610-3of multiple PGWs, and may include a physical interface IP address620-3(e.g., address “168.0.0.1”) established with network device140-3. Physical interface IP addresses620-1,620-2, and620-3may be determined by the network architecture and assigned by a network administrator.

Network device140-4may connect with UE110, via eNB120(not shown), and may include a route table630. Route table630may include a network address field, a next hop field, and a metric field. The network address field may include entries for loopback IP addresses associated with PGWs160. The next hop field may include entries for physical interface IP addresses associated with PGWs160. The metric field may include entries for metrics assigned to PGWs160associated with the physical interface IP addresses identified in the next hop field. The metrics may be influenced by the loads placed on PGWs160, distances to PGWs160, costs of connecting to PGWs160, etc.

In one example implementation, first PGW160-1, second PGW160-2, and third PGW160-3may be assigned a common loopback IP address (e.g., address “1.1.1.1/32”). As further shown inFIG. 6, first PGW160-1may advertise, via network device140-1and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of first PGW160-1, as indicated by reference number640-1. Second PGW160-2may advertise, via network device140-2and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of second PGW160-2, as indicated by reference number640-2. Third PGW160-3may advertise, via network device140-3and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of third PGW160-3, as indicated by reference number640-3. Network device140-4may receive advertisements640-1,640-2, and640-3, and may populate route table630with the information included in advertisements640-1,640-2, and640-3.

UE110may generate a connection request650to connect to network130(not shown), and may provide connection request650to network device140-4. Network device140-4may receive connection request650, and may determine an optimal PGW160to which to route a communication session of UE110based on connection request650and based on the metrics provided in route table630. For example, assuming a lower metric value indicates a more optimal PGW160, network device140-4may determine that PGW160-1(e.g., associated with the next hop of “192.168.1.1”), which has a metric value of one (1), is the optimal PGW160to which to route the communication session of UE110.

Based on the determination of the optimal PGW160, network device140-4may route the communication session of UE110to PGW160-1, as indicated by reference number660. UE110may connect to PGW160-1, and PGW160-1may enable UE110to connect to network130and receive services670from network130. In one example, PGW160-1may serve as a routed device, rather than a host node, so that loopback may be achieved.

In one example, implementations described herein may assign a common loopback IP address to all network nodes that can be grouped by TACs of a network, along with the physical interface IP addresses. All network nodes associated with a group of TACs may be assigned the same loopback IP address. For example, if particular network nodes are associated with particular TACs, the particular network nodes may have the same loopback IP address and subnet mask. Implementations described herein may utilize the best metric to determine to which network node, in a group of network nodes, to forward UE110. The group of network nodes may be able to modify their associated metrics by incorporating load and other factors that optimize network node selection into the metrics.

In the implementations depicted inFIGS. 4-6, pools (e.g., MME pools, SGW pools, and SGW pools) may be established and may enable the network nodes (e.g., MMEs, SGWs, and PGWs) in the pools to share state information in order to improve load balancing and availability. Network nodes in a pool may use a multicast approach to share the state information associated with a subscriber (e.g., UE110) connection in order to avoid requiring a reconnect.

In the implementations depicted inFIGS. 4-6, the network nodes may assign appropriate values in the metric field during route advertisement to incorporate load and other factors that influence optimal network node selection. In the event of a network node failure, route updates may cease and a route may be retracted for the failed network node so that automatic failure detection and recovery may be provided within seconds. If a new network node is added to network130, a central data storage device may not be updated with information about the new network node. Rather, network130may automatically discover the new network node and may begin receiving subscriber traffic since the routing protocol may automatically recognize the new network node and routes may be advertised. This may reduce the latency involved in identifying the new network node since an IP address of the new network node may be automatically provisioned in the route tables and UE110or eNB120may point to the loopback IP address.

AlthoughFIG. 6shows example components of network portion600, in other implementations, network portion600may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 6. Additionally, or alternatively, one or more components of network portion600may perform one or more other tasks described as being performed by one or more other components of network portion600.

FIG. 7is a diagram of an example deployment scenario700according to an implementation described herein. As shown, scenario700may include four tracking area codes (TACs)710-A,710-B,710-C, and710-D (collectively referred to herein as “TACs710,” and, in some instances, singularly as “TAC710”) and six zones720-1through720-6(collectively referred to herein as “zones720,” and, in some instances, singularly as “zone720”). Each TAC710may include one or more UEs110and eNBs120. Each zone720may include MME150, PGW160, and SGW170. UEs110, eNBs120, MMEs150, PGWs160, and SGWs170may include the features described above in connection with, for example, one or more ofFIGS. 1-6.

As further shown inFIG. 7, eNBs120may interconnect with networks730. Network730may include a LAN, a WAN, a MAN, a telephone network, such as the PSTN, an intranet, the Internet, an optical fiber (or fiber optic)-based network, or a combination of networks.

Based on this example, SGW170located in zone720-1may service TAC710-A and710-C and SGW170may be configured with two loopback IP addresses: “1.1.1.1/32” and “1.1.1.3/32.” All other zones720that contain a SGW170may be configured accordingly with the loopback IP addresses as specified in the example. If a particular eNB120in TAC710-A is searching for a SGW170, the particular eNB120may attempt to connect with a SGW170via loopback IP address “1.1.1.1/32.” The candidate SGWs170that may serve the particular eNB120may include SGWs170associated with loopback IP address “1.1.1.1/32,” which may include SGWs170provided in zones720-1,720-2,720-3,720-5, and720-6, as specified in the example. An internal routing protocol may control an actual route to an optimal SGW170by automatically configuring and load balancing to the optimal SGW170based on metrics.

AlthoughFIG. 7shows example components of scenario700, in other implementations, scenario700may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 7. Additionally, or alternatively, one or more components of scenario700may perform one or more other tasks described as being performed by one or more other components of scenario700.

FIG. 8is a diagram of example MME metric computations capable of being performed by a further example portion800of network100(FIG. 1). As shown, network portion800may include eNB120, network devices140-1through140-4, first MME150-1, second MME150-2, and third MME150-3. eNB120, network devices140, and MMEs150may include the features described above in connection with, for example, one or more ofFIGS. 1-7.

As further shown inFIG. 8, first MME150-1may compute key performance indicators (KPIs)810-1, such as an attach failure ratio, a handover failure ratio, latency, jitter, frame loss, bandwidth, a distance, a cost, etc., as well as raw statistics that determine a load on first MME150-1. First MME150-1may utilize KPIs810-1and the raw statistics to compute a metric value840-1associated with first MME150-1, as indicated by reference number820-1. A protocol process, such as an OSPF process830-1, may receive metric value840-1and may advertise metric value840-1to network device140-1.

Second MME150-2may compute KPIs810-2, such as an attach failure ratio, a handover failure ratio, latency, jitter, frame loss, bandwidth, a distance, a cost, etc., as well as raw statistics that determine a load on second MME150-2. Second MME150-2may utilize KPIs810-2and the raw statistics to compute a metric value840-2associated with second MME150-2, as indicated by reference number820-2. A protocol process, such as an OSPF process830-2, may receive metric value840-2and may advertise metric value840-2to network device140-2.

Third MME150-3may compute KPIs810-3, such as an attach failure ratio, a handover failure ratio, latency, jitter, frame loss, bandwidth, a distance, a cost, etc., as well as raw statistics that determine a load on third MME150-3. Third MME150-3may utilize KPIs810-3and the raw statistics to compute a metric value840-3associated with third MME150-3, as indicated by reference number820-3. A protocol process, such as an OSPF process830-3, may receive metric value840-3and may advertise metric value840-3to network device140-3.

An interior routing protocol may enable network devices140to provide metric values840-1,840-2, and840-3in a route table that may be used to automatically route to an optimal MME150at any particular point in time. In one example implementation, the operations depicted inFIG. 8may be utilized for PGW160and/or SGW170selection and routing.

AlthoughFIG. 8shows example components of network portion800, in other implementations, network portion800may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 8. Additionally, or alternatively, one or more components of network portion800may perform one or more other tasks described as being performed by one or more other components of network portion800.

FIGS. 9-11are flow charts of an example process900for performing optimized network node selection according to an implementation described herein. In one implementation, process900may be performed by one or more network devices140. Alternatively, or additionally, some or all of process900may be performed by another device or group of devices, including or excluding one or more network devices140.

As shown inFIG. 9, process900may include receiving a request to connect to a network from a UE (block910), and receiving advertised IP addresses and metrics associated with network nodes (block920). For example, in an implementation described above in connection withFIG. 4, first MME150-1, second MME150-2, and third MME150-3may be assigned a common loopback IP address (e.g., address “1.1.1.1/32”). First MME150-1may advertise, via network device140-1and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of first MME150-1, as indicated by reference number440-1. Second MME150-2may advertise, via network device140-2and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of second MME150-2, as indicated by reference number440-2. Third MME150-3may advertise, via network device140-3and to network device140-4, the common loopback IP address, the physical interface IP address, and the metrics of third MME150-3, as indicated by reference number440-3. Network device140-4may receive advertisements440-1,440-2, and440-3. UE110may generate connection request450to connect to network130(not shown), and may provide connection request450to network device140-4. Network device140-4may receive connection request450.

As further shown inFIG. 9, process900may include providing the advertised IP addresses and metrics in a route table (block930), and determining a particular network node to which to forward the UE based on the metrics provided in the route table (block940). For example, in an implementation described above in connection withFIG. 4, network device140-4may receive advertisements440-1,440-2, and440-3, and may populate route table430with the information included in advertisements440-1,440-2, and440-3. Network device140-4may determine an optimal MME150to which to route a communication session of UE110based on connection request450and based on the metrics provided in route table430. In one example, assuming a lower metric value indicates a more optimal MME150, network device140-4may determine that MME150-1(e.g., associated with the next hop of “192.168.1.1”), which has a metric value of one (1), is the optimal MME150to which to route the communication session of UE110.

Returning toFIG. 9, process900may include routing the UE to the particular network node, where the particular network node enables the UE to connect to the network (block950). For example, in an implementation described above in connection withFIG. 4, based on the determination of the optimal MME150, network device140-4may route the communication session of UE110to MME150-1, as indicated by reference number460. UE110may connect to MME150-1, and MME150-1may enable UE110to connect to network130and receive services470from network130. In one example, MME150-1may serve as a routed device, rather than a host node, so that loopback may be achieved.

Process block940may include the process blocks depicted inFIG. 10. As shown inFIG. 10, process block940may include determining loads associated with the network nodes (block1000), determining distances associated with the network nodes (block1010), and determining costs associated with the network nodes (block1020). For example, in an implementation described above in connection withFIG. 4, network device140-4may include route table430. Route table430may include a network address field, a next hop field, and a metric field. The network address field may include entries for loopback IP addresses associated with MMEs150. The next hop field may include entries for physical interface IP addresses associated with MMEs150. The metric field may include entries for metrics assigned to MMEs150associated with the physical interface IP addresses identified in the next hop field. The metrics may be influenced by the loads placed on MMEs150, distances to MMEs150, costs of connecting to MMEs150, etc.

As further shown inFIG. 10, process block940may include calculating metrics for the network nodes based on the loads, the distances, and the costs (block1030), providing the calculated metrics to the route table (block1040), and selecting the particular network node based on the calculated metrics provided in the route table (block1050). For example, in an implementation described above in connection withFIG. 8, first MME150-1may compute KPIs810-1, such as an attach failure ratio, a handover failure ratio, latency, jitter, frame loss, bandwidth, a distance, a cost, etc., as well as raw statistics that determine a load on first MME150-1. First MME150-1may utilize KPIs810-1and the raw statistics to compute metric value840-1associated with first MME150-1, as indicated by reference number820-1. A protocol process, such as OSPF process830-1, may receive metric value840-1and may advertise metric value840-1to network device140-1. An interior routing protocol may enable network devices140to provide metric values840-1,840-2, and840-3in a route table that may be used to automatically route to an optimal MME150at any particular point in time.

Process block1000may include the process blocks depicted inFIG. 11. As shown inFIG. 11, process block1000may include receiving the loads associated with the network nodes based on key performance indicators calculated by the network nodes (block1100), and receiving the loads associated with the network nodes based on raw load statistics calculated by the network nodes (block1110). For example, in an implementation described above in connection withFIG. 8, first MME150-1may compute KPIs810-1, such as an attach failure ratio, a handover failure ratio, latency, jitter, frame loss, bandwidth, a distance, a cost, etc., as well as raw statistics that determine a load on first MME150-1. First MME150-1may utilize KPIs810-1and the raw statistics to compute metric value840-1associated with first MME150-1, as indicated by reference number820-1. A protocol process, such as OSPF process830-1, may receive metric value840-1and may advertise metric value840-1to network device140-1.

Systems and/or methods described herein may provide for optimized selection of network nodes, such as LTE network nodes (e.g., a MME, a SGW, a PGW, etc.), using an integrated control and data plane approach. The systems and/or methods may leverage features in routing protocols, such as the OSPF protocol, the IS-IS protocol, and the EIGRP, that perform longest prefix matching and metrics to select optimal routes. Furthermore, the systems and/or methods may eliminate long latencies in the event of network node failures, may eliminate unequal load on network nodes, and may eliminate complex mappings and manual configurations. The systems and/or methods may automatically load balance among a pool of network nodes by incorporating factors related to load in routing metrics.

For example, while series of blocks have been described with regard toFIGS. 9-11, the order of the blocks may be modified in other implementations. Further, non-dependent blocks may be performed in parallel.