US20120281534A1

US20120281534A1 - Variable aaa load distribution for pdsn

Info

Publication number: US20120281534A1
Application number: US13/553,660
Authority: US
Inventors: Terry Sullivan; Carlos A. Cazanas; Azam Khan
Original assignee: Cellco Partnership
Current assignee: Cellco Partnership
Priority date: 2009-10-02
Filing date: 2012-07-19
Publication date: 2012-11-08
Also published as: US8301735B1

Abstract

A packet data serving node (PDSN) manages sessions between mobile devices and a packet-based network. The PDSN sends requests to and receives responses from an authentication, authorization, and accounting (AAA) server. The PDSN includes a packet session manager configured to create, maintain, and terminate the sessions between mobile devices and the packet-based network. The PDSN also includes a global AAA manager configured to determine latency in communication between the PDSN and the AAA server based on latencies of responses to at least two requests which the PDSN sends to the AAA server. The global AAA manager determines an adjustment in a load which may be imposed on the AAA sever based on the determined latency and causes the determined adjustment in the load which may be imposed on the AAA server to be implemented.

Description

RELATED APPLICATION

This application is a continuation of and claims the benefit of U.S. application Ser. No. 12/572,662 entitled “VARIABLE AAA LOAD DISTRIBUTION FOR PDSN” filed Oct. 2, 2009, the disclosure of which also is entirely incorporated herein by reference.

BACKGROUND

Wireless communication systems may enable one or more mobile stations to communicate with various services through one or more packet-based networks, such as the internet. To facilitate these communications, a packet data serving node (PDSN) may be configured to function as a gateway between one or more of the wireless mobile stations and one or more of the packet-based networks.
The PDSN may seek to authenticate a wireless mobile station, to verify its authorization to communicate over the packet-based network, and/or to account for that communication. A server commonly known as an authentication, authorization, and accounting (AAA) server may be used by the PDSN to facilitate these functions. The PDSN may send requests to the AAA server seeking authentication, authorization, and/or accounting services, and the AAA server may send responses back to the PDSN.
A PDSN may need to process thousands of communications with an AAA server each second. To facilitate this throughput, the PDSN may delegate the responsibility for managing small groups of these communications to a subsystem commonly known as an AAA manager (referred to herein as a “sub-AAA manager”). A single PDSN may have over one hundred such sub-AAA managers which may all operate at approximately the same time. A single AAA server, in turn, may be shared among numerous PDSNs. Thus, a single AAA server may receive tens of thousands of requests for authentication, authorization, and/or accountings services each second.
Problems may arise with the AAA server and/or the communication system between the AAA server and the PDSN. Such problems may cause the sub-AAA manager not to receive a response to a request to an AAA server in a timely manner. If a response is not received by a sub-AAA manager within a pre-determined time, the sub-AAA manager may resend the request to the AAA server. If a response is repeatedly not received by the sub-AAA manager within the pre-determined time, the sub-AAA manager may redirect future requests to a secondary AAA server.
Delays encountered by one sub-AAA manager may be encountered by all of the AAA managers at about the same time. Thus, when an unacceptable delay occurs in connection with a request being sent by one sub-AAA manager, all of the sub-AAA managers may incur the same unacceptable delay. In turn, this may cause all of the sub-AAA managers to resend their requests. This may cause the AAA server to be even further overloaded. This may further slow the responses from the AAA server, causing even more requests to be resent. The AAA server may very quickly become overloaded with more requests than it can handle. This may seriously degrade the performance of the AAA server and may cause it to shut down.

BRIEF DESCRIPTION OF DRAWINGS

The drawings disclose illustrative embodiments. They do not set forth all embodiments. Other embodiments may be used in addition or instead. Details that may be apparent or unnecessary may be omitted to save space or for more effective illustration. Conversely, some embodiments may be practiced without all of the details that are disclosed. When the same numeral appears in different drawings, it is intended to refer to the same or like components or steps.

FIG. 1 illustrates an example mobile communication network which provides packet data communications.

FIG. 2 illustrates an example packet data serving node (PDSN) which automatically regulates a load it imposes on an authentication, authorization, and accounting (AAA) server.

FIG. 3 is a flow diagram of an example load adjustment process for the automatic regulation of a load imposed by a PDSN on an AAA server.

FIG. 4 is a table of example latency and corresponding shedding values.

