System and method for managing tracking area identity lists in a mobile network environment

A method is provided in one example embodiment and includes communicating a plurality of queries associated with common tracking areas in a wireless network; identifying a set of serving gateways that serve the common tracking areas; generating a tracking area identity (TAI) list to be used in provisioning network resources for user equipment; and selecting a first serving gateway from the set of serving gateways for the user equipment, wherein the first serving gateway is selected based on the common tracking areas served by the set of serving gateways. In more specific embodiments, the queries are domain name system (DNS) queries that are supported by a network element and that have no cached DNS response.

TECHNICAL FIELD

This disclosure relates in general to the field of communications, and more particularly, to a system and a method for managing tracking area identity lists in a mobile network environment.

BACKGROUND

Networking architectures have grown increasingly complex in communications environments, particularly mobile wireless environments. Mobile data traffic has grown extensively in recent years, which has significantly increased the demands on radio resources. As the subscriber base of end users increases, efficient management of communication resources becomes even more critical. In some instances, failure of a network element may cause user equipment to detach and then reattach to the network, which may waste valuable radio resources and potentially create overload conditions in other network elements. Hence, there is a significant challenge in managing radio resources, particularly when certain network elements fail.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

A method is provided in one example embodiment and includes communicating a plurality of queries associated with common tracking areas in a wireless network; identifying a set of serving gateways that serve the common tracking areas; generating a tracking area identity (TAI) list to be used in provisioning network resources for user equipment; and selecting a first serving gateway from the set of serving gateways for the user equipment, wherein the first serving gateway is selected based on the common tracking areas served by the set of serving gateways. In more specific embodiments, the queries are domain name system (DNS) queries that are supported by a network element and that have no cached DNS response.

In other instances, example embodiments of the present disclosure may include relocating the user equipment to a second serving gateway in the set of serving gateways without detaching the user equipment. In other cases, the method can include relocating the user equipment to a second serving gateway in the set of serving gateways in response to a failure of the first serving gateway. A weight factor can be calculated for each common tracking area, the weight factor being representative of a number of eNodeBs that are not in an eNodeB group of the user equipment's current tracking area identity (TAI). Assigned tracking areas can be determined by selecting the common tracking areas having lower weight factors.

Example Embodiments

Turning toFIG. 1,FIG. 1is a simplified block diagram of a communication system10for managing tracking area identity lists in a mobile wireless network environment. This particular configuration may be tied to the 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) architecture, also sometimes referred to as the Long-Term Evolution (LTE) EPS architecture, but alternatively this depicted architecture may be applicable to other environments equally. The example architecture ofFIG. 1includes multiple end users operating user equipment (UE)12a-cand a packet data network (PDN) gateway (PGW)14, which has a logical connection to a serving gateway (SGW)28. Also provided is a home subscriber server (HSS)18and an Authentication, Authorization, and Accounting (AAA) element24. SGW28has a logical connection to an eNodeB34and a Mobility Management Entity (MME)40. Both SGW28and PGW14can interface with a Policy and Charging Rules Function (PCRF)36.

Each of the elements ofFIG. 1may couple to one another through simple interfaces (as illustrated) or through any other suitable connection (wired or wireless), which provides a viable pathway for network communications. Additionally, any one or more of these elements may be combined or removed from the architecture based on particular configuration needs. Communication system10may include a configuration capable of transmission control protocol/Internet protocol (TCP/IP) communications for the transmission or reception of packets in a network. Communication system10may also operate in conjunction with a user datagram protocol/IP (UDP/IP) or any other suitable protocol where appropriate and based on particular needs.

Also provided in the architecture ofFIG. 1is a series of interfaces, which can offer mobility, policy control, AAA functions, and charging activities for various network elements. For example, interfaces can be used to exchange point of attachment, location, and access data for one or more end users. Resource, accounting, location, access network information, network address translation (NAT) control, etc. can be exchanged using a remote authentication dial in user service (RADIUS) protocol, or any other suitable protocol where appropriate. Other protocols to be used in such communications can include Diameter, service gateway interface (SGI), terminal access controller access-control system (TACACS), TACACS+, etc.