FIG. 5 is a graph of an example latency problem in responses from an AAA server to requests from a PDSN which is not addressed with load adjustments of the type described herein.

FIG. 6 is a graph of an example latency problem in responses from an AAA server to requests from a PDSN which is addressed with load adjustments of the type described herein.

FIG. 7 is a table of example load adjustment parameters for the automatic regulation of a load imposed by a PDSN on an AAA server.

DETAILED DESCRIPTION

Illustrative embodiments are now discussed. Other embodiments may be used in addition or instead. Details that may be apparent or unnecessary may be omitted to save space or for a more effective presentation. Conversely, some embodiments may be practiced without all of the details that are disclosed.
FIG. 1 illustrates an example mobile communication network which provides packet data communications. As illustrated in FIG. 1, one or more mobile stations, such as mobile stations 101 and 103, may communicate wirelessly with a radio access network 105.
Each mobile station may be of any type. For example, each mobile station may consist of or include a cell phone, a laptop with an aircard, a portable multimedia device, such as a smart phone, and/or a messaging device.
The radio access network 105 may be configured to implement radio access technology. It may be configured to facilitate communication between each of the mobile stations, such as the mobile stations 101 and 103, and a wireless service provider network (not shown in FIG. 1). There may be additional mobile stations.
The radio access network 105 may communicate with one or more packet data serving nodes (PDSNs), such as a PDSN 107. Each PDSN may be configured to function as a gateway between one or more of the mobile stations and a packet-based network, such as an IP network 109. Each PDSN may be configured to manage sessions between one or more of the mobile stations and the packet-based network. Each session may include communications between a mobile station and one or more IP services that are part of the IP network, such as IP services 111 and 113. Each IP service may provide information to and/or receive information from a mobile station. An IP service may include, for example, a web site, an email server, and/or a source of streaming multi-media.
The PDSN may function as a foreign agent (FA), a home agent (HA), and/or in any other capacity. Data packets that are communicated between each mobile station and an IP service may flow through the PDSN.
As indicated in the Description of Related Art above, the PDSN may seek to authenticate a mobile station, to verify its authorization to communicate with the IP network 109, and/or to account for the utilization of the IP network. To facilitate this, and as also explained above, one or more authentication, authorization, and accounting (AAA) servers may be provided, such as AAA servers 115 and 117. There may be additional AAA servers.
Each AAA server may be configured to receive requests from a PDSN for authentication, authorization, and/or accounting services and to provide appropriate responses. Each PDSN may be configured to communicate with a primary AAA server and, in the event of a problem, with a secondary AAA server. Although not shown in FIG. 1, many PDSNs may be configured to communicate with the same primary and/or secondary AAA server.
Each PDSN may be configured to communicate with an AAA server through any means. This means may consist of or include a wired and/or wireless network, such as a local area network, a wide area network, and/or the internet.
FIG. 2 illustrates an example PDSN which automatically regulates a load it imposes on an AAA server. The PDSN illustrated in FIG. 2 may be used as the PDSN 107 illustrated in FIG. 1 or in any other type of mobile communication network. A PDSN other than of the type illustrated in FIG. 2 may instead be used as the PDSN 107 illustrated in FIG. 1.
As illustrated in FIG. 2, the PDSN may include a packet session manager 201. The packet session manager may be configured to create, maintain, and/or to terminate sessions between mobile stations that are communicating with the PDSN and a packet-based network. The packet session manager 201 may be configured to assign a dynamic IP address to each mobile station during a session. The packet session manager 201 may be configured to provide other services.
The PDSN may include a plurality of sub-AAA managers, such as sub-AAA managers 203, 205, and 207. Although only three sub-AAA managers are illustrated in FIG. 2, the PDSN may, in fact, have a much larger number of sub-AAA managers, such as in excess of 100.
Each sub-AAA manager may be configured to manage a small number of communications between the PDSN and an AAA server. That small number, for example, may be in the range of 1-5. Each sub-AAA manager may be configured to initiate requests to the AAA server for authentication, authorization, and/or accounting services at approximately the same time as such requests are being initiated by the other sub-AAA managers.
Each sub-AAA manager may be configured to process responses from the AAA server which are received to requests which the sub-AAA manager sends to the AAA server. As part of this management, each sub-AAA manager may be configured to store latency data. For example, sub-AAA managers 203, 205, and 207 may be configured to store latency data 209, 211, and 213, respectively.
The latency data may relate to how long it takes for the PDSN to receive a response from the AAA server to each request which the sub-AAA manager sends. The latency data may be of any type or in any form. For example, the time at which each sub-AAA manager sends each request to the AAA server may be recorded as the latency data or as part of that data. Upon receiving a response to a request, latency may be determined by subtracting the time when the request was made, as reflected by the latency data, from the time the response was received. This latency determination may or may not be recorded as part of the latency data.
In another example, each outgoing request to an AAA server may be stamped with the time of its departure. The AAA server may, in turn, include this time stamp in its response. When the response is received, the latency in the communication with the AAA server may be determined by subtracting the time stamp of its departure that is included within the response from the time at which the response was received by the PDSN. This latency determination, the time stamp, and/or the time of receipt of the response at the PDSN may or may not be recorded as part of the latency data.
In some cases, a response from the AAA server may not be received in a timely manner. Indeed, a response may never be received. A timer for each outgoing request to an AAA server may be set within the PDSN to expire within a pre-determined time after the issuance of the request. If a response is not received from the AAA server within that pre-determined time, the request may be treated by the PDSN as nevertheless having received a response from the AAA server with a pre-determined latency.
For example, a time may be set for a pre-determined time of 1.5 or 1.75 seconds. If no response to a request is received within this time, a response may nevertheless be deemed to have been received with a pre-determined latency, such as a latency of 1.5 or 1.75 seconds. Although equal in this example, the pre-determined latency need not be the same as the period of the timer. Again, this deemed latency may or may not be stored as part of latency data.
The PDSN may include a global AAA manager 215. The global AAA manager 215 may be configured to perform a variety of functions. Examples of these will now be discussed in connection with FIG. 3, which is a flow diagram of an example load adjustment process for the automated regulation of a load imposed by a PDSN on an AAA server.
The global AAA manager 215 may be configured to determine an AAA server latency, as reflected in a Determine AAA Server Latency step 301. The global AAA manager 215 may be configured to determine this latency using any method. For example, the global AAA manager 215 may be configured to request and receive reports from each of the sub-AAA managers, such as the sub-AAA managers 203, 205, and 207, about latencies in responses from the AAA server which are being experienced by each of the sub-AAA managers. The latency data may contain this information in whole or in part. This information may instead be delivered to the global AAA manager 215 without a request from the global AAA manager for it.
The latency information which is delivered to the global AAA manager 215 may be of any type. For example, the latency information may include information about some, but not necessarily all of the latencies which each sub-AAA manager is experiencing. In another example, all of the latency information about all of the sub-AAA managers may be provided to the global AAA manager 215. In a still further example, latency information from only some or even only one of the sub-AAA managers may be provided.
The history covered by the latency data which is sent to the global AAA manager 215 may vary. In one example, only latency data concerning the very latest request or set of requests which were handled by a sub-AAA manager may be sent. In another example, a longer latency history may be sent.
In still other examples, the global AAA manager 215 may be configured to determine and/or acquire latency information itself and/or from some other sub-system.
The global AAA manager 215 may be configured to determine the latency in communication between the PDSN and the AAA server based on any function which is applied to the latency data which it receives. For example, the global AAA manager 215 may be configured to determine the latency in communication between the PDSN and the AAA server by calculating an average value of all of the individual request/response latency data. A calculation of a mean may instead be made. The latency data which is used in this calculation may vary. For example, it may include only the most recent latency data which is received, or it may include a longer history of latency data. Different weights may be assigned to the latency data based on its age. For example, more recent latency data may be given more weight than older latency data. Aberrations in the latency data may be included in the computation or ignored.
The global AAA manager 215 may be configured to determine an adjustment in a load which may be imposed on the AAA server by the PDSN, as reflected by a Determine Adjustment In Load On AAA Server step 303. During this step, the global AAA manager 215 may be configured to determine whether the latency which it calculated during step 301 justifies a change in the load which the PDSN is imposing on the AAA server and, if so, the amount of an adjustment which should be made.
The global AAA manager 215 may be configured to make this adjustment determination based on a single latest latency determination, such as the latest latency determination, or based on a number of latency determinations. If multiple latency determinations are used, they may be weighted equally or differently.
The global AAA manager 215 may be configured to cause the determined adjustment in the load on the AAA server to be implemented, as reflected by an Implement Load Adjustment on AAA Server step 305. During this step, for example, the global AAA manager 215 may direct one, some, or all of the sub-AAA managers, such as the sub-AAA managers 203, 205, and/or 207, to shed all future requests to a secondary AAA server, thus lightening the load on the primary AAA server. The global AAA manager 215 may be configured to instead direct one, some, or all of the sub-AAA managers to shed only a portion of their future requests to a secondary AAA server. The global AAA manager 215 may be configured so as to cause the totality of the requests which are being sent to the primary AAA server to thereby be adjusted in accordance with the adjustment that was determined in step 303.
The global AAA manager 215 may be configured to determine the adjustment in step 303 based on a function of the latency determined in step 301. Any functional relationship may be used. The functional relationship may or may not be linear and/or continuous.
For example, the global AAA manager 215 may be configured to adjust the load on the AAA server in discrete steps. The taking of each step may depend upon whether the determined latency reaches or falls below a threshold value for each step. Several thresholds may be used. When a set of thresholds is used, the set may include or consist of a maximum determined latency and a sub-set of lower thresholds which represent different percentages of this maximum.
FIG. 4 is a table of example latency and corresponding shedding values. It is an example of the discrete steps approach discussed above. The left column of FIG. 4 illustrates latency values as a percentage of a maximum latency value. The right column illustrates the corresponding adjustment determination, e.g., the percentage of requests which the global AAA manager 215 may be configured to cause the sub-AAA managers to collectively shed as a result.
For example, if the determined latency is below 15% of the maximum specified latency, the global AAA manager 215 may be configured not to cause the sub-AAA managers to shed any portion of their requests to the primary AAA server. When the latency reaches 15% of the maximum, the global AAA manager 215 may be configured to cause the sub-AAA managers to collectively shed 10% of their requests to a secondary AAA server. Each time the latency reaches a higher level, the global AAA manager 215 may be configured to cause the sub-AAA managers to collectively shed a greater portion of their requests to the secondary AAA server. If the determined latency reaches 100% of the maximum value, the global AAA manager 215 may be configured to cause the sub-AAA managers to collectively shed 100% of their requests to the secondary AAA server, i.e., all of their future requests.
As also reflected in FIG. 4, the percentage of shedding need not match the percentage of the maximum latency. Further, the relationship between changes in the determined latency and changes in the shedding need not be linear. This is also illustrated in FIG. 4 by the fact that a 15% increase in the latency from 15% to 30% results in a 15% increase in the shedding, but that a 15% increase in the latency from 30% to 45% results in a 20% increase in the shedding.
The global AAA manager 215 may instead be configured to calculate the shedding as a continuous function of the determined latency based on a formula. Again, the relationship between changes in the determined latency and changes in the determined shedding may or may not be linear.
During the implement load adjustment step 305, the global AAA manager 215 may be configured to compare the amount of shedding which is currently taking place (due to an earlier computation and adjustment) with the amount of shedding which it has most recently determined should take place. If the current amount is less than the determined amount, the global AAA manager 215 may be configured to determine and implement an upward adjustment in the shedding. Conversely, if the current shedding level is above the needed amount, the global AAA manager 215 may be configured to determine and implement a downward adjustment in the amount of shedding.
The net effect of these configurations and operations may be to protect an AAA server from an overload and to improve the overall performance of a PDSN. This may be accomplished by making gradual downward or upward changes in the load which the PDSN imposes upon the AAA server. The amount of these changes may vary in degree continuously or in discrete steps. The degree of the changes may be based on an average or other type of collective assessment of latencies in responses to individual requests to the AAA server from the sub-AAA managers.
FIG. 5 is a graph of an example latency problem in responses from an AAA server to requests from a PDSN which is not addressed with load adjustments of the type described herein. The X axis represents time, and the Y axis represents percentages of a maximum permissible latency. As illustrated in FIG. 5, the collective latency 501 in these responses can rapidly grow. This can ultimately cause a shut down of the AAA server.
Latency thresholds 503, 505, 507, 509, and 511 are included in FIG. 5 as an example of a set of stepped-latency thresholds that may be employed, although no load adjustments are shown in FIG. 5 as being made in connection with them. They are illustrated as having the same values as set forth in the table in FIG. 4. Of course, there may be a different number of thresholds, they may have different values, and a continuous function may instead be used.
FIG. 6 is a graph of an example latency problem in responses from an AAA server to requests from a PDSN which is addressed with load adjustments of the type described herein. The X axis represents time, the Y axis represents percentages of a maximum pre-determined latency, a solid line 601 illustrates determined latencies, and a dotted line 603 illustrates determined adjustments. As illustrated in FIG. 5, the latency and responses from an AAA server at an initial time may be below a first 15% threshold. The global AAA manager 215 may be configured to provide no adjustment in the shedding when the determined latency is this low. The determined latency may then rise until it reached the first 15% level at a time 603. The global AAA manager 215 may then cause the PDSN to shed 10% of its request to a secondary AAA server. This may reduce the rate of latency increases. However, it may not be enough to prevent the latency from continuing to rise. Thus, the determined latency may reach the second 30% latency threshold at a time 605. The global AAA manager 215 may then cause the shedding to increase to 25%. This may further reduce the rate of latency increases until it ultimately stabilizes at a time 607. Later, the latency may begin to decline at a time 609 due to a falloff in requests and/or for other reasons until it falls back at a time 611 to the 30% latency threshold. At this point, the global AAA manager 215 may cut back the shedding to the 10% level.
Although changes in the shedding have thus-far been illustrated as being in discrete steps, the changes in the shedding may instead be implemented on a continuous basis, rather than in discrete steps. When implemented in steps, moreover, the amounts between each step and the number of steps may be different.
Returning to FIG. 3, the global AAA manager 215 may be configured to issue an alert in response to each incremental increase and/or each incremental decrease in the shedding, as reflected by an Issue Alert if Problem step 307. During this step, the global AAA manager 215 may cause an alert to be issued to persons and/or systems responsible for the PDSN and/or the AAA servers. These persons may then take other steps to reduce the latencies and/or to minimize their consequences. Although having been described as being issued after each incremental increase and/or decrease in the shedding, the global AAA manager 215 may be configured to issue a lesser number of alerts, such as only when the determined latency is at a level which threatens to bring down the AAA server or has returned to a certain prior level or an operational state.
The alerts may be sent using any means and in any form. For example, the alerts may be sent via SNMP to a centralized SNMP management station which may be configured to receive alerts from several PDSNs. Each alert may begin with an O.I.D. code which is indicative of the nature of the alert. Each alert may be followed by an O.I.D. code which contains additional information about the alert, such as the percentage of sub-AAA managers within the PDSN that have been moved to a secondary AAA server and/or the percentage of requests from the PDSN which are being redirected to a secondary AAA server.
The centralized SNMP management station may be configured to poll the PDSNs for any or all of this AAA load status information by delivering requests to them for this information. This polling may be done on a periodic or other basis. The PDSNs may be configured to respond by delivering the requested status information to the SNMP management station.
The centralized SNMP management station may be configured to analyze the alerts and/or responses to polling requests from the PDSNs and to generate reports that will aid in making configuration and/or other changes that may improve the overall performance of the system.
The global AAA manager 215 may be configured to wait after each load adjustment cycle, as reflected by a Wait step 309. The amount of this wait may relate to a desired frequency at which the global AAA manager 215 should be making adjustments. Increasing the frequency of these adjustments beyond a certain amount may not improve performance, while it may utilize valuable processing time. If the period is too long, on the other hand, the global AAA manager may not act quickly enough to prevent a shut down of the primary AAA server.
Various parameters relating to the load adjustment process may be received from an operator or another source and stored in a memory, as reflected by load adjustment parameters memory 217 in FIG. 2. A broad variety of such parameters may be received and stored.
FIG. 7 is a table of example load adjustment parameters for the automatic regulation of a load imposed by a PDSN on an AAA server. As reflected in FIG. 7, one load adjustment parameter may be a Sample Period. This period may govern the frequency at which the global AAA manager 215 determines latency and makes associated load adjustments. This period may be used as the period of the Wait step 309 in FIG. 3.
As also reflected in FIG. 7, another parameter may be a Maximum Latency. This parameter may reflect the maximum determined latency beyond which all requests from the PDSN should be shed to a secondary AAA server. This Maximum Latency parameter may be used in the computation of the various latency thresholds which have been described above. These thresholds may be automatically calculated by equating them with pre-determined percentages of the Maximum Latency parameter, such as 15%, 30%, 45%, 60%, and 100%, as illustrated in FIG. 4. Alternatively, the value of each threshold may be the subject of a separate parameter in the load adjustment parameters table.
A still further parameter may be a Time Out parameter. This parameter may specify the maximum amount of time which each sub-AAA manager should wait to receive a response to a request. If this time is exceeded, the sub-AAA manager may be configured to deem the PDSN to have received a response from the AAA server at the end of the timed-out period or at any other time. The occurrence of a time-out may also be used by one or more of the sub-AAA managers as a trigger to resend the request to the primary AAA server. If a response is not received within the time-out period after a pre-determined number of attempts, the sub-AAA manager may be configured on its own to redirect all further requests to a secondary AAA server.
Each of the various systems, devices, components, elements, and blocks which have been illustrated in FIGS. 1 and 2 and discussed above may be implemented with computer hardware or a combination of computer hardware and computer software. The computer hardware may include one or more processors, memory devices, storage devices (such as hard disk drives, RAMS, and/or PROMS), and/or user interface devices (such as one or more keyboards, mice, and/or displays). When including software, the software may include computer-readable instructions coded to implement one, some, or all of the functions which are recited in connection with each component, element, or block. For example, the packet session manager 201, global AAA manager 215, and each of the sub-AAA managers may be implemented by specific configurations of hardware and software algorithms, each of which is configured to implement one or more of the functions of these components which have been described herein. All or portions of the software may be stored on computer-readable storage media, such as one or more hard disk drives, CD's, DVD's, flash memories, and/or PROMS.
The components, steps, features, objects, benefits and advantages that have been discussed are merely illustrative. None of them, nor the discussions relating to them, are intended to limit the scope of protection in any way. Numerous other embodiments are also contemplated. These include embodiments that have fewer, additional, and/or different components, steps, features, objects, benefits and advantages. These also include embodiments in which the components and/or steps are arranged and/or ordered differently.
For example, a PDSN may be configured to shed requests from a secondary AAA server to a tertiary AAA server if there are problematic latencies in the communications with the secondary AAA server. The shedding may be performed in the same way and using the same equipment as has been described above in connection with shedding to a secondary AAA server. Additional back-up AAA servers may also be provided and the PDSN may be configured to successively shed to these as well, when needed.
Although the global AAA manager 215 has thus-far been described as determining AAA server latency based on a plurality of individual request/response latency reports, it may instead determine the latency based on only a single report.
Although having been discussed in connection with PDSNs and AAA servers, the load balancing systems and methods which have been described may be used in connection with other types of clients and servers.
Unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are set forth in this specification, including in the claims that follow, are approximate, not exact. They are intended to have a reasonable range that is consistent with the functions to which they relate and with what is customary in the art to which they pertain.
All articles, patents, patent applications, and other publications which have been cited in this disclosure are hereby incorporated herein by reference.
The phrase “means for” when used in a claim is intended to and should be interpreted to embrace the corresponding structures and materials that have been described and their equivalents. Similarly, the phrase “step for” when used in a claim embraces the corresponding acts that have been described and their equivalents. The absence of these phrases means that the claim is not intended to and should not be interpreted to be limited to any of the corresponding structures, materials, or acts or to their equivalents.
Nothing that has been stated or illustrated is intended or should be interpreted to cause a dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public, regardless of whether it is recited in the claims.
The scope of protection is limited solely by the claims that now follow. That scope is intended and should be interpreted to be as broad as is consistent with the ordinary meaning of the language that is used in the claims when interpreted in light of this specification and the prosecution history that follows and to encompass all structural and functional equivalents.

Claims

1. A method comprising steps of

managing through a packet data serving node (PDSN) packet communication sessions of mobile stations through a network, the managing step including:

(a) sending from the PDSN requests to an authentication, authorization, and accounting (AAA) server for authentication, authorization, and/or accounting services with regard to the packet communication sessions of the mobile stations, and

(b) receiving responses to the requests from the AAA server;

based on latencies of responses received from the AAA server, determining a latency in communication between the PDSN and the AAA server; and

adjusting number of requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to the AAA server based on the latency in communication between the PDSN and the AAA server.

2. The method of claim 1, wherein the adjusting step comprises directing a portion of future requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to an alternate AAA server, to reduce load on the AAA server.

3. The method of claim 1, wherein the adjusting step comprises directing a portion of future requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to the AAA server, instead of to an alternate AAA server, to increase load on the AAA server.

4. The method of claim 1, wherein the adjusting step is responsive to determination of a relationship of the latency in communication between the PDSN and the AAA server relative to one of a set of pre-determined latency threshold values.

5. The method of claim 4, wherein the adjusting step is responsive to the latency in communication between the PDSN and the AAA server reaching or exceeding the one threshold value.

6. The method of claim 5, wherein the adjusting step comprises directing a portion of future requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to an alternate AAA server, to reduce load on the AAA server, when the latency in communication between the PDSN and the AAA server reaches or exceeds the one threshold value.