There are two access cases represented inFIG. 1, which depicts these as trusted and untrusted non-3GPP IP access. For the trusted scenario, a viable relationship exists between the service provider and the core network. For the untrusted scenario, a suitable security mechanism can be provided to ensure the integrity of the data communications (e.g., encryption and decryption operations can occur in this scenario and, further, involve an evolved packet data gateway (ePDG), which has a logical connection to PCRF36as shown inFIG. 1).

In more general terms, 3GPP defines the Evolved Packet System (EPS) as specified in TS 23.401, TS.23.402, TS 23.203, etc. The EPS generally consists of IP access networks and an Evolved Packet Core (EPC). Access networks may be 3GPP access networks, such a GERAN, UTRAN, and E-UTRAN, or they may be non-3GPP IP access networks such as digital subscriber line (DSL), Cable, WiMAX, code division multiple access (CDMA) 2000, WiFi, or the Internet. Non-3GPP IP access networks can be divided into trusted and untrusted segments. Trusted IP access networks support mobility, policy, and AAA interfaces to the EPC, whereas untrusted networks do not. Instead, access from untrusted networks is done via the ePDG, which provides for IPsec security associations to the user equipment over the untrusted IP access network. The ePDG (in turn) supports mobility, policy, and AAA interfaces to the EPC, similar to the trusted IP access networks.

Before detailing the operations and the infrastructure ofFIG. 1, certain contextual information is provided to offer an overview of some problems that may be encountered while managing radio resources in a mobile wireless network environment. Such information is offered earnestly and for teaching purposes only and, therefore, should not be construed in any way to limit the broad applications for the present disclosure.

When the UE attaches to an access network, it should be assigned a list of tracking area identities (TAIs). The UE can be mobile within these TAIs without updating the MME. If the UE moves to a TAI that is not within the assigned TAI list, the UE sends a Tracking Area Update (TAU) message to the MME, which triggers an SGW relocation. The data path from the UE to the network commonly is through an eNodeB and an SGW. An SGW can serve a set of TAIs. Selection of a TAI list for a UE is an MME function usually. The MME can ensure that all the TAIs in the TAI list are served by the selected SGW, as specified in TS 23.401. Domain Name Service (DNS) procedures provide a mechanism for finding an SGW that serves a particular TAI, but there is no such mechanism for reverse mapping. Thus, there is currently no viable strategy for computing a list of TAIs that an SGW supports. Consequently, if an SGW fails while supporting a call, the MME detaches the UE.

Choosing another SGW that supports the current UE TAI is not sufficient since the UE could move to a TAI that is not supported by the new SGW without sending a TAU to the MME (e.g., if the UE moves to a new TAI that is in its current TAI list). Hence, a TAI-to-SGW mapping may be available using DNS, but the list of TAIs that an SGW supports is not readily available. The MME should cache DNS responses for multiple TAIs, identify which SGW is common in response to multiple queries, and suitably manage this list. Separately, any TAI list that the MME assigns to the UE should be served by the selected SGW.

Logistically, when an SGW fails in existing architectures, an MME detects this event. The MME is forced to detach the UEs that are supported by the failed SGW. Without the cached and processed DNS query result, the most that an MME could do is to select an SGW that supports the current TAI of the UE; however, the MME has no mechanism for changing the UE tracking area list. Having the cached and processed DNS query result, but not having the SGW serving area grouping, the MME could attempt to find an SGW that supports all the TAIs currently assigned to the UE. This would be processing intensive and, furthermore, there is no mechanism to ensure that another SGW could be found.

In accordance with one embodiment, communication system10can overcome the aforementioned shortcomings (and others) by providing TAI list management based on SGW serving areas. When an eNodeB sends a setup request to an MME, and the MME accepts this request, the MME can send DNS queries for all the TAIs that are supported by the new eNodeB, but that currently have no cached DNS response. Note that some TAIs could have been queried in the context of processing setup requests from another eNodeB because multiple eNodeBs can service the same TAI. By processing the DNS responses, the MME can build sets of SGWs that serve common TAIs. In some embodiments, an SGW can belong to multiple sets, but the SGWs that belong to the same set can serve the same TAIs. A TAI may be an element in exactly one SGW set.

In operation, MME40can learn the serving areas of an SGW using DNS operations. MME40is configured to construct sets or groups of SGWs that serve common TAIs. Such groups of SGWs are included in an “SGW serving area.” According to one embodiment, a TAI belongs to exactly one SGW serving area, where all TAIs belonging to an SGW serving area are served by the SGWs that belong to it, and an SGW may be part of multiple SGW serving areas. Similarly, eNodeBs that serve the same TAIs may be grouped together. Such a group of eNodeBs is referred to herein as an “eNodeB group.”

When the SGW serving area solution is used, the MME can choose any SGW in the same SGW serving area. To relocate a UE in the ECM_IDLE state, the MME should create a session in the new SGW for each PDN to which the UE is attached. Similarly, to relocate a UE in the ECM_CONNECTED state, the MME should create a session in the new SGW for each PDN to which the UE is attached and, subsequently, move the UE to an idle state by releasing the UE eNB context. The UE can then send a Service Request to start using the network.

If the TAI list that is assigned to a UE is limited to TAIs within the same SGW serving area, and the SGW serving a particular UE fails, then the MME can relocate the UE to one of the other SGWs in the SGW serving area. The term ‘relocate’ is inclusive of operations associated with provisioning, allocating, distributing, or otherwise managing the network resources. To do SGW relocation if an SGW fails, all the TAIs in the TAI list assigned to the UE should be supported by the new SGW.

Constructing SGW serving areas and allocating TAI lists based such elements enables the MME to relocate the call to another SGW within the SGW serving area without having to check if all the TAIs are supported by the new SGW. Thus, failure of an SGW could be handled similar to an SGW relocation, which avoids the paging of idle UEs, the detaching UEs, and the reattaching UEs. This could minimize interactions with network elements and, further, conserve resources of the radio network. It also allows the UEs to remain attached to the EPS network if an SGW fails.

Note that in certain embodiments, the number of TAIs in a list may be limited to sixteen, which is the maximum amount that currently can be assigned in NAS messaging. The number of TAIs in a list is configurable and, therefore, can vary considerably from an operational perspective. In a particular example, the number of SGWs to be deployed for the logical area covered by the TAIs in a list would be operator dependent. In one instance, at least two could be deployed for load balancing/geographical redundancy purposes. Additional details relating to the operational capabilities of communication system10are provided below. Before turning to those capabilities and additional features, the infrastructure ofFIG. 1is discussed.

Returning toFIG. 1, UE12a-ccan be associated with clients or customers wishing to initiate a flow in communication system10via some network. The terms ‘user equipment’, ‘mobile node’, ‘end user’, ‘and ‘subscriber’ are inclusive of devices used to initiate a communication, such as a computer, a personal digital assistant (PDA), a laptop or electronic notebook, a cellular telephone, an i-Phone, i-Pad, a Google Droid phone, an IP phone, or any other device, component, element, or object capable of initiating voice, audio, video, media, or data exchanges within communication system10. UE12a-cmay also be inclusive of a suitable interface to the human user such as a microphone, a display, a keyboard, or other terminal equipment. UE12a-cmay also be any device that seeks to initiate a communication on behalf of another entity or element such as a program, a database, or any other component, device, element, or object capable of initiating an exchange within communication system10. Data, as used herein in this document, refers to any type of numeric, voice, video, media, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another. In certain embodiments, UE12a-chave a bundled subscription for network access and application services (e.g., voice), etc. Once the access session is established, the user can register for application services as well, without additional authentication requirements. There can be two different user data repositories (AAA databases): one for the access user profile and one for the application user profile. IP addresses can be assigned using dynamic host configuration protocol (DHCP), Stateless Address Auto-configuration, default bearer activation, etc., or any suitable variation thereof.