7. The method of claim 4, wherein the adjusting step is responsive to the latency in communication between the PDSN and the AAA server falling to or below the one threshold value.

8. The method of claim 7, wherein the adjusting step comprises directing a portion of future requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to the AAA server, instead of to an alternate AAA server, to increase load on the AAA server, when the latency in communication between the PDSN and the AAA server falls to or below the one threshold value.

9. The method of claim 4, further comprising a step of adjusting the number of requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to the AAA server based on a relationship of the latency in communication between the PDSN and the AAA server relative to a different one of the pre-determined latency threshold values.

10. The method of claim 9, wherein the adjusting steps adjust the number of requests for authentication, authorization, and/or accounting services sent from the PDSN to the AAA server in discrete steps corresponding to successively higher ones of the pre-determined latency threshold values.

11. The method of claim 9, wherein:

for determined latency below a lowest of the pre-determined latency threshold values, there is no adjusting of requests authentication, authorization, and/or accounting services sent from the PDSN to the AAA server; and

as the adjusting steps correspond to successively higher ones of the pre-determined latency threshold values, the adjusting steps comprise directing successively higher portions of future requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to an alternate AAA server.

12. The method of claim 11, wherein successively higher portions are not proportional to successively higher ones of the pre-determined latency threshold values.