PCRF36is a network element responsible for coordinating charging and/or policy decisions for UE12a-c. PCRF36can be configured to use subscription information as a basis for the policy and charging control decisions. The subscription information may apply for both session-based and non-session based services. PCRF36can maintain session linking to the sessions via policy interactions with PGW14(and possibly SGW28) and application functions (e.g., provided as part of the operator's IP services). An application function (AF) can be provided within PCRF36(or simply interact with PCRF36) in order to offer applications that require dynamic policy and/or charging control. The AF can communicate with PCRF36to transfer dynamic session information. Additionally, any type of policy and/or charging control element (e.g., PCC infrastructure) can be provided within (or suitably interact with) PCRF36.

HSS18offers a subscriber database in 3GPP (e.g., GSM, LTE, etc.) environments. In one sense, HSS18can provide functions similar to those offered by an AAA server in a CDMA environment. When a user moves to 3GPP access, HSS18can be aware of this location and this anchor point (i.e., PGW14). Additionally, HSS18can communicate with AAA element24such that when a UE moves to a CDMA environment, it still has an effective anchor for communications (i.e., PGW14). HSS18and AAA element24can coordinate this state information for the UE (and synchronize this information) to achieve mobility. No matter how a UE moves, the access network element can be interacting with either HSS18or AAA element24in order to identify which PGW should receive the appropriate signaling. The route to a UE can be consistently maintained, where routing topology ensures that data is sent to the correct IP address. Thus, synchronization activity on the backend of the architecture allows mobility to be achieved for the user when operating in different environments. Additionally, in certain examples, PGW14performs home agent functions, and the trusted non-3GPP IP access network can provide packet data serving node (PDSN) functions in order to achieve these objectives.

AAA element24is a network element responsible for accounting, authorization, and authentication functions for UEs12a-c. For the AAA considerations, AAA element24may provide the mobile node IP address and the accounting session identification (Acct-Session-ID) and other mobile node states in appropriate messaging (e.g., via an access-Request/access-Accept message). An accounting message can be sent for the following events: accounting-start when the IP session is initially created for the mobile node on the gateway; accounting-interim-update when a handover occurred between gateways; and an accounting-stop when the IP session is removed from the gateway serving the element. For roaming scenarios, the home routed case is fully supported by the architecture.

The EPC generally comprises an MME, an SGW, a PGW, and a PCRF. The MME is the primary control element for the EPC. Among other things, the MME provides tracking area list management, idle mode UE tracking, bearer activation and deactivation, SGW and PGW selection for UEs, and authentication services. The SGW is a data plane element that can manage user mobility and interfaces with Radio Access Networks. The SGW also maintains the data paths between eNodeBs and the PGW, and serves as a mobility anchor when UEs move across areas served by different eNodeBs. The PGW provides connectivity for UEs to external packet data networks. The PCRF detects service flows and enforces charging policies.

Radio Access Networks (RANs) in an EPS architecture consist of eNodeBs (also known as eNBs). An eNodeB is generally connected directly to an EPC, as well as to adjacent eNodeBs. Connections with adjacent eNodeBs allow many calls to be routed more directly, often with minimal or no interaction with an EPC. An eNodeB is also responsible for selecting an MME for UEs, managing radio resources, and making handover decisions for UEs.

In operation, UE12acan attach to the network for purposes of establishing a communication session. UE12acan communicate with eNodeB34, which can further interact with MME40to complete some form of authentication for a particular user. MME40can interact with SGW28, which interacts with PGW14such that a session is being setup between these components. Tunnels could be established at this juncture, and a suitable IP address would also be issued for this particular user. This process generally involves a default EPS bearer being created for UE12a. As the session is established, PGW14can interact with PCRF36to identify policies associated with this particular user, such as a certain QoS setting, bandwidth parameter, latency setting, priority, billing, etc.

Turning toFIG. 2,FIG. 2is a simplified block diagram illustrating additional details associated with one potential embodiment of communication system10.FIG. 2includes PGW14, SGW28, eNodeB34, PCRF36, and MME40. Each of these elements includes a respective processor30a-eand a respective memory element32a-e. MME40also includes a TAI list management module26and a TAI list management database42in this particular example. Hence, appropriate software and/or hardware is being provisioned in MME40in order to facilitate the TAI list management activities discussed herein. Alternatively, such a mechanism can be provisioned in any of the other elements ofFIGS. 1-2. Such provisioning may be based on particular operator constraints, particular networking environments, or specific protocol parameters. Note that in certain examples, TAI list management database42can be consolidated with memory elements (or vice versa), or the storage can overlap/exist in any other suitable manner. Also depicted inFIG. 2is UE12a-b, where these devices can attach to respective networks in order to conduct their communication sessions.

In one example implementation, PGW14, SGW28, eNodeB34, and/or MME40are network elements, which are meant to encompass network appliances, servers, routers, switches, gateways, bridges, loadbalancers, firewalls, processors, modules, or any other suitable device, component, element, or object operable to exchange information in a network environment. Moreover, the network elements may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.

In regards to the internal structure associated with communication system10, each of PGW14, SGW28, eNodeB34, and/or MME40can include memory elements (as shown inFIG. 2) for storing information to be used in achieving the TAI list management operations, as outlined herein. Additionally, each of these devices may include a processor that can execute software or an algorithm to perform the TAI list management activities discussed herein. These devices may further keep information in any suitable memory element [(e.g., random access memory (RAM), read only memory (ROM), an erasable programmable read only memory (EPROM), application specific integrated circuit (ASIC), etc.], software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs. Any of the memory items discussed herein should be construed as being encompassed within the broad term ‘memory element.’ The information being tracked or sent by PGW14, SGW28, eNodeB34, and/or MME40could be provided in any database, queue, register, control list, or storage structure, all of which can be referenced at any suitable timeframe. Any such storage options may be included within the broad term ‘memory element’ as used herein. Similarly, any of the potential processing elements, modules, and machines described herein should be construed as being encompassed within the broad term ‘processor.’ Each of the network elements and user equipment (e.g., mobile nodes) can also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment.

In one example implementation, PGW14, SGW28, eNodeB34, and/or MME40include software (e.g., as part of TAI list management module26, etc.) to achieve, or to foster, the TAI list management operations, as outlined herein. In other embodiments, this feature may be provided externally to these elements, or included in some other network device to achieve this intended functionality. Alternatively, these elements include software (or reciprocating software) that can coordinate in order to achieve the operations, as outlined herein. In still other embodiments, one or all of these devices may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof.

Note that in certain example implementations, the TAI list management functions outlined herein may be implemented by logic encoded in one or more tangible media (e.g., embedded logic provided in an ASIC, in DSP instructions, software [potentially inclusive of object code and source code] to be executed by a processor, or other similar machine, etc.). In some of these instances, memory elements [as shown inFIG. 2] can store data used for the operations described herein. This includes the memory elements being able to store software, logic, code, or processor instructions that are executed to carry out the activities described herein. A processor can execute any type of instructions associated with the data to achieve the operations detailed herein. In one example, the processors [as shown inFIG. 2] could transform an element or an article (e.g., data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), a digital signal processor (DSP), an EPROM, EEPROM) or an ASIC that includes digital logic, software, code, electronic instructions, or any suitable combination thereof.

Turning toFIG. 3,FIG. 3is a simplified block diagram illustrating an example configuration92associated with TAI list management module40and TAI list management database42.FIG. 3shows the relationships between certain elements in one embodiment of TAI list management database42. For example, TAI list management database42may store information about serving gateway A and serving gateway B, which may have an M:N relationship to serving area1and to serving area2. Serving area1and serving area2, in turn, can be each associated with N TAIs. In the example ofFIG. 3, serving area1is associated with TAI1and TAI2, while serving area2is associated with TAI3. Each eNodeB can be associated with one or more TAIs such that, inFIG. 3, eNodeB1is associated with TAI1and TAI2, and eNodeB2is associated with TAI3. Each eNodeB can also be associated with an eNodeB group. An eNodeB group is a set of eNodeBs that serve the same TAIs. Thus, an eNodeB group may be characterized by a set of TAIs and a set of eNodeBs, where a TAI is in one eNodeB group. InFIG. 3, for example, eNodeB1serves both TAI1and TAI2, so eNodeB1, TAI1, and TAI2are associated with eNodeB group1. eNodeB2serves TAI3, where both are associated with eNodeB group2.

Certain network events may affect the information in TAI list management database42. For example, DNS queries may be used for identifying an SGW that serves a TAI. The response to the DNS query can include a list of all SGWs that serve the TAI. The first time a DNS query response is received, the list of SGWs can be compared with existing SGW serving areas. If any of the existing SGW serving areas have the same list of SGWs as indicated in the DNS response, the TAI can be added to that SGW serving area. Otherwise, a new SGW serving area can be created and the TAI can be added to the new SGW serving area. The TAI list for the TAI that started the query can subsequently be calculated. If the response is a refresh, the current SGW serving area of the TAI may be checked to determine if the DNS response includes the same set of SGWs. If not, the TAI should be removed from the SGW serving area. TAI lists of the remaining TAIs in the old SGW serving area may then be determined. A new SGW serving area for the TAI can be determined as if it was the first DNS response. If the DNS response includes the same set of SGWs, then no further changes may be necessary.

FIG. 4is a simplified flowchart400illustrating example operations associated with processing an eNodeB setup request in one example operation of communication system10. In one particular embodiment, these operations may be carried out by TAI list management module26in MME40. At any time prior to a UE attaching to the network, an eNodeB can establish a connection with MME40using a setup request and response messages. In general, the eNodeB is configured to send a list of supported TAIs in the setup request message. Thus, processing starts when the list of TAIs is received. The first TAI in the list may be compared to existing eNodeB groups at405. If a matching eNodeB group is found, then the remaining TAIs in the list can be compared with the TAI list of the matching eNodeB group at410. If all of the TAIs in the eNodeB group are supported by the eNodeB sending the setup request, then no further processing may be required. If the TAI list of the eNodeB does not fit into any existing eNodeB group, a new eNodeB group can be created at415. If all the TAIs that are supported by the eNodeB are new, then a new eNodeB group is created to include the eNodeB and its TAIs (indicated at420), where no further processing is required. However, if at least one of the TAIs is already known, then for each TAI supported by the eNodeB, the TAI should be removed from its current eNodeB group at425. If any other existing eNodeB group supports the exact list of eNodeBs as the removed TAI, then the TAI may be added to that eNodeB group at430. If no such eNodeB group is found, a new eNodeB group can be created at435, and the removed TAI can be added to the new group at435.

FIG. 5is a simplified flowchart500illustrating example operations associated with removing an eNodeB from TAI list management database42in one embodiment of communication system10. In one particular embodiment, these operations may be carried out by TAI list management module26in MME40. Alternatively, such activities can be performed by any network element of communication system10. For all of the eNodeB groups to which the eNodeB belongs, the eNodeB may be removed from the groups at505. For each eNodeB group from which the eNodeB is removed, a determination is made if the group can be merged with another group (indicated at510). For example, two eNodeB groups may be merged if they have the same set of eNodeBs in them. If the eNodeB group (from which the eNodeB has been removed) can possibly be merged with another group, it can be merged with the other group at515.

The example operations illustrated inFIG. 4andFIG. 5may also be associated with processing an eNodeB configuration update request. In some scenarios, a configuration update may not include a TAI list, in which case no additional processing may be necessary. However, if the configuration update request results in an additional eNodeB, the request may be processed similar to that which is described above inFIG. 4. If the configuration update request results in the removal of an eNodeB, the request may be processed similarly to that which is described inFIG. 5.

In one embodiment of communication system10, TAI lists assigned to a UE are linked lists into which TAIs may be inserted or removed. As noted above, all of the TAIs in such a list should be serviced by the same SGW. Moreover, additional criteria may make a TAI list more effective. For example, if all of the TAIs assigned to a UE are in the same SGW serving area, an MME may be better able to process an SGW failure by transferring calls to any of the other SGWs in the same SGW serving area. In another example, the number of eNodeBs that need to be paged in certain scenarios may be reduced, provided the number of eNodeB groups that is used to generate a TAI list is reduced.

FIG. 6is a simplified flowchart600illustrating example operations associated with maintaining a list of TAIs for a UE in one embodiment of communication system10. In one particular embodiment, these operations may be carried out by TAI list management module26in MME40. In this example embodiment, the linked list may be maintained based on increasing weights. For example, the weights may be the number of eNodeBs that are not in the eNodeB group of the UE's current TAI. Thus, as is depicted inFIG. 6, a weight factor for adding a TAI to a TAI list is calculated by comparing the eNodeB groups of the TAIs at605and, subsequently, adding it to a candidate pool of TAIs at610. This operation is repeated for all the TAIs in the SGW serving area of the current TAI. The TAIs with a weight factor of zero are selected as the initial TAI list at615. While the number of selected TAIs (X) is less than the maximum number of allowed TAIs (Xmax) and the total eNodeB count (Y) is less than the maximum allowed eNodeB count (Ymax), the TAI that is at the front of the list is selected at620, and the rest of the list is updated at625. The weights of the other elements in the list may change if new eNodeBs have been added.

The computation of a TAI list need not occur at each call instance. For example, the computation can be done when the information in TAI list management database42changes in a way that could affect the TAI list for a TAI. Certain events may trigger these changes, such as an eNodeB configuration update, or an S1 setup that changes the eNodeB group to which a TAI belongs, a DNS query result that changes the SGW pool to which the TAI belongs, or a configuration update that changes the SGW list that supports the TAI. Once a TAI list is computed, it can be assigned on a per-call basis.

Note that with the examples provided above, as well as numerous other examples provided herein, interaction may be described in terms of two, three, or four network elements. However, this has been done for purposes of clarity and example only. In certain cases, it may be easier to describe one or more of the functionalities of a given set of flows by only referencing a limited number of network elements. It should be appreciated that communication system10(and its teachings) are readily scalable and can accommodate a large number of components, as well as more complicated/sophisticated arrangements and configurations. Accordingly, the examples provided should not limit the scope or inhibit the broad teachings of communication system10as potentially applied to a myriad of other architectures. Additionally, although described with reference to particular scenarios, where a TAI list management module is provided within the network elements, these modules can be provided externally, or consolidated and/or combined in any suitable fashion. In certain instances, a TAI list management module may be provided in a single proprietary unit.

It is also important to note that the steps in the appended diagrams illustrate only some of the possible signaling scenarios and patterns that may be executed by, or within, communication system10. Some of these steps may be deleted or removed where appropriate, or these steps may be modified or changed considerably without departing from the scope of teachings provided herein. In addition, a number of these operations have been described as being executed concurrently with, or in parallel to, one or more additional operations. However, the timing of these operations may be altered considerably. The preceding operational flows have been offered for purposes of example and discussion. Substantial flexibility is provided by communication system10in that any suitable arrangements, chronologies, configurations, and timing mechanisms may be provided without departing from the teachings provided herein.