13. The method of claim 1, further comprising:

repeatedly performing the determining and adjusting steps; and

waiting an amount of time after each performance of the adjusting step before performing the subsequent determining step.

14. The method of claim 1, wherein the determining step comprises averaging the latencies of the responses received from the AAA server.

15. The method of claim 1, wherein the determining step comprises treating each request from the PDSN to which no response is received from the AAA server within a pre-determined time as a response from the AAA server with a pre-determined latency.

16. The method of claim 1, wherein the determining step comprises determining the latency in communication between the PDSN and the AAA server based on only most recent latency data for responses from the AAA server.

17. The method of claim 1, wherein the determining step comprises determining the latency in communication between the PDSN and the AAA server based on a history of latency data for responses from the AAA server.

18. The method of claim 17, wherein the determining step involves differently weighting of latency data from the history based on respectively different age of the latency data.

19. The method of claim 18, wherein more recent latency data is weighted more heavily than older latency data from the history.

20. A packet data serving node (PDSN), comprising:

a processor;

a storage device; and

coded instructions for the processor, in the storage device,

wherein the coded instructions configure the PDSN to implement functions, including functions to:

manage packet communication sessions of mobile stations through a network, including to:

(a) send from the PDSN requests to an authentication, authorization, and accounting (AAA) server for authentication, authorization, and/or accounting services with regard to the packet communication sessions of the mobile stations, and

(b) receive responses to the requests from the AAA server;

based on latencies of responses received from the AAA server, determine a latency in communication between the PDSN and the AAA server; and

adjust number of requests for authentication, authorization, and/or accounting services with regard to the packet communication sessions sent from the PDSN to the AAA server based on the latency in communication between the PDSN and the AAA server.

21. A system, comprising:

a radio communication network;

a packet data serving node (PDSN), comprising a processor and a memory device, configured to manage sessions of mobile devices through the radio communication network for communication with a packet-based network; and

first and second authentication, authorization, and accounting (AAA) servers,

wherein the PDSN is further configured to:

send requests to the first and second AAA servers for authentication, authorization, and/or accounting services with regard to the packet communication sessions of the mobile stations;

receive responses to the requests from the first and second AAA servers;

based on latencies of responses received from the first AAA server, determine a latency in communication between the PDSN and the first AAA server; and

adjust number of the requests sent to the first AAA server and number of the requests sent to the second AAA server, based on the latency in communication between the PDSN and the AAA server